| Age | Commit message (Collapse) | Author |
|---|
|
Fixes Coverity CID 479.
|
|
George Kadianakis notes that if you give crypto_rand_int() a value
above INT_MAX, it can return a negative number, which is not what
the documentation would imply.
The simple solution is to assert that the input is in [1,INT_MAX+1].
If in the future we need a random-value function that can return
values up to UINT_MAX, we can add one.
Fixes bug 3306; bugfix on 0.2.2pre14.
|
|
When we added the check for key size, we required that the keys be
128 bytes. But RSA_size (which defers to BN_num_bytes) will return
128 for keys of length 1017..1024. This patch adds a new
crypto_pk_num_bits() that returns the actual number of significant
bits in the modulus, and uses that to enforce key sizes.
Also, credit the original bug3318 in the changes file.
|
|
Fixed trivial conflict due to headers moving into their own .h files
from or.h.
Conflicts:
src/or/or.h
|
|
Rename crypto_pk_check_key_public_exponent to crypto_pk_public_exponent_ok:
it's nice to name predicates s.t. you can tell how to interpret true
and false.
|
|
|
|
bug3122_memcmp_022
Conflicts throughout. All resolved in favor of taking HEAD and
adding tor_mem* or fast_mem* ops as appropriate.
src/common/Makefile.am
src/or/circuitbuild.c
src/or/directory.c
src/or/dirserv.c
src/or/dirvote.c
src/or/networkstatus.c
src/or/rendclient.c
src/or/rendservice.c
src/or/router.c
src/or/routerlist.c
src/or/routerparse.c
src/or/test.c
|
|
Here I looked at the results of the automated conversion and cleaned
them up as follows:
If there was a tor_memcmp or tor_memeq that was in fact "safe"[*] I
changed it to a fast_memcmp or fast_memeq.
Otherwise if there was a tor_memcmp that could turn into a
tor_memneq or tor_memeq, I converted it.
This wants close attention.
[*] I'm erring on the side of caution here, and leaving some things
as tor_memcmp that could in my opinion use the data-dependent
fast_memcmp variant.
|
|
This commit is _exactly_ the result of
perl -i -pe 's/\bmemcmp\(/tor_memcmp\(/g' src/*/*.[ch]
perl -i -pe 's/\!\s*tor_memcmp\(/tor_memeq\(/g' src/*/*.[ch]
perl -i -pe 's/0\s*==\s*tor_memcmp\(/tor_memeq\(/g' src/*/*.[ch]
perl -i -pe 's/0\s*!=\s*tor_memcmp\(/tor_memneq\(/g' src/*/*.[ch]
git checkout src/common/di_ops.[ch]
git checkout src/or/test.c
git checkout src/common/test.h
|
|
Conflicts:
src/common/torint.h
|
|
None of the comparisons were _broken_ previously, but avoiding
signed/unsigned comparisons makes everybody happier.
Fixes bug2475.
|
|
|
|
About 860 doxygen-less things remain in 0.2.2
|
|
Our regular DH parameters that we use for circuit and rendezvous
crypto are unchanged. This is yet another small step on the path of
protocol fingerprinting resistance.
(Backport from 0.2.2's 5ed73e3807d90dd0a3)
|
|
This bug was noticed by cypherpunks; fixes bug 2378.
Bugfix on svn commit r110.
|
|
|
|
|
|
Our regular DH parameters that we use for circuit and rendezvous
crypto are unchanged. This is yet another small step on the path of
protocol fingerprinting resistance.
|
|
|
|
Found by cypherpunks; fixes bug 2384.
|
|
Conflicts:
src/or/routerparse.c
src/or/test.c
|
|
|
|
Conflicts:
src/or/config.c
src/or/networkstatus.c
src/or/rendcommon.c
src/or/routerparse.c
src/or/test.c
|
|
mistake again
Our public key functions assumed that they were always writing into a
large enough buffer. In one case, they weren't.
(Incorporates fixes from sebastian)
|
|
I am not at all sure that it is possible to trigger a bug here,
but better safe than sorry.
|
|
|
|
Fixes bug 2331.
|
|
|
|
Conflicts:
src/common/test.h
src/or/test.c
|
|
|
|
|
|
Conflicts:
src/common/memarea.c
src/or/or.h
src/or/rendclient.c
|
|
It's all too easy in C to convert an unsigned value to a signed one,
which will (on all modern computers) give you a huge signed value. If
you have a size_t value of size greater than SSIZE_T_MAX, that is way
likelier to be an underflow than it is to be an actual request for
more than 2gb of memory in one go. (There's nothing in Tor that
should be trying to allocate >2gb chunks.)
|
|
On windows, it's called something different.
|
|
In a2bb0bf we started using a separate client identity key. When we are
in "public server mode" (that means not a bridge) we will use the same
key. Reusing the key without doing the proper refcounting leads to a
segfault on cleanup during shutdown. Fix that.
Also introduce an assert that triggers if our refcount falls below 0.
That should never happen.
|
|
This should make us conflict less with system files named "log.h".
Yes, we shouldn't have been conflicting with those anyway, but some
people's compilers act very oddly.
The actual change was done with one "git mv", by editing
Makefile.am, and running
find . -name '*.[ch]' | xargs perl -i -pe 'if (/^#include.*\Wlog.h/) {s/log.h/torlog.h/; }'
|
|
|
|
Possible workaround for bug 1139, if anybody cares.
|
|
This should never happen unless openssl is buggy or some of our
assumptions are deeply wrong, but one of those might have been the
cause of the not-yet-reproducible bug 1209. If it ever happens again,
let's get some info we can use.
|
|
|
|
Conflicts:
src/common/test.h
src/or/test.c
|
|
|
|
|
|
|
|
|
|
Some *_free functions threw asserts when passed NULL. Now all of them
accept NULL as input and perform no action when called that way.
This gains us consistence for our free functions, and allows some
code simplifications where an explicit null check is no longer necessary.
|
|
In 5e4d53d535a3cc9903250b3df0caa829f1c5e4bf we made it so that
crypto_cipher_set_key cannot fail. The call will now
always succeed, to returning a boolean for success/failure makes
no sense.
|
|
In C, the code "char x[10]; if (x) {...}" always takes the true branch of
the if statement. Coverity notices this now.
In some cases, we were testing arrays to make sure that an operation
we wanted to do would suceed. Those cases are now always-true.
In some cases, we were testing arrays to see if something was _set_.
Those caes are now tests for strlen(s), or tests for
!tor_mem_is_zero(d,len).
|
|
See task 1114. The most plausible explanation for someone sending us weak
DH keys is that they experiment with their Tor code or implement a new Tor
client. Usually, we don't care about such events, especially not on warn
level. If we really care about someone not following the Tor protocol, we
can set ProtocolWarnings to 1.
|
|
|
