Age | Commit message (Collapse) | Author |
|
|
|
This warning would previously be given every time we tried to open a
connection to a foo.exit address, which could potentially be used to
flood the logs. Now, we don't allow this warning to appear more
than once every 15 minutes.
Fixes bug 31466; bugfix on 0.2.2.1-alpha, when .exit was first
deprecated.
|
|
We previously used tor_fragile_assert() to declare that this case
could not happen: VERSIONS cells are always supposed to be
variable-sized, right?
This is incorrect, though. On a v1 link protocol connection, all
cells are fixed-sized. There aren't supposed to be any VERSIONS
cells with this version of the protocol, but apparently, somebody
was messing up. (The v1 link protocol is obsolete, so probably the
implementer responsible didn't mean to be using it.)
Fixes bug 31107. Bugfix on 0.2.4.4-alpha, when we introduced a
tor_fragile_assert() for this case.
|
|
New IP address from 194.109.206.212 to 45.66.33.45.
Signed request from Alex de Joode, operator of dizum:
https://trac.torproject.org/projects/tor/ticket/31406
Published descriptor by dizum on August 12th, 2019:
--
r dizum fqbq1v2DCDxTj0QDi7+gd1h911U GZmZtCLaPDQNxkhIFj8UcgTRAuA 2019-08-12 15:28:40 45.66.33.45 443 80
s Authority Fast Running Stable V2Dir Valid
v Tor 0.4.0.5
pr Cons=1-2 Desc=1-2 DirCache=1-2 HSDir=1-2 HSIntro=3-4 HSRend=1-2 Link=1-5 LinkAuth=1,3 Microdesc=1-2 Relay=1-2 Padding=1
w Bandwidth=20 Unmeasured=1
p reject 1-65535
--
Finally, confirmed by DNS:
$ dig +short tor.dizum.com
45.66.33.45
Closes #31406
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
|
|
|
|
|
|
|
My previous fix removed a comparison, which would have caused us to
warn about every skew instead of skews of over an hour.
|
|
On some windows builds, time_t is 64 bits but long is not. This is
causing appveyor builds to fail.
Also, one of our uses of labs() on time_t was logically incorrect:
it was telling us to accept NETINFO cells up to three minutes
_before_ the message they were responding to, which doesn't make
sense.
This patch adds a time_abs() function that we should eventually move
to intmath.h or something. For now, though, it will make merges
easier to have it file-local in channeltls.c.
Fixes bug 31343; bugfix on 0.2.4.4-alpha.
|
|
Update the fallback directory mirrors by merging the current list with:
fallback_dirs_2019-06-28-08-58-39_AU_f0437a39ddbc8459.inc
Part of 28795, see that ticket for logs.
|
|
Update the fallback directory mirrors by replacing the old list with:
fallback_dirs_2019-06-25-11-49-10_AU_a37adb956fbb5cd2.inc
Part of 28795, see that ticket for logs.
|
|
We think this bug can only be triggered by modifying a local file.
Fixes bug 30781; bugfix on 0.2.0.8-alpha.
|
|
|
|
|
|
In 0.3.4 and later, we declare write_array as:
extern struct bw_array_t *write_array;
...
typedef struct bw_array_t bw_array_t;
But in 0.2.9, we declare write_array as:
typedef struct bw_array_t bw_array_t;
extern bw_array_t *write_array;
And then again in rephist.c:
typedef struct bw_array_t bw_array_t;
So some compilers fail with a duplicate declaration error.
We backport 684b396ce5, which removes the duplicate declaration.
And this commit deals with the undeclared type error.
Backports a single line from merge commit 813019cc57.
Fixes bug 30184; not in any released version of Tor.
|
|
|
|
If the concatenation of connection buffer and the buffer of linked
connection exceeds INT_MAX bytes, then buf_move_to_buf returns -1 as an
error value.
This value is currently casted to size_t (variable n_read) and will
erroneously lead to an increasement of variable "max_to_read".
This in turn can be used to call connection_buf_read_from_socket to
store more data inside the buffer than expected and clogging the
connection buffer.
If the linked connection buffer was able to overflow INT_MAX, the call
of buf_move_to_buf would have previously internally triggered an integer
overflow, corrupting the state of the connection buffer.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
|
|
Many buffer functions have a hard limit of INT_MAX for datalen, but
this limitation is not enforced in all functions:
- buf_move_all may exceed that limit with too many chunks
- buf_move_to_buf exceeds that limit with invalid buf_flushlen argument
- buf_new_with_data may exceed that limit (unit tests only)
This patch adds some annotations in some buf_pos_t functions to
guarantee that no out of boundary access could occur even if another
function lacks safe guards against datalen overflows.
[This is a backport of the submitted patch to 0.2.9, where the
buf_move_to_buf and buf_new_with_data functions did not exist.]
|
|
|
|
Allow connections to single onion services to remain idle without being
disconnected.
Relays acting as rendezvous points for single onion services were
mistakenly closing idle established rendezvous circuits after 60 seconds,
thinking that they are unused directory-fetching circuits that had served
their purpose.
Fixes bug 29665; bugfix on 0.2.1.26.
|
|
|
|
|
|
|
|
Stop leaking parts of the shared random state in the shared-random unit
tests. The previous fix in 29599 was incomplete.
Fixes bug 29706; bugfix on 0.2.9.1-alpha.
|
|
Turns out that when reloading a tor configured with hidden service(s), we
weren't copying all the needed information between the old service object to
the new one.
For instance, the desc_is_dirty timestamp wasn't which could lead to the
service uploading its descriptor much later than it would need to.
The replaycache wasn't also moved over and some intro point information as
well.
Fixes #23790
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
|
Prior to #23100, we were not counting HS circuit build times in our
calculation of the timeout. This could lead to a condition where our timeout
was set too low, based on non HS circuit build times, and then we would
abandon all HS circuits, storing no valid timeouts in the histogram.
This commit avoids the assert.
|
|
Stop logging "Tried to establish rendezvous on non-OR circuit..." as
a warning. Instead, log it as a protocol warning, because there is
nothing that relay operators can do to fix it.
Fixes bug 29029; bugfix on 0.2.5.7-rc.
|
|
|
|
Merge Phoul's two lists into teor's list.
Replace the 150 fallbacks originally introduced in Tor 0.3.3.1-alpha in
January 2018 (of which ~115 were still functional), with a list of
157 fallbacks (92 new, 65 existing, 85 removed) generated in
December 2018.
Closes ticket 24803.
|
|
Replace the 150 fallbacks originally introduced in Tor 0.3.3.1-alpha in
January 2018 (of which ~115 were still functional), with a list of
148 fallbacks (89 new, 59 existing, 91 removed) generated in
December 2018.
Closes ticket 24803.
|
|
Resolved conflicts with the 26269 fix in 015fcd0e1191aa6f.
|
|
Related to fix for 28202.
|
|
Remember, you can't check to see if there are N bytes left in a
buffer by doing (buf + N < end), since the buf + N computation might
take you off the end of the buffer and result in undefined behavior.
Fixes 28202; bugfix on 0.2.0.3-alpha.
|
|
|
|
|
|
This avoids asymmetry in our public relay stats, which can be exploited for
guard discovery and other attacks.
|
|
The rest of rephist uses uint64_t internally. Let's make these take it too,
so we don't have to worry about overflowing size_t on 32 bit systems.
|
|
The spec only allows the characters [A-Za-z0-9-].
Fix on b2b2e1c7f24d9b65059e3d089768d6c49ba4f58f.
Fixes #27316; bugfix on 0.2.9.4-alpha.
|
|
|
|
It is not supported, and always fails. Some compilers warn about the
function pointer cast on 64-bit Windows.
Fixes bug 27461; bugfix on 0.2.2.23-alpha.
|
|
gcc 8 warns that extend_info_t.nickname might be truncated by strncpy().
But it doesn't know that nickname can either contain a hex id, or a
nicknames. hex ids are only used for general and HSDir circuits.
Fixes bug 27463; bugfix on 0.1.1.2-alpha.
|
|
There should be a separate check to update descriptor when start
or end hibernating.
|
|
|
|
used to determine large changes in bandwidth.
|
|
|
|
Instead, log a protocol warning when single onion services or
Tor2web clients fail to authenticate direct connections to relays.
Fixes bug 26924; bugfix on 0.2.9.1-alpha.
|