This is just refactoring work here. The old logic was kind of
convoluted, especially after the bug 5572 fix. We don't actually need to
distinguish so many cases here. Dropping detection of the
"!old_options || !old_options->DynamicDHGroups" case is fine because
that's the same that we'd do for clients.
Also add a changes file for bug 5572.
The message only means that we're publishing a new descriptor when we
are actually in some kind of server mode, and publication is on.
Fix for bug 3942; bugfix on 0.2.3.2-alpha.
This fixes a side-channel attack on the (fortunately unused!)
BridgePassword option for bridge authorities. Fix for bug 5543;
bugfix on 0.2.0.14-alpha.
This is ticket 2479. Roger's original explanation was:
We have a series of bugs where relays publish a descriptor within
12 hours of their last descriptor, but the authorities drop it
because it's not different "enough" from the last one and it's
too close to the last one.
The original goal of this idea was to a) reduce the number of new
descriptors authorities accept (and thus have to store) and b)
reduce the total number of descriptors that clients and mirrors
fetch. It's a defense against bugs where relays publish a new
descriptor every minute.
Now that we're putting out one consensus per hour, we're doing
better at the total damage that can be caused by 'b'.
There are broader-scale design changes that would help here, and
we've had a trac entry open for years about how relays should
recognize that they're not in the consensus, or recognize when
their publish failed, and republish sooner.
In the mean time, I think we should change some of the parameters
to make the problem less painful.
When we started RefuseUnknownExits back in 0.2.2.11-alpha, we
started making exits act like they cache directory info (since they
need an up-to-date idea of who is really a router). But this
included fetching needless (unrecognized) authorities' certs, which
doesn't make any sense for them.
This is related to, but not necessarily the same as, the issue that
Ian reported for bug #2297.
(This patch is based on a patch from a user who I believe has asked
not to be named. If I'm wrong about that, please add the
appropriate name onto the changelog.)
==
Nick here. I tweaked this patch a little to make it apply cleanly to
master, to extract some common code into a function, and to replace
snprintf with tor_snprintf.
-- nickm
Specifically, it was a fix on 33e2053ebc, where we introduced the
WRA_* and ROUTER_* codes for dirserv_add_descriptor. Previously, we
had checked for a _negative_ return from dirserv_add_descriptor, which
meant "rejected". An insufficiently new descriptor would give a
0-valued return. But when we switched from numbers to enums, we got
this check wrong and had init_keys() give an error whenever the
descriptor wasn't accepted.