Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2022-07-09T04:22:44Zhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/5119make BridgeDB spit out a list of server-transport-proxy lines2022-07-09T04:22:44ZSathyanarayanan Gunasekaranmake BridgeDB spit out a list of server-transport-proxy linesWe need BridgeDB to spit out a list of server-transport-proxy lines for distributing obfs-bridges. I currently have a bridge tester script(part of ooni) that can -1) check if the bridges work, 2) check if they are public, 3) check their ...We need BridgeDB to spit out a list of server-transport-proxy lines for distributing obfs-bridges. I currently have a bridge tester script(part of ooni) that can -1) check if the bridges work, 2) check if they are public, 3) check their bandwidth(w/ a crude implementation, probably useless for now). This can be used to help BridgeDB decide which obfs-bridges to send. I've never messed around with the BridgeDB code and I need help with that.
Copied from #tor-dev
09:49 < rransom_> The next thing to do would be to modify BridgeDB to spit out a list of all bridge descriptor lines starting with "transport-proxy ", along with the fingerprint of the bridge that provided it.
09:49 < rransom_> Hmm. Better make that "server-transport-proxy ".
09:50 < gsathya> Ok, but I'll need help with the BridgeDB codeAaron GibsonAaron Gibsonhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/12505Refactor BridgeDB's hashrings2022-07-09T04:22:44ZIsis LovecruftRefactor BridgeDB's hashringsI have slowly been refactoring all of BridgeDB. Code which has been already refactored is named with "proper" (according to PEP8) lower-cased module names in `lib/bridgedb` in the BridgeDB repository.
Some of the largest, least-unitest...I have slowly been refactoring all of BridgeDB. Code which has been already refactored is named with "proper" (according to PEP8) lower-cased module names in `lib/bridgedb` in the BridgeDB repository.
Some of the largest, least-unitested, (and most difficult to refactor) sections of BridgeDB's code are the `Bridges.py` module and the `Dist.py` module. This code primarily controls the hashrings and the distributors (which for some reason are subclasses of the very-confused hashrings structures).
The biggest problems are:
1. The code for the various types of hashrings in `bridgedb.Bridges` is a complete mess. In some places, hashrings are referred to as `BridgeHolders`, in other places as `Buckets` (though not to be confused with the `Bucket.py` module, and in other places as "hashrings". Subclassing is haphazard and confusing to say the least. In addition, the hashrings are not algorithmically as efficient as they could be. Throughout the hashring code were old-style classes, unused methods, half-implemented methods, and unnecessary parameters. All of this code needs some serious help.
2. The Distributors in `bridgedb.Dist` inherit, for some unknown reason, from the improperly implemented "base class" `bridgedb.Bridges.BridgeHolder`. One, this isn't how one implements a proper Python base class (by deriving from a class with `__metaclass__ = abc.ABCMeta`). Two, why a `Distributor` should be a subclass of a the "base" hashring class is unclear and unnecessary, and we should move away from that. A `Distributor` is something which distributes bridges to users, not some weird half-thought-out hashring subclass.
3. The various Distributors in `bridgedb.Dist` should be different modules.
4. Almost none of the code in `Bridges.py` and `Dist.py` is unittested. These modules have the highest number of untested lines of code currently in BridgeDB.
After this is finished, I am mostly willing to tag `BridgeDB-1.0.0`. There may be a few other refactoring that should get finished before then, but this is the main piece remaining to be completed.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/5232Import bridges into BridgeDB in a separate thread and database transaction2022-07-09T04:22:44ZKarsten LoesingImport bridges into BridgeDB in a separate thread and database transactionLast week, kaner briefly mentioned that BridgeDB doesn't accept client connections during startup. I then asked aagbsn whether he can look at the relevant code parts to see if this also applies to reloading bridges, which happens twice ...Last week, kaner briefly mentioned that BridgeDB doesn't accept client connections during startup. I then asked aagbsn whether he can look at the relevant code parts to see if this also applies to reloading bridges, which happens twice an hour. He said it does.
To be clear: if BridgeDB takes 1 minute to load bridges (20K bridges on aagbsn's linode VM, 8K bridges on my desktop machine), it won't give out any bridges to clients for 2 minutes per hour. That's a maximum availability of 96.6 %. This is going to get worse the more bridges we add.
aagbsn and I think that we could make BridgeDB import bridges in a separate thread and in a single database transaction. There should probably be a check that it doesn't serve too old bridges (e.g., not more than a few hours old) during startup if it hasn't run for a while.Matthew FinkelMatthew Finkelhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/34318BridgeDB doesn't like non-UTF8 encoded requests2022-07-09T04:22:44ZPhilipp Winterphw@torproject.orgBridgeDB doesn't like non-UTF8 encoded requestsI stumbled upon the following exception in BridgeDB's log:
```
Traceback (most recent call last):
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/web/http.py", line 1755, in dataReceived
finishCallbac...I stumbled upon the following exception in BridgeDB's log:
```
Traceback (most recent call last):
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/web/http.py", line 1755, in dataReceived
finishCallback(data[contentLength:])
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/web/http.py", line 2171, in _finishRequestBody
self.allContentReceived()
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/web/http.py", line 2284, in allContentReceived
req.requestReceived(command, path, version)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/web/http.py", line 946, in requestReceived
self.process()
--- <exception caught here> ---
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/web/server.py", line 235, in process
self.render(resrc)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/web/server.py", line 302, in render
body = resrc.render(self)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/web/resource.py", line 265, in render
return m(request)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/bridgedb-0.10.0+34.ga6eb0d1c.dirty-py3.7.egg/bridgedb/distributors/https/server.py", line 722, in render_POST
return CaptchaProtectedResource.render_POST(self, request)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/bridgedb-0.10.0+34.ga6eb0d1c.dirty-py3.7.egg/bridgedb/distributors/https/server.py", line 573, in render_POST
request.args = stringifyRequestArgs(request.args)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/bridgedb-0.10.0+34.ga6eb0d1c.dirty-py3.7.egg/bridgedb/distributors/https/server.py", line 109, in stringifyRequestArgs
arg = arg if isinstance(arg, str) else arg.decode("utf-8")
builtins.UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc2 in position 1: invalid continuation byte
```Armin HuremagicArmin Huremagichttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40039Request bridges from torproject.org gets stuck on "Contacting BridgeDB. Pleas...2022-07-09T04:22:44ZHackerNCoderhackerncoder@encryptionin.spaceRequest bridges from torproject.org gets stuck on "Contacting BridgeDB. Please wait."<!--
* Use this issue template for reporting a new bug.
-->
### Summary
**Summarize the bug encountered concisely.**
Tor Browser 11, going to Tor network settings, enabling "use a bridge" and choosing "request a bridge from torproject....<!--
* Use this issue template for reporting a new bug.
-->
### Summary
**Summarize the bug encountered concisely.**
Tor Browser 11, going to Tor network settings, enabling "use a bridge" and choosing "request a bridge from torproject.org", then clicking "request a new bridge..." makes a pop-up show which just says "Contacting BridgeDB. Please wait.", I guess it should show a captcha.
### Steps to reproduce:
**How one can reproduce the issue - this is very important.**
1. Go to network settings
2. Enable "Use a bridge" and select "request a bridge from torproject.org"
3. Click "request a new bridge..."
4. It doesn't work?
### What is the current bug behavior?
**What actually happens.**
I never get the captcha
### What is the expected behavior?
**What you want to see instead**
I should get a captcha image which I then input the correct text in the text box below
### Environment
Debian GNU/Linux 11.2, two users on windows 10 have also encountered the issue; https://forum.torproject.net/t/tor-browser-11-0-3-windows-10-os-cannot-use-bridge-to-connect/1424/4
Downloaded from website, 32-bit.
### Relevant logs and/or screenshots
Not surehttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/4056bridgedb tracebacks2022-07-09T04:22:44ZRoger Dingledinebridgedb tracebacks```
Traceback (most recent call last):
File "/usr/lib/python2.6/runpy.py", line 122, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/usr/lib/python2.6/runpy.py", line 34, in _run_code
exec code in run_globa...```
Traceback (most recent call last):
File "/usr/lib/python2.6/runpy.py", line 122, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/usr/lib/python2.6/runpy.py", line 34, in _run_code
exec code in run_globals
File "/home/bridges/lib/python2.6/site-packages/TorBridgeDB.py", line 4, in <module>
bridgedb.Main.run()
File "/home/bridges/lib/python2.6/site-packages/bridgedb/Main.py", line 381, in run
startup(configuration)
File "/home/bridges/lib/python2.6/site-packages/bridgedb/Main.py", line 339, in startup
Server.addWebServer(cfg, ipDistributor, webSchedule)
File "/home/bridges/lib/python2.6/site-packages/bridgedb/Server.py", line 268, in addWebServer
useRecaptcha=cfg.RECAPTCHA_ENABLED,
AttributeError: Conf instance has no attribute 'RECAPTCHA_ENABLED'
```
running 054560d33d74e7 with no new lines added to my config file. The fix presumably is to check if the config line is present before trying to access it. (Once I added the config line I didn't get the traceback.)
```
Traceback (most recent call last):
File "/usr/lib/python2.6/dist-packages/twisted/internet/base.py", line 1165, in run
self.mainLoop()
File "/usr/lib/python2.6/dist-packages/twisted/internet/base.py", line 1174, in mainLoop
self.runUntilCurrent()
File "/usr/lib/python2.6/dist-packages/twisted/internet/base.py", line 796, in runUntilCurrent
call.func(*call.args, **call.kw)
File "/usr/lib/python2.6/dist-packages/twisted/internet/task.py", line 194, in __call__
d = defer.maybeDeferred(self.f, *self.a, **self.kw)
--- <exception caught here> ---
File "/usr/lib/python2.6/dist-packages/twisted/internet/defer.py", line 125, in maybeDeferred
result = f(*args, **kw)
File "/home/bridges/lib/python2.6/site-packages/bridgedb/Dist.py", line 299, in cleanDatabase
db.cleanWarnedBridges(time.time()-MAX_EMAIL_RATE)
exceptions.AttributeError: Database instance has no attribute 'cleanWarnedBridges'
```
Looks like we meant to say cleanWarnedEmails?Aaron GibsonAaron Gibsonhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/23251Parsing a networkstatus-bridges with flags only causes BridgeDB to hang2022-07-09T04:22:44ZIsis LovecruftParsing a networkstatus-bridges with flags only causes BridgeDB to hangThe following file:
```
bridgedb@polyanthum /srv/bridges.torproject.org/from-bifroest
% cat networkstatus-bridges
published 2017-08-15 18:58:10 ...The following file:
```
bridgedb@polyanthum /srv/bridges.torproject.org/from-bifroest
% cat networkstatus-bridges
published 2017-08-15 18:58:10
flag-thresholds stable-uptime=0 stable-mtbf=0 fast-speed=0 guard-wfu=0.000% guard-tk=0 guard-bw-inc-exits=0 guard-bw-exc-exits=0 enough-mtbf=1 ignoring-advertised-bws=0
```
causes the bridgedb process to hang. The last log lines output are:
```
bridgedb@polyanthum ~ % tail -f /srv/bridges.torproject.org/log/bridgedb.log
19:46:33 INFO L465:Bridges.insert() BridgeSplitter placing bridge $$C44836BF2F42DB5B1AD3CF6085626056593D846A~Shizuokalibelous into hashring https (via n=5, pos=0).
19:46:33 DEBUG L547:Bridges.insert() Inserting $$C44836BF2F42DB5B1AD3CF6085626056593D846A~Shizuokalibelous into hashring...
19:46:33 DEBUG L78:geo.getCountryCode() Looked up country code: NL
19:46:33 INFO L465:Bridges.insert() BridgeSplitter placing bridge $$2CC6A05D7F52D7B936ABEE13C782780E4B23B64F~conglutinatoreri into hashring email (via n=14, pos=1).
19:46:33 DEBUG L547:Bridges.insert() Inserting $$2CC6A05D7F52D7B936ABEE13C782780E4B23B64F~conglutinatoreri into hashring...
19:46:33 INFO L174:Main.load() Done inserting 1959 bridges into hashring.
19:46:33 DEBUG L208:persistent.save() Saving state to: '/srv/bridges.torproject.org/run/bridgedb.state'
19:46:33 INFO L80:Main.load() Processing descriptors in ../from-bifroest directory...
19:46:33 INFO L86:Main.load() Opening networkstatus file: /srv/bridges.torproject.org/from-bifroest/networkstatus-bridges
19:46:33 INFO L124:descriptors.parseNetwo() Parsing networkstatus file: /srv/bridges.torproject.org/from-bifroest/networkstatus-bridges
```
Further, and this might be a separate issue, but when BridgeDB hangs in this state, the cronjob which calls `bridgedb --reload` launches an entirely new process of bridgedb, without killing the old one, since the old one is locked while doing blocking IO, and the signal handlers are in the async code that it's supposed to come back to. I think there's not really any way to fix this, since Stem is doing the IO there, and Stem isn't async aware/capable.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/3797Clean BridgeDB logs from sensitive data2022-07-09T04:22:44ZChristian FrommeClean BridgeDB logs from sensitive dataIn an ideal world, we wouldn't keep sensitive user data in the BridgeDB logs. Maybe we can come up with an idea on how to keep the data of statistical value and still not keep anything sensitive.
For instance, GetTor logs hashed email a...In an ideal world, we wouldn't keep sensitive user data in the BridgeDB logs. Maybe we can come up with an idea on how to keep the data of statistical value and still not keep anything sensitive.
For instance, GetTor logs hashed email addresses of users. Maybe this is something we could do for BridgeDB, too.Christian FrommeChristian Frommehttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/5331BridgeDB should re-open log files upon HUP2022-07-09T04:22:45ZAaron GibsonBridgeDB should re-open log files upon HUPBridgeDB does not re-open log files after HUP.
This functionality is needed for log rotation.BridgeDB does not re-open log files after HUP.
This functionality is needed for log rotation.Aaron GibsonAaron Gibsonhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/4771bridgedb should make clearer in its logs which addresses it knows are from bu...2022-07-09T04:22:45ZRoger Dingledinebridgedb should make clearer in its logs which addresses it knows are from bulk-exitlistWhen I start bridgedb with loglevel INFO, it says things like
```
Dec 24 19:58:54 [INFO] by location set: 59 50 56 50
Dec 24 19:58:54 [INFO] by category set: 40
```
and then when I hit if from an IP in the 'category set', it says
```...When I start bridgedb with loglevel INFO, it says things like
```
Dec 24 19:58:54 [INFO] by location set: 59 50 56 50
Dec 24 19:58:54 [INFO] by category set: 40
```
and then when I hit if from an IP in the 'category set', it says
```
Dec 24 19:59:17 [INFO] area is 87.236.194
Dec 24 19:59:17 [INFO] ---------------------------------
Dec 24 19:59:17 [INFO] category<1970>87.236.194
Dec 24 19:59:17 [INFO] Replying to web request from 87.236.194.158. Parameters were {}
```
So I assume that means the category set is the same as the set of bridges it gives out when an IP from the bulk-exitlist file asks.
But the assignments.log gives no hint about which bridges are in this category set. Is it a subset of each ring? Or some other set that never gets logged in the assignments list? Confusing.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/4087bridgedb translation text for blocked bridges is wrong2022-07-09T04:22:45ZAaron Gibsonbridgedb translation text for blocked bridges is wrongthe wrong string is selected for bridges that 'might be blocked'the wrong string is selected for bridges that 'might be blocked'https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/4772bridgedb doesn't read the new log severity on hup2022-07-09T04:22:45ZRoger Dingledinebridgedb doesn't read the new log severity on hupWhen I change the LOGLEVEL line in bridgedb.conf and then hup it, it doesn't care what the new LOGLEVEL is.
It looks like it does *something* on hup, so it's not just totally ignoring it. I think.When I change the LOGLEVEL line in bridgedb.conf and then hup it, it doesn't care what the new LOGLEVEL is.
It looks like it does *something* on hup, so it's not just totally ignoring it. I think.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/4405bridgedb's list of tor exit relays is down since bulk exit list is down2022-07-09T04:22:45ZRoger Dingledinebridgedb's list of tor exit relays is down since bulk exit list is downbridgedb has a PROXY_LIST config option that pulls in a list of IPs that should be treated specially for the https bucket. The goal is to prevent people from using their open proxy list (or heck, the Tor network) to appear to be many use...bridgedb has a PROXY_LIST config option that pulls in a list of IPs that should be treated specially for the https bucket. The goal is to prevent people from using their open proxy list (or heck, the Tor network) to appear to be many users of the https bucket.
Unfortunately, when we took down the bulk exit list cgi, we broke bridgedb's ability to learn Tor exit relay IPs.
The new plan has been to wait for TorBEL to go live, since it will have a replacement bulk exit list script. But it looks like TorBEL will be a while more.
In the mean time, weasel suggested that we use the old 'exitlist' script to generate a set of Tor exit IPs. That sounds like a great plan to me.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/24432The meek<->moat tunneling isn't set up correctly2022-07-09T04:22:45ZIsis LovecruftThe meek<->moat tunneling isn't set up correctlyThe apache config has:
...The apache config has:
ProxyPass /meek/ http://127.0.0.1:2000/
ProxyPass /moat/ http://127.0.0.1:3881/moat/
ProxyPass / http://127.0.0.1:3880/ retry=10
ProxyPassReverse / http://127.0.0.1:3880/
(BridgeDB's HTTPS distributor is a Python process listening on port 3880, and the moat distributor is listening on 3881.)
The moat-server is run with the following:
∃!isisⒶwintermute:(master $>)~/code/torproject/bridgedb-admin ∴ cat bin/run-meek
#!/usr/bin/env bash
export TOR_PT_MANAGED_TRANSPORT_VER=1
export TOR_PT_SERVER_BINDADDR=meek-0.0.0.0:2000
#export TOR_PT_SERVER_BINDADDR=meek-78.47.38.229:2000
export TOR_PT_SERVER_TRANSPORTS=meek
export TOR_PT_ORPORT=127.0.0.1:443
/srv/bridges.torproject.org/bin/meek-server --disable-tls & disown
The moat distributor has two pages, /moat/fetch and /moat/check. In my Tor Browser, if I go to https://4-dot-tor-bridges-hyphae-channel.appspot.com/meek/moat/fetch I get a "301 Permanent Redirect" from the Apache server telling me to go to https://bridges.torproject.org/meek/meek/moat/fetch.
Probably I've just configured all the URIs wrong?Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/3573bridges.torproject.org doesn't have a robots.txt2022-07-09T04:22:45ZSebastian Hahnbridges.torproject.org doesn't have a robots.txtWe should add one. Not that it matters too much, but if a search engine is nice about their indexing why not make use of thatWe should add one. Not that it matters too much, but if a search engine is nice about their indexing why not make use of thatIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40024Index error in BridgeDB HTTPS distributor2022-07-09T04:22:45ZCecylia BocovichIndex error in BridgeDB HTTPS distributorI saw the following error while looking at BridgeDB logs:
```
14:09:51 ERROR L143:server.replaceErrorPag() Error while attempting to render te
mplate:
Traceback (most recent call last):
File "/home/bridgedb/virtualenvs/bridgedb/l...I saw the following error while looking at BridgeDB logs:
```
14:09:51 ERROR L143:server.replaceErrorPag() Error while attempting to render te
mplate:
Traceback (most recent call last):
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/bridgedb-0.
12.2+0.gee08b6b1.dirty-py3.7.egg/bridgedb/distributors/https/server.py", line 405,
in render_GET
langs = translations.getLocaleFromHTTPRequest(request)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/bridgedb-0.
12.2+0.gee08b6b1.dirty-py3.7.egg/bridgedb/translations.py", line 98, in getLocaleFr
omHTTPRequest
installTranslations(langs)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/bridgedb-0.
12.2+0.gee08b6b1.dirty-py3.7.egg/bridgedb/translations.py", line 145, in installTra
nslations
languages=[langs[0]], fallback=True)
IndexError: list index out of range
```https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/12843Bridgedb shouldn't handout bridges from .ir and .sy2022-07-09T04:22:45ZNima FatemiBridgedb shouldn't handout bridges from .ir and .syThe public network in these countries is highly censored and the average non-gov-supported/non-suspicious internet connection a user can have is capped to 128kb/s (16KB/s) by authorities in ir.
I can't think of anything these bridges ca...The public network in these countries is highly censored and the average non-gov-supported/non-suspicious internet connection a user can have is capped to 128kb/s (16KB/s) by authorities in ir.
I can't think of anything these bridges can offer to tor network and its users other than harm and unmasking attacks.
Hopefully, we'd come up with a plan to prevent malicious activity by these bridges in long-term, but for now, we should stop handing them out.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/9snowflake-webextension "Could not connect to the bridge."2022-07-09T04:32:31Zcypherpunkssnowflake-webextension "Could not connect to the bridge."My snowflake webextension has been working well up to this point but recently started having the error "Could not connect to the bridge." for the past few days. I'm not sure if this is something on my end or something with Snowflake.My snowflake webextension has been working well up to this point but recently started having the error "Could not connect to the bridge." for the past few days. I'm not sure if this is something on my end or something with Snowflake.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/14Update bug-reporting links for gitlab2022-07-09T04:32:31ZDavid Fifielddcf@torproject.orgUpdate bug-reporting links for gitlabAfter the [gitlab migration](https://lists.torproject.org/pipermail/tor-project/2020-June/002866.html) we need to update bug-reporting instructions.
* https://snowflake.torproject.org/#bugs<br>
https://gitweb.torproject.org/pluggabl...After the [gitlab migration](https://lists.torproject.org/pipermail/tor-project/2020-June/002866.html) we need to update bug-reporting instructions.
* https://snowflake.torproject.org/#bugs<br>
https://gitweb.torproject.org/pluggable-transports/snowflake-webext.git/tree/static/index.html?h=webext-0.3.1&id=d2a9a8fd136ac6bbba393de3d51fb7ca85e17b8a#n75
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/wikis/home#reporting-bugs
I checked in snowflake.git and did not find anything that needs to be changed.Gabagaba@torproject.orgGabagaba@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/42"Snowflake is off. Could not connect to the bridge."2022-07-09T04:32:31ZRoger Dingledine"Snowflake is off. Could not connect to the bridge."I checked my Snowflake proxy in my Firefox, and it told me "Snowflake is off. Could not connect to the bridge." and gave me the option to retry.
I clicked retry, and it connected and seemed happy again.
Was it going to retry on its own...I checked my Snowflake proxy in my Firefox, and it told me "Snowflake is off. Could not connect to the bridge." and gave me the option to retry.
I clicked retry, and it connected and seemed happy again.
Was it going to retry on its own at some point?
This is either a UX bug, "it should tell me it will retry so I don't get anxious that it's broken forever, and maybe the button should be called 'retry now'" or a more serious snowflake bug, "we have a bunch of snowflakes that gave up and we don't know about it". Hopefully the former. :)