| Age | Commit message (Collapse) | Author |
|---|
|
The tor_memcmp code is by Robert Ransom, and the tor_memeq code is
by me. Both incorporate some ideas from DJB's stuff.
|
|
tor_fragile_assert() might be a no-op, so we have to return something
here to indicate failure to the caller.
|
|
If the user sent a SIGNAL NEWNYM command after we fetched a rendezvous
descriptor, while we were building the introduction-point circuit, we
would give up entirely on trying to connect to the hidden service.
Original patch by rransom slightly edited to go into 0.2.1
|
|
i.e. without closing the AP connection.
|
|
|
|
Under heavy load, this could result in an assertion failure. Fix for
bug 2933; bugfix on 0.2.0.10-alpha.
|
|
|
|
|
|
|
|
|
|
|
|
Issue noticed by Steven Murdoch; fixes bug 2689. The cast didn't do
anything, and we don't need to look at the return value of the function
here.
|
|
|
|
Partial backport of daa0326aaaa85a760be94ee2360cfa61a9fb5be2 .
Resolves bug 2402. Bugfix on 0.2.1.15 (for the part where we switched to
git) and on 0.2.1.30 (for the part where we dumped micro-revisions.)
|
|
This reverts commit a1073ee956021ead19d30c2151510dbaced416a8.
Apparently, we totally misunderstood how the debian packages were using
microrevisions. Better fix that!
|
|
This is based on shitlei's fix for bug2629, with extra parens removed.
Fixes bug 2629, bugfix on 0.2.1.2-alpha.
|
|
|
|
We need to _REJECT_ descriptors with accept6/reject6 lines. If we
let them onto the network , other un-upgraded tors will crash.
|
|
|
|
This reverts commit b3918b3bbbfa9097246d63746c8b540eff2ec8e8.
|
|
|
|
This fixes a remotely triggerable assert on directory authorities, who
don't handle descriptors with ipv6 contents well yet. We will want to
revert this once we're ready to handle ipv6.
Issue raised by lorth on #tor, who wasn't able to use Tor anymore.
Analyzed with help from Christian Fromme. Fix suggested by arma. Bugfix
on 0.2.1.3-alpha.
|
|
piebeer
|
|
|
|
|
|
|
|
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)
|
|
Fixes #2408.
|
|
|
|
fixes bug 2470
|
|
When we stopped using svn, 0.2.1.x lost the ability to notice its svn
revision and report it in the version number. However, it kept
looking at the micro-revision.i file... so if you switched to master,
built tor, then switched to 0.2.1.x, you'd get a micro-revision.i file
from master reported as an SVN tag. This patch takes out the "include
the svn tag" logic entirely.
Bugfix on 0.2.1.15-rc; fixes bug 2402.
|
|
|
|
Found by piebeer.
|
|
|
|
we need to do more hunting, but this fixes the ones mentioned in 2385.
|
|
|
|
This is checked elsewhere too, but let's be RFC-conformant.
|
|
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)
|
|
In dnsserv_resolved(), we carefully made a nul-terminated copy of the
answer in a PTR RESOLVED cell... then never used that nul-terminated
copy. Ouch.
Surprisingly this one isn't as huge a security problem as it could be.
The only place where the input to dnsserv_resolved wasn't necessarily
nul-terminated was when it was called indirectly from relay.c with the
contents of a relay cell's payload. If the end of the payload was
filled with junk, eventdns.c would take the strdup() of the name [This
part is bad; we might crash there if the cell is in a bad part of the
stack or the heap] and get a name of at least length
495[*]. eventdns.c then rejects any name of length over 255, so the
bogus data would be neither transmitted nor altered.
[*] If the name was less than 495 bytes long, the client wouldn't
actually be reading off the end of the cell.
Nonetheless this is a reasonably annoying bug. Better fix it.
Found while looking at bug 2332, reported by doorss. Bugfix on
0.2.0.1-alpha.
|
|
|
|
An object, you'll recall, is something between -----BEGIN----- and
-----END----- tags in a directory document. Some of our code, as
doorss has noted in bug 2352, could assert if one of these ever
overflowed SIZE_T_CEILING but not INT_MAX. As a solution, I'm setting
a maximum size on a single object such that neither of these limits
will ever be hit. I'm also fixing the INT_MAX checks, just to be sure.
|
|
I am not at all sure that it is possible to trigger a bug here,
but better safe than sorry.
|
|
|
|
Found by cypherpunks; fixes more of 2328. Bug was introduced in 3623a122;
first appeared in 0.2.0.5-alpha.
|
|
|
|
We were not decrementing "available" every time we did
++next_virtual_addr in addressmap_get_virtual_address: we left out the
--available when we skipped .00 and .255 addresses.
This didn't actually cause a bug in most cases, since the failure mode
was to keep looping around the virtual addresses until we found one,
or until available hit zero. It could have given you an infinite loop
rather than a useful message, however, if you said "VirtualAddrNetwork
127.0.0.255/32" or something broken like that.
Spotted by cypherpunks
|
|
Fix for bug 2328; bugfix on 0.1.2.1-alpha; bug found by doorss.
|
|
We were decrementing "available" twice for each in-use address we ran
across. This would make us declare that we ran out of virtual
addresses when the address space was only half full.
|
|
|
|
|
