Tor merge requestshttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests2021-01-28T17:51:35Zhttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/50#33781 for 0.3.5: Strip '\r' characters when reading text files on Unix.2021-01-28T17:51:35ZAlexander Færøyahf@torproject.org#33781 for 0.3.5: Strip '\r' characters when reading text files on Unix.This patch ensures that we strip "\\r" characters on both Windows as well as Unix when we read text files. This should prevent the issue where some Tor state files have been moved from a Windows machine, and thus contains CRLF line endin...This patch ensures that we strip "\\r" characters on both Windows as well as Unix when we read text files. This should prevent the issue where some Tor state files have been moved from a Windows machine, and thus contains CRLF line ending, to a Unix machine where only \\n is needed.
We add a test-case to ensure that we handle this properly on all our platforms.
See: https://bugs.torproject.org/tpo/core/tor/33781
This is the 0.3.5 replacement for !34.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/398[40410] Fix compilation on OpenSUSE.2021-06-18T18:29:39ZAlexander Færøyahf@torproject.org[40410] Fix compilation on OpenSUSE.This patch fixes a build error with GCC 7.x which doesn't seem to accept
const int's as constants in macro initialization.
See: tpo/core/tor#40410This patch fixes a build error with GCC 7.x which doesn't seem to accept
const int's as constants in macro initialization.
See: tpo/core/tor#40410Tor: 0.4.7.x-freezeAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/338Add a MinTimeToReportBandwidth option; make it 0 for testing networks.2021-10-21T12:37:07ZNick MathewsonAdd a MinTimeToReportBandwidth option; make it 0 for testing networks.This option changes the time for which a bandwidth measurement period
must have been in progress before we include it when reporting our
observed bandwidth in our descriptors. Without this option, we only
consider a time period towards ...This option changes the time for which a bandwidth measurement period
must have been in progress before we include it when reporting our
observed bandwidth in our descriptors. Without this option, we only
consider a time period towards our maximum if it has been running
for a full day. Obviously, that's unacceptable for testing
networks, where we'd like to get results as soon as possible.
For non-testing networks, I've put a (somewhat arbitrary) 2-hour
minimum on the option, since there are traffic analysis concerns
with immediate reporting here.
Closes #40337.https://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/643Add several new metrics to MetricsPort2022-10-27T15:46:23ZDavid Gouletdgoulet@torproject.orgAdd several new metrics to MetricsPortRelated to #40194
Signed-off-by: David Goulet <dgoulet@torproject.org>Related to #40194
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.7.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/77Adjust the rules for warning about too many connections.2020-10-07T12:29:57ZNick MathewsonAdjust the rules for warning about too many connections.Previously we tolerated up to 1.5 connections for every relay we
were connected to, and didn't warn if we had fewer than 5
connections total.
Now we tolerate up to 1.5 connections per relay, and up to 4
connections per authority, and we...Previously we tolerated up to 1.5 connections for every relay we
were connected to, and didn't warn if we had fewer than 5
connections total.
Now we tolerate up to 1.5 connections per relay, and up to 4
connections per authority, and we don't warn at all when we have
fewer than 25 connections total.
Fixes bug 33880, which seems to have been provoked by our #17592
change in 0.3.5.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/763Bug 40858: Cache sendme_inc to avoid purging intro points.2023-09-14T19:34:51ZMike PerryBug 40858: Cache sendme_inc to avoid purging intro points.Bug found and fixed by @hyunsoo.kim676.Bug found and fixed by @hyunsoo.kim676.Tor: 0.4.7.x-post-stableMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/163Bug40133 043: resolve merge conflict in !1432021-01-19T17:54:26ZNick MathewsonBug40133 043: resolve merge conflict in !143https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/653build: fix -Wstrict-prototypes (Clang 16)2022-11-10T00:29:41ZSam Jamesbuild: fix -Wstrict-prototypes (Clang 16)Clang 16 warns on -Wstrict-prototypes in preparation for C23 which can
among other things, lead to some configure tests silently failing/returning the wrong result.
Fixes this error:
```
-ignoreme: warning: a function declaration withou...Clang 16 warns on -Wstrict-prototypes in preparation for C23 which can
among other things, lead to some configure tests silently failing/returning the wrong result.
Fixes this error:
```
-ignoreme: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
+ignoreme: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
main ()
```
For more information, see LWN.net [0] or LLVM's Discourse [1], gentoo-dev@ [2],
or the (new) c-std-porting mailing list [3].
[0] https://lwn.net/Articles/913505/
[1] https://discourse.llvm.org/t/configure-script-breakage-with-the-new-werror-implicit-function-declaration/65213
[2] https://archives.gentoo.org/gentoo-dev/message/dd9f2d3082b8b6f8dfbccb0639e6e240
[3] hosted at lists.linux.dev.
Bug: https://bugs.gentoo.org/879747
Signed-off-by: Sam James <sam@gentoo.org>
---Tor: 0.4.7.x-post-stablehttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/344channel: Fix use after free in channel_do_open_actions()2021-03-24T16:25:16ZDavid Gouletdgoulet@torproject.orgchannel: Fix use after free in channel_do_open_actions()Fortunately, our tor_free() is setting the variable to NULL after so we were
in a situation where NULL was always used instead of the transport name.
This first appeared in 894ff2dc8422cb86312c512698acd76476224f87 and results in
basical...Fortunately, our tor_free() is setting the variable to NULL after so we were
in a situation where NULL was always used instead of the transport name.
This first appeared in 894ff2dc8422cb86312c512698acd76476224f87 and results in
basically no bridge with a transport being able to use DoS defenses.
Fixes #40345
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.6.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/641circ: Set proper timeout cutoff for HS circuits2022-10-26T19:13:17ZDavid Gouletdgoulet@torproject.orgcirc: Set proper timeout cutoff for HS circuitsExplicitly set the S_CONNECT_REND purpose to a 4-hop cutoff.
As for the established rendezvous circuit waiting on the RENDEZVOUS2,
set one that is very long considering the possible waiting time for the
service to get the request and jo...Explicitly set the S_CONNECT_REND purpose to a 4-hop cutoff.
As for the established rendezvous circuit waiting on the RENDEZVOUS2,
set one that is very long considering the possible waiting time for the
service to get the request and join our rendezvous.
Part of #40694
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.7.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/638circ: Set proper timeout cutoff for HS circuits2022-10-26T19:13:14ZDavid Gouletdgoulet@torproject.orgcirc: Set proper timeout cutoff for HS circuitsExplicitly set the S_CONNECT_REND purpose to a 4-hop cutoff.
As for the established rendezvous circuit waiting on the RENDEZVOUS2,
set one that is very long considering the possible waiting time for the
service to get the request and jo...Explicitly set the S_CONNECT_REND purpose to a 4-hop cutoff.
As for the established rendezvous circuit waiting on the RENDEZVOUS2,
set one that is very long considering the possible waiting time for the
service to get the request and join our rendezvous.
Part of #40694
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.8.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/323configure: Handle deprecated mallinfo()2021-02-23T15:55:06ZDavid Gouletdgoulet@torproject.orgconfigure: Handle deprecated mallinfo()We still use it if available or even deprecated.
Closes #40309
Signed-off-by: David Goulet <dgoulet@torproject.org>We still use it if available or even deprecated.
Closes #40309
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/322configure: Handle deprecated mallinfo()2021-02-23T15:55:03ZDavid Gouletdgoulet@torproject.orgconfigure: Handle deprecated mallinfo()We still use it if available or even deprecated.
Closes #40309
Signed-off-by: David Goulet <dgoulet@torproject.org>We still use it if available or even deprecated.
Closes #40309
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/384conn: MetricsPort listener is a listener port2021-05-17T13:04:32ZDavid Gouletdgoulet@torproject.orgconn: MetricsPort listener is a listener portThe connection type for the listener part was missing from the "is
connection a listener" function.
This lead to our periodic event that retries our listeners to keep
trying to bind() again on an already opened MetricsPort.
Closes #403...The connection type for the listener part was missing from the "is
connection a listener" function.
This lead to our periodic event that retries our listeners to keep
trying to bind() again on an already opened MetricsPort.
Closes #40370
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.7.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/606conn: Notify btrack subsys on normal OR conn close2022-08-02T20:11:22ZDavid Gouletdgoulet@torproject.orgconn: Notify btrack subsys on normal OR conn closeFixes #40604
Signed-off-by: David Goulet <dgoulet@torproject.org>Fixes #40604
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.7.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/137conn: Remove assert on new listener connection when retrying2020-10-07T12:08:13ZDavid Gouletdgoulet@torproject.orgconn: Remove assert on new listener connection when retryingOpening a new listener connection can fail in many ways like a bind()
permission denied on a low port for instance.
And thus, we should expect to handle an error when creating a new one instead
of assert() on it.
To hit the removed ass...Opening a new listener connection can fail in many ways like a bind()
permission denied on a low port for instance.
And thus, we should expect to handle an error when creating a new one instead
of assert() on it.
To hit the removed assert:
ORPort 80
KeepBindCapabilities 0
Start tor. Then edit torrc:
ORPort <some-IP>:80
HUP tor and the assert is hit.
Fixes #40073
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.5.x-freezeAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/635dir auths now omit Measured= if rs->is_authority2022-10-26T20:32:32ZRoger Dingledinedir auths now omit Measured= if rs->is_authority dir auths now omit Measured= if rs->is_authority
Directory authorities stop voting a consensus "Measured" weight
for relays with the Authority flag. Now these relays will be
considered unmeasured, which should reserv... dir auths now omit Measured= if rs->is_authority
Directory authorities stop voting a consensus "Measured" weight
for relays with the Authority flag. Now these relays will be
considered unmeasured, which should reserve their bandwidth
for their dir auth role and minimize distractions from other roles.
In place of the "Measured" weight, they now include a
"MeasuredButAuthority" weight (not used by anything) so the bandwidth
authority's opinion on this relay can be recorded for posterity.
Resolves ticket 40698.Tor: 0.4.7.x-post-stableRoger DingledineRoger Dingledinehttps://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/630dirauth: Change dizum IP address2022-10-26T18:33:49ZDavid Gouletdgoulet@torproject.orgdirauth: Change dizum IP addressCloses #40687
Signed-off-by: David Goulet <dgoulet@torproject.org>Closes #40687
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.8.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org