Tor merge requestshttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests2022-01-18T17:57:51Zhttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/508Update new relay blogpost URL2022-01-18T17:57:51ZJérôme Charaouilavamind@torproject.orgUpdate new relay blogpost URLThis removes the '/blog/' URL component which relies on a
redirection since the blog has been migrated to Lektor.This removes the '/blog/' URL component which relies on a
redirection since the blog has been migrated to Lektor.Tor: 0.4.7.x-stableJérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/497Limit the number of elements in a consdiff hash line.2022-04-14T13:36:29ZNick MathewsonLimit the number of elements in a consdiff hash line.This avoids performing and then freeing a lot of small mallocs() if
the hash line has too many elements.
Fixes one case of bug #40472; resolves OSS-Fuzz 38363. Bugfix on
0.3.1.1-alpha when the consdiff parsing code was introduced.
I'm...This avoids performing and then freeing a lot of small mallocs() if
the hash line has too many elements.
Fixes one case of bug #40472; resolves OSS-Fuzz 38363. Bugfix on
0.3.1.1-alpha when the consdiff parsing code was introduced.
I'm opening this fix against 0.3.5, but I do think it's safe not to backport it.Tor: 0.4.5.x-post-stableNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/491Do not count controller-selected paths towards path bias.2022-04-14T13:38:06ZNick MathewsonDo not count controller-selected paths towards path bias.As a side effect, this fixes a "Bug" warning.
Closes #40515. Bugfix on 0.2.4.10-alpha.As a side effect, this fixes a "Bug" warning.
Closes #40515. Bugfix on 0.2.4.10-alpha.Tor: 0.4.5.x-post-stableNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/484Add scary warnings about changing the protover list.2021-11-05T15:01:51ZDavid Gouletdgoulet@torproject.orgAdd scary warnings about changing the protover list.Doing this in the wrong way has potential to cause serious havoc on
the network, so let's make it harder for future programmers to mess
it up.Doing this in the wrong way has potential to cause serious havoc on
the network, so let's make it harder for future programmers to mess
it up.Tor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/482relay: Don't advertise HSv2 protocol version2021-11-05T14:19:42ZDavid Gouletdgoulet@torproject.orgrelay: Don't advertise HSv2 protocol versionWe removed HSIntro=3 and HSDir=1 that are v2 specific. Since 0.4.5.12,
we do not support introducing or being a directory for onion service v2.
Closes #40509
Signed-off-by: David Goulet <dgoulet@torproject.org>We removed HSIntro=3 and HSDir=1 that are v2 specific. Since 0.4.5.12,
we do not support introducing or being a directory for onion service v2.
Closes #40509
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.5.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/481relay: Don't advertise HSv2 protocol version2021-11-05T14:19:35ZDavid Gouletdgoulet@torproject.orgrelay: Don't advertise HSv2 protocol versionWe removed HSIntro=3 and HSDir=1 that are v2 specific. Since 0.3.5.17,
we do not support introducing or being a directory for onion service v2.
Closes #40509
Signed-off-by: David Goulet <dgoulet@torproject.org>We removed HSIntro=3 and HSDir=1 that are v2 specific. Since 0.3.5.17,
we do not support introducing or being a directory for onion service v2.
Closes #40509
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/478man: Missing OverloadStatistics option in tor.12021-11-02T15:28:28ZDavid Gouletdgoulet@torproject.orgman: Missing OverloadStatistics option in tor.1Closes #40504
Signed-off-by: David Goulet <dgoulet@torproject.org>Closes #40504
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.6.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/477Draft: relay: Don't allow DirPort on non-IPv42021-11-03T13:55:19ZDavid Gouletdgoulet@torproject.orgDraft: relay: Don't allow DirPort on non-IPv4Our code doesn't allow it and so this prevents an assert() crash if the
DirPort is for instance IPv6 only.
Fixes #40494
Signed-off-by: David Goulet <dgoulet@torproject.org>Our code doesn't allow it and so this prevents an assert() crash if the
DirPort is for instance IPv6 only.
Fixes #40494
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.5.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/475Fix Windows build for 0.3.52021-10-29T16:57:06ZAlexander Færøyahf@torproject.orgFix Windows build for 0.3.5This is a 0.3.5 backport of tor#40275.
While trying to resolve our CI issues, the Windows build broke with an
unused function error:
src/test/test_switch_id.c:37:1: error: ‘unprivileged_port_range_start’
defined but not used [-We...This is a 0.3.5 backport of tor#40275.
While trying to resolve our CI issues, the Windows build broke with an
unused function error:
src/test/test_switch_id.c:37:1: error: ‘unprivileged_port_range_start’
defined but not used [-Werror=unused-function]
We solve this by moving the `#if !defined(_WIN32)` test above the
`unprivileged_port_range_start()` function defintion such that it is
included in its body.
This is an unreviewed commit.
See: tor#40275https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/474fetch missing bridge descriptors without delay2022-08-04T13:14:29ZRoger Dingledinefetch missing bridge descriptors without delayWithout this change, if we have a working bridge, and we add a new bridge,
we will schedule the fetch attempt for that new bridge descriptor for
three hours(!) in the future.
This change is especially needed because of bug #40396, where...Without this change, if we have a working bridge, and we add a new bridge,
we will schedule the fetch attempt for that new bridge descriptor for
three hours(!) in the future.
This change is especially needed because of bug #40396, where if you have
one working bridge and one bridge whose descriptor you haven't fetched
yet, your Tor will stall until you have successfully fetched that new
descriptor -- in this case for hours.
In the old design, we would put off all further bridge descriptor fetches
once we had any working bridge descriptor. In this new design, we make the
decision per bridge based on whether we successfully got *its* descriptor.
To make this work, we need to also call learned_bridge_descriptor() every
time we get a bridge descriptor, not just when it's a novel descriptor.
Fixes bug 40396.
Also happens to fix bug 40495 (redundant descriptor fetches for every
bridge) since now we delay fetches once we succeed.
A side effect of this change is that if we have any configured bridges
that *aren't* working, we will keep trying to fetch their descriptors
on the modern directory retry schedule -- every couple of seconds for
the first half minute, then backing off after that -- which is a lot
faster than before.Tor: 0.4.5.x-post-stableRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/467fallbackdir: Regenerate the list for October 20212021-10-21T14:03:38ZDavid Gouletdgoulet@torproject.orgfallbackdir: Regenerate the list for October 2021Closes #40493
Signed-off-by: David Goulet <dgoulet@torproject.org>Closes #40493
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/463Draft: relay: Overload state on DNS timeout is now X% over Y secs2021-10-20T13:19:19ZDavid Gouletdgoulet@torproject.orgDraft: relay: Overload state on DNS timeout is now X% over Y secsWith this commit, we will only report a general overload state if we've
seen more than X% of DNS timeout errors over Y seconds. Previous
behavior was to report when a single timeout occured which is really too
small of a threshold.
The ...With this commit, we will only report a general overload state if we've
seen more than X% of DNS timeout errors over Y seconds. Previous
behavior was to report when a single timeout occured which is really too
small of a threshold.
The value X is a consensus parameters called
"overload_dns_timeout_scale_percent" which is a scaled percentage
(factor of 1000) so we can represent decimal points for X like 0.5% for
instance. Its default is 1000 which ends up being 1%.
The value Y is a consensus parameters called
"overload_dns_timeout_period_secs" which is the time period for which
will gather DNS errors and once over, we assess if that X% has been
reached ultimately triggering a general overload signal.
Closes #40491
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.6.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/462hs-v2: Disable SOCKS connection for v2 addresses2021-10-19T15:03:17ZDavid Gouletdgoulet@torproject.orghs-v2: Disable SOCKS connection for v2 addressesThis effectively turns off the ability of tor to use HSv2 as a client by
invalidating the v2 onion hostname passed through a SOCKS request.
Part of #40476
Signed-off-by: David Goulet <dgoulet@torproject.org>This effectively turns off the ability of tor to use HSv2 as a client by
invalidating the v2 onion hostname passed through a SOCKS request.
Part of #40476
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.6.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/461hs-v2: Disable SOCKS connection for v2 addresses2021-10-19T15:03:15ZDavid Gouletdgoulet@torproject.orghs-v2: Disable SOCKS connection for v2 addressesThis effectively turns off the ability of tor to use HSv2 as a client by
invalidating the v2 onion hostname passed through a SOCKS request.
Part of #40476
Signed-off-by: David Goulet <dgoulet@torproject.org>This effectively turns off the ability of tor to use HSv2 as a client by
invalidating the v2 onion hostname passed through a SOCKS request.
Part of #40476
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.5.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/449hs-v2: Only log once the connection warning to v22021-10-06T17:27:48ZDavid Gouletdgoulet@torproject.orghs-v2: Only log once the connection warning to v2Signed-off-by: David Goulet <dgoulet@torproject.org>Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.6.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/448hs-v2: Only log once the connection warning to v22021-10-06T17:27:47ZDavid Gouletdgoulet@torproject.orghs-v2: Only log once the connection warning to v2Signed-off-by: David Goulet <dgoulet@torproject.org>Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.5.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/445hs-v2: Disable SOCKS connection for v2 addresses2021-10-19T15:03:13ZDavid Gouletdgoulet@torproject.orghs-v2: Disable SOCKS connection for v2 addressesThis effectively turns off the ability of tor to use HSv2 as a client by
invalidating the v2 onion hostname passed through a SOCKS request.
Part of #40476
Signed-off-by: David Goulet <dgoulet@torproject.org>This effectively turns off the ability of tor to use HSv2 as a client by
invalidating the v2 onion hostname passed through a SOCKS request.
Part of #40476
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/420dir: Do not flag non-running failing HSDir2021-10-06T19:36:23ZDavid Gouletdgoulet@torproject.orgdir: Do not flag non-running failing HSDirWhen a directory request fails, we flag the relay as non Running so we
don't use it anymore.
This can be problematic with onion services because there are cases
where a tor instance could have a lot of services, ephemeral ones, and
keep...When a directory request fails, we flag the relay as non Running so we
don't use it anymore.
This can be problematic with onion services because there are cases
where a tor instance could have a lot of services, ephemeral ones, and
keeps failing to upload descriptors, let say due to a bad network, and
thus flag a lot of nodes as non Running which then in turn can not be
used for circuit building.
This commit makes it that we never flag nodes as non Running on a onion
service directory request (upload or fetch) failure as to keep the
hashring intact and not affect other parts of tor.
Fortunately, the onion service hashring is _not_ selected by looking at
the Running flag but since we do a 3-hop circuit to the HSDir, other
services on the same instance can influence each other by removing nodes
from the consensus for path selection.
This was made apparent with a small network that ran out of nodes to
used due to rapid succession of onion services uploading and failing.
See #40434 for details.
Fixes #40434
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.5.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/417fallbackdir: Regenerate list2021-08-11T13:16:20ZDavid Gouletdgoulet@torproject.orgfallbackdir: Regenerate listNew list for all stable releases.
Closes #40447
Signed-off-by: David Goulet <dgoulet@torproject.org>New list for all stable releases.
Closes #40447
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/416fallbackdir: Regenerate lists2021-08-11T13:07:38ZDavid Gouletdgoulet@torproject.orgfallbackdir: Regenerate listsNew lists for all stable releases.
Closes #40447
Signed-off-by: David Goulet <dgoulet@torproject.org>New lists for all stable releases.
Closes #40447
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org