Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2022-03-16T15:45:50Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/21312Memory and file descriptor leaks in programs that use go-webrtc2022-03-16T15:45:50ZArlo BreaultMemory and file descriptor leaks in programs that use go-webrtc```
1:30:49 AM - arma5: 2017/01/24 18:57:44 candidate:3131354255 1 tcp 1518280447 192.168.1.154 36729 typ host tcptype passive generation 0 ufrag YXKXffPBBnA3SJ3K network-id 1
1:30:52 AM - arma5: this is the last line in its log
1:31:20 ...```
1:30:49 AM - arma5: 2017/01/24 18:57:44 candidate:3131354255 1 tcp 1518280447 192.168.1.154 36729 typ host tcptype passive generation 0 ufrag YXKXffPBBnA3SJ3K network-id 1
1:30:52 AM - arma5: this is the last line in its log
1:31:20 AM - arma5: and snowflake-client is pegged at 100% cpu
1:32:39 AM - arma5: % strace -p3074
1:32:39 AM - arma5: Process 3074 attached
1:32:39 AM - arma5: futex(0x1059710, FUTEX_WAIT, 0, NULL
```Arlo BreaultArlo Breaulthttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/5012Write proposals to allow an external program that discovers bridge addresses ...2020-06-27T13:44:08ZKarsten LoesingWrite proposals to allow an external program that discovers bridge addresses to tell Tor about them and start implementing the proposalsThis ticket is part of sponsor F deliverable 7. Once we have a recommended approach for an external program that discovers bridge addresses to tell Tor about them, we need to write proposals and start implementing them. The "and start ...This ticket is part of sponsor F deliverable 7. Once we have a recommended approach for an external program that discovers bridge addresses to tell Tor about them, we need to write proposals and start implementing them. The "and start implementation as needed" part of the deliverable text is vague enough to focus on the design discussion and proposals. If there's time left to implement something, great, but if not, that's fine, too. We can still implement proposals between March and November 2012.Mike PerryMike Perryhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/2301migrate bridgedb to tor server2020-06-27T13:43:34ZAndrew Lewmanmigrate bridgedb to tor serverCurrently bridgedb runs on byblos. The byblos owner asks us to move it to a tor server.Currently bridgedb runs on byblos. The byblos owner asks us to move it to a tor server.Aaron GibsonAaron Gibsonhttps://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/10099wiki: DontBlockMe project / ListOfServicesBlockingTor doc2020-06-27T13:43:42Zcypherpunkswiki: DontBlockMe project / ListOfServicesBlockingTor docThe current meta ticket for these two wiki pages.
DontBlockMe
ListOfServicesBlockingTor
Join related tickets to this parent.The current meta ticket for these two wiki pages.
DontBlockMe
ListOfServicesBlockingTor
Join related tickets to this parent.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/12146Firefox meek-http-helper leaks Host header in CONNECT requests2020-06-27T13:44:20ZDavid Fifielddcf@torproject.orgFirefox meek-http-helper leaks Host header in CONNECT requestslegacy/trac#12120 enabled the browser extension helper to use an upstream HTTP or SOCKS proxy. I'm watching the requests that go to the proxy, and Firefox is leaking the Host header in the proxy request:
```
CONNECT www.google.com:443 HT...legacy/trac#12120 enabled the browser extension helper to use an upstream HTTP or SOCKS proxy. I'm watching the requests that go to the proxy, and Firefox is leaking the Host header in the proxy request:
```
CONNECT www.google.com:443 HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Firefox/24.0
Proxy-Connection: keep-alive
Connection: keep-alive
Host: meek-reflect.appspot.com
```
The `Host: meek-reflect.appspot.com` is not supposed to be visible on the wire. It's encrypted inside of HTTPS. But Firefox leaks it when configured to use an HTTP proxy.
The Host header must be getting special treatment, because the extension also sets X-Session-ID, and that's not showing up in the proxy request.
We have to turn off the HTTP proxy feature if we can't find a way to prevent the Host from leaking.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/21314snowflake-client needs to stop using my network when I'm not giving it requests2020-11-23T18:41:46ZRoger Dingledinesnowflake-client needs to stop using my network when I'm not giving it requestsI started my Tor Browser, and told it to use snowflake, and it did. Then I changed my mind and told it to stop using snowflake. Now, apparently there's a bug in Tor where Tor is supposed to kill snowflake-client when there are no more br...I started my Tor Browser, and told it to use snowflake, and it did. Then I changed my mind and told it to stop using snowflake. Now, apparently there's a bug in Tor where Tor is supposed to kill snowflake-client when there are no more bridge lines in my torrc that want to use it. But ignoring that Tor bug, snowflake-client should also be defensive for me. Right now it is touching the broker every 10 seconds, looking for a snowflake, even though it is getting no requests. That can't be good for scalability or for the broker or for the users.Snowflake in Tor Browser 10.5Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/5023Morpher pluggable transport: Select algorithm for packet size morphing2020-06-27T13:44:08ZGeorge KadianakisMorpher pluggable transport: Select algorithm for packet size morphingThis is a ticket to resolve a) of comment:1:ticket:4680 :
We should evaluate whether the final morpher transport should use 'random sampling', or 'morphing matrices' to select a packet's final packet size.
In 'random sampling', you hav...This is a ticket to resolve a) of comment:1:ticket:4680 :
We should evaluate whether the final morpher transport should use 'random sampling', or 'morphing matrices' to select a packet's final packet size.
In 'random sampling', you have a packet size probability distribution of a target protocol, and you pick a random variable, and then you shape your packet to be of that size.
By 'morphing matrices', I mean the technique described in the paper Traffic Morphing: An efficient defense against statistical traffic analysis which attempts to minimize the padding overhead imposed by packet size shaping.
Since our morpher transport will try to turn Tor traffic into HTTPS traffic, as far as packet sizes are concerned, we should evaluate whether the 'morphing matrices' method is worth it. We can build a tool that uses both methods on a couple thousand packets, and see which method is more effective. If 'morphing matrices' is indeed more effective, we should see whether it's effective enough to justify its troublesome implementation.
I stupidly attached all relevant files to legacy/trac#4680, but let's continue the discussion here to avoid flooding legacy/trac#4680 more.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/21315publish some realtime stats from the broker?2021-11-24T16:39:37ZRoger Dingledinepublish some realtime stats from the broker?How many snowflakes are there registered right now and happy to serve censored users?
Right now there's a big difference between 0 and 1, and it's not easy to figure out which it is.
Knowing this number would help me as a snowflake vol...How many snowflakes are there registered right now and happy to serve censored users?
Right now there's a big difference between 0 and 1, and it's not easy to figure out which it is.
Knowing this number would help me as a snowflake volunteer decide whether I am needed, and whether to do advocacy at this moment to get other people to be snowflakes.
Knowing this number would help the censored users too, because it would give them a sense of the health of the snowflake population, and also it can help them debug their "it's not working, I wonder if I can narrow down some possible problems" situations.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/2372Export BridgeDB's pool assignments2020-06-27T13:43:34ZKarsten LoesingExport BridgeDB's pool assignmentsFollowing the (actually newly introduced) tradition of summarizing IRC
discussions in Trac or email, here's what Roger and I discussed today:
I'm interested in learning whether keeping a certain fraction of bridges
unassigned, that is n...Following the (actually newly introduced) tradition of summarizing IRC
discussions in Trac or email, here's what Roger and I discussed today:
I'm interested in learning whether keeping a certain fraction of bridges
unassigned, that is not distributing them via email or HTTP, is a good
idea. AIUI, the idea was to have a small set of fresh bridges in case we
come up with a new distribution channel or want to give out fresh bridges
manually. This idea might fail if people who run a bridge that ends up in
the unallocated pool decide that their bridge is not being useful. They
might turn off their bridge or delete their keys in order to get a new
fingerprint and end up in another pool. If many people do so, we might
better allocate all bridges to pools directly and start a new pool
whenever there's a new distribution channel. Given the high churn of
bridges, we might have a sufficient set of fresh bridges in that pool very
soon. Also, if we want to give out bridges manually, we might give out
bridges from the other pools which may have higher uptime than bridges in
the unallocated pool. Allocating all bridges also means we don't have to
explain to bridge operators why their bridge is also useful even if it
doesn't have any users right now.
So, we need to export pool assignments from BridgeDB somehow. Currently,
we have log files of the following format:
```
Jan 10 01:41:14 [DEBUG] Leaving bridge 1.2.3.4:443 dddddddddddddddddddddddddddddddddddddddd unallocated
Jan 10 01:41:14 [DEBUG] Adding bridge 2.3.4.5:443 eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee to IP ring 1 (port-443 subring)
Jan 10 01:41:14 [DEBUG] Adding bridge 2.3.4.5:443 eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee to IP ring 1 (stable subring)
Jan 10 01:41:14 [DEBUG] Adding bridge 2.3.4.5:443 eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee to IP ring 1
```
If we want to analyze bridge pool assignments we need a better data format
than this log format. Here's a proposed data format for bridge pool
assignments (with sanitized IP addresses and fingerprints):
```
bridge-pool-assignment 2011-01-10 01:41:14
b 127.0.0.1:443 abcdef0123456789abcdef0123456789abcdef01
b 127.0.0.1:443 0123456789abcdef0123456789abcdef01234567
s IP ring 1 (port-443 subring)
s IP ring 1 (stable subring)
s IP ring 1
```
The timestamp in the bridge-pool-assignment line is the time when the
assignment is written to disk (twice an hour). Lines starting with b
contain IP address, port, and fingerprint of a bridge. For sanitizing
purposes, I replaced bridge IP addresses with 127.0.0.1 and bridge
identities with their SHA-1 hashes. That's the same approach that we take
for sanitizing bridge descriptors. Lines starting with s contain the
rings or subrings that a bridge is allocated to.
Possible questions that I'm trying to answer with these data are:
1. Do bridges ever switch pools?
2. Is bridge uptime affected by the pool assignment?
Are there reasons not to publish the sanitized versions of these bridge
pool assignments? Are any sensitive data left that we need to remove?
Can we change the BridgeDB code to export its pool assignment in this
format (without the sanitizing which I would do on a metrics machine)?Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/15198Cyberoam blocking connections to Tor2021-07-09T18:29:19ZJacob AppelbaumCyberoam blocking connections to TorI'm currently in Istanbul, Turkey at a local university. The network blocks connections to the Tor network (using Tails) with a layered approach to censorship, I suspect.
I've tried to configure regular bridges, obfs2,3,scramblesuit PT ...I'm currently in Istanbul, Turkey at a local university. The network blocks connections to the Tor network (using Tails) with a layered approach to censorship, I suspect.
I've tried to configure regular bridges, obfs2,3,scramblesuit PT and direct connections. None appear to function. I am able to ssh out - so I can connect to Tor by binding a local SOCKS proxy and configuring Tor to connect over a SOCKS proxy. That is how I've filed this bug report.
The Cyberoam device is clearly acting as a MITM - it is highly annoying. It is a captive portal, which is easy to bypass with a login/password (ironically, not deployed with https!), after the captive portal, it filters conections by protocol, ip address and port number - I haven't yet fingerprinted the device upstream but I'll add information as I find it.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/12208Make it possible to use an IP address as a front (no DNS request and no SNI)2021-11-08T19:49:21ZDavid Fifielddcf@torproject.orgMake it possible to use an IP address as a front (no DNS request and no SNI)meek puts one domain name on the "outside" of your connection (the DNS request and SNI), and a different name on the "inside" (the HTTP Host header). It would be good for some uses if the outside could be just to an IP address rather tha...meek puts one domain name on the "outside" of your connection (the DNS request and SNI), and a different name on the "inside" (the HTTP Host header). It would be good for some uses if the outside could be just to an IP address rather than a domain name, so that there were no DNS request, and no server_name extension in the CLientHello. Kind of like if you were to browse to https://38.229.72.16/ instead of https://www.torproject.org/.
The motivating use case is using a CDN as a front instead of www.google.com. A CDN has many domains behind it, but if we choose just one of them as the front, that domain might get blocked (because the collateral damage would be limited to just one domain). Such blocking would break the transport and also incidentally get the innocent third-party domain, who has nothing to do with any of this, censored even for non-circumventors. What we want is to use one of the CDN's frontend IP addresses as a front, so that the censor has to block the whole IP and the thousands of domains behind it, not just a single domain.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/5059Organize an obfsproxy/PTTB test run2020-06-27T13:44:08ZGeorge KadianakisOrganize an obfsproxy/PTTB test runkarsten and arma were considering an obfsproxy testrun, where a
client-PTTB (legacy/trac#4927) would be deployed, configured with hardcoded
obfs2'ed bridges.
This should get us some bug reports on obfsproxy, some usability
comments from...karsten and arma were considering an obfsproxy testrun, where a
client-PTTB (legacy/trac#4927) would be deployed, configured with hardcoded
obfs2'ed bridges.
This should get us some bug reports on obfsproxy, some usability
comments from end-users, and help us figure out legacy/trac#5038 and other
performance-related questions.
The initial plan was to setup an obfsproxy in moria, but I believe
it's a better idea to setup obfsproxy in less sensitive boxes [0].
This is a ticket to coordinate this effort.
legacy/trac#5047 is also important, to gather statistics and see approximately
how many users used pluggable transports during the testing period.
We should also decide how many bridges to hardcode. Do we actually
need more than one? I know that gamambel, marlowe and ln5 are
interested in setting up obfsproxy. Still, I think that the original
idea of a single bridge is better, so that we can get better answers
for legacy/trac#5038. If too many users use the bundle, we can then add more
bridges. So, who gets to setup the PTTB obfsproxy?
[0]:
There are probably easier ways of compromising computers than
exploiting obfsproxy security bugs, but I will be feeling better if
obfsproxy-beta is not touching a directory authority.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/21748Snowflake breaks nightly builds as of March 152023-04-01T17:44:34ZGeorg KoppenSnowflake breaks nightly builds as of March 15Our nightly builds are broken now due to Snowflake compilation being unhappy:
```
+ go install github.com/keroserene/go-webrtc
# github.com/keroserene/go-webrtc
<command-line>:0:0: warning: "_GLIBCXX_USE_CXX11_ABI" redefined
<command-lin...Our nightly builds are broken now due to Snowflake compilation being unhappy:
```
+ go install github.com/keroserene/go-webrtc
# github.com/keroserene/go-webrtc
<command-line>:0:0: warning: "_GLIBCXX_USE_CXX11_ABI" redefined
<command-line>:0:0: note: this is the location of the previous definition
# github.com/keroserene/go-webrtc
<command-line>:0:0: warning: "_GLIBCXX_USE_CXX11_ABI" redefined
<command-line>:0:0: note: this is the location of the previous definition
# github.com/keroserene/go-webrtc
<command-line>:0:0: warning: "_GLIBCXX_USE_CXX11_ABI" redefined
<command-line>:0:0: note: this is the location of the previous definition
../../go/src/github.com/keroserene/go-webrtc/peerconnection.cc:13:51: fatal error: webrtc/pc/test/fakeaudiocapturemodule.h: No such file or directory
compilation terminated.
```Arlo BreaultArlo Breaulthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/2472Find out if BridgeDB stores more than 1 IP address per bridge fingerprint2021-07-09T18:27:09ZKarsten LoesingFind out if BridgeDB stores more than 1 IP address per bridge fingerprintWhen sanitizing the bridge pool assignments for legacy/trac#2372, I noticed that the BridgeDB logs mention some bridge fingerprints more than once with changing IP addresses. Here is an example:
```
Sep 29 08:07:15 [DEBUG] Leaving brid...When sanitizing the bridge pool assignments for legacy/trac#2372, I noticed that the BridgeDB logs mention some bridge fingerprints more than once with changing IP addresses. Here is an example:
```
Sep 29 08:07:15 [DEBUG] Leaving bridge --.--.--.138:443 -----------------------------------bc654 unallocated
Sep 29 08:07:16 [DEBUG] Leaving bridge --.--.--.138:443 -----------------------------------bc654 unallocated
Sep 29 08:07:16 [DEBUG] Leaving bridge --.--.--.138:443 -----------------------------------bc654 unallocated
Sep 29 08:07:17 [DEBUG] Leaving bridge --.--.---.34:443 -----------------------------------bc654 unallocated
Sep 29 08:07:17 [DEBUG] Leaving bridge --.--.---.34:443 -----------------------------------bc654 unallocated
Sep 29 08:07:17 [DEBUG] Leaving bridge --.--.---.34:443 -----------------------------------bc654 unallocated
Sep 29 08:07:18 [DEBUG] Leaving bridge ---.--.---.219:443 -----------------------------------bc654 unallocated
Sep 29 08:07:12 [DEBUG] Adding bridge ---.---.--.3:443 -----------------------------------d80ca to email ring
Sep 29 08:07:16 [DEBUG] Adding bridge --.---.--.31:443 -----------------------------------d80ca to email ring
Sep 29 08:07:16 [DEBUG] Adding bridge --.---.--.31:443 -----------------------------------d80ca to email ring
Sep 29 08:07:17 [DEBUG] Adding bridge ---.---.--.238:443 -----------------------------------d80ca to email ring
Sep 29 08:07:17 [DEBUG] Adding bridge ---.---.--.238:443 -----------------------------------d80ca to email ring
Sep 29 08:07:17 [DEBUG] Adding bridge ---.---.--.253:443 -----------------------------------d80ca to email ring
Sep 29 08:07:17 [DEBUG] Adding bridge ---.---.--.253:443 -----------------------------------d80ca to email ring
Sep 29 08:07:17 [DEBUG] Adding bridge ---.---.--.54:443 -----------------------------------d80ca to email ring
Sep 29 08:07:17 [DEBUG] Adding bridge --.---.--.17:443 -----------------------------------d80ca to email ring
Sep 29 08:07:17 [DEBUG] Adding bridge ---.---.--.167:443 -----------------------------------d80ca to email ring
Sep 29 08:07:17 [DEBUG] Adding bridge ---.---.--.148:443 -----------------------------------d80ca to email ring
Sep 29 08:07:17 [DEBUG] Adding bridge ---.---.--.37:443 -----------------------------------d80ca to email ring
Sep 29 08:07:18 [DEBUG] Adding bridge ---.---.--.37:443 -----------------------------------d80ca to email ring
Sep 29 08:07:18 [DEBUG] Adding bridge --.---.--.117:443 -----------------------------------d80ca to email ring
Sep 29 08:07:18 [DEBUG] Adding bridge ---.---.--.26:443 -----------------------------------d80ca to email ring
Sep 29 08:07:18 [DEBUG] Adding bridge --.---.--.91:443 -----------------------------------d80ca to email ring
Sep 29 08:07:18 [DEBUG] Adding bridge ---.---.--.225:443 -----------------------------------d80ca to email ring
Sep 29 08:07:18 [DEBUG] Adding bridge ---.---.--.3:443 -----------------------------------d80ca to email ring
Sep 29 08:07:19 [DEBUG] Adding bridge ---.---.--.235:443 -----------------------------------d80ca to email ring
```
I didn't find a case when a bridge was added to different rings, but I didn't look closely. I wonder if this affects giving out bridges in some way, either by giving out a bridge's old IP address or by giving out a bridge more often than others.Christian FrommeChristian Frommehttps://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/16772Google's reCAPTCHA Tor Censorship !?2020-06-27T13:43:42ZcypherpunksGoogle's reCAPTCHA Tor Censorship !?This week, everytime I've encountered a reCAPTCHA from Google, I was completely unable to solve the CAPTCHA's, see attached image with my CAPTCHA solutions.
Also, from since last week, I encountered Google displaying no CAPTCHA image, b...This week, everytime I've encountered a reCAPTCHA from Google, I was completely unable to solve the CAPTCHA's, see attached image with my CAPTCHA solutions.
Also, from since last week, I encountered Google displaying no CAPTCHA image, but an error, that Google wants to protect it's users from automated requests or something like that.
Sorry, If there are some errors in my CAPTCHA solutions.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/12402Meek bundle occasionally makes direct contact to Tor node.2020-06-27T13:44:20ZcypherpunksMeek bundle occasionally makes direct contact to Tor node.I have been testing with meek transport bundle 3.6.2.
I simply observed outbound connections with wireshark, and it was nearly always google's IP. But occasionally, it reaches out to a Tor node. In my case, it took 66 bytes from 5.135.59...I have been testing with meek transport bundle 3.6.2.
I simply observed outbound connections with wireshark, and it was nearly always google's IP. But occasionally, it reaches out to a Tor node. In my case, it took 66 bytes from 5.135.59.74 which is a Tor node (checked with ExoneraTOR)
I think this will let the traffic observer know you are connecting to tor network.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/issues/33461Multiarch docker obfs4 bridge2021-06-17T14:23:19ZTracMultiarch docker obfs4 bridgeHaving more images enables the bridge operators to directly pull an image instead of modifying the Dockerfile and consequently building that image. For example, the supported architectures can be x86_64, aarch64 and arm.
In order to do s...Having more images enables the bridge operators to directly pull an image instead of modifying the Dockerfile and consequently building that image. For example, the supported architectures can be x86_64, aarch64 and arm.
In order to do so we can have multiple `Dockerfile.arch` where is used https://github.com/multiarch/qemu-user-static in order to build such image.
For example in the Dockerfile.arm file the content should be something like:
```
# Base docker image
FROM multiarch/qemu-user-static:x86_64-arm as qemu
FROM arm32v7/debian:buster-slim
COPY --from=qemu /usr/bin/qemu-arm-static /usr/bin
# Install remaining dependencies.
RUN apt-get update && apt-get install -y \
tor \
tor-geoipdb \
obfs4proxy \
libcap2-bin \
--no-install-recommends
# Allow obfs4proxy to bind to ports < 1024.
RUN setcap cap_net_bind_service=+ep /usr/bin/obfs4proxy
RUN setcap cap_net_bind_service=+ep /usr/bin/tor
# Our torrc is generated at run-time by the script start-tor.sh.
RUN rm /etc/tor/torrc
RUN chown debian-tor:debian-tor /etc/tor
RUN chown debian-tor:debian-tor /var/log/tor
COPY start-tor.sh /usr/local/bin
RUN chmod 0755 /usr/local/bin/start-tor.sh
COPY get-bridge-line /usr/local/bin
RUN chmod 0755 /usr/local/bin/get-bridge-line
USER debian-tor
CMD [ "/usr/local/bin/start-tor.sh" ]
```
**Trac**:
**Username**: thymbahutymbahttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/5143ServerTransportPlugin sets or_port to '127.0.0.1:0'2020-06-27T13:44:08ZTracServerTransportPlugin sets or_port to '127.0.0.1:0'When Tor is configured with
ORPort "[::]:9001" so on default linux it is configured
to listen on both v4 and v6 sockets.
and obfsproxy configured to run in managed mode:
ServerTransportPlugin obfs2 exec /usr/local/bin/obfsproxy --log...When Tor is configured with
ORPort "[::]:9001" so on default linux it is configured
to listen on both v4 and v6 sockets.
and obfsproxy configured to run in managed mode:
ServerTransportPlugin obfs2 exec /usr/local/bin/obfsproxy --log-min-severity=debug --no-safe-logging --logfile=/var/log/tor/obfsproxy.log --managed
we get:
Proxy environment:
[...]
or_port: '127.0.0.1:0'
[...]
If we add a v4 only OrPort
OrPort "0.0.0.0:9001"
it works as expected:
[...]
or_port: '127.0.0.1:9001'
[...]
**Trac**:
**Username**: murbleGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/21954Snowflake breaks the 7.0a3 build2022-07-09T04:20:15ZGeorg KoppenSnowflake breaks the 7.0a3 buildBuilding Snowflake breaks our 7.0a3 build with the following error:
```
+ mkdir -p /home/debian/go/src/github.com/keroserene/
+ ln -sf /home/debian/build/go-webrtc /home/debian/go/src/github.com/keroserene/go-webrtc
+ CGO_CXXFLAGS='-D_GL...Building Snowflake breaks our 7.0a3 build with the following error:
```
+ mkdir -p /home/debian/go/src/github.com/keroserene/
+ ln -sf /home/debian/build/go-webrtc /home/debian/go/src/github.com/keroserene/go-webrtc
+ CGO_CXXFLAGS='-D_GLIBCXX_USE_CXX11_ABI=1 -D__STDC_FORMAT_MACROS=1'
+ CGO_LDFLAGS=-latomic
+ go install github.com/keroserene/go-webrtc
# github.com/keroserene/go-webrtc
<command-line>:0:0: warning: "_GLIBCXX_USE_CXX11_ABI" redefined
<command-line>:0:0: note: this is the location of the previous definition
# github.com/keroserene/go-webrtc
<command-line>:0:0: warning: "_GLIBCXX_USE_CXX11_ABI" redefined
<command-line>:0:0: note: this is the location of the previous definition
# github.com/keroserene/go-webrtc
<command-line>:0:0: warning: "_GLIBCXX_USE_CXX11_ABI" redefined
<command-line>:0:0: note: this is the location of the previous definition
# github.com/keroserene/go-webrtc
/home/debian/install/binutils/bin/ld.gold.real: error: ../../go/src/github.com/keroserene/go-webrtc/lib/libwebrtc-linux-386-magic.a(dump_syms_regtest.o): unsupported ELF file type 2
collect2: error: ld returned 1 exit status
```
I double-checked that the commits I am on are the same as in the patch for legacy/trac#21748. Furthermore, I made a `make clean-webrtc` and the build started with `tbb-7.0a3-build3`.
There are actually two issues here:
1) We need to unblock the 7.0a3 build as soon as possible as we want to release the first ESR52-based Tor Browser alpha next week.
2) I'd like to understand how this can happen at all given that we did not change the commits compared to the fix in legacy/trac#21748 and I tested that the building worked back then. I somehow doubt that arlolra and I made the same mistake (by using the wrong commit or something).
I need to have a fix for that within the next 24 hours, otherwise do I need to disable Snowflake in the alphas.Arlo BreaultArlo Breaulthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/2556BridgeDB silently ignores RUN_IN_DIR option when run with --dump-bridges2021-07-09T18:27:09ZKarsten LoesingBridgeDB silently ignores RUN_IN_DIR option when run with --dump-bridgesBridgeDB silently ignores the RUN_IN_DIR option when being run with the `--dump-bridges` option. The result is that it doesn't find its database and dumps no bridges to files. I don't know if the fix is to respect the RUN_IN_DIR option...BridgeDB silently ignores the RUN_IN_DIR option when being run with the `--dump-bridges` option. The result is that it doesn't find its database and dumps no bridges to files. I don't know if the fix is to respect the RUN_IN_DIR option, or if we should respect more config options when running with the `--dump-bridges` option.Christian FrommeChristian Fromme