| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Fix for #10563. This is a compatibility issue with libseccomp-2.1.
I guess you could call it a bugfix on 0.2.5.1?
|
| |
|
|
|
|
| |
This is harmless in the Tor of today, but important for correctness.
Fixes bug 10536; bugfix on 0.2.4.8-alpha. Reported by "cypherpunks".
|
| |\ |
|
| | |
| |
| |
| | |
Fix for 10485. Fix on 0.2.4.17-alpha.
|
| |\| |
|
| | |
| |
| |
| | |
Bugfix on 0.2.4.7-alpha; fixes bug 10465.
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When I introduced the unusable_for_new_circuits flag in
62fb209d837f3f551, I had a spurious ! in the
circuit_stream_is_being_handled loop. This made us decide that
non-unusable circuits (that is, usable ones) were the ones to avoid,
and caused it to launch a bunch of extra circuits.
Fixes bug 10456; bugfix on 0.2.4.12-alpha.
|
| |\ \ |
|
| | | | |
|
| |\ \ \
| | |/
| |/|
| | |
| | | |
Conflicts:
src/common/crypto.c
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This fixes bug 10402, where the rdrand engine would use the rdrand
instruction, not as an additional entropy source, but as a replacement
for the entire userspace PRNG. That's obviously stupid: even if you
don't think that RDRAND is a likely security risk, the right response
to an alleged new alleged entropy source is never to throw away all
previously used entropy sources.
Thanks to coderman and rl1987 for diagnosing and tracking this down.
|
| |\| | |
|
| | |\ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is a fix for 10423, which was introducd in caa0d15c in 0.2.4.13-alpha.
Spotted by bobnomnom.
|
| |\| | |
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/or/microdesc.c
Conflict because one change was on line adjacent to line where
01206893 got fixed.
|
| | |\ \
| | |/
| |/| |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The 'body' field of a microdesc_t holds a strdup()'d value if the
microdesc's saved_location field is SAVED_IN_JOURNAL or
SAVED_NOWHERE, and holds a pointer to the middle of an mmap if the
microdesc is SAVED_IN_CACHE. But we weren't setting that field
until a while after we parsed the microdescriptor, which left an
interval where microdesc_free() would try to free() the middle of
the mmap().
This patch also includes a regression test.
This is a fix for #10409; bugfix on 0.2.2.6-alpha.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
The old behavior was that NULL matched only bridges without known
identities; the correct behavior is that NULL should match all
bridges (assuming that their addr:port matches).
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We were checking whether a 8-bit length field had overflowed a
503-byte buffer. Unless somebody has found a way to store "504" in a
single byte, it seems unlikely.
Fix for 10313 and 9980. Based on a pach by Jared L Wong. First found
by David Fifield with STACK.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This flag prevents the creation of a console window popup on Windows. We
need it for pluggable transport executables--otherwise you get blank
console windows when you launch the 3.x browser bundle with transports
enabled.
http://msdn.microsoft.com/en-us/library/ms684863.aspx#CREATE_NO_WINDOW
The browser bundles that used Vidalia used to set this flag when
launching tor itself; it was apparently inherited by the pluggable
transports launched by tor. In the 3.x bundles, tor is launched by some
JavaScript code, which doesn't have the ability to set CREATE_NO_WINDOW.
tor itself is now being compiled with the -mwindows option, so that it
is a GUI application, not a console application, and doesn't show a
console window in any case. This workaround doesn't work for pluggable
transports, because they need to be able to write control messages to
stdout.
https://trac.torproject.org/projects/tor/ticket/9444#comment:30
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The previous commit from piet would have backed out some of proposal
198 and made servers built without the V2 handshake not use the
unrestricted cipher list from prop198.
Bug not in any released Tor.
|
| | | | |
| | | |
| | | |
| | | | |
Fixes bug 4677; bugfix on 0.2.3.2-alpha. Fix by "piet".
|
| | | | |
| | | |
| | | |
| | | | |
Fixes CID 743381
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
It's conceivable (but probably impossible given our code) that lseek
could return -1 on an error; when that happens, we don't want off to
become -1.
Fixes CID 1035124.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
CIDs: 1130994, 1130993, 1130992, 1130991
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
Coverity wants this; CID 1130990.
|
| | | | | |
|
| |\ \ \ \ |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As a bridge authority, before we create our networkstatus document, we
should compute the thresholds needed for the various status flags
assigned to each bridge based on the status of all other bridges. We
then add these thresholds to the networkstatus document for easy access.
Fixes for #1117 and #9859.
|
| | | | | | |
|
| |\ \ \ \ \ |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
In proposal 157, we added a cross-certification element for
directory authority certificates. We implemented it in
0.2.1.9-alpha. All Tor directory authorities now generate it.
Here, as planned, make it required, so that we can finally close
proposal 157.
The biggest change in the code is in the unit test data, where some
old hardcoded certs that we made long ago have become no longer
valid and now need to be replaced.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
With any luck, this will clean up errors where we detect that
REG_{EIP,RIP} is present in autoconf, but when we go to include it,
it isn't there.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
It's not nice to talk about NID_aes_{128,256}_{ctr,gcm} when they
don't exist.
Fix on 84458b79a78ea7e26820bf0; bug not in any released Tor.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This was a mistake in the merge commit 7a2b30fe16eacc040b3dd11. It
would have made the CellStatistics code give completely bogus
results. Bug not in any released Tor.
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Fixes ticket 10043; patch from Joshua Datko.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Conflicts:
src/common/sandbox.c
src/common/sandbox.h
src/common/util.c
src/or/main.c
src/test/include.am
src/test/test.c
|
| | | | | | | | |
|