Age | Commit message (Collapse) | Author |
|
Contrary to what 15e59a1fedf47e7e689e06e5649849552d8b8c0d
said, the C implementation has always accepted an empty string
without complaint. Meanwhile the rust implementation has always
given an error. Make the rust implementation match C.
Also eliminate some more redundant tests.
Fix on 0.3.3.1-alpha.
|
|
commit 15e59a1fedf47e7e689e06e5649849552d8b8c0d added a test
for parsing an empty string twice.
|
|
It was just a copypaste of the test above it.
Fix on commit 15e59a1fedf47e7e689e06e5649849552d8b8c0d
|
|
|
|
|
|
This fixes a startup crash with libseccomp v2.4.0 if Sandbox is
set to 1.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Doing so caused us to crash in some unusual circumstances, such as
using --verify-config to verify a configuration that failed during
the options_act() stage.
Fixes bug 32407; bugfix on 0.3.3.1-alpha.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
hs_client_purge_state() and hs_cache_clean_as_client() can remove a descriptor
from the client cache with a NEWNYM or simply when the descriptor expires.
Which means that for an INTRO circuit being established during that time, once
it opens, we lookup the descriptor to get the IP object but hey surprised, no
more descriptor.
The approach here is minimalist that is accept the race and close the circuit
since we can not continue. Before that, the circuit would stay opened and the
client wait the SockTimeout.
Fixers #28970.
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
|
|
|
* actually sleep when tor has not logged anything
* log at debug level when waiting for tor to log something
* backslash-replace bad UTF-8 characters in logs
* format control messages as ASCII: tor does not accept UTF-8 control commands
Fixes bug 31837; bugfix on 0.3.5.1-alpha.
|
|
When tearing down all periodic events during shutdown, disable them first so
their enable flag is updated.
This allows the tor_api.h to relaunch tor properly after a clean shutdown.
Fixes #32058
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Code adapted from Rob's proposed patch in #30344.
Also add a comment in connection_mark_for_close_internal_() on why we should
not be adding extra code there without a very good reason.
|
|
When encoding introduction points, we were not checking if that intro points
had an established circuit.
When botting up, the service will pick, by default, 3 + 2 intro points and the
first 3 that establish, we use them and upload the descriptor.
However, the intro point is removed from the service descriptor list only when
the circuit has opened and we see that we have already enough intro points, it
is then removed.
But it is possible that the service establishes 3 intro points successfully
before the other(s) have even opened yet.
This lead to the service encoding extra intro points in the descriptor even
though the circuit is not opened or might never establish (#31561).
Fixes #31548
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Rather than filling the logs with similar warnings.
Fixes bug 31939; bugfix on 0.3.0.4-rc.
|
|
|
|
|
|
When processing a %included folder, a bug caused the pointer to
the last element of the options list to be set to NULL when
processing a file with only comments or whitepace. This could
cause options from other files on the same folder to be
discarded depending on the lines after the affected %include.
|
|
|
|
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.
|
|
Our dimap code asserts if you try to add the same key twice; this
can't happen if everything is running smoothly, but it's possible if
you try to start a relay where secret_onion_key_ntor is the same as
secret_onion_key_ntor.old.
Fixes bug 30916; bugfix on 0.2.4.8-alpha when ntor keys were
introduced.
|
|
No behavioral change here: this is just refactoring.
|
|
|
|
|
|
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.
|
|
Our code assumes that when we're configured to get IPv6 addresses
out of a TRANS_PF transparent proxy connection, we actually will.
But we didn't check that, and so FreeBSD started warning us about a
potential NULL pointer dereference.
Fixes part of bug 31687; bugfix on 0.2.3.4-alpha when this code was
added.
|
|
We used to do this on Windows only, but it appears to affect
multiple platforms when building with certain versions of GCC, and a
common pattern for defining the floating-point classifier functions.
Fixes part of 31687. I'm calling this a bugfux on 31687, when we
started suppressing these warnings on Windows.
|
|
Closes #31673
|
|
Closes #31673
|
|
When tor is missing descriptors for some primary entry guards, make the
log message less alarming. It's normal for descriptors to expire, as long
as tor fetches new ones soon after.
Fixes bug 31657; bugfix on 0.3.3.1-alpha.
|