Authorities don't set is_possible_guard on node_t, so they were
never deciding that they could build enough paths.  This is a quick
and dirty fix.

Bug not in any released version of Tor

These seem to have gotten conflicted out of existence while mike was
working on path bias stuff.

Thanks to sysrqb for collecting these in a handy patch.

It appears that the code for 7291 gave an unused-value warning when
built with --disable-curve25519.

The fix is to move the two functions to format/parse base64
curve25519 public keys into a new "crypto_format.c" file.  I could
have put them in crypto.c, but that's a big file worth splitting
anyway.

Fixes bug 8153; bugfix on 0.2.4.8-alpha where I did the fix for 7869.

When we first implemented TLS, we assumed in conneciton_handle_write
that a TOR_TLS_WANT_WRITE from flush_buf_tls meant that nothing had
been written. But when we moved our buffers to a ring buffer
implementation back in 0.1.0.5-rc (!), we broke that invariant: it's
possible that some bytes have been written but nothing.

That's bad.  It means that if we do a sequence of TLS writes that ends
with a WANTWRITE, we don't notice that we flushed any bytes, and we
don't (I think) decrement buckets.

Fixes bug 7708; bugfix on 0.1.0.5-rc

Mike Perry authored 12 years ago and Nick Mathewson committed 12 years ago

This informational counter is probably now redundant, but might as well keep
it consistent I guess.

Mike Perry authored 12 years ago and Nick Mathewson committed 12 years ago

It had nothing to do with circuit build times.

Mike Perry authored 12 years ago and Nick Mathewson committed 12 years ago

The other remaining parameters don't really need range checks.

Mike Perry authored 12 years ago and Nick Mathewson committed 12 years ago

Also document it better.

Mention this refactoring in the comments for the path state machine.

Mike Perry authored 12 years ago and Nick Mathewson committed 12 years ago

Also, deprecate the torrc options for the scaling values. It's unlikely anyone
but developers will ever tweak them, even if we provided a single ratio value.

Improve the log message when "Bug/attack: unexpected sendme cell
from client" occurs.

This is the non-automated portion of bug 7599.

This is meant to avoid conflict with the built-in log() function in
math.h.  It resolves ticket 7599.  First reported by dhill.

This was generated with the following perl script:

 #!/usr/bin/perl -w -i -p

 s/\blog\(LOG_(ERR|WARN|NOTICE|INFO|DEBUG)\s*,\s*/log_\L$1\(/g;

 s/\blog\(/tor_log\(/g;

Cosmetic tweak on 5956; not in any released tor.

Instead of hardcoding the minimum fraction of possible paths to 0.6, we
take it from the user, and failing that from the consensus, and
failing that we fall back to 0.6.

Previously we did this based on the fraction of descriptors we
had. But really, we should be going based on what fraction of paths
we're able to build based on weighted bandwidth, since otherwise a
directory guard or two could make us behave quite oddly.

Implementation for feature 5956

This way we get the usable nodes themselves, so we can feed them into
frac_nodes_with_descriptors