Fortunately, the arithmetic cannot actually overflow, so long as we
*always* check for the size of potentially hostile input before
copying it.  I think we do, though.  We do check each line against
MAX_LINE_LENGTH, and each object name or object against
MAX_UNPARSED_OBJECT_SIZE, both of which are 128k.  So to get this
overflow, we need to have our memarea allocated way way too high up
in RAM, which most allocators won't actually do.

Bugfix on 0.2.1.1-alpha, where memarea was introduced.

Found by Guido Vranken.

Now that the field exists in signed_descriptor_t, we need to make
sure we free it when we free a signed_descriptor_t, and we need to
make sure that we don't free it when we convert a routerinfo_t to a
signed_descriptor_t.

But not in any released Tor. I found this while working on #19128.

One problem: I don't see how this could cause 19128.

No behaviour change - just remove the variables

Comment-only change

teor (Tim Wilson-Brown) authored 8 years ago and Nick Mathewson committed 8 years ago

No behaviour change

This function is used twice. The code is simpler if we split
it up and inline it where it is used.

teor (Tim Wilson-Brown) authored 8 years ago and Nick Mathewson committed 8 years ago

Previosuly, during bootstrap, we would continue to download
consensuses if we had a consensus, but didn't have the certificates
to validate it.

With the fix for #17150, I added a duplicate certificate here.  Here
I remove the original location in 0.2.8.  (I wouldn't want to do
that in 027, due to the amount of authority-voting-related code
drift.)

Closes 19073.

This API change makes it so that routerinfo_incompatible...() no
longer takes a routerinfo_t, so that it's obvious that it should
only look at fields from the signed_descriptor_t.

This change should prevent a recurrence of #17150.

We need to make sure that the corresponding sd and ei match in their
certificates.

We need this field to be in signed_descriptor_t so that
routerinfo_incompatible_with_extrainfo can work correctly (#17150).
But I don't want to move it completely in this patch, since a great
deal of the code that messes with it has been in flux since 0.2.7,
when this ticket was opened.  I should open another ticket about
removing the field from routerinfo_t and extrainfo_t later on.

This patch fixes no actual behavior.

The routerinfo we pass to routerinfo_incompatible_with_extrainfo is
the latest routerinfo for the relay.  The signed_descriptor_t, on
the other hand, is the signed_descriptor_t that corresponds to the
extrainfo.  That means we should be checking the digest256 match
with that signed_descriptor_t, not with the routerinfo.

Fixes bug 17150 (and 19017); bugfix on 0.2.7.2-alpha.

This patch includes no semantic changes; it's just a field movement.

It's prerequisite for a fix to 19017/17150.

no behavior changes

Had conflicts related to other correct_tm bugs in 0.2.6.  Added wday
for another case.

The tm_wday field had been left uninitialized, which was causing
some assertions to fail on Windows unit tests.

Fixes bug 18977.