- Apr 30, 2010
-
-
Roger Dingledine authored
-
Roger Dingledine authored
-
- Apr 24, 2010
-
-
Roger Dingledine authored
-
Roger Dingledine authored
-
- Apr 23, 2010
-
-
Roger Dingledine authored
-
Roger Dingledine authored
-
- Apr 13, 2010
-
-
Nick Mathewson authored
Our code assumed that any version of OpenSSL before 0.9.8l could not possibly require SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION. This is so... except that many vendors have backported the flag from later versions of openssl when they backported the RFC5476 renegotiation feature. The new behavior is particularly annoying to detect. Previously, leaving SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION unset meant that clients would fail to renegotiate. People noticed that one fast! Now, OpenSSL's RFC5476 support means that clients will happily talk to any servers there are, but servers won't accept renegotiation requests from unpatched clients unless SSL_OP_ALLOW_etc is set. More fun: servers send back a "no renegotiation for you!" error, which unpatched clients respond to by stalling, and generally producing no useful error message. This might not be _the_ cause of bug 1346, but it is quite likely _a_ cause for bug 1346.
-
- Apr 12, 2010
-
-
- Apr 04, 2010
-
-
Roger Dingledine authored
-
- Mar 16, 2010
-
-
Roger Dingledine authored
-
- Mar 15, 2010
-
-
Roger Dingledine authored
it's perfect, let's ship it
-
- Mar 07, 2010
-
-
Roger Dingledine authored
-
- Mar 04, 2010
-
-
Nick Mathewson authored
From http://archives.seul.org/tor/relays/Mar-2010/msg00006.html : As I understand it, the bug should show up on relays that don't set Address to an IP address (so they need to resolve their Address line or their hostname to guess their IP address), and their hostname or Address line fails to resolve -- at that point they'll pick a random 4 bytes out of memory and call that their address. At the same time, relays that *do* successfully resolve their address will ignore the result, and only come up with a useful address if their interface address happens to be a public IP address.
-
- Mar 02, 2010
-
-
Nick Mathewson authored
-
- Feb 27, 2010
-
-
Nick Mathewson authored
-
Sebastian Hahn authored
Treat strings returned from signed_descriptor_get_body_impl() as not NUL-terminated. Since the length of the strings is available, this is not a big problem. Discovered by rieo.
-
- Feb 26, 2010
-
-
Sebastian Hahn authored
Another dereference-then-NULL-check sequence. No reports of this bug triggered in the wild. Fixes bugreport 1256. Thanks to ekir for discovering and reporting this bug.
-
Sebastian Hahn authored
Fix a dereference-then-NULL-check sequence. This bug wasn't triggered in the wild, but we should fix it anyways in case it ever happens. Also make sure users get a note about this being a bug when they see it in their log. Thanks to ekir for discovering and reporting this bug.
-
Sebastian Hahn authored
We used to only zero the first ptrsize bytes of the cipher. Since cipher is large enough, we didn't zero too many bytes. Discovered and fixed by ekir. Fixes bug 1254.
-
- Feb 21, 2010
-
-
Roger Dingledine authored
-
Roger Dingledine authored
-
- Feb 18, 2010
-
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Sebastian Hahn authored
-
Nick Mathewson authored
This time, set the SSL3_FLAGS_ALLOW_UNSAFE_RENEGOTIATION flag on every version before OpenSSL 0.9.8l. I can confirm that the option value (0x0010) wasn't reused until OpenSSL 1.0.0beta3.
-
- Feb 13, 2010
-
-
Roger Dingledine authored
-
- Feb 12, 2010
-
-
Roger Dingledine authored
-
Roger Dingledine authored
-
- Feb 08, 2010
-
-
Sebastian Hahn authored
Tor has tor_lookup_hostname(), which prefers ipv4 addresses automatically. Bug 1244 occured because gethostbyname() returned an ipv6 address, which Tor cannot handle currently. Fixes bug 1244; bugfix on 0.0.2pre25. Reported by Mike Mestnik.
-
- Feb 07, 2010
-
-
Sebastian Hahn authored
The problem was that we didn't allocate enough memory on 32-bit platforms with 64-bit time_t. The memory leak occured every time we fetched a hidden service descriptor we've fetched before.
-
- Feb 02, 2010
-
-
Nick Mathewson authored
For most linking setups, this doesn't matter. But for some setups, when statically linking openssl, it does matter, since you need to link things with dependencies before you link things they depend on. Fix for bug 1237.
-
- Feb 01, 2010
-
-
Nick Mathewson authored
In brief: you mustn't use the SSL3_FLAG solution with anything but 0.9.8l, and you mustn't use the SSL_OP solution with anything before 0.9.8m, and you get in _real_ trouble if you try to set the flag in 1.0.0beta, since they use it for something different. For the ugly version, see my long comment in tortls.c
-
- Jan 29, 2010
-
-
Nick Mathewson authored
We need to do this because Apple doesn't update its dev-tools headers when it updates its libraries in a security patch. On the bright side, this might get us out of shipping a statically linked OpenSSL on OSX. May fix bug 1225. [backported]
-
- Jan 24, 2010
-
-
Nick Mathewson authored
These options only work when using --with-(openssl|libevent)-dir to explicitly pick a libevent or openssl location.
-
the new configure option --enable-gcc-warnings-advisory enables all the gcc flags that --enable-gcc-warnings does with the exception of -Werror.
-
Nick Mathewson authored
-
- Jan 22, 2010
-
-
Nick Mathewson authored
We were checking for msg==NULL, but not lib or proc. This case can only occur if we have an error whose string we somehow haven't loaded, but it's worth coding defensively here. Spotted by rieo on IRC.
-
- Jan 19, 2010
-
-
Roger Dingledine authored
-
Roger Dingledine authored
-