- Jul 14, 2011
-
-
Nick Mathewson authored
-
- Jul 13, 2011
-
-
Nick Mathewson authored
It's possible for us to be a server and have a fingerprint without having yet generated a descriptor. Fixes bug 3577; bugfix on 0.2.0.1-alpha
-
- Jul 07, 2011
-
-
Sebastian Hahn authored
The issue was that we overlooked the possibility of reverse DNS success at the end of connection_ap_handshake_socks_resolved(). Issue discovered by katmagic, thanks!
-
- Jul 06, 2011
-
-
Sebastian Hahn authored
Asciidoc was inserting <pre> tags for paragraphs that started with a '+' at the beginning of the line. Instead, we need a space in front of the plus.
-
Roger Dingledine authored
-
- Jul 05, 2011
-
-
Nick Mathewson authored
-
- Jul 01, 2011
-
-
Nick Mathewson authored
-
Nick Mathewson authored
We were using strncpy before, which isn't our style for stuff like this. This isn't a bug, though: before calling strncpy, we were checking that strlen(src) was indeed == HEX_DIGEST_LEN, which is less than sizeof(dst), so there was no way we could fail to NUL-terminate. Still, strncpy(a,b,sizeof(a)) is an idiom that we ought to squash everyplace. Fixes CID #427.
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
Using strncpy meant that if listenaddress were ever >= sizeof(sockaddr_un.sun_path), we would fail to nul-terminate sun_path. This isn't a big deal: we never read sun_path, and the kernel is smart enough to reject the sockaddr_un if it isn't nul-terminated. Nonetheless, it's a dumb failure mode. Instead, we should reject addresses that don't fit in sockaddr_un.sun_path. Coverity found this; it's CID 428. Bugfix on 0.2.0.3-alpha.
-
Nick Mathewson authored
When we rejected a descriptor for not being the one we wanted, we were letting the parsed descriptor go out of scope. Found by Coverity; CID # 30. Bugfix on 0.2.1.26. (No changes file yet, since this is not in any 0.2.1.x release.)
-
Nick Mathewson authored
-
Nick Mathewson authored
I'm not one to insist on C's miserly stack limits, but allocating a 256K array on the stack is too much even for me. Bugfix on 0.2.1.7-alpha. Found by coverity. Fixes CID # 450.
-
- Jun 25, 2011
-
-
Robert Ransom authored
-
- Jun 24, 2011
-
-
Robert Ransom authored
-
- Jun 23, 2011
-
-
Robert Ransom authored
-
- Jun 22, 2011
-
-
Robert Ransom authored
-
Robert Ransom authored
-
Robert Ransom authored
-
- Jun 21, 2011
-
-
Roger Dingledine authored
otherwise you scp a tarball up but only one version of the website has it.
-
- Jun 20, 2011
-
-
Nick Mathewson authored
-
Nick Mathewson authored
-
- Jun 17, 2011
-
-
Nick Mathewson authored
-
Nick Mathewson authored
This reverts commit 507c1257.
-
Nick Mathewson authored
This reverts commit 40cfad1b.
-
Nick Mathewson authored
-
-
Nick Mathewson authored
-
-
-
-
Roger Dingledine authored
debug-level since it will be quite common. logged at both client and server side. this step should help us track what's going on with people filtering tor connections by our ssl habits.
-
- Jun 14, 2011
-
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Original message from bug3393: check_private_dir() to ensure that ControlSocketsGroupWritable is safe to use. Unfortunately, check_private_dir() only checks against the currently running user… which can be root until privileges are dropped to the user and group configured by the User config option. The attached patch fixes the issue by adding a new effective_user argument to check_private_dir() and updating the callers. It might not be the best way to fix the issue, but it did in my tests. (Code by lunar; changelog by nickm)
-
- Jun 13, 2011
-
-
Nick Mathewson authored
-
Fix for bug 3369.
-
- Jun 08, 2011
-
-
Sebastian Hahn authored
If rep_hist_buffer_stats_write() was called unitinitalized, we'd leak memory.
-