Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2020-06-27T13:42:44Zhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/33631BridgeDB doesn't allow bridges to change their distribution mechanism2020-06-27T13:42:44ZPhilipp Winterphw@torproject.orgBridgeDB doesn't allow bridges to change their distribution mechanismIf a bridge configures `BridgeDistribution https` and then changes its mind and configures `BridgeDistribution any`, BridgeDB won't allow that and keeps thinking that the bridge wants to be distributed over HTTPS. The offending code is [...If a bridge configures `BridgeDistribution https` and then changes its mind and configures `BridgeDistribution any`, BridgeDB won't allow that and keeps thinking that the bridge wants to be distributed over HTTPS. The offending code is [here](https://gitweb.torproject.org/bridgedb.git/tree/bridgedb/Bridges.py?id=9a7ae57cfc85be8aa488bf0e69e8b6f35e2ce38d#n497).
This surprised me and I would consider it unexpected behaviour. Bridges should be able to change their distribution mechanism any time.Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/32657Investigate Snowflake blocking in China2023-08-02T00:08:33ZCecylia BocovichInvestigate Snowflake blocking in ChinaWe've been receiving updates from amiableclarity2011 about snowflake issues in China for a while now (they first reported the blocking of our default STUN servers a while back).
Recently they have not been able to bootstrap a connection...We've been receiving updates from amiableclarity2011 about snowflake issues in China for a while now (they first reported the blocking of our default STUN servers a while back).
Recently they have not been able to bootstrap a connection at all. I wrote a script for monitoring snowflake health (#32545) to check to see if this is due to the faulty snowflake problem we've been having, and ran these tests from a VPS in China and a VPS in North America. I was expecting to see about half of the snowflake connection attempts to succeed and set a 3 minute time out on circuit construction. However, what I saw was a 90% success rate from North America and a 0% success rate in China.
This almost certainly due to blocking, and as ambleclarity recently confirmed in #32597, not due to the blocking of STUN servers.Sponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/33647Minor updates to BridgeDB's dependencies2020-07-14T02:03:41ZArmin HuremagicMinor updates to BridgeDB's dependenciesSome minor errors occurred when trying to setup BridgeDB on a fresh system:
The link to the get-pip script is outdated and no longer available.
The new address would be: [https://bootstrap.pypa.io/get-pip.py]
When setup.py is executed...Some minor errors occurred when trying to setup BridgeDB on a fresh system:
The link to the get-pip script is outdated and no longer available.
The new address would be: [https://bootstrap.pypa.io/get-pip.py]
When setup.py is executed the following error occurs:
error: The 'pyasn1' distribution was not found and is required by service-identity.
Therefore i suggest adding pyasn1 to requirements.txt.
Since BridgeDB's port seems as good as done, this might not be necessary but the pylint version 2.4.4 in .test.requirements.txt is only supporting Python 3.
For the installation with Python 2.7, pylint version 1.9.5 would be required.Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/33835Gmail's quoted response confuses BridgeDB's email autoresponder2021-07-01T17:47:15ZPhilipp Winterphw@torproject.orgGmail's quoted response confuses BridgeDB's email autoresponderWhen replying to a BridgeDB email in Gmail's web interface, one ends up sending an email like this:
```
On Mon, Apr 6, 2020 at 2:12 PM <bridges@torproject.org> wrote:
>
> [This is an automated email. Please do not reply.]
>
> Here are ...When replying to a BridgeDB email in Gmail's web interface, one ends up sending an email like this:
```
On Mon, Apr 6, 2020 at 2:12 PM <bridges@torproject.org> wrote:
>
> [This is an automated email. Please do not reply.]
>
> Here are your bridges:
>
> [redacted]
>
> Add these bridges to your Tor Browser by opening your browser
> preferences, clicking on "Tor", and then adding them to the "Provide a
> bridge" field.
>
> If these bridges are not what you need, reply to this email with one of
> the following commands in the message body:
>
> get bridges (Request unobfuscated Tor bridges.)
> get ipv6 (Request IPv6 bridges.)
> get transport TYPE (Request obfuscated bridges. Replace TYPE with
> 'obfs4'.)
> get key (Get a copy of BridgeDB's public GnuPG key.)
>
>
>
--000000000000dde1a205a2a60f3e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">get transport obfs4<br></div><br><div class=3D"gmail_quote=
"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Apr 6, 2020 at 2:12 PM <=
<a href=3D"mailto:bridges@torproject.org">bridges@torproject.org</a>> wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
[This is an automated email.=C2=A0 Please do not reply.]<br>
<br>
Here are your bridges:<br>
<br>
=C2=A0 [redacted]<br>
<br>
Add these bridges to your Tor Browser by opening your browser<br>
preferences, clicking on "Tor", and then adding them to the "=
;Provide a<br>
bridge" field.<br>
<br>
If these bridges are not what you need, reply to this email with one of<br>
the following commands in the message body:<br>
<br>
=C2=A0 get bridges=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (Request unobfu=
scated Tor bridges.)<br>
=C2=A0 get ipv6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(Requ=
est IPv6 bridges.)<br>
=C2=A0 get transport TYPE=C2=A0 =C2=A0 =C2=A0(Request obfuscated bridges. R=
eplace TYPE with 'obfs4'.)<br>
=C2=A0 get key=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (Get =
a copy of BridgeDB's public GnuPG key.)<br>
<br>
<br>
</blockquote></div>
--000000000000dde1a205a2a60f3e--
```
BridgeDB correctly ignores the commands that start with `>` but it doesn't ignore the commands that are encoded in quoted-printable. BridgeDB's email parser ends up [interpreting each line as command](https://gitweb.torproject.org/bridgedb.git/tree/bridgedb/distributors/email/request.py?h=develop&id=bca64964a255cf959489c7049c66e5eb70b5291c#n87), ending in "get key", which raises an exception, resulting in BridgeDB sending no response at all.
We should make sure that BridgeDB doesn't get confused by Gmail's quoted-printable response.Sponsor 30 - Objective 2.2Armin HuremagicArmin Huremagichttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/33886bridges@torproject.org Don't respond to gmail2020-06-27T13:42:44ZTracbridges@torproject.org Don't respond to gmailhi,
i sent mail to bridges@torproject.org with body "get bridges" by gmail but it don't respond to me
**Trac**:
**Username**: mh828hi,
i sent mail to bridges@torproject.org with body "get bridges" by gmail but it don't respond to me
**Trac**:
**Username**: mh828Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/33945Failed assertion breaks BridgeDB's email responder2021-07-09T18:27:09ZPhilipp Winterphw@torproject.orgFailed assertion breaks BridgeDB's email responderBridgeDB's email responder stops working after a while. The issue is probably related to the exception below but I don't know how exactly. As part of our Python 3 port, we [modifed the context manager](https://gitweb.torproject.org/bridg...BridgeDB's email responder stops working after a while. The issue is probably related to the exception below but I don't know how exactly. As part of our Python 3 port, we [modifed the context manager](https://gitweb.torproject.org/bridgedb.git/commit/?id=c1a48d1b568b00fab19a308e6497881f31d17680), which may be a good place to start debugging.
```
Unhandled Error
Traceback (most recent call last):
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/python/log.py", line 103, in callWithLogger
return callWithContext({"system": lp}, func, *args, **kw)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/python/log.py", line 86, in callWithContext
return context.call({ILogContext: newCtx}, func, *args, **kw)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/python/context.py", line 122, in callWithContext
return self.currentContext().callWithContext(ctx, func, *args, **kw)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/python/context.py", line 85, in callWithContext
return func(*args,**kw)
--- <exception caught here> ---
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/internet/posixbase.py", line 614, in _doReadOrWrite
why = selectable.doRead()
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/internet/tcp.py", line 243, in doRead
return self._dataReceived(data)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/internet/tcp.py", line 249, in _dataReceived
rval = self.protocol.dataReceived(data)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/protocols/basic.py", line 454, in dataReceived
self.lineReceived(line)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/mail/smtp.py", line 445, in lineReceived
return getattr(self, 'state_' + self.mode)(line)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/mail/smtp.py", line 705, in dataLineReceived
m.eomReceived() for m in self.__messages
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/mail/smtp.py", line 705, in <listcomp>
m.eomReceived() for m in self.__messages
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/bridgedb-0.10.0+11.g4cdd6a61.dirty-py3.7.egg/bridgedb/distributors/email/server.py", line 230, in eomReceived
self.responder.reply()
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/bridgedb-0.10.0+11.g4cdd6a61.dirty-py3.7.egg/bridgedb/distributors/email/autoresponder.py", line 574, in reply
response = self.getMailData()
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/bridgedb-0.10.0+11.g4cdd6a61.dirty-py3.7.egg/bridgedb/distributors/email/autoresponder.py", line 392, in getMailData
client, lang)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/bridgedb-0.10.0+11.g4cdd6a61.dirty-py3.7.egg/bridgedb/distributors/email/autoresponder.py", line 101, in createResponseBody
bridges = context.distributor.getBridges(bridgeRequest, interval)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/bridgedb-0.10.0+11.g4cdd6a61.dirty-py3.7.egg/bridgedb/distributors/email/distributor.py", line 145, in getBridges
with bridgedb.Storage.getDB() as db:
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/bridgedb-0.10.0+11.g4cdd6a61.dirty-py3.7.egg/bridgedb/Storage.py", line 352, in __enter__
return next(self.gen)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/bridgedb-0.10.0+11.g4cdd6a61.dirty-py3.7.egg/bridgedb/Storage.py", line 472, in getDB
assert _REFCOUNT == 0
builtins.AssertionError:
```Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/34116Set up OONI's MetaDB on polyanthum2020-07-09T18:21:00ZPhilipp Winterphw@torproject.orgSet up OONI's MetaDB on polyanthumAs part of legacy/trac#32740, we need to sync OONI's test results with BridgeDB's SQLite database; in particular its BlockedBridges table. [Over here](https://trac.torproject.org/projects/tor/ticket/32126#comment:4) and [here](https://gi...As part of legacy/trac#32740, we need to sync OONI's test results with BridgeDB's SQLite database; in particular its BlockedBridges table. [Over here](https://trac.torproject.org/projects/tor/ticket/32126#comment:4) and [here](https://github.com/ooni/backend/issues/396#issuecomment-620611456), hellais suggested to set up a copy of OONI's MetaDB and have it sync with their canonical database. We can then use our local copy on polyanthum to update BridgeDB's SQLite database.
Instructions for setting up a MetaDB are available at:
https://github.com/ooni/sysadmin/blob/master/docs/metadb-sharing.mdPhilipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/34154Extend BlockedBridges table2020-06-27T13:42:44ZPhilipp Winterphw@torproject.orgExtend BlockedBridges tableBridgeDB has a (currently unused) table in its SQLite database that captures where a bridge is blocked. We are going to use this table as part of our work on legacy/trac#32740. It currently has the following fields:
* ID (primary key)
* ...BridgeDB has a (currently unused) table in its SQLite database that captures where a bridge is blocked. We are going to use this table as part of our work on legacy/trac#32740. It currently has the following fields:
* ID (primary key)
* hex_key (fingerprint)
* blocking_country (country code)
A fingerprint can relate to a bridge's OR port or any of its pluggable transports but these endpoints can be blocked independently. To remove this ambiguity, we should add additional fields for a bridge's IP address, port, and perhaps for an autonomous system because blocking isn't always uniform across a country.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/34260Make BridgeDB take into account its BlockedBridges table2022-07-24T17:07:58ZPhilipp Winterphw@torproject.orgMake BridgeDB take into account its BlockedBridges tableBridgeDB has a table called BlockedBridges in its SQLite database. The table is empty and currently unused but we are extending it over at legacy/trac#34154.
BridgeDB already has code to deal with bridge blocking (e.g., [here](https://g...BridgeDB has a table called BlockedBridges in its SQLite database. The table is empty and currently unused but we are extending it over at legacy/trac#34154.
BridgeDB already has code to deal with bridge blocking (e.g., [here](https://gitweb.torproject.org/bridgedb.git/tree/bridgedb/bridges.py?id=2ccf7ef9dee07c0d645a5dfed5b099678c243fc5#n936)) but we still have to make it process BlockedBridges and take it into account when handing out bridges.Sponsor 30 - Objective 2.3Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40001BridgeDB pretends to reload descriptors but actually doesn't2020-07-07T15:58:28ZPhilipp Winterphw@torproject.orgBridgeDB pretends to reload descriptors but actually doesn'tBridgeDB is supposed to reload its bridges descriptors every 30 minutes. The following cron job takes care of that (you can see it by running `crontab -l` as the bridgedb user on polyanthum):
```
*/30 * * * * bin/reload-bridgedb >/dev/n...BridgeDB is supposed to reload its bridges descriptors every 30 minutes. The following cron job takes care of that (you can see it by running `crontab -l` as the bridgedb user on polyanthum):
```
*/30 * * * * bin/reload-bridgedb >/dev/null 2>&1
```
Among other things, the script `reload-bridgedb` does the following:
```
[...]
bridgedb -c ${BRIDGEDB_CONFIG} --reload
[...]
```
BridgeDB implements the `--reload` command line switch but the switch doesn't actually reload anything. In fact, it does nothing at all. So when the cron job runs bridgedb with the `--reload` switch every 30 minutes, it starts a separate (!) process that (re)loads the bridge descriptors and then exits because it cannot bind to the ports that the original BridgeDB is already bound to. Unfortunately, the new BridgeDB process writes to our log file, and makes it look like the original process is reloading bridge descriptors while it actually is our volatile, new process. In other words: the way it's set up now, BridgeDB never actually reloads bridges.
Fortunately, the fix is relatively simple: we just have to send the process a SIGHUP. BridgeDB has a SIGHUP handler that – unlike the `--reload` switch – actually works. We should also remove the `--reload` switch.Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40000Gitlab Migration Milestone2020-06-13T18:30:28ZTracGitlab Migration MilestoneWe're creating this ticket as a part of the Trac-to-Gitlab migration, so that each project's numbering for new tickets will start with 40001.We're creating this ticket as a part of the Trac-to-Gitlab migration, so that each project's numbering for new tickets will start with 40001.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40002Replace sysrqb's Travis CI references with phw's2021-07-09T18:27:08ZPhilipp Winterphw@torproject.orgReplace sysrqb's Travis CI references with phw'sOur README.rst has several links to Matt's Travis CI profile, which is no longer used. Let's update these links and use phw's profile instead.Our README.rst has several links to Matt's Travis CI profile, which is no longer used. Let's update these links and use phw's profile instead.Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40003Update bridgedb-metrics spec to align with version 2 of metrics format2020-07-15T21:38:54ZhanneloresxUpdate bridgedb-metrics spec to align with version 2 of metrics formatWhile looking at #32117, I saw that a couple of lines on the bridgedb-metrics spec had not been updated to refer to the latest version 2 and could use some updates on the internal metrics that were added. Namely, I had trouble understan...While looking at #32117, I saw that a couple of lines on the bridgedb-metrics spec had not been updated to refer to the latest version 2 and could use some updates on the internal metrics that were added. Namely, I had trouble understanding what the internal metrics were measuring just from reading the spec, and the SUBRING field was not defined.hanneloresxhanneloresxhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40004Tor problem with Captive portals and Wifi Hot Spots (TOR/Bridges blocked only...2021-09-09T14:37:22Zmx5kevinTor problem with Captive portals and Wifi Hot Spots (TOR/Bridges blocked only works with externel VPN tunneling using UDP port 53)The first problem when Tor Browser starts can not setup allowed ports. If Tor are blocked the browser does not start where ports can be configured. The other problem bridges are not working. Using a VPN with port 53 and UDP tunneling thr...The first problem when Tor Browser starts can not setup allowed ports. If Tor are blocked the browser does not start where ports can be configured. The other problem bridges are not working. Using a VPN with port 53 and UDP tunneling through DNS TOR are working but slow and limited. If it fails to connect not trying bridges other ports and protocols the program. For less knowledgeable users this is not good.
Tested services with TOR:
https://www.psiphon3.com/en/index.html
and
https://www.vpnbook.com/
With Open VPN
Using a UDP tunnel with port 53 tor are working. It could be integrated into a bridge which is known in protocols try to connect to the internet 53 DNS, 137 netbios, 67 DHCP. In mobile devices, laptops are becoming more widespread the open wifi networks. There is a working protocol that the tor cannot do, it should just be integrated. It would be useful for a lot of people if that worked by default. Solving the problem would help spread the TOR software widely.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40005some issues about using tor browser with bridges2021-01-28T11:29:21Zdebug996some issues about using tor browser with bridgesHello, team members and other friends. I have some troubles about using tor browser (version 10.0.8) with bridges.
I can't use any bridge for tor browser to connect tor network, but only proxy server like **sock 5** can be used to conne...Hello, team members and other friends. I have some troubles about using tor browser (version 10.0.8) with bridges.
I can't use any bridge for tor browser to connect tor network, but only proxy server like **sock 5** can be used to connect tor browser. When I use any bridge(like meek,obfs4) to connect tor browser, it will fail in a minute, and export the same log:
```
1/27/21, 03:14:05.812 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
1/27/21, 03:14:14.805 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
1/27/21, 03:14:14.805 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
1/27/21, 03:14:14.805 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
1/27/21, 03:14:14.806 [NOTICE] Opening Socks listener on 127.0.0.1:9150
1/27/21, 03:14:14.806 [NOTICE] Opened Socks listener on 127.0.0.1:9150
1/27/21, 03:14:15.799 [NOTICE] Bootstrapped 1% (conn_pt): Connecting to pluggable transport
1/27/21, 03:14:15.800 [NOTICE] Bootstrapped 2% (conn_done_pt): Connected to pluggable transport
1/27/21, 03:14:15.803 [NOTICE] Bootstrapped 10% (conn_done): Connected to a relay
1/27/21, 03:14:15.804 [WARN] Problem bootstrapping. Stuck at 10% (conn_done): Connected to a relay. (TLS_ERROR; TLS_ERROR; count 1; recommendation warn; host 97700DFE9F483596DDA6264C4D7DF7641E1E39CE at 0.0.2.0:2)
1/27/21, 03:14:15.804 [WARN] 1 connections have failed:
1/27/21, 03:14:15.805 [WARN] 1 connections died in state handshaking (TLS) with SSL state SSLv3/TLS write client hello in HANDSHAKE
1/27/21, 03:14:15.810 [NOTICE] Closing no-longer-configured Socks listener on 127.0.0.1:9150
1/27/21, 03:14:15.810 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
1/27/21, 03:14:15.810 [WARN] Pluggable Transport process terminated with status code 0
```
The tor daemon packaged by my distribution (Debian GNU/Linux testing) works fine with bridge. (currently only meek bridge has tested)
I can't resolve the problem by myself, I need your help!https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40007Get more alpha users of Snowflake to stress-test before stable2021-05-27T18:18:26ZCecylia BocovichGet more alpha users of Snowflake to stress-test before stableIn a discussion before the stable release of Tor Browser 9.5, we discussed that we'd like to get more snowflake users before moving it out of alpha so that we can stress-test the system to make sure it will work with the massive increase...In a discussion before the stable release of Tor Browser 9.5, we discussed that we'd like to get more snowflake users before moving it out of alpha so that we can stress-test the system to make sure it will work with the massive increase of users we get in stable.
This ticket is to track that progress and perform measurements. We have https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40027 open as a way to get more alpha testers on mobile.Snowflake in Tor Browser 10.5Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40032Document go1.13+ requirement2021-03-08T16:05:22ZJacobo NájeraDocument go1.13+ requirementHi,
I am trying to install snowflake standalone. But I have an issue with module crypto/ed25519`
**Steps to reproduce**
```
git clone https://git.torproject.org/pluggable-transports/snowflake.git
cd snowflake
cd proxy
go get
```
**...Hi,
I am trying to install snowflake standalone. But I have an issue with module crypto/ed25519`
**Steps to reproduce**
```
git clone https://git.torproject.org/pluggable-transports/snowflake.git
cd snowflake
cd proxy
go get
```
**Result**
`build git.torproject.org/pluggable-transports/snowflake.git/proxy: cannot find module for path crypto/ed25519`
**Setup**
- Debian 10
- go version go1.11.6 linux/amd64https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40034Upgrade tor on Snowflake bridge for TROVE-2021-001 and TROVE-2021-002 (2021-0...2021-03-16T22:03:05ZDavid Fifielddcf@torproject.orgUpgrade tor on Snowflake bridge for TROVE-2021-001 and TROVE-2021-002 (2021-03-16)[Upcoming releases next week to fix denial-of-service bugs in Tor](https://lists.torproject.org/pipermail/tor-talk/2021-March/045711.html)
> Early next week -- around Tuesday -- we plan to put out new Tor
releases to fix a pair of denia...[Upcoming releases next week to fix denial-of-service bugs in Tor](https://lists.torproject.org/pipermail/tor-talk/2021-March/045711.html)
> Early next week -- around Tuesday -- we plan to put out new Tor
releases to fix a pair of denial-of-service issues that we have found.
> We are tracking these issues as "High" and "Medium" severity
respectively under our security policy at
https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/SecurityPolicy
> * We are tracking these issues as TROVE-2021-001 and TROVE-2021-002
at https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/TROVE
> * All currently supported Tor versions are affected.
>
> The impact of these issues is that a remote attacker participating in
the directory protocol can cause a denial of service attack against
Tor instances. Once the new versions are released, we will recommend
that all relays and authorities should upgrade. The impact is worst
for directory authorities: we have already distributed patches to the
authority operators and encouraged them to upgrade.
>
> To the best of our knowledge these vulnerabilities are not being
exploited in the wild.
>
> We'll be releasing more information about these issues after the fixes
are available.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40035Snowflake doesn't close OR connections2021-03-19T02:10:31ZCecylia BocovichSnowflake doesn't close OR connectionsI was staring at the snowflake logs after #40033 happened, and noticed a lot more `io: read/write on closed pipe` style errors than I was expecting. Looking at our proxy loop:
```
// Copy from one stream to another.
func proxy(local *net...I was staring at the snowflake logs after #40033 happened, and noticed a lot more `io: read/write on closed pipe` style errors than I was expecting. Looking at our proxy loop:
```
// Copy from one stream to another.
func proxy(local *net.TCPConn, conn net.Conn) {
var wg sync.WaitGroup
wg.Add(2)
go func() {
if _, err := io.Copy(conn, local); err != nil {
log.Printf("error copying ORPort to WebSocket %v", err)
}
if err := local.CloseRead(); err != nil {
log.Printf("error closing read after copying ORPort to WebSocket %v", err)
}
conn.Close()
wg.Done()
}()
go func() {
if _, err := io.Copy(local, conn); err != nil {
log.Printf("error copying WebSocket to ORPort %v", err)
}
if err := local.CloseWrite(); err != nil {
log.Printf("error closing write after copying WebSocket to ORPort %v", err)
}
conn.Close()
wg.Done()
}()
wg.Wait()
}
```
If the client closes the connection, the bottom io.Copy will terminate and cause the other one to generate the error. If the OR connection closes: vice versa. However, when the client closes the connection, the bottom loop doesn't terminate because the bottom loop is reading from a KCP stream, not the WebSocket connection. So neither of these loops terminate until the OR connection times out (~20 minutes in a local test).
I'm not actually sure if this is bug or if it could cause performance problems. It means we're keeping goroutines and open connections around for longer than they need to be, but as far as I can tell we're not running out of memory on the bridge. At the very least it means that `local.CloseRead` and `local.CloseWrite` aren't doing anything here and will always generate errors.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40037Update version of pion webrtc to fix CVE-2021-286812021-04-01T13:21:09ZCecylia BocovichUpdate version of pion webrtc to fix CVE-2021-28681This was patched in v3.0.15This was patched in v3.0.15Cecylia BocovichCecylia Bocovich