The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-09-05T17:50:35Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25528When ClientTransportPlugin is missing, tor connects directly to bridge addres...2022-09-05T17:50:35ZDavid Fifielddcf@torproject.orgWhen ClientTransportPlugin is missing, tor connects directly to bridge addresses, even if they have a transport nameStart `tcpdump -n host 83.212.101.3`
Run tor with this torrc:
```
UseBridges 1
Bridge obfs4 83.212.101.3:50002 A09D536DD1752D542E1FBB3C9CE4449D51298239 cert=lPRQ/MXdD1t5SRZ9MquYQNT9m5DV757jtdXdlePmRCudUU9CFUOX1Tm7/meFSyPOsud7Cw iat-mode...Start `tcpdump -n host 83.212.101.3`
Run tor with this torrc:
```
UseBridges 1
Bridge obfs4 83.212.101.3:50002 A09D536DD1752D542E1FBB3C9CE4449D51298239 cert=lPRQ/MXdD1t5SRZ9MquYQNT9m5DV757jtdXdlePmRCudUU9CFUOX1Tm7/meFSyPOsud7Cw iat-mode=0
```
See a connection to 83.212.101.3:50002, despite that, lacking a `ClientTransportPlugin` line, tor doesn't know how to connect to an "obfs4" bridge.
Another way to see it is with this torrc, using a phony address like meek and snowflake do:
```
UseBridges 1
Bridge dummy 0.0.3.0:1
```
tor actually tries to connect to the 0.0.3.0:1 address, and fails with an "Invalid argument" error:
```
[warn] Problem bootstrapping. Stuck at 5%: Connecting to directory server. (Invalid argument; RESOURCELIMIT; count 1; recommendation warn; host 0000000000000000000000000000000000000000 at 0.0.3.0:1)
```
I expected instead that tor would not try to connect to the address, but rather would show [this error message](https://gitweb.torproject.org/tor.git/tree/src/or/connection_or.c?h=tor-0.3.2.10#n1231):
> We were supposed to connect to bridge 'X' using pluggable transport 'Y', but we can't find a pluggable transport proxy supporting 'Y'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
The problem exists in both 0.2.9.14 and 0.3.4.0-alpha-dev, which are the two versions I tested.
I found this problem through a user report at legacy/trac#25527. The user was trying to run the Tor Browser tor, but they were in the wrong directory, so they were only getting torrc and not torrc-defaults. torrc contains `UseBridges` and `Bridge`, but torrc-defaults contains `ClientTransportPlugin`.
There was another ticket about tor occasionally connecting to PT bridges as if they were ordinary guards: legacy/trac#20532. It may be the same as this. At legacy/trac#25527 I speculated that the problem might have been caused by cached `Guard` entries, but that doesn't seem to be the case. All you have to do is omit the `ClientTransportPlugin` line.Tor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40100Mixing long lived streams with shorter connections causes hidden tor service ...2021-07-09T17:30:28Ztubby-torMixing long lived streams with shorter connections causes hidden tor service name (.onion) resolution/routing failuresFrom one single tor instance with default settings and a single client address, long-lived streams to some .onion addresses seems to eventually break name resolution/routing to other .onion addresses that are short-lived connections.
Fo...From one single tor instance with default settings and a single client address, long-lived streams to some .onion addresses seems to eventually break name resolution/routing to other .onion addresses that are short-lived connections.
For example:
- Copy a large file over ssh from Client to server a.onion, b.onion, c.onion. (simultaneously for several hours)
- Connect to server d.onion, e.onion, f.onion for a few commands, then disconnect several times during the long running streams.
Eventually and intermittently, connections to d.onion, e.onion, f.onion fail on the client-side only.
Tests to isolate the problem:
- Testing the connections from another clients works, confirming that the servers d.onion, e.onion, f.onion are still up and it is a problem with the client-side tor
- Forcing a `SIGNAL NEWNYM` on the client corrects the problem and the client can subsequently connect to d.onion, e.onion, f.onion. The bad side-effect is that all the long-running streams are disconnected (of course).
- Forcing very aggressive circuit rebuilding on the client-side tor mostly solves the problem but also causes more disconnection of streams. I haven't been able to isolate further which one of these options is actually fixing the problem, but providing these are further information for others.
```
KeepalivePeriod 1
LongLivedPorts
MaxCircuitDirtiness 30
NewCircuitPeriod 30
```
- Stream Isolation `SocksPort ... IsolateDestAddr` did NOT seem to help.
I suspect that stale circuits are remaining opened for the long-running streams and that even though they keep streaming, they can no longer resolve/route new .onion requests and thus fail.
I think that tor with default configuration should be robust in these situations and there should not be an obscure .onion name resolution/routing failre to connect to hosts. Most users will not be able to diagnose such a situation and will also have trouble resolving it, ultimately giving the impression that .onion services are unreliable, regardless of whether it is .onion server side failure or client side .onion name resolution or routing failure.
I am not specifically looking for a solution, since I have many workarounds, simply trying to report the issue in a way that may help the tor project.
I have NOT tested the same problem using clearnet IP or domain name based servers, so I cannot report if it is specific to .onion or more general to all client-side tor circuits.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40109Does every new consensus disable IntroDosDefense?2022-10-11T23:39:35ZRoger DingledineDoes every new consensus disable IntroDosDefense?In handle_establish_intro_cell_dos_extension(), when the intro point receives an extension asking it to enable the rate limiting feature, it does:
```
/* We passed validation, enable defenses and apply rate/burst. */
circ->introduce2...In handle_establish_intro_cell_dos_extension(), when the intro point receives an extension asking it to enable the rate limiting feature, it does:
```
/* We passed validation, enable defenses and apply rate/burst. */
circ->introduce2_dos_defense_enabled = 1;
/* Initialize the INTRODUCE2 token bucket for the rate limiting. */
token_bucket_ctr_init(&circ->introduce2_bucket,
(uint32_t) intro2_rate_per_sec,
(uint32_t) intro2_burst_per_sec,
(uint32_t) approx_time());
```
But then later, in hs_dos_consensus_has_changed() we call set_consensus_parameters(ns) which resets some global variables about what we think the consensus says (so far so good), and then it calls update_intro_circuits() which goes through the list of established intro points and
```
SMARTLIST_FOREACH_BEGIN(intro_circs, circuit_t *, circ) {
/* Defenses might have been enabled or disabled. */
TO_OR_CIRCUIT(circ)->introduce2_dos_defense_enabled =
consensus_param_introduce_defense_enabled;
/* Adjust the rate/burst value that might have changed. */
token_bucket_ctr_adjust(&TO_OR_CIRCUIT(circ)->introduce2_bucket,
consensus_param_introduce_rate_per_sec,
consensus_param_introduce_burst_per_sec);
} SMARTLIST_FOREACH_END(circ);
```
It sure looks to me like this is *overwriting* the values requested in the intro cell DoS extension.
And since the consensus right now doesn't have these consensus params set, then they will be reset to their defaults ("disabled", "25", "200") for every intro point every time a new consensus is processed by the intro point.
If this is so, then it sure seems like we want to set some flag on the intro point, called "I am using explicit values rather than the default", and if that flag is set then we don't mess with it when processing a new consensus.Tor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/2178We launch dummy descriptor fetches more often than needed2020-09-22T15:11:40ZNick MathewsonWe launch dummy descriptor fetches more often than neededRight now, we have code in update_router_descriptor_downloads() to launch a fetch for authority.z if we want to learn our IP from a directory fetch. We do this if:
* We're a server
* We don't have the Address option set
* At le...Right now, we have code in update_router_descriptor_downloads() to launch a fetch for authority.z if we want to learn our IP from a directory fetch. We do this if:
* We're a server
* We don't have the Address option set
* At least 20 minutes have passed since we last launched a router descriptor download
* At least 20 minutes have passed since we last launched a
Per discussion in bug legacy/trac#652, we could be even more quiet about launching these fetches. We could also require that
* At least 20 minutes have passed since we last launched *any* appropriate directory op.
* At least 20 minutes have passed since we got a new incoming connection on what we think our IP is.
* At least 20 minutes have passed since we got confirmation of our current IP in a NETINFO cell
We could also make the "20 minutes" value configurable by a networkstatus parameter.
This is a minor issue, since the current behavior is inelegant, but not actually hurting anything.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40038tracing: CI builder for our tracing2020-10-22T15:12:33ZDavid Gouletdgoulet@torproject.orgtracing: CI builder for our tracingSimple build system that would run the `configure --enable-tracing-instrumentation-log-debug` and make sure we haven't broken them.
We could think one day to have a builder for `LTTng-UST` and `USDT`. I would think that just a configure...Simple build system that would run the `configure --enable-tracing-instrumentation-log-debug` and make sure we haven't broken them.
We could think one day to have a builder for `LTTng-UST` and `USDT`. I would think that just a configure + make would be enough in order to avoid needless delays in our CI.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33437Unsuccessful compilation of tor on FreeBSD system with libssl.so.112020-09-23T13:43:20ZTracUnsuccessful compilation of tor on FreeBSD system with libssl.so.11+Sebastian | so, this looks like a configure error in detecting available openssl correctly. Please file a bug
----
I'm running into a compilation error related to openssl while compiling tor-0.4.2.6 on FreeBSD 11.3 (amd64). Log files a...+Sebastian | so, this looks like a configure error in detecting available openssl correctly. Please file a bug
----
I'm running into a compilation error related to openssl while compiling tor-0.4.2.6 on FreeBSD 11.3 (amd64). Log files are attached.
Notes:
- compilation of **0.4.2.6** with **libssl.so.9** was successful
- compilation of **0.4.2.6** with **libssl.so.11** was unsuccessful
----
**Trac**:
**Username**: stillicideTor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12401Document EntryGuardPathBias in doc/state-contents.txt2021-09-16T14:35:28ZGeorge KadianakisDocument EntryGuardPathBias in doc/state-contents.txtWe should document the newly added `EntryGuardPathBias` and `EntryGuardPathUseBias` to `doc/state-contents.txt`.We should document the newly added `EntryGuardPathBias` and `EntryGuardPathUseBias` to `doc/state-contents.txt`.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40069Remove Digitalcourage3 relays from fallbackdir list2020-10-22T15:12:33ZDavid Gouletdgoulet@torproject.orgRemove Digitalcourage3 relays from fallbackdir listSomehow they ended up in the list and they were not suppose to. The operator just emailed me about it.
Removal is:
```
9EAD5B2D3DBD96DBC80DCE423B0C345E920A758D
ADB2C26629643DBB9F8FE0096E7D16F9414B4F8D
C2AAB088555850FC434E68943F55107204...Somehow they ended up in the list and they were not suppose to. The operator just emailed me about it.
Removal is:
```
9EAD5B2D3DBD96DBC80DCE423B0C345E920A758D
ADB2C26629643DBB9F8FE0096E7D16F9414B4F8D
C2AAB088555850FC434E68943F551072042B85F1
```David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/team/-/issues/11Release 0.4.4 stable (on time?)2020-09-15T13:45:24ZNick MathewsonRelease 0.4.4 stable (on time?)This is a tracking ticket for our 0.4.4 stable release, which is scheduled for 15 September. We can, of course, defer if needed.
Here are some things we should do before 0.4.4 is stable:
* [x] Ensure that every ~044-must ticket is fi...This is a tracking ticket for our 0.4.4 stable release, which is scheduled for 15 September. We can, of course, defer if needed.
Here are some things we should do before 0.4.4 is stable:
* [x] Ensure that every ~044-must ticket is fixed, or relabeled as not truly being must-fix for 0.4.4.
* [ ] Review all remaining ~044-should tickets and make sure that we are okay releasing without fixing any that remain. Fix all of the ones that are necessary, reclassifying them as ~044-must if needed.
* [x] Put out a release candidate in late August or early September, if there are significant changes since 0.4.4.4-rc
* [x] Write a changelog and releasenotes. (Nick is happy to do this when he's back.)Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/arti/-/issues/6Better type for ed25519 identifiers2020-10-15T16:57:11ZNick MathewsonBetter type for ed25519 identifiersWe validate ed25519 public keys every time we read them. I should benchmark that, but I think it could be more expensive than we want. I should make a better type here.We validate ed25519 public keys every time we read them. I should benchmark that, but I think it could be more expensive than we want. I should make a better type here.M3: Cleanup and tidyNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40078Potential consensus divergence from Ed25519 edge cases2022-07-07T00:48:31ZhdevalencePotential consensus divergence from Ed25519 edge casesEd25519 poses risks in consensus-critical applications, because (a) the spec does not require that implementations agree on whether signatures are valid and (b) in practice, implementations differ from the spec and from each other.
In t...Ed25519 poses risks in consensus-critical applications, because (a) the spec does not require that implementations agree on whether signatures are valid and (b) in practice, implementations differ from the spec and from each other.
In the context of working to address this issue in Zcash (resulting in [ZIP215]), I created a set of 196 test vectors, consisting of hex-encoded (public key, signature) pairs on the message `b"Zcash"`. Running these test vectors across various other Ed25519 implementations reveals a wide divergence in behaviour (see [1] [2] for additional context).
From a quick look at the Tor source and some tips from Teor, it looks like Tor has four different verification codepaths: ref10 `open`, ref10 `open_batch`, donna `open`, and donna `open_batch`. But I'm not entirely sure whether these are all used, because that requires a deeper knowledge of the codebase than I have.
The test vectors can be found in C-friendly format (thanks to Patrick Steuer) here: https://github.com/p-steuer/ossl-eddsa-tests
[ZIP215]: https://zips.z.cash/zip-0215
[1]: https://github.com/informalsystems/tendermint-rs/issues/355
[2]: https://github.com/golang/go/issues/40478#issuecomment-666043072https://gitlab.torproject.org/tpo/tpa/team/-/issues/40178jnewsome access to https://git.torproject.org/torsocks.git/2021-02-22T19:06:48ZJim Newsomejnewsome access to https://git.torproject.org/torsocks.git/@dgoulet and I would like to give me write-access to https://git.torproject.org/torsocks.git/@dgoulet and I would like to give me write-access to https://git.torproject.org/torsocks.git/Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/27736Make sure that Tor doesn't build an IPv4 and an IPv6 connection to the same r...2020-08-07T17:16:00ZteorMake sure that Tor doesn't build an IPv4 and an IPv6 connection to the same relayWhen we implement legacy/trac#17835, Tor will choose between IPv4 and IPv6 at random.
I'm pretty sure that we prefer existing connections to the same relay, even if the chosen address doesn't match.
But I need to read the client code t...When we implement legacy/trac#17835, Tor will choose between IPv4 and IPv6 at random.
I'm pretty sure that we prefer existing connections to the same relay, even if the chosen address doesn't match.
But I need to read the client code to make sure this check is done on clients and relays. And I need to run the new code to make sure we're not doubling the number of connections that Tor clients make.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21044ORPort self reachability test happens also when it shouldn't2020-08-06T14:38:06Zs7rORPort self reachability test happens also when it shouldn'tI think we did not cover all cases when the self reachability test before publishing descriptors was introduced.
I am running a bridge with `PublishServerDescriptor 0` and `ORPort 127.0.0.1:443` because I want to run it just to do some...I think we did not cover all cases when the self reachability test before publishing descriptors was introduced.
I am running a bridge with `PublishServerDescriptor 0` and `ORPort 127.0.0.1:443` because I want to run it just to do some responsible testing without hammering the public Guards used by other clients. The bridge is configured with `PublishServerDescriptor 0` so it means I don't need a descriptor, I don't intend to make the bridge (or relay) public.
When a bridge is run in the conditions described above the log is spammed (exactly one log message at every 20 minutes) with:
```
[warn] Your server (PUBLIC_IP:443) has not managed to confirm that its ORPort is reachable. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.
```
and
```
[warn] The IPv4 ORPort address 127.0.0.1 does not match the descriptor address PUBLIC_IP. If you have a static public IPv4 address, use 'Address <IPv4>' and 'OutboundBindAddress <IPv4>'. If you are behind a NAT, use two ORPort lines: 'ORPort <PublicPort> NoListen' and 'ORPort <InternalPort> NoAdvertise'.
```
What it did wrong:
- It guessed the public IP address and tried to make the self test on that address, regardless it's not the address explicitly configured at `ORPort`. `Address` is not set in this setup.
- Based on the second log message, I think it even overwritten the address used with `ORPort` with the public IP address that it guessed and built the descriptor.
- It infinitely tries once every 20 minutes and logs a message that the descriptor cannot be published (and my intention based on the options configured is exactly not to publish one even if the tests were successful).
What Tor should do:
- Bypass the protocol to guess `Address` (the public IP address) when `ORPort` / `DirPort` is explicitly configured as a loopback address or NAT address. This will have a logic follow-up (which I think we already do, but want to make sure) like this:
- Bypass self tests when `ORPort` / `DirPort` address is explicitly configured as a loopback address or NAT address (simplest thing would be to treat these cases as like `AssumeReachable 1` is set). Such addresses cannot be tested from the public internet anyway.
- `PublishServerDescriptor 0` maybe should not even build a descriptor at all, or at least bypass the self tests in this case too, it does not make sense to try to test something we never want to publish. Or, only make 1 attempt to test and log a message stating success or failure.
legacy/trac#19919 is kind of related, it treats as it should the cases where `ORPort` is explicitly configured as a public address. In this ticket we cover an extension for cases where `ORPort` is a loopback or NAT address.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40211Downgrade geckoview build-tools version to 29.0.22021-04-05T23:57:08ZGeorg KoppenDowngrade geckoview build-tools version to 29.0.2In order to have less churn in our Android toolchain we downgrade the
GeckoView build-tools version from 29.0.3 to 29.0.2. See:
tor-browser-build#40126 for context.In order to have less churn in our Android toolchain we downgrade the
GeckoView build-tools version from 29.0.3 to 29.0.2. See:
tor-browser-build#40126 for context.Tor Browser: 10.0https://gitlab.torproject.org/tpo/core/tor/-/issues/40106Tor client could not re-connect to a bridge which removed its obfs4 feature2021-04-13T12:35:47ZtoralfTor client could not re-connect to a bridge which removed its obfs4 featureI removed from a bridge (hashed fp: 662D4E4DE2C883625C543DFA3C4EE466899E6C85) the obfs4 feature and restarted the bridge.
When I restarted now the Tor client configured as:
```
UpdateBridgesFromAuthority 1
UseBridges 1
#ClientTransportPl...I removed from a bridge (hashed fp: 662D4E4DE2C883625C543DFA3C4EE466899E6C85) the obfs4 feature and restarted the bridge.
When I restarted now the Tor client configured as:
```
UpdateBridgesFromAuthority 1
UseBridges 1
#ClientTransportPlugin obfs4 exec /usr/bin/obfs4proxy
Bridge <snip>:<snip> <snip>
```
I got
```
Aug 15 17:39:23.000 [notice] Bootstrapped 0% (starting): Starting
Aug 15 17:39:23.000 [notice] Starting with guard context "bridges"
Aug 15 17:39:23.000 [notice] Delaying directory fetches: No running bridges
```
and the Tor client did not connect to the bridge. I stopped the Tor client, changed this line
```
UpdateBridgesFromAuthority 0
```
and now the Tor client could after a restart connect to the bridge.
After that I could revert that change and now every restart of the Tor client works flawlessly.Tor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40111Unable to build tor statically (no linkable openssl found)2020-12-08T14:15:35ZsimplejackUnable to build tor statically (no linkable openssl found)
I try to build tor statically.
While configure tor it errors with:
```
checking for openssl directory... configure: WARNING: Could not find a linkable openssl. If you have it installed somewhere unusual, you can specify an explicit pat...
I try to build tor statically.
While configure tor it errors with:
```
checking for openssl directory... configure: WARNING: Could not find a linkable openssl. If you have it installed somewhere unusual, you can specify an explicit path using --with-openssl-dir
configure: WARNING: On Debian, you can install openssl using "apt-get install libssl-dev"
configure: error: Missing libraries; unable to proceed.
```
I tried:
- with several tor versions
- with several openssl versions, using several paths to openssl.
- with ubuntu, debian, in container, locally (ubuntu 20.04) etc. I got always the same error.
- several different options for openssl, libevent
- with openssl-dev and path point to it
I don't know if it's a but however i spent now 1-2 days on this.
The error should be more precise anyway.
Here a complete example:
```code
FROM debian
RUN mkdir /tor
WORKDIR /tor
RUN apt update && apt upgrade -y
RUN apt install -y exa
RUN apt install -y git
RUN apt install -y build-essential automake pkgconf
RUN apt install -y zlib1g-dev libsystemd-dev
RUN apt install -y libtool autopoint
#RUN git clone --depth 1 -b tor-0.3.3.9 --single-branch https://github.com/torproject/tor.git /tor
RUN git clone --depth 1 -b tor-0.4.5.0-alpha-dev --single-branch https://github.com/torproject/tor.git /tor
#RUN git clone --depth 1 -b openssl-3.0.0-alpha6 --single-branch https://github.com/openssl/openssl /tor/openssl
RUN git clone --depth 1 -b OpenSSL_1_1_1f --single-branch https://github.com/openssl/openssl /tor/openssl
RUN git clone --depth 1 -b v1.2.9 --single-branch https://github.com/madler/zlib /tor/zlib
RUN git clone --depth 1 -b release-2.1.12-stable --single-branch https://github.com/libevent/libevent /tor/libevent
RUN git clone --depth 1 -b v5.2.3 --single-branch https://github.com/roboticslibrary/xz /tor/xz
RUN cd /tor/openssl && \
./config --prefix=/opt/openssl \
no-shared no-dso zlib \
--static && \
make -j$(nproc) && \
make install_sw
RUN cd /tor/libevent && \
./autogen.sh && \
./configure --prefix=/opt/libevent \
--disable-openssl && \
make -j$(nproc) && \
make install
RUN cd /tor/zlib && \
./configure --prefix=/opt/zlib && \
make -j$(nproc) && \
make install
RUN cd /tor/xz && \
./autogen.sh && \
./configure --prefix=/opt/xz && \
make -j$(nproc) && \
make install
RUN apt install -y libevent-dev libssl-dev
RUN ./autogen.sh && \
./configure --prefix=/opt/tor \
--disable-module-relay --disable-module-dirauth \
--disable-system-torrc \
--disable-asciidoc --disable-manpage --disable-html-manual \
--disable-lzma --disable-zstd \
--enable-systemd \
--disable-gcc-hardening \
--disable-tool-name-check \
--enable-static-tor \
--with-libevent-dir=/opt/libevent \
--with-openssl-dir=/tor/openssl \
--with-zlib-dir=/opt/zlib \
--enable-pci && \
make -j$(nproc) && \
make install
RUN env
RUN exa -l --tree fixtures /opt/tor
RUN /opt/tor/bin/tor --version
```Tor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/11Use minimized cell-type wrappers throughout the codebase2020-10-15T18:46:13ZNick MathewsonUse minimized cell-type wrappers throughout the codebaseNot every cell type belongs on a circuit; not every relay cell type belongs on an open stream. Right now we use `if` checks to enforce these things, but it would be smarter to use a specialized set of types so that it's easy to see wher...Not every cell type belongs on a circuit; not every relay cell type belongs on an open stream. Right now we use `if` checks to enforce these things, but it would be smarter to use a specialized set of types so that it's easy to see where the checks and conversions happen.M3: Cleanup and tidyNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40107Bridge chooses IPv6 instead of IPv4 (as configured) for server transport 'obfs4'2021-02-24T12:14:47ZtoralfBridge chooses IPv6 instead of IPv4 (as configured) for server transport 'obfs4'Running a bridge at a Debian (buster stable) with 0.4.3.6-1~d10.buster+1 and 0.0.7-4+b12 brought the issue that configuring the server transport 'obfs4' according to the official Tor documentation to listen at IPv4 as
```
ServerTransport...Running a bridge at a Debian (buster stable) with 0.4.3.6-1~d10.buster+1 and 0.0.7-4+b12 brought the issue that configuring the server transport 'obfs4' according to the official Tor documentation to listen at IPv4 as
```
ServerTransportListenAddr obfs4 0.0.0.0:443
```
let the bridge choose IPv6:
```
Aug 16 09:44:57.000 [notice] Registered server transport 'obfs4' at '[::]:443'
```
I set ServerTransportListenAddr to the real IP address which helped:
```
# we have to explicitly set this (and NOT to "0.0.0.0:443" and "[..]:443" respectively)
ServerTransportListenAddr obfs4 <ip addr>:<obfs4 port>
```
This bridge behaviour effectively turnes the bridge in being unusable for obfs4 connections for me.
I tested the above with a connection from a local Tor client and from within Tails from a client location where only IPv4 was working.Tor: 0.4.5.x-post-stableGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40238Proxy bypass audit for GeckoView 842020-12-01T21:24:02ZGeorg KoppenProxy bypass audit for GeckoView 84Tor Browser: 10.0