| Age | Commit message (Collapse) | Author |
|---|
|
Give size_mul_check() external linkage and use it in base64_decode() to
avoid a potential integer wrap.
Closes #19222
|
|
|
|
|
|
This came up on #21035, where somebody tried to build on a linux
system with kernel headers including CLOCK_MONOTONIC_COARSE, then
run on a kernel that didn't support it.
I've adopted a belt-and-suspenders approach here: we detect failures
at initialization time, and we also detect (loudly) failures later on.
Fixes bug 21035; bugfix on 0.2.9.1-alpha when we started using
monotonic time.
|
|
|
|
|
|
Self-testing circuits don't use guards, and nobody uses guards when
UseEntryGuards is disabled.
Fixes bug 21007; bug not in any released Tor.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Replace the 81 remaining fallbacks of the 100 originally introduced
in Tor 0.2.8.3-alpha in March 2016, with a list of 177 fallbacks
(123 new, 54 existing, 27 removed) generated in December 2016.
Resolves ticket 20170.
|
|
|
|
In get_token(), we could read one byte past the end of the
region. This is only a big problem in the case where the region
itself is (a) potentially hostile, and (b) not explicitly
nul-terminated.
This patch fixes the underlying bug, and also makes sure that the
one remaining case of not-NUL-terminated potentially hostile data
gets NUL-terminated.
Fix for bug 21018, TROVE-2016-12-002, and CVE-2016-1254
|
|
They broke stem, and breaking application compatibility is usually a
bad idea.
This reverts commit 6e10130e18c80f4521e31b071455ae0b1bbea761,
commit 78a13df15842e8ab262e17825160386fadb77056, and
commit 62f52a888acc191bcb507d27d31d54e42e6effdd.
We might re-apply this later, if all the downstream tools can handle
it, and it turns out to be useful for some reason.
|
|
|
|
I got confused when I saw my Tor saying it was opening a file
that doesn't exist. It turns out it isn't opening it, it's just
calling open() on it and then moving on when it's not there.
|
|
This is the same as we fixed in 39f455468731d4746adb729a67.
|
|
|
|
|
|
|
|
This reverts commit 954eeda619a59dae76144ad69967f0ed7341b564.
Apparently, OpenBSD is what expects you to declare environ
yourself. So 19142 is a wontfix.
|
|
I broke this with 20292ec4974b777d430e7962cc38349c5f82b220 when I
changed the primary guard retry schedule.
|
|
(Keeping the code around in case I broke Tor in some unexpected
way.)
|
|
|
|
Now that we support NumEntryGuards, NumDirectoryGuards is pretty
easy to put back in.
|
|
Further, add a "guard-n-primary-guards-to-use" parameter, defaulting
to 1, for NumEntryGuards to override.
|
|
Previously, we had NumEntryGuards kind of hardwired to 1. Now we
have the code (but not the configuarability) to choose randomly from
among the first N primary guards that would work, where N defaults
to 1.
Part of 20831 support for making NumEntryGuards work again.
|
|
It overrides both the GUARD_LIFETIME and the
GUARD_CONFIRMED_MIN_LIFETIME options.
|
|
It is obsoleted in an always-on direction by prop271.
|
|
|
|
Since we already had a separate function for getting the universe of
possible guards, all we had to do was tweak it to handle very the
GS_TYPE_RESTRICTED case.
|
|
|
|
|
|
|
|
asn found while testing that this function can be reached with
GUARD_STATE_COMPLETE circuits; I believe this happens when
cannibalization occurs.
The added complexity of handling one more state made it reasonable
to turn the main logic here into a switch statement.
|
|
Letting the maximum sample size grow proportionally to the number of
guards defeats its purpose to a certain extent. Noted by asn during
code review.
Fixes bug 20920; bug not in any released (or merged) version of Tor.
|
|
The valid_until check was redundant.
|
|
|
|
- Correctly maintain the previous guard selection in choose_guard_selection().
- Print bridge identifier instead of nothing in entry_guard_describe()._
|
|
|
|
This will make it easier to see what we remove down the line.
|
|
|
|
|
|
|
|
|
