Ensure we securely wipe keys from memory after
crypto_digest_get_digest and init_curve25519_keypair_from_file
have finished using them.
Fixes bug 13477.
Check all date/time values passed to tor_timegm
and parse_rfc1123_time for validity, taking leap
years into account.
Improves HTTP header validation.
Avoid unlikely signed integer overflow in tor_timegm
on systems with 32-bit time_t.
Fixes bug 13476.
Fix an instance of integer overflow in format_time_interval() when
taking the absolute value of the supplied signed interval value.
Fixes bug 13393.
Create unit tests for format_time_interval().
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.
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
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.
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 is another case where DJB likes sticking the whole signature
prepended to the message, and I don't think that's the hottest idea.
The unit tests still pass.
This reduces the likelihood that I have made any exploitable errors
in the encoding/decoding.
This commit also imports the trunnel runtime source into Tor.
Uses libscrypt when found; otherwise, we don't have scrypt and we
only support openpgp rfc2440 s2k hashing, or pbkdf2.
Includes documentation and unit tests; coverage around 95%. Remaining
uncovered code is sanity-checks that shouldn't be reachable fwict.
Since address.c is the first file to get compiled, let's have it use
a little judicious c99 in order to catch broken compilers that
somehow make it past our autoconf tests.
"The NULL pointer warnings on the return value of
tor_addr_to_in6_addr32() are incorrect. But clang can't work this
out itself due to limited analysis depth. To teach the analyser that
the return value is safe to dereference, I applied tor_assert to the
return value."
Patch from teor. Part of 13157.
(And replay them once we know our first real logs.)
This is an implementation for issue 6938. It solves the problem of
early log mesages not getting sent to log files, but not the issue of
early log messages not getting sent to controllers.
