Tor merge requestshttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests2021-03-01T13:37:20Zhttps://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/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/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/176Ticket40162 044: Update the required/recommended protocol versions2020-10-27T13:41:26ZNick MathewsonTicket40162 044: Update the required/recommended protocol versionsWe're about to drop support for parsing documents from before 0.2.9 -- ones without Ed25519 signatures and keys. We should adjust the required/recommended protocol versions accordingly.
Closes #40162
Github PR at https://github.com/t...We're about to drop support for parsing documents from before 0.2.9 -- ones without Ed25519 signatures and keys. We should adjust the required/recommended protocol versions accordingly.
Closes #40162
Github PR at https://github.com/torproject/tor/pull/2094Tor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/139statistics: Properly count all rendezvous cells (avoid undercounting). [044+]2020-09-08T15:16:40ZGeorge Kadianakisstatistics: Properly count all rendezvous cells (avoid undercounting). [044+]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.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/104Remove channel_is_canonical_is_reliable (for 0.4.4..)2020-08-12T12:42:51ZNick MathewsonRemove channel_is_canonical_is_reliable (for 0.4.4..)This MR merges !103 to maint-0.4.4, and resolves conflicts.
We should merge this before thinking about a backport of !101.
See also #40081This MR merges !103 to maint-0.4.4, and resolves conflicts.
We should merge this before thinking about a backport of !101.
See also #40081Tor: 0.4.4.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/90Bug40076 044: Forward-port of !89 to 0.4.42020-07-31T02:01:04ZNick MathewsonBug40076 044: Forward-port of !89 to 0.4.4This MR contains !89, plus a fix for a merge conflict in 0.4.4.
See #40076 .This MR contains !89, plus a fix for a merge conflict in 0.4.4.
See #40076 .Tor: 0.4.4.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/85Use _lseeki64() on windows.2020-07-30T13:37:27ZNick MathewsonUse _lseeki64() on windows.Fixes bug 31036; bugfix on 0.2.1.8-alpha when we moved the logging
system to use posix fds.
Closes #31036Fixes bug 31036; bugfix on 0.2.1.8-alpha when we moved the logging
system to use posix fds.
Closes #31036Tor: 0.4.4.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/65Use gitlab-friendly URLs when formatting changelogs as HTML2020-07-20T14:32:42ZNick MathewsonUse gitlab-friendly URLs when formatting changelogs as HTMLOur old https://bugs.torproject.org/nnnn URLs only work for bugs
numbered before 40000. Newer gitlab bugs need to have specific
projects mentioned.
This patch assumes that bugs are in tpo/core/tor by default, but
allows us to refer to ...Our old https://bugs.torproject.org/nnnn URLs only work for bugs
numbered before 40000. Newer gitlab bugs need to have specific
projects mentioned.
This patch assumes that bugs are in tpo/core/tor by default, but
allows us to refer to several other projects by saying
e.g. "chutney#nnnnn" if we want.
Our format_changelog script is not distributed, so no changes file
is necessary.
Closes #40051.Tor: 0.4.4.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://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/33hs-v3: Remove a possible BUG() condition2020-07-09T14:08:57ZDavid Gouletdgoulet@torproject.orghs-v3: Remove a possible BUG() conditionWhen receiving an introduction NACK, the client either decides to close or
re-extend the circuit to another intro point.
In order to do this, the service descriptor needs to exists but it is possible
that it gets removed from the cache ...When receiving an introduction NACK, the client either decides to close or
re-extend the circuit to another intro point.
In order to do this, the service descriptor needs to exists but it is possible
that it gets removed from the cache between the establishement of the
introduction circuit and the reception of the (N)ACK.
For that reason, the BUG(desc == NULL) is removed because it is a possible
normal use case. Tor recovers gracefully already.
Fixes #34087
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.4.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/26Revert "config: Make clients tell dual-stack exits they prefer IPv6"2020-07-09T14:00:29ZDavid Gouletdgoulet@torproject.orgRevert "config: Make clients tell dual-stack exits they prefer IPv6"This reverts commit bf2a399fc0d90df76e091fa3259f7c1b8fb87781.
PR CI: https://github.com/torproject/tor/pull/1979This reverts commit bf2a399fc0d90df76e091fa3259f7c1b8fb87781.
PR CI: https://github.com/torproject/tor/pull/1979Tor: 0.4.4.x-finalNick MathewsonNick Mathewson