* FIXES #16823: https://bugs.torproject.org/16823
   If an OP were to send a CREATE_FAST cell to an OR, and that
   CREATE_FAST cell had unparseable key material, then tor_free() would
   be called on the create cell twice.  This fix removes the second
   (conditional on the key material being bad) call to tor_free(), so
   that now the create cell is always freed, regardless of the status of
   the key material.

David Goulet authored Aug 05, 2015 and Nick Mathewson committed Aug 11, 2015

Signed-off-by: David Goulet <dgoulet@ev0ke.net>

David Goulet authored Aug 05, 2015 and Nick Mathewson committed Aug 11, 2015

Signed-off-by: David Goulet <dgoulet@ev0ke.net>

David Goulet authored Jun 25, 2015 and Nick Mathewson committed Aug 11, 2015

Signed-off-by: David Goulet <dgoulet@ev0ke.net>

David Goulet authored Jun 25, 2015 and Nick Mathewson committed Aug 11, 2015

Safer, wiser, stronger!

Signed-off-by: David Goulet <dgoulet@ev0ke.net>

David Goulet authored Jun 25, 2015 and Nick Mathewson committed Aug 11, 2015

Signed-off-by: David Goulet <dgoulet@ev0ke.net>

David Goulet authored Jun 18, 2015 and Nick Mathewson committed Aug 11, 2015

When fetching a descriptor, we know test every introduction points in it
against our rend failure cache to know if we keep it or not. For this to
work, now everytime an introduction points is discareded (ex: receiving a
NACK), we note it down in our introduction cache.

See rendcache.c for a detailed explanation of the cache's behavior.

Fixes #16389

Signed-off-by: David Goulet <dgoulet@ev0ke.net>

When we removed Running/Valid checks from Fast and Stable in 8712, I
removed them from HSDir too, which apparently wasn't a good idea.

Reverts part of a65e8358.  Fixes bug 16524. Bugfix
on 0.2.7.2-alpha.

microdesc_free_() called get_microdesc_cache(), which had the fun
side-effect of potentially reloading the whole cache from disk.
Replace it with a variant that doesn't.

Closes ticket 16734.

If setrlimit() failed, max_out wasn't set in set_max_file_descriptors()
ending in a state where we don't use ULIMIT_BUFFER for things like tor
private key files.

Also fix the set_max_file_descriptors() documentation.

Fixes #16274

Signed-off-by: David Goulet <dgoulet@ev0ke.net>

cypherpunks authored Jul 23, 2015 and Nick Mathewson committed Aug 04, 2015

According to POSIX, the mutex must be locked by the thread calling the signal
functions to ensure predictable scheduling behavior.

Found the issue using Helgrind which gave the warning `dubious: associated lock
is not held by any thread`.

Previously, this required me to do stuff like
  'cp src/or/tor-cov src/or/tor' ,
which is pretty embarrassing.

The base64 and base32 functions used to be in crypto.c;
crypto_format.h had no header; some general-purpose functions were in
crypto_curve25519.c.

This patch makes a {crypto,util}_format.[ch], and puts more functions
there.  Small modules are beautiful!

Fixes 16286; bugfix on 0.2.7.2-alpha.

The control port was using set_max_file_descriptors() with a limit set to 0
to query the number of maximum socket Tor can use. With the recent changes
to that function, a check was introduced to make sure a user can not set a
value below the amount we reserved for non socket.

This commit adds get_max_sockets() that returns the value of max_sockets so
we can stop using that "setter" function to get the current value.

Finally, the dead code is removed that is the code that checked for limit
equal to 0. From now on, set_max_file_descriptors() should never be used
with a limit set to 0 for a valid use case.

Fixes #16697

Signed-off-by: David Goulet <dgoulet@ev0ke.net>

Doing this is no longer necessary, and it leads to weird recursions in
our call graph.  Closes ticket 16480.

This should make some scripts and IDEs happier.