Add the TestingDirAuthVoteExit option, a list of nodes to vote Exit for,
regardless of their uptime, bandwidth, or exit policy.

TestingTorNetwork must be set for this option to have any effect.

Works around an issue where authorities would take up to 35 minutes to
give nodes the Exit flag in a test network, despite short consensus
intervals. Partially implements ticket 13161.

Closes 11582; patch from "ra".

Fixes bug 13295; bugfix on 0.2.5.3-alpha.

The alternative here is to call crypto_global_init() from tor-resolve,
but let's avoid linking openssl into tor-resolve for as long as we
can.

teor authored 10 years ago and Nick Mathewson committed 10 years ago

When a spawned process forks, fails, then exits very quickly, (this
typically occurs when exec fails), there is a race condition between the
SIGCHLD handler updating the process_handle's fields, and checking the
process status in those fields. The update can occur before or after the
spawn tests check the process status.

We check whether the process is running or not running (rather than just
checking if it is running) to avoid this issue.

I'd prefer not to use the name "send" for any function that doesn't
really send things.

Generally, we don't like to parse the same thing over and over; it's
best IMO to do it once at the start of the code.

Patch from "chobe".  Closes ticket 961.

In circuit_build_times_calculate_timeout() in circuitstats.c, avoid dividing
by zero in the pareto calculations.

If either the alpha or p parameters are 0, we would divide by zero, yielding
an infinite result; which would be clamped to INT32_MAX anyway. So rather
than dividing by zero, we just skip the offending calculation(s), and
use INT32_MAX for the result.

Division by zero traps under clang -fsanitize=undefined-trap -fsanitize-undefined-trap-on-error.

Ensure test & bench code that references curve25519 is disabled by the
appropriate macros. tor now builds with and without --disable-curve25519.

teor authored 10 years ago and Nick Mathewson committed 10 years ago

Avoid 4 null pointer errors under clang shallow analysis (the default when
building under Xcode) by using tor_assert() to prove that the pointers
aren't null. Resolves issue 13284 via minor code refactoring.

teor authored 10 years ago and Nick Mathewson committed 10 years ago

Standardise usage in ge_scalarmult_base.c for 1 new fix.

This helps us avoid undefined behavior. It's based on a patch from teor,
except that I wrote a perl script to regenerate the patch:

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

  BEGIN { %vartypes = (); }

  if (/^[{}]/) {
      %vartypes = ();
  }

  if (/^ *crypto_int(\d+) +([a-zA-Z_][_a-zA-Z0-9]*)/) {
      $vartypes{$2} = $1;
  } elsif (/^ *(?:signed +)char +([a-zA-Z_][_a-zA-Z0-9]*)/) {
      $vartypes{$1} = '8';
  }

  # This fixes at most one shift per line. But that's all the code does.
  if (/([a-zA-Z_][a-zA-Z_0-9]*) *<< *(\d+)/) {
      $v = $1;
      if (exists $vartypes{$v}) {
  	s/$v *<< *(\d+)/SHL$vartypes{$v}($v,$1)/;
      }
  }

  # remove extra parenthesis
  s/\(SHL64\((.*)\)\)/SHL64\($1\)/;
  s/\(SHL32\((.*)\)\)/SHL32\($1\)/;
  s/\(SHL8\((.*)\)\)/SHL8\($1\)/;

teor authored 10 years ago and Nick Mathewson committed 10 years ago

The macros let us use unsigned types for potentially overflowing left
shifts. Create SHL32() and SHL64() and SHL8() macros for convenience.

Fixes CID 752028

This one should no longer generate dead-code warnings with coverity.
Fingers crossed?  This was CID 1241498

There are some loops of the form

       for (i=1;i<1;++i) ...

And of course, if the loop index is initialized to 1, it will never
be less than 1, and the loop body will never be executed.  This
upsets coverity.

Patch fixes CID 1221543 and 1221542

This bug shouldn't be reachable so long as secret_to_key_len and
secret_to_key_make_specifier stay in sync, but we might screw up
someday.

Found by coverity; this is CID 1241500

Bugfix on ed8f020e; bug not in any
released version of Tor.  Found by Coverity; this is CID 1239290.

[Yes, I used this commit message before, in 58e813d0.
Turns out, that fix wasn't right, since I didn't look up a
screen. :P ]

When size_t is the most memory you can have, make sure that things
referring to real parts of memory are size_t, not uint64_t or off_t.

But not on any released Tor.

Add some documentation

Rename "derive" -> "blind"

Check for failure on randombytes().

I know it's pointless to optimize them, but I just can't let them
spend all that time in expmod() when native python pow() does the same
thing.

Also, use it to generate test vectors, and add those test vectors
to test_crypto.c

This is based on ed25519.py from the ed25519 webpage; the kludgy hacks
are my own.

Our integer-definition headers apparently suck in a definition for
select(2), which interferes with the select() in ge_scalarmult_base.c

This implementation allows somebody to add a blinding factor to a
secret key, and a corresponding blinding factor to the public key.

Robert Ransom came up with this idea, I believe.  Nick Hopper proved a
scheme like this secure.  The bugs are my own.

For proposal 228, we need to cross-certify our identity with our
curve25519 key, so that we can prove at descriptor-generation time
that we own that key.  But how can we sign something with a key that
is only for doing Diffie-Hellman?  By converting it to the
corresponding ed25519 point.

See the ALL-CAPS warning in the documentation.  According to djb
(IIUC), it is safe to use these keys in the ways that ntor and prop228
are using them, but it might not be safe if we start providing crazy
oracle access.

(Unit tests included.  What kind of a monster do you take me for?)

This refactors the "== type:tag ==" code from crypto_curve25519.c

This will be needed/helpful for the key blinding of prop224, I
believe.