| Age | Commit message (Collapse) | Author |
|---|
|
Requested by Gisle Vanem on tor-dev. I'm not quite sure this is the
right solution, but it's probably harmless.
|
|
|
|
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.
|
|
|
|
Conflicts in various places, mainly node-related. Resolved them in
favor of HEAD, with copying of tor_mem* operations from bug3122_memcmp_022.
src/common/Makefile.am
src/or/circuitlist.c
src/or/connection_edge.c
src/or/directory.c
src/or/microdesc.c
src/or/networkstatus.c
src/or/router.c
src/or/routerlist.c
src/test/test_util.c
|
|
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.
|
|
Conflicts:
src/common/crypto.c
|
|
|
|
Trivial Conflicts in
src/common/crypto.c
src/or/main.h
src/or/or.h
|
|
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
|
|
|
|
I dug through the OpenSSL source and verified that RSA_private_decrypt will
not write more than RSA_size(key) bytes to its output buffer.
|
|
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.
|
