Work on style, add some sentences to blurb, explain that 10468 is more
general than had been described, etc etc

Probably releasing within ~22 hours, pending testing

Otherwise we'll never remember what to re-run before each release, or
whether we tried a given checker.

When I merged the fix for #7351, and implemented proposal 214 (4-byte
circuit IDs), I forgot to add a changes file.  Later, we never noticed
that it didn't have one.

Resolves ticket #11555.  Thanks to cypherpunks for noticing this was
missing.

This is a cherry-pick of 75e10f58 into
the master branch.

Also, add a script to do this, since doing it manually with fmt sucks.

Conflicts:
	src/or/main.c

That is, GETINFO limits/max-mem-in-queues

If we can't detect the physical memory, the new default is 8 GB on
64-bit architectures, and 1 GB on 32-bit architectures.

If we *can* detect the physical memory, the new default is
  CLAMP(256 MB, phys_mem * 0.75, MAX_DFLT)
where MAX_DFLT is 8 GB on 64-bit architectures and 2 GB on 32-bit
architectures.

You can still override the default by hand.  The logic here is simply
trying to choose a lower default value on systems with less than 12 GB
of physical RAM.

Conflicts:
	src/or/circuitbuild.c

Use a per-channel ratelim_t to control the rate at which we report
failures for each channel.

Explain why I picked N=32.

Never return a zero circID.

Thanks to Andrea and to cypherpunks.

George Kadianakis authored 10 years ago and Nick Mathewson committed 10 years ago

Make it clear that a SIGHUP is not the only action that can cause a
config re-read.

George Kadianakis authored 10 years ago and Nick Mathewson committed 10 years ago

Since we need to toggle that element in non-SIGHUP situations too where
the config was re-read (like in SETCONF or RESETCONF).

George Kadianakis authored 10 years ago and Nick Mathewson committed 10 years ago

Instead, figure out if we should restart PT proxies _immediately_ after
we re-read the config file.

This is an "ours" merge, to avoid taking the 0.2.4 version of the

Conflicts:
	src/or/entrynodes.c

The memarea_strndup() function would have hit undefined behavior by
creating an 'end' pointer off the end of a string if it had ever been
given an 'n' argument bigger than the length of the memory ares that
it's scanning.  Fortunately, we never did that except in the unit
tests.  But it's not a safe behavior to leave lying around.

If we had an address of the form "1.2.3.4" and we tried to pass it to
tor_inet_pton with AF_INET6, it was possible for our 'eow' pointer to
briefly move backwards to the point before the start of the string,
before we moved it right back to the start of the string.  C doesn't
allow that, and though we haven't yet hit a compiler that decided to
nuke us in response, it's best to fix.

So, be more explicit about requiring there to be a : before any IPv4
address part of the IPv6 address.  We would have rejected addresses
without a : for not being IPv6 later on anyway.

Instead of taking the length of a buffer, we were taking the length of
a pointer, so that our debugging log would cover only the first
sizeof(void*) bytes of the client nonce.

We meant to using random bytes to fill a buffer, up to 3000 at a
time. Instead we were taking them sizeof(void*) at a time.

This is harmless, since tor-gencert exits right afterwards, but it's
best to clean up after ourselves.

scan-build didn't like the unlimited version since we might need to
overflow size_t to hexify a string that took up half our address
space. (!)