The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-03-10T14:13:30Zhttps://gitlab.torproject.org/tpo/web/donate-neo/-/issues/3CRM integration2024-03-10T14:13:30ZKezCRM integrationcontext donate-static#111
this issue is to coordinate the design and implementation of the civicrm data layer in donate-neo. the planned design is to have donate-neo use the civicrm REST api over a secure connection (like an ssh tunnel)...context donate-static#111
this issue is to coordinate the design and implementation of the civicrm data layer in donate-neo. the planned design is to have donate-neo use the civicrm REST api over a secure connection (like an ssh tunnel).
data needs to flow from civi to django; for things like active perks, YEC total, etc. the work for this is currently in the `civicrm-integration` branch.
the civi integration is being accomplished with a repository pattern. a main `CivicrmRepositoryProtocol` interface defines the methods for retrieving data from civi (currently just `get_active_perks` and `get_yec_total`). all of these methods are asynchronous; django isn't completely async-ready yet, but making these methods async gives us an easy upgrade path. a `WithSyncMeta` metaclass adds synchronous versions of the async methods, using `asgiref.sync.async_to_sync`, so that calling code doesn't need to do the heavy lifting of wrapping these asynchronous methods.
a `CivicrmRepositoryMock` class provides a mock implementation of the civi repository interface for testing, until i can work with @mathieu to set up an implementation that uses the REST APIstephenstephenhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40768Decide whether to disable circuit cannibalization entirely2023-04-12T14:47:42Zgabi-250Decide whether to disable circuit cannibalization entirelyThe discussions around #40570 reignited a discussion about circuit cannibalization, and whether the performance improvements it provides (if any) justify the maintenance costs of keeping it around. This ticket is about deciding whether w...The discussions around #40570 reignited a discussion about circuit cannibalization, and whether the performance improvements it provides (if any) justify the maintenance costs of keeping it around. This ticket is about deciding whether we should disable cannibalization in c-tor.https://gitlab.torproject.org/tpo/core/tor/-/issues/40767Investigate high circuit build error rates in simulation2023-04-12T14:46:43Zgabi-250Investigate high circuit build error rates in simulationWe ran some shadow simulations to debug/repro the issue from #40570, and @jnewsome noticed the onion service clients have consistently high [circuit build failure rates](https://gitlab.torproject.org/tpo/core/tor/-/issues/40570#note_2883...We ran some shadow simulations to debug/repro the issue from #40570, and @jnewsome noticed the onion service clients have consistently high [circuit build failure rates](https://gitlab.torproject.org/tpo/core/tor/-/issues/40570#note_2883257).
We should figure out what causes these circuit build failures.https://gitlab.torproject.org/tpo/network-health/margot/-/issues/8Come up with a plan for our efforts of finding similar relays2024-02-19T17:21:32ZGeorg KoppenCome up with a plan for our efforts of finding similar relaysWe want at some point figure out what similar relays to a relay X or a group of relays XYZ means. We should look at the literature and proposals that showed up in the past to create a plan and follow-up tickets.
https://lists.torproject...We want at some point figure out what similar relays to a relay X or a group of relays XYZ means. We should look at the literature and proposals that showed up in the past to create a plan and follow-up tickets.
https://lists.torproject.org/pipermail/network-health/2021-April/000672.html and phw's work around sybil hunting are good starting points here.jugajugahttps://gitlab.torproject.org/tpo/core/arti/-/issues/781Consider tor_bytes::write/read_counted_u8 etc2023-03-24T18:49:34ZNick MathewsonConsider tor_bytes::write/read_counted_u8 etcWe frequently want to encode a number of objects as a u8 or u16, and then encode the objects one by one. We could benefit from a helper method in Reader and/or Writer to do that.
One possible API:
```
impl Reader {...
pub fn read_co...We frequently want to encode a number of objects as a u8 or u16, and then encode the objects one by one. We could benefit from a helper method in Reader and/or Writer to do that.
One possible API:
```
impl Reader {...
pub fn read_counted_u8<V:Readable>(&mut self) -> Result<Vec<V>> { ... }
}
trait Writer {
pub fn write_counted_u8<V:Writeable>(&mut self, slice: &[V]) -> EncodeResult<()> {...}
}
```
This comes out of a discussion on !1052https://gitlab.torproject.org/tpo/core/tor/-/issues/40761DDoS mitigation: analysis to understand relay-to-relay connections from non-r...2023-04-12T14:46:14ZbnmDDoS mitigation: analysis to understand relay-to-relay connections from non-relay IPs
We are working on a tor proposal that should help
with protecting non-guard relays from a large fraction
of the DDoS load.
In first tests we have seen a 55% CPU usage decrease
when deploying our proposed mitigations, but we
want to mak...
We are working on a tor proposal that should help
with protecting non-guard relays from a large fraction
of the DDoS load.
In first tests we have seen a 55% CPU usage decrease
when deploying our proposed mitigations, but we
want to make sure that we are not introducing an
over blocking problem. We know about a few
configurations when a relay will use a source IP that is not in
consensus to connect to other relays (OutboundBindAddress, OutboundBindAddressOR)
but we would like to have some actual data about it.
To measure, understand and solve that potential problem and to
back up the proposal with some actual data we would
like to measure the following on our tor relays:
Log when our non-guard tor relays get
an authenticated relay to relay connection to our ORPort
from a source IP that is not in consensus and not in
the exit lists:
```
timestamp relay-fingerprint source-IP
```
If the "and not in the exit lists" part is too hard,
we can take care of that in post-processing of the logs
to filter them out.
We do not care about client to relay connections and do not want to log them.
Would it be possible to provide a patch or branch
that implements that logging on top of main?
It does not have to be in a release and we will run it
only temporarily.
thank you!https://gitlab.torproject.org/tpo/core/torspec/-/issues/191KH reuse; ESTABLISH_INTRO HANDSHAKE_AUTH MAC lacks distinguishing string2023-04-12T14:46:06ZIan Jacksoniwj@torproject.orgKH reuse; ESTABLISH_INTRO HANDSHAKE_AUTH MAC lacks distinguishing string```
The HANDSHAKE_AUTH field contains the MAC of all earlier fields in
the cell using as its key the shared per-circuit material ("KH")
generated during the circuit extension protocol; see tor-spec.txt
section 5.2, "Setting c...```
The HANDSHAKE_AUTH field contains the MAC of all earlier fields in
the cell using as its key the shared per-circuit material ("KH")
generated during the circuit extension protocol; see tor-spec.txt
section 5.2, "Setting circuit keys". It prevents replays of
ESTABLISH_INTRO cells.
```
Ie there is no distinguishing string that might distinguish other uses of KH. I looked for other uses of KH and it seems to appear only in CREATED/EXTENDED.
Overall, the use of KH seems a bit odd. The specs aren't clear on what its type and usage are. If it's a MAC key, it ought not to be sent in plaintext. If it's a nonce, using it as a MAC key is odd. This situation is a hazard which might introduce confusion/reuse weaknesses when the protocol is extended in future.https://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/issues/15Aggregate network totals for metrics with too many data points2024-01-16T13:49:10ZHiroAggregate network totals for metrics with too many data pointsWe should aggregate network totals when computing metrics that have too many data points to be aggregated by VictoriaMetrics itself.
One example is ``desc_relay_dirreq_v3_responses`` which can be aggregated by relay or a few other flags...We should aggregate network totals when computing metrics that have too many data points to be aggregated by VictoriaMetrics itself.
One example is ``desc_relay_dirreq_v3_responses`` which can be aggregated by relay or a few other flags but it cannot be aggregated over all relays by the timeseries DB.
This metric comes from parsing ExtraInfoDescriptor. I think a good approach would be to create an aggregated metrics that collects the total number of dirreq_v3_responses over a run of the parser. We can then aggregate the different aggregated measurement that we do over the course of a range of time.HiroHirohttps://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/87Clicking "Make Default" on Windows 11/Fedora 37 doesn't do anything2023-09-18T20:27:48ZruihildtClicking "Make Default" on Windows 11/Fedora 37 doesn't do anythingGoing to `about:preferences` in General, clicking "Make Default" on Windows 11 doesn't do anything.
Also restarting the browser and clicking on the popup inviting to make it default has the same (non)result.
Sub issues:
- [ ] Windows: #...Going to `about:preferences` in General, clicking "Make Default" on Windows 11 doesn't do anything.
Also restarting the browser and clicking on the popup inviting to make it default has the same (non)result.
Sub issues:
- [ ] Windows: #80
- [ ] Linux: #233Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41655Text in the Try Onion Services popup could be clearer2024-03-13T17:04:49ZhenryText in the Try Onion Services popup could be clearerI feel like some of the text in the "Try Onion Services" popup is a bit misleading:
## Title
It is currently "*Try* Onion Services", but this is a setting a preference that will be applied indefinitely, rather than for a short time. So...I feel like some of the text in the "Try Onion Services" popup is a bit misleading:
## Title
It is currently "*Try* Onion Services", but this is a setting a preference that will be applied indefinitely, rather than for a short time. So it seems like it should be more like "Use Onion Services".
## Body
The first sentence is
> There is a more private and secure version of this site available over the Tor network via onion services.
Given the context of this being shown when you visit a HTTPS site, this seems to be telling the user that the current connection they have to the HTTPS site is less private and less secure than if they used the onion site. Moreover, there is no text in the "Learn more" link (https://tb-manual.torproject.org/onion-services/) to back this up. It only says
> All traffic between Tor users and onion services is end-to-end encrypted, so you do not need to worry about connecting over HTTPS
but we already have HTTPS-Only mode in the browser.
In contrast, the second sentence
> Onion services help website publishers and their visitors defeat surveillance and censorship.
is easily understood and backed up.
I feel like maybe this first sentence should be more of a light overview of what an onion service *is*, with the second sentence being the benefits, making it clear what is benefiting the tor browser user.
## Button label
At least for me, "Not Now" tends to mean "I will bother you again in the future until you select the other option", so it can imply the *popup* will shown again for the next onion-available site, even though the user will never see it again. I think this is *trying* to indicate that you can always set this preference in the "Privacy & Security" settings in the future, but that could just be part of the body text if it is important.
## Design estimate:
* Complexity: low (1 days)
* Think about:
* How would a new user understand this? Do a mini user journey.
* What are the different ways the copy / design can be misunderstood?
* Ask:
* What is this thing?
* How does it benefit me?
* What are you asking me to do?
* Uncertainty level: high (2)
* I don't do much copy, so it's a bit of a challenge for me.
* There could be lenghty back and forth between stakeholders discussing the copy.
* Total: 1-2 dayshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41620Improve the UX of the request a bridge dialog2024-03-05T18:48:23ZdonutsImprove the UX of the request a bridge dialogFollowing recent improvements to the built-in bridges (https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41617) and provide a bridge dialogs (https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40552), w...Following recent improvements to the built-in bridges (https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41617) and provide a bridge dialogs (https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40552), we should also take a look at improving the UX of the request a bridge dialog. However it makes sense to wait on the outcome of https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/49 first, where the Anti-Censorship team will be considering a new CAPTCHA strategy.https://gitlab.torproject.org/tpo/core/arti/-/issues/766Should cargo-audit become advisory in CI?2023-04-25T15:39:30ZNick MathewsonShould cargo-audit become advisory in CI?Twice in the last 24 hours, I have had a branch where CI was passing before start failing because a package _which was okay when I opened the branch_ became insecure before the branch was merged.
Maybe we should make this an advisory fa...Twice in the last 24 hours, I have had a branch where CI was passing before start failing because a package _which was okay when I opened the branch_ became insecure before the branch was merged.
Maybe we should make this an advisory failure, and not have it make the branch unmergeable? OTOH, if we ignore this warning, it could allow us to merge known-insecure crates.https://gitlab.torproject.org/tpo/core/arti/-/issues/764Review use of manual slicing operations2023-10-10T16:14:56ZIan Jacksoniwj@torproject.orgReview use of manual slicing operationsIdeally we would avoid, as much as possible, manual slicing operations on any kind of buffers. We should use abstractions which avoid mistaken lengths etc. We're pretty good with this for parsing/writing binary messages, but it mostly ...Ideally we would avoid, as much as possible, manual slicing operations on any kind of buffers. We should use abstractions which avoid mistaken lengths etc. We're pretty good with this for parsing/writing binary messages, but it mostly goes out of the window when we do cryptography.
This should be improved. The work involves reviewing existing code, designing new abstractions, and deploying them.
```
16:10 <+Diziet> [much context elided]
https://security-tracker.debian.org/tracker/CVE-2022-2097
16:10 <+Diziet> Nowadays I always read things like this wearing my RESF beanie.
16:10 <+Diziet> And I wondered, could we have a bug like this?
16:11 <+Diziet> And sadly the answer is yes, because our pattern for applying a
stream cipher is to apply it to &mut [u8]
16:12 <+Diziet> And we sometimes slice and dice buffers rather than using
Readers and things.
```https://gitlab.torproject.org/tpo/core/tor/-/issues/40747android: fdsan SIGABRT tor_main_configuration_free2023-04-12T14:45:21Zsbsandroid: fdsan SIGABRT tor_main_configuration_free### Summary
When testing tor-0.4.7.13 on Android 13, I experienced a `SIGABRT` in `tor_main_configuration_free` caused by [fdsan](https://android.googlesource.com/platform/bionic/+/master/docs/fdsan.md). The reason why fdsan causes an a...### Summary
When testing tor-0.4.7.13 on Android 13, I experienced a `SIGABRT` in `tor_main_configuration_free` caused by [fdsan](https://android.googlesource.com/platform/bionic/+/master/docs/fdsan.md). The reason why fdsan causes an abort is that the owning control socket is closed twice. I noticed this crash as part of testing a release candidate of [OONI Probe Android](https://github.com/ooni/probe-android/) where we embed `libtor.a`.
The corresponding OONI Probe issue is: https://github.com/ooni/probe/issues/2405.
### Steps to reproduce
I do not have a very simple procedure to reproduce the issue that does not involve OONI Probe and its build system.
However, the underlying issue is independent of Android. The only reason why Android matters is that the fdsan notices the double close of the same file descriptor and hence triggers a crash (for Android API level >= 30).
Because of this, here are instructions to reproduce the underlying issue using GNU/Linux (I used Ubuntu 22.04):
1. clone tor
2. `git checkout tor-0.4.7.13`
3. `git apply tor.diff` where `tor.diff` is the following patch:
```diff
diff --git a/src/core/mainloop/connection.c b/src/core/mainloop/connection.c
index cf25213cb1..d690de3892 100644
--- a/src/core/mainloop/connection.c
+++ b/src/core/mainloop/connection.c
@@ -149,6 +149,8 @@
#include "core/or/congestion_control_flow.h"
+#include <stdio.h>
+
/**
* On Windows and Linux we cannot reliably bind() a socket to an
* address and port if: 1) There's already a socket bound to wildcard
@@ -949,6 +951,7 @@ connection_free_minimal(connection_t *conn)
if (SOCKET_OK(conn->s)) {
log_debug(LD_NET,"closing fd %d.",(int)conn->s);
+ fprintf(stderr, "SBSDEBUG: connection_free_minimal %lld\n", (long long)conn->s);
tor_close_socket(conn->s);
conn->s = TOR_INVALID_SOCKET;
}
diff --git a/src/feature/api/tor_api.c b/src/feature/api/tor_api.c
index 88e91ebfd5..fb49d92ad7 100644
--- a/src/feature/api/tor_api.c
+++ b/src/feature/api/tor_api.c
@@ -116,6 +116,11 @@ tor_main_configuration_setup_control_socket(tor_main_configuration_t *cfg)
cfg_add_owned_arg(cfg, "__OwningControllerFD");
cfg_add_owned_arg(cfg, buf);
+ fprintf(
+ stderr, "SBSDEBUG: tor_main_configuration_setup_control_socket %lld %lld\n",
+ (long long)fds[0], (long long)fds[1]
+ );
+
cfg->owning_controller_socket = fds[1];
return fds[0];
}
@@ -132,6 +137,10 @@ tor_main_configuration_free(tor_main_configuration_t *cfg)
raw_free(cfg->argv_owned);
}
if (SOCKET_OK(cfg->owning_controller_socket)) {
+ fprintf(
+ stderr, "SBSDEBUG: tor_main_configuration_free %lld\n",
+ (long long)cfg->owning_controller_socket
+ );
raw_closesocket(cfg->owning_controller_socket);
}
raw_free(cfg);
```
4. `./autogen.sh`
5. `./configure --disable-asciidoc`
6. `make`
7. `mkdir tmp`
8. `vi tmp/main.c` making sure it contains the following content:
```C
#include "../src/feature/api/tor_api.h"
#include <stdlib.h>
#include <unistd.h>
int main() {
tor_main_configuration_t *cfg = tor_main_configuration_new();
if (cfg == NULL) {
exit(1);
}
tor_control_socket_t sock = tor_main_configuration_setup_control_socket(cfg);
if (sock == INVALID_TOR_CONTROL_SOCKET) {
exit(2);
}
(void)close(sock); // close immediately (it's async on Android but it should not matter AFAICT)
(void)tor_run_main(cfg);
tor_main_configuration_free(cfg);
}
```
9. `gcc -Wall tmp/main.c -L. -ltor -levent -lcrypto -lssl -lz -lm`
10. `./a.out` which should produce this output:
```
SBSDEBUG: tor_main_configuration_setup_control_socket 4 5
Feb 02 17:18:07.330 [notice] Tor 0.4.7.13 (git-7c1601fb6edd780f) running on Linux with Libevent 2.1.12-stable, OpenSSL 3.0.2, Zlib 1.2.11, Liblzma N/A, Libzstd N/A and Glibc 2.35 as libc.
Feb 02 17:18:07.330 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://support.torproject.org/faq/staying-anonymous/
Feb 02 17:18:07.330 [notice] Configuration file "/usr/local/etc/tor/torrc" not present, using reasonable defaults.
Feb 02 17:18:07.331 [notice] Opening Socks listener on 127.0.0.1:9050
Feb 02 17:18:07.331 [notice] Opened Socks listener connection (ready) on 127.0.0.1:9050
Feb 02 17:18:07.000 [notice] Bootstrapped 0% (starting): Starting
Feb 02 17:18:07.000 [notice] Starting with guard context "default"
Feb 02 17:18:07.000 [notice] Owning controller connection has closed -- exiting now.
SBSDEBUG: connection_free_minimal 5
Feb 02 17:18:07.000 [notice] Catching signal TERM, exiting cleanly.
SBSDEBUG: connection_free_minimal 8
SBSDEBUG: tor_main_configuration_free 5
```
If you analyze the above output, you would see that the file descriptor `5` is closed twice. This output is almost identical to the output that I have seen in the Android logcat (more on that below). Also, I _think_ the way in which I am using the embedding API above (which mirrors our more complex implementation written in Go) is fine; if not, please educate me.
(If you want to reproduce the same problem I experience on Android, I can either explain how to compile and test OONI Probe for Android, or I can try to work on creating a simple Android PoC like the one above.)
### What is the current bug behavior?
We're in an embedding scenario where we eventually call `tor_run_main`, as mentioned in the previous section.
This is the sequence of APIs we call along with my best understanding of what happens inside `tor`:
We create a configuration using `tor_main_configuration_new`.
Calling `tor_main_configuration_setup_control_socket` creates a pair of sockets, returns `fds[0]` to us, and retains `fds[1]` inside `tor_main_configuration_t::owning_controller_socket`.
Calling `tor_run_main` calls (in a way that is not 100% clear to me) `options_act` that passes the `owning_controller_socket` to `control_connection_add_local_fd`. In turn, this function registers the file descriptor `fds[1]` as the control connection.
Eventually we `close` the `fds[0]` that was returned to us, which causes `tor` to stop its libevent loop.
When `tor_run_main` terminates, it calls `tor_cleanup`, which calls `tor_free_all`, which calls `connection_free_all`, which calls `connection_free_minimal` for each connection, including the owning file descriptor `fds[1]`.
After `tor_run_main`, we call `tor_main_configuration_free`. In turn, this function calls `raw_closesocket` on the `owning_controller_socket`, which is hence closed for the second time.
On Android with API level >= 30, the [fdsan](https://android.googlesource.com/platform/bionic/+/master/docs/fdsan.md) sanitizer notices the second close and _sometimes_ (roughly 50%) this fact causes the app to abort.
### What is the expected behavior?
I think tor should duplicate the file descriptor before registering it into the core event loop such that there is a single owner of each of the two duplicates. The `tor_main_configuration_free` function owns one of them and the core event loop owns the other one. This semantics shouldn't cause any issue with the fdsan sanitizer because it's designed to enforce it.
Alternatively, it should probably be documented to use API level < 30 (where the fdsan only warns). Or it should be documented that one should use the proper fdsan API to disable crashing on double close. (I do not remember seeing these warnings when I read how to use the embedding API and a quick `git grep fdsan` or `git grep "API level"` did not return anything, but it's still possible that I overlooked _some_ documentation about this issue.)
### Environment
- Which version of Tor are you using?
tor-0.4.7.13
- Which operating system are you using?
Android 13 (but I also provided a minimal example on GNU/Linux)
- Which installation method did you use?
We cross compile tor for Android using [our cross compilation scripts](https://github.com/ooni/probe-cli/tree/v3.17.0-alpha.1/internal/cmd/buildtool).
We obtain a static set of libraries and a `tor_api.h` that we link as part of building an AAR with [go mobile](https://github.com/golang/mobile).
We use the obtained AAR as a dependency for [OONI Probe Android](https://github.com/ooni/probe-android/).
The code that specifically invokes tor [is written in Go](https://github.com/ooni/probe-android/). The sequence of events in terms of the Tor embedding API is the one I described above in the "what is the current bug behavior?" section.
However, I have also provided a minimal example for GNU/Linux that shows the double-close issue.
### Relevant logs and/or screenshots
The following is an excerpt from the tombstone generated by the crashing app:
```
[notice] Catching signal TERM, exiting cleanly.
fdsan: attempted to close file descriptor 104, expected to be unowned, \
actually owned by unique_fd 0x70b7e5f19c
[...]
ABI: 'arm64'
Timestamp: 2023-02-02 11:39:31.181519664+0100
Cmdline: org.openobservatory.ooniprobe.experimental
pid: 16472, tid: 16593, name: AsyncTask #1 >>> org.openobservatory.ooniprobe.experimental <<<
signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
[...]
backtrace:
#00 pc 0000000000055c48 .../lib64/bionic/libc.so (fdsan_error(char const*, ...)+556) (...)
#01 pc 0000000000055954 .../lib64/bionic/libc.so (android_fdsan_close_with_tag+732) (...)
#02 pc 00000000000560a8 .../lib64/bionic/libc.so (close+16) (...)
#03 pc 00000000012ad08c [...]/lib/arm64/libgojni.so (tor_main_configuration_free+128)
```
If I apply the patch that above I called `tor.diff` and run OONI Probe on Android, I see this in the logcat:
```
SBSDEBUG: tor_main_configuration_setup_control_socket 94 98 // <- fds[0] and fds[1]
[...]
[notice] Catching signal TERM, exiting cleanly.
SBSDEBUG: connection_free_minimal 141
SBSDEBUG: connection_free_minimal 98 // <- first close of fds[1]
SBSDEBUG: connection_free_minimal 116
SBSDEBUG: connection_free_minimal 152
SBSDEBUG: tor_main_configuration_free 98 // <- second close of fds[1]
```
### Possible fixes
The following patch makes the app work as intended (i.e., no crashes for several runs):
```diff
diff --git a/src/feature/api/tor_api.c b/src/feature/api/tor_api.c
index 88e91ebfd5..2773949264 100644
--- a/src/feature/api/tor_api.c
+++ b/src/feature/api/tor_api.c
@@ -131,9 +131,13 @@ tor_main_configuration_free(tor_main_configuration_t *cfg)
}
raw_free(cfg->argv_owned);
}
+ /* See https://github.com/ooni/probe/issues/2405 to understand
+ why we're not closing the controller socker here. */
+ /*
if (SOCKET_OK(cfg->owning_controller_socket)) {
raw_closesocket(cfg->owning_controller_socket);
}
+ */
raw_free(cfg);
}
```
That said, I think this patch is wrong because it leaks the file descriptor when `tor_run_main` returns prematurely (e.g., when the command line flags are wrong). Because of this, I think the more robust fix would be to duplicate the file descriptor before registering it into the libevent loop, as I explained above.Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/754should upgrading *some* dependancies be considered a breaking change2023-04-25T15:37:54Ztrinity-1686ashould upgrading *some* dependancies be considered a breaking changeUpgrading some dependencies can break downstream integrator. In particular, going from `rusqlite` 0.27 to 0.28 prevented a seamless upgrade of onionmasq from arti-some-old-version to arti-1.1.0, because 0.27 and 0.28 can't live together ...Upgrading some dependencies can break downstream integrator. In particular, going from `rusqlite` 0.27 to 0.28 prevented a seamless upgrade of onionmasq from arti-some-old-version to arti-1.1.0, because 0.27 and 0.28 can't live together apparently.
(found while working on onionmasq.)https://gitlab.torproject.org/tpo/core/tor/-/issues/40746Conflicting logic about whether bridges need descriptors for fetching dir inf...2023-04-12T14:42:46ZRoger DingledineConflicting logic about whether bridges need descriptors for fetching dir info from themIf you start your Tor with a pile of configured bridges but nothing cached, your Tor will sample the configured bridges to pick its ordered list of primary entry guards, and launch descriptor fetches to each of them.
But if the descript...If you start your Tor with a pile of configured bridges but nothing cached, your Tor will sample the configured bridges to pick its ordered list of primary entry guards, and launch descriptor fetches to each of them.
But if the descriptor hasn't arrived yet, while trying to bootstrap dir info you get these confusing messages in your logs:
```
Jan 31 18:56:44.928 [notice] Ignoring directory request, since no bridge nodes are available yet.
```
Things do bootstrap eventually, but it takes longer than it should, and the pile of scary log messages is scary.
What's going on here?
The way the log message comes about is that directory_get_from_dirserver() calls
```
const node_t *node = guards_choose_dirguard(dir_purpose, &guard_state);
if (node && node->ri) {
[...]
} else {
[...]
log_notice(LD_DIR, "Ignoring directory request, since no bridge "
"nodes are available yet.");
}
```
i.e. guards_choose_dirguard had better return a bridge for which we have the descriptor, or we're going to log a complaint and abort the directory fetch attempt.
But in select_primary_guard_for_circuit(), we do
```
const int need_descriptor = (usage == GUARD_USAGE_TRAFFIC);
[...]
SMARTLIST_FOREACH_BEGIN(gs->primary_entry_guards, entry_guard_t *, guard) {
[...]
if (guard->is_reachable != GUARD_REACHABLE_NO) {
if (need_descriptor && !guard_has_descriptor(guard)) {
log_info(LD_GUARD, "Guard %s does not have a descriptor",
entry_guard_describe(guard));
continue;
}
```
That is, in select_primary_guard_for_circuit() we require that the bridge have a descriptor only for the GUARD_USAGE_TRAFFIC case, but then in directory_get_from_dirserver() we expect that the bridge will always have a descriptor, even in the GUARD_USAGE_DIRGUARD case.
In normal operation this bug isn't a big deal, because it is a race to finish fetching the descriptor before we happen to pick it for asking directory info. But with the #40578 fix, where we defer fetching the descriptor if we won't use the bridge for the GUARD_USAGE_TRAFFIC case, the bug becomes more obvious.
I believe the fix is simply to always need_descriptor in select_primary_guard_for_circuit() -- meaning when we're going to launch a directory fetch we always choose among our primary guards who have descriptors already.https://gitlab.torproject.org/tpo/network-health/onbasca/-/issues/135Refactor code from onbrisca to onbasca2024-01-24T11:55:05ZjugaRefactor code from onbrisca to onbascajugajugahttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41582Tor Browser Android app context menu still has option to open "New Tab" (not ...2023-08-26T06:09:43ZDan BallardTor Browser Android app context menu still has option to open "New Tab" (not private). Crashes when invokedTor Browser Android app has a context menu item on the app on home screen's for "New Tab" (the non private version). This should not appear. Semi thankfully, when invoked, tor browser seems to crash and restart.
This menu item should be...Tor Browser Android app has a context menu item on the app on home screen's for "New Tab" (the non private version). This should not appear. Semi thankfully, when invoked, tor browser seems to crash and restart.
This menu item should be removedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40739[warn] Possible compression bomb; abandoning stream.2023-11-18T19:42:40Zcomputer_freak[warn] Possible compression bomb; abandoning stream.Relay with `Tor 0.4.7.13`:
```
[warn] Possible compression bomb; abandoning stream.
[warn] Unable to decompress HTTP body (tried Zstandard compressed, on Directory connection (client reading) with 86.59.21.38:80).
```
obfs4 Bridge with ...Relay with `Tor 0.4.7.13`:
```
[warn] Possible compression bomb; abandoning stream.
[warn] Unable to decompress HTTP body (tried Zstandard compressed, on Directory connection (client reading) with 86.59.21.38:80).
```
obfs4 Bridge with `Tor 0.4.7.13`:
```
[warn] Possible compression bomb; abandoning stream.
[warn] Error while uncompressing data: bad input?
[warn] Unable to decompress HTTP body (tried Zstandard compressed, on Directory connection (client reading) with 95.214.53.221:443).
```
Relay with `Tor 0.4.8.0-alpha-dev`:
```
[warn] Possible compression bomb; abandoning stream.
[warn] Unable to decompress HTTP body (tried Zstandard compressed, on Directory connection (client reading) with 199.58.81.140:80).
```
There are no more logs on `notice` log level.
A user at the [forum](https://forum.torproject.net/t/compression-bomb-in-tor-logs/6226) has the same problem.Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41555HTTPS-only warning page (from Firefox) not suited for tor browser context2024-02-27T19:08:10ZhenryHTTPS-only warning page (from Firefox) not suited for tor browser contextCurrently, if you try and visit a HTTP website, like http.badssl.com, you get a warning page. But the text of the warning page comes from Firefox, and is not really suited for Tor Browser.
![screenshot of HTTPS-Only warning page](/uploa...Currently, if you try and visit a HTTP website, like http.badssl.com, you get a warning page. But the text of the warning page comes from Firefox, and is not really suited for Tor Browser.
![screenshot of HTTPS-Only warning page](/uploads/166669f773488064f40f4b3c3f33f151/Screenshot_from_2023-01-06_15-50-08.png)
Currently it says
> **HTTPS-Only Mode Alert**
>
> **Secure Site Not Available**
>
> You’ve enabled HTTPS-Only Mode for enhanced security, and a HTTPS version of http.badssl.com is not available.
The first part should probably be more like
> HTTPS-Only Mode is enabled in Tor Browser for enhanced security
since it is not a user choice to turn this on. Plus, the second part should probably be
> a HTTPS version of http.badssl.com was not found.
since the HTTPS version could be available on another circuit (or it may have been triggered by a timeout as in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41068).
In addition, the "Learn More…" link takes the user to https://support.mozilla.org/en-US/kb/https-only-prefs which includes a good explanation of HTTP vs HTTPS, but it has no Tor Browser or network context and gives instructions on how to turn on or off https-only mode.
Finally, we should probably let the user know that sometimes reloading the page with a new circuit can establish a HTTPS connection (e.g. if your current exit node is bad), and perhaps give them a button to do so.