Tor merge requestshttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests2021-05-17T13:04:32Zhttps://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/369Stop calling evdns_set_random_bytes_fn()2021-10-20T17:37:18ZNick MathewsonStop calling evdns_set_random_bytes_fn()This function has been a no-op since Libevent 2.0.4-alpha, when
libevent got an arc4random() implementation. Libevent has finally
removed it, which will break our compilation unless we stop calling
it. (This is currently breaking compi...This function has been a no-op since Libevent 2.0.4-alpha, when
libevent got an arc4random() implementation. Libevent has finally
removed it, which will break our compilation unless we stop calling
it. (This is currently breaking compilation in OSS-fuzz.)
Closes #40371.Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://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/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/326Remove mallinfo() from codebase2021-03-01T13:37:20ZDavid Gouletdgoulet@torproject.orgRemove mallinfo() from codebaseNow deprecated in libc >= 2.33
Closes #40309
Signed-off-by: David Goulet <dgoulet@torproject.org>Now deprecated in libc >= 2.33
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/324Remove mallinfo() from codebase2021-03-01T13:37:18ZDavid Gouletdgoulet@torproject.orgRemove mallinfo() from codebaseNow deprecated in libc >= 2.33
Closes #40309
Signed-off-by: David Goulet <dgoulet@torproject.org>Now deprecated in libc >= 2.33
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/256hs-v3: Require reasonably live consensus2021-02-01T18:59:31ZDavid Gouletdgoulet@torproject.orghs-v3: Require reasonably live consensus
Some days before this commit, the network experienced a DDoS on the directory authorities that prevented them to generate a consensus for more than 5 hours straight.
That in turn entirely disabled onion service v3, client and service ...
Some days before this commit, the network experienced a DDoS on the directory authorities that prevented them to generate a consensus for more than 5 hours straight.
That in turn entirely disabled onion service v3, client and service side, due to the subsystem requiring a live consensus to function properly.
We know require a reasonably live consensus which means that the HSv3 subsystem will to its job for using the best consensus tor can find. If the entire network is using an old consensus, than this should be alright.
If the service happens to use a live consensus while a client is not, it should still work because the client will use the current SRV it sees which might be the previous SRV for the service for which it still publish descriptors for.
If the service is using an old one and somehow can't get a new one while clients are on a new one, then reachability issues might arise. However, this is a situation we already have at the moment since the service will simply not work if it doesn't have a live consensus while a client has one.
Fixes #40237
Signed-off-by: David Goulet dgoulet@torproject.orgTor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/255hs-v3: Require reasonably live consensus2021-01-28T17:15:45ZDavid Gouletdgoulet@torproject.orghs-v3: Require reasonably live consensus
Some days before this commit, the network experienced a DDoS on the directory authorities that prevented them to generate a consensus for more than 5 hours straight.
That in turn entirely disabled onion service v3, client and service ...
Some days before this commit, the network experienced a DDoS on the directory authorities that prevented them to generate a consensus for more than 5 hours straight.
That in turn entirely disabled onion service v3, client and service side, due to the subsystem requiring a live consensus to function properly.
We know require a reasonably live consensus which means that the HSv3 subsystem will to its job for using the best consensus tor can find. If the entire network is using an old consensus, than this should be alright.
If the service happens to use a live consensus while a client is not, it should still work because the client will use the current SRV it sees which might be the previous SRV for the service for which it still publish descriptors for.
If the service is using an old one and somehow can't get a new one while clients are on a new one, then reachability issues might arise. However, this is a situation we already have at the moment since the service will simply not work if it doesn't have a live consensus while a client has one.
Fixes #40237
Signed-off-by: David Goulet dgoulet@torproject.orgTor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/254hs-v3: Require reasonably live consensus2021-01-28T17:15:43ZDavid Gouletdgoulet@torproject.orghs-v3: Require reasonably live consensusSome days before this commit, the network experienced a DDoS on the directory
authorities that prevented them to generate a consensus for more than 5 hours
straight.
That in turn entirely disabled onion service v3, client and service si...Some days before this commit, the network experienced a DDoS on the directory
authorities that prevented them to generate a consensus for more than 5 hours
straight.
That in turn entirely disabled onion service v3, client and service side, due
to the subsystem requiring a live consensus to function properly.
We know require a reasonably live consensus which means that the HSv3
subsystem will to its job for using the best consensus tor can find. If the
entire network is using an old consensus, than this should be alright.
If the service happens to use a live consensus while a client is not, it
should still work because the client will use the current SRV it sees which
might be the previous SRV for the service for which it still publish
descriptors for.
If the service is using an old one and somehow can't get a new one while
clients are on a new one, then reachability issues might arise. However, this
is a situation we already have at the moment since the service will simply not
work if it doesn't have a live consensus while a client has one.
Fixes #40237
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/243Fix Keccak undefined behavior on exotic platforms.2021-01-28T17:37:40ZGeorge KadianakisFix Keccak undefined behavior on exotic platforms.Bug reported and diagnosed in:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975977
Fixes bug #40210.Bug reported and diagnosed in:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975977
Fixes bug #40210.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/239Socks5: handle truncated client requests correctly2021-01-28T17:44:23ZNick MathewsonSocks5: handle truncated client requests correctlyPreviously, our code would send back an error if the socks5 request
parser said anything but DONE. But there are other non-error cases,
like TRUNCATED: we shouldn't send back errors for them.
This patch lowers the responsibility for se...Previously, our code would send back an error if the socks5 request
parser said anything but DONE. But there are other non-error cases,
like TRUNCATED: we shouldn't send back errors for them.
This patch lowers the responsibility for setting the error message
into the parsing code, since the actual type of the error message
will depend on what problem was encountered.
Fixes bug 40190; bugfix on 0.3.5.1-alpha.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/189Validate ed25519 keys and canonicity from circuit_n_conn_done()2020-11-09T21:18:18ZNick MathewsonValidate ed25519 keys and canonicity from circuit_n_conn_done()Fixes #40080. Bugfix on 0.2.7.2-alpha.
Fixes #40086.Fixes #40080. Bugfix on 0.2.7.2-alpha.
Fixes #40086.https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/186Ticket40165 035: Fix OpenSSL3 deprecation warnings2021-01-28T17:07:13ZNick MathewsonTicket40165 035: Fix OpenSSL3 deprecation warningsFixes #40165.
Fixes #40170.
Merges cleanly forward to master; see https://github.com/torproject/tor/pull/2100 for CI on master.Fixes #40165.
Fixes #40170.
Merges cleanly forward to master; see https://github.com/torproject/tor/pull/2100 for CI on master.Tor: 0.3.5.x-finalhttps://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/143Resolve a compilation warning in test_connection.c2021-01-19T17:54:24ZNick MathewsonResolve a compilation warning in test_connection.cInstead of casting an enum to a void and back, use a string --
that's better C anyway.
Fixes bug 40113; bugfix on 0.2.9.3-alpha.Instead of casting an enum to a void and back, use a string --
that's better C anyway.
Fixes bug 40113; bugfix on 0.2.9.3-alpha.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/140statistics: Properly count all rendezvous cells (avoid undercounting). [035+]2021-01-28T17:09:35ZGeorge Kadianakisstatistics: Properly count all rendezvous cells (avoid undercounting). [035+]tl;dr We were not counting cells flying from the client to the service, but we
were counting cells flying from the service to the client.
When a rendezvous cell arrives from the client to the RP, the RP forwards it to
the service.
For ...tl;dr We were not counting cells flying from the client to the service, but we
were counting cells flying from the service to the client.
When a rendezvous cell arrives from the client to the RP, the RP forwards it to
the service.
For this to happen, the cell first passes through command_process_relay_cell()
which normally does the statistics counting. However because the `rend_circ`
circuit was not flagged with `circuit_carries_hs_traffic_stats` in
rend_mid_rendezvous(), the cell is not counted there.
Then the cell goes to circuit_receive_relay_cell() which has a special code
block based on `rend_splice` specifically for rendezvous cells, and the cell
gets directly passed to `rend_circ` via a direct call to
circuit_receive_relay_cell(). The cell never passes through
command_process_relay_cell() ever again and hence is never counted by our
rephist module.
The fix here is to flag the `rend_circ` circuit with
`circuit_carries_hs_traffic_stats` so that the cell is counted as soon as it
hits command_process_relay_cell().
Furthermore we avoid double-counting cells since the special code block of
circuit_receive_relay_cell() makes us count rendezvous cells only as they enter
the RP and not as they exit it.
Fixes #40117.Tor: 0.3.5.x-finalhttps://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/130hs: Don't overwrite DoS parameters on circuit with consensus params2020-08-25T11:53:14ZDavid Gouletdgoulet@torproject.orghs: Don't overwrite DoS parameters on circuit with consensus paramsTurns out that the HS DoS defenses parameters were overwritten by the
consensus parameters everytime a new consensus would arrive.
This means that a service operator can still enable the defenses but as soon
as the intro point relay wou...Turns out that the HS DoS defenses parameters were overwritten by the
consensus parameters everytime a new consensus would arrive.
This means that a service operator can still enable the defenses but as soon
as the intro point relay would get a new consensus, they would be overwritten.
And at this commit, the network is entirely disabling DoS defenses.
Fix this by introducing an "explicit" flag that indicate if the
ESTABLISH_INTRO cell DoS extension set those parameters or not. If set, avoid
using the consenus at once.
We are not bumping the protover HSIntro value for this because 0.4.2.x series
is EOL in 1 month and thus 0.4.3.x would be the only series with this bug. We
are confident that a backport and then upgrade path to the latest 0.4.4.x
stable coming up soon is enough to mitigate this problem in the coming months.
It avoids the upgrade path on the service side by keeping the requirement for
protover HSIntro=5.
Fixes #40109
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/103Remove channel_is_canonical_is_reliable() (for 0.3.5..0.4.3)2020-10-07T12:06:01ZNick MathewsonRemove channel_is_canonical_is_reliable() (for 0.3.5..0.4.3)This function once served to let circuits continue to be built over
version-1 link connections. But such connections are long-obsolete,
and it's time to remove this check.
Closes #40081.This function once served to let circuits continue to be built over
version-1 link connections. But such connections are long-obsolete,
and it's time to remove this check.
Closes #40081.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/94Reject extra commas in protover2020-08-03T13:02:29ZNick MathewsonReject extra commas in protoverThis code is from cypherpunks, on #27194.
Closes #27194.
Github PR at https://github.com/torproject/tor/pull/2039This code is from cypherpunks, on #27194.
Closes #27194.
Github PR at https://github.com/torproject/tor/pull/2039