The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:43:02Zhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/17006different perspective on censorship2020-06-27T13:43:02ZTracdifferent perspective on censorshipbridgedb and gettor are trying to solve a tchnical problem which is a good thing, no doubt but often technical solutions are not the key to changing a society. most of the time it is the way in which technology is brought into peoples li...bridgedb and gettor are trying to solve a tchnical problem which is a good thing, no doubt but often technical solutions are not the key to changing a society. most of the time it is the way in which technology is brought into peoples lives.
i think it is important to look at how censorship works and how it is integrates with peoples lives:
prevent people from spreading and finding specific information.
One average way someone uses tor could be like this:
-i feel like the goverment is hiding something from me.
-i should try to find a way to get around this.
-i found tons of different tools to do that but what is the best?
-i gonna use tor
-but the goverment makes it difficult for me to get it.
-i have to try to find a way to get it working.
-after a while i finally got it working
-i now have full access to the whole internet...
-now where are the interesting things the goverment is hiding?
-where should i start searching?
-...hmm this thing is nice to have but without aquiring further knowlege its probably not of much use for the average user...
-i probably should look into this some other day.
the problem here is that it requires initiative several times.
except for porn people usually do not show this behavior. thats why facebook and tv are so popular. most humans are passive animals and let others decide the boundaries of ther lives. so there are 2 ways of reaching people: attatch to something within the boundaries or change the boundaries. the best way is to start with the first and continue with the second. with other words we should find a way to make tor a thing.
but starting a movement is hard and usually not going to work. it has to evolve naturally. societies have a gigantic amount of trial and error potential. if a creative environment is being provided a crowd can come up with amazing solutions. creativity works the best the way of expression is universal but some not too tight and not to loose boundaries exist in one or few dimensions.
so what bridgedb gettor and other related projects should do is to find tools that can provide such properities.
on idea i had for example was to make a website or a button in torbrowser that generates a qr code that a mirror for torbrowser, a set of bridges and an url inside. that way all is in one place. the information and the tool to access it. it can be share with friends on a smartphone, stickers could be made of it or shared in any channel that is difficult for censors to control
thats only on idea. there are probably way more different things.
**Trac**:
**Username**: elypterIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/16995Splitting the pool of bridges by seperating people depending on typing cadence2020-06-27T13:43:02ZTracSplitting the pool of bridges by seperating people depending on typing cadencewith OCR getting better and better captchas soon wont be able to provide enough protection against bots fetching bridges anymore. but even if it was safe enough a censor could still hire a cheap worker to type in captchas all day long.
...with OCR getting better and better captchas soon wont be able to provide enough protection against bots fetching bridges anymore. but even if it was safe enough a censor could still hire a cheap worker to type in captchas all day long.
if you let a neural network group people by typing cadence and only supply a group with a subset of the bridges then a single person/bot will never be able to pull the whole database.
**Trac**:
**Username**: elypterIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/16733BridgeDB ports 80 and 443 checkbox2020-06-27T13:43:02ZcypherpunksBridgeDB ports 80 and 443 checkboxPlease include a checkbox to https://bridges.torproject.org/options asking if the results should be limited to bridges running on ports 80 and 443.Please include a checkbox to https://bridges.torproject.org/options asking if the results should be limited to bridges running on ports 80 and 443.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/16671Design a new Bridge Distributor for Tor Browser2020-06-27T13:43:03ZIsis LovecruftDesign a new Bridge Distributor for Tor BrowserFrom recent discussions in developer meetings and on the mailing lists, it is planned that there should be some API/mechanism for Tor Browser to retrieve bridges from BridgeDB. , this will require a new Bridge Distributor.
Regardless of...From recent discussions in developer meetings and on the mailing lists, it is planned that there should be some API/mechanism for Tor Browser to retrieve bridges from BridgeDB. , this will require a new Bridge Distributor.
Regardless of whether this mechanism is automated or interactive, if we follow [BridgeDB's spec](https://gitweb.torproject.org/torspec.git/tree/bridgedb-spec.txt), and we allow wish for the logic controlling how Tor Browser users are handled to be separate (and thus more maintainable), then this will require a new Bridge Distributor, and we should probably start thinking about the threat model/security requirements, and behaviours, of the new Distributor. Some design questions we'll need to answer include:
* Should all points on the Distributor's hashring be reachable at a given time (i.e., should there be some feasible way, at any given point in time, to receive any and every Bridge allocated to the Distributor)?
* Or should the Distributor's hashring rotate per time period? Or should it have sub-hashrings which rotate in and out of commission?
* Should it attempt to balance the distribution of clients to Bridges, so that a (few) Bridge(s) at a time aren't hit with tons of new clients?
* Should it treat users coming from the domain front as separate from those coming from elsewhere? (Is is even possible for clients to come from elsewhere? Can clients use Tor to reach this distributor? Can Tor Browser connect directly to BridgeDB, not through the domain front? See legacy/trac#16650)
* If we're going to do autoprobing, should it still give out a maximum of three Bridges per request? More? Less?https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/16670BridgeDB should be capable of verifying Ed25519 signatures2021-11-26T18:29:20ZIsis LovecruftBridgeDB should be capable of verifying Ed25519 signaturesFrom [proposal #220](https://gitweb.torproject.org/torspec.git/tree/proposals/220-ecc-id-keys.txt) and [proposal #228](https://gitweb.torproject.org/torspec.git/tree/proposals/228-cross-certification-onionkeys.txt), Ed25519 relay (and br...From [proposal #220](https://gitweb.torproject.org/torspec.git/tree/proposals/220-ecc-id-keys.txt) and [proposal #228](https://gitweb.torproject.org/torspec.git/tree/proposals/228-cross-certification-onionkeys.txt), Ed25519 relay (and bridge) keys were added. BridgeDB is going to need to be able to work with the keys in these descriptors and verify the signatures they create.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/16650Set up domain fronting for BridgeDB2021-10-15T03:50:45ZIsis LovecruftSet up domain fronting for BridgeDBWe've been [discussing setting up domain fronting for BridgeDB](https://lists.torproject.org/pipermail/tor-dev/2015-May/008793.html) for a while now.
Benefits include better reachability (to BridgeDB) for clients in censored regions. So...We've been [discussing setting up domain fronting for BridgeDB](https://lists.torproject.org/pipermail/tor-dev/2015-May/008793.html) for a while now.
Benefits include better reachability (to BridgeDB) for clients in censored regions. Solving the problem of clients not being able to reach BridgeDB would allow for Tor Browser to do smarter things w.r.t. helping clients get bridges, helping them get the right kind of bridges, helping clients determine which kind of bridge is the right kind, and helping BridgeDB know more about which (types of) bridges are blocked (in specific regions, possibly). This will also allow Tor Browser to recommend to meek users to obtain a different type of working bridges, which will allow us to hopefully start reducing meek's costs without losing bridge users (and hopefully, without decreasing usability).
This shouldn't be too difficult to set up, however, some open questions include:
* What changes, if any, will we need to make to meek-server to reuse David's work?
* What changes will we need to make to BridgeDB?
* Who will maintain the CDN accounts? Who will pay for them?
* How can we ensure that the traffic to/from BridgeDB is end-to-end TLS encrypted? Can we do this and yet still get the client's real IP address (which BridgeDB currently uses for some necessary rate-limiting logic)?
* How many, and which, CDNs do we want to set up?Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/16649Improve mobile UI experience of BridgeDB's HTTPS Distributor2020-06-27T13:43:03ZIsis LovecruftImprove mobile UI experience of BridgeDB's HTTPS DistributorMany people, including Nathan of The Guardian Project, have complained that the UI of https://bridges.torproject.org has problems on mobile devices. Here are some screen shots from a device with a 320x480px screen:
![https://trac.torpro...Many people, including Nathan of The Guardian Project, have complained that the UI of https://bridges.torproject.org has problems on mobile devices. Here are some screen shots from a device with a 320x480px screen:
![https://trac.torproject.org/projects/tor/raw-attachment/ticket/16649/Screen%20Shot%202015-07-05%20at%2021.45.28.png](https://trac.torproject.org/projects/tor/raw-attachment/ticket/16649/Screen%20Shot%202015-07-05%20at%2021.45.28.png)
![https://trac.torproject.org/projects/tor/raw-attachment/ticket/16649/Screen%20Shot%202015-07-05%20at%2021.45.59.png](https://trac.torproject.org/projects/tor/raw-attachment/ticket/16649/Screen%20Shot%202015-07-05%20at%2021.45.59.png)
![https://trac.torproject.org/projects/tor/raw-attachment/ticket/16649/Screen%20Shot%202015-07-05%20at%2021.46.11.png](https://trac.torproject.org/projects/tor/raw-attachment/ticket/16649/Screen%20Shot%202015-07-05%20at%2021.46.11.png)
![https://trac.torproject.org/projects/tor/raw-attachment/ticket/16649/Screen%20Shot%202015-07-05%20at%2021.46.30.png](https://trac.torproject.org/projects/tor/raw-attachment/ticket/16649/Screen%20Shot%202015-07-05%20at%2021.46.30.png)
![https://trac.torproject.org/projects/tor/raw-attachment/ticket/16649/Screen%20Shot%202015-07-05%20at%2021.47.25.png](https://trac.torproject.org/projects/tor/raw-attachment/ticket/16649/Screen%20Shot%202015-07-05%20at%2021.47.25.png)
![https://trac.torproject.org/projects/tor/raw-attachment/ticket/16649/Screen%20Shot%202015-07-05%20at%2021.47.43.png](https://trac.torproject.org/projects/tor/raw-attachment/ticket/16649/Screen%20Shot%202015-07-05%20at%2021.47.43.png)
Specifically, some improvements I can see which should be made are:
* Fix the font sizes. Some are randomly so HUGE that their text takes up like half a page.
* We need less text on mobile devices. Particularly, things like buttons which have icons probably should not have text.
* The background image is doing wonky things. We probably should just get rid of it on small devices, to make the design cleaner and improve readability.
* The CAPTCHA image is too big to see without swiping to scroll to the right.
* The QRCode image is too big to fit on the screen.
* The "Select All" and "QRCode" buttons look like they are merged together.
* The footer text is a dangerous pile of links; hard to navigate with a touch screen without potentially accidentally clicking one when you didn't mean to.
* The header at the top of the screen (called a "navbar" in Bootstrap lingo) which has a "BridgeDB" and "The Tor Project" buttons is all wonky.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/16616Add BridgeDB unittests for HSDir flag in Bridge networkstatus documents2020-06-27T13:43:03ZIsis LovecruftAdd BridgeDB unittests for HSDir flag in Bridge networkstatus documentsBridgeDB doesn't test for this yet, and [it's going to be added soon](https://lists.torproject.org/pipermail/tor-dev/2015-July/009101.html). We should double check that nothing will break.BridgeDB doesn't test for this yet, and [it's going to be added soon](https://lists.torproject.org/pipermail/tor-dev/2015-July/009101.html). We should double check that nothing will break.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/16521Adresse mail pour ponts relais2020-06-27T13:43:03ZTracAdresse mail pour ponts relaisBonjour, l'adresse mail servant à obtenir des ponts-relais (bridges) ne fonctionne pas.
De plus, pour obtenir des ponts relais, le site "torproject.org" indique cette adresse mail : bridges@bridges.torproject.org
Tandis que le site "br...Bonjour, l'adresse mail servant à obtenir des ponts-relais (bridges) ne fonctionne pas.
De plus, pour obtenir des ponts relais, le site "torproject.org" indique cette adresse mail : bridges@bridges.torproject.org
Tandis que le site "bridges.torproject.org" fournit celle-ci : bridges@torproject.org
Merci de bien vouloir m'indiquer quelle est l'adresse mail à contacter pour obtenir des ponts-relais.
**Trac**:
**Username**: PitmyloveIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/16331BridgeDB is failing to parse extrainfo descriptors because bridges are runnin...2020-06-27T13:43:04ZIsis LovecruftBridgeDB is failing to parse extrainfo descriptors because bridges are running the ed25519 codeBridgeDB is failing to parse descriptors because its version of Stem (1.3.0) can't parse the ed25519 code from prop#220 and prop#228.BridgeDB is failing to parse descriptors because its version of Stem (1.3.0) can't parse the ed25519 code from prop#220 and prop#228.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/16330BridgeDB isn't parsing server descriptors because Stem is choking on a line2020-06-27T13:43:04ZIsis LovecruftBridgeDB isn't parsing server descriptors because Stem is choking on a line```
WARNING:root:This Python version is too old! It doesn't support new-style buffer interfaces: https://mail.python.org/pipermail/python-dev/2010-October/104917.html
Traceback (most recent call last):
File "/home/bridgedb/virtualenvs/...```
WARNING:root:This Python version is too old! It doesn't support new-style buffer interfaces: https://mail.python.org/pipermail/python-dev/2010-October/104917.html
Traceback (most recent call last):
File "/home/bridgedb/virtualenvs/bridgedb/bin/bridgedb", line 5, in <module>
pkg_resources.run_script('bridgedb==0.3.2-dirty', 'bridgedb')
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 499, in run_script
self.require(requires)[0].run_script(script_name, ns)
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 1235, in run_script
execfile(script_filename, namespace, namespace)
File "/srv/bridges.torproject.org/home/virtualenvs/bridgedb/lib/python2.7/site-packages/bridgedb-0.3.2_dirty-py2.7.egg/EGG-INFO/scripts/bridgedb", line 31, in <module>
run(option)
File "/home/bridgedb/virtualenvs/bridgedb/local/lib/python2.7/site-packages/bridgedb-0.3.2_dirty-py2.7.egg/bridgedb/Main.py", line 499, in run
emailDistributor, ipDistributor = reload(False)
File "/home/bridgedb/virtualenvs/bridgedb/local/lib/python2.7/site-packages/bridgedb-0.3.2_dirty-py2.7.egg/bridgedb/Main.py", line 425, in reload
load(state, splitter, clear=False)
File "/home/bridgedb/virtualenvs/bridgedb/local/lib/python2.7/site-packages/bridgedb-0.3.2_dirty-py2.7.egg/bridgedb/Main.py", line 137, in load
serverdescriptors = descriptors.parseServerDescriptorsFile(filename)
File "/home/bridgedb/virtualenvs/bridgedb/local/lib/python2.7/site-packages/bridgedb-0.3.2_dirty-py2.7.egg/bridgedb/parse/descriptors.py", line 144, in parseServerDescriptorsFile
routers = list(document)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python2.7/site-packages/stem/descriptor/__init__.py", line 169, in parse_file
for desc in handler(descriptor_file, descriptor_type, validate, document_handler, **kwargs):
File "/home/bridgedb/virtualenvs/bridgedb/lib/python2.7/site-packages/stem/descriptor/__init__.py", line 234, in _parse_file_for_path
for desc in parse_file(desc_file, *args, **kwargs):
File "/home/bridgedb/virtualenvs/bridgedb/lib/python2.7/site-packages/stem/descriptor/__init__.py", line 219, in parse_file
for desc in file_parser(descriptor_file):
File "/home/bridgedb/virtualenvs/bridgedb/lib/python2.7/site-packages/stem/descriptor/__init__.py", line 269, in _parse_metrics_file
for desc in stem.descriptor.server_descriptor._parse_file(descriptor_file, is_bridge = False, validate = validate, **kwargs):
File "/home/bridgedb/virtualenvs/bridgedb/lib/python2.7/site-packages/stem/descriptor/server_descriptor.py", line 170, in _parse_file
yield RelayDescriptor(descriptor_text, validate, annotations, **kwargs)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python2.7/site-packages/stem/descriptor/server_descriptor.py", line 674, in __init__
super(RelayDescriptor, self).__init__(raw_contents, validate, annotations)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python2.7/site-packages/stem/descriptor/server_descriptor.py", line 539, in __init__
self._parse(entries, validate)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python2.7/site-packages/stem/descriptor/__init__.py", line 494, in _parse
raise exc
ValueError: extra-info-digest line had an invalid value (should be 40 hex characters): extra-info-digest 24EAF6D76B81EF9DC51B5B913812EBCFA8535639 BlGu+TfQKcL46aQ/PZvnsub6ki+YvO9iEagu6jZHpA0
```
This also means that BridgeDB won't start/restart.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/16273Fix URLs for new gitweb.2020-06-27T13:43:04ZDavid Fifielddcf@torproject.orgFix URLs for new gitweb.The software behind https://gitweb.torproject.org/ changed a while back and broke some of the URLs in BridgeDB. One of them is user-facing, the link to CHANGELOG in lib/bridgedb/templates/base.html.The software behind https://gitweb.torproject.org/ changed a while back and broke some of the URLs in BridgeDB. One of them is user-facing, the link to CHANGELOG in lib/bridgedb/templates/base.html.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/15968Add a "Content-Security-Policy" header to BridgeDB's HTTPS Distributor2020-06-27T13:43:04ZIsis LovecruftAdd a "Content-Security-Policy" header to BridgeDB's HTTPS DistributorNow that BridgeDB uses a tiny bit of Javascript on the https://bridges.torproject.org/bridges page (to facilitate displaying the QR code and selecting all the bridge lines), we should consider possibly adding a ["Content-Security-Policy"...Now that BridgeDB uses a tiny bit of Javascript on the https://bridges.torproject.org/bridges page (to facilitate displaying the QR code and selecting all the bridge lines), we should consider possibly adding a ["Content-Security-Policy" (CSP) HTTP header](http://www.html5rocks.com/en/tutorials/security/content-security-policy/) to responses from BridgeDB's HTTP(S) server.
While the XSS attack surface of BridgeDB is essentially non-existent, the idea is instead that a malicious bridge could specify in its Pluggable Transport arguments in its extrainfo descriptor something like:
```
transport obfs4 1.1.1.1:1111 evil=<script>[…]</script>
```
If BridgeDB added the CSP HTTP header:
```
Content-Security-Policy: default-src 'none'; base-uri https://bridges.torproject.org; script-src https://bridges.torproject.org; style-src https://bridges.torproject.org; img-src https://bridges.torproject.org data:; font-src https://bridges.torproject.org; frame-options 'deny';
```
Then inline Javascript, inline CSS (CSS3, when combined with HTML5, is Turing-complete), and loading of fonts, images, blobs, scripts and basically every other type of content from external sources (i.e. everything other than https://bridges.torproject.org), would all be disabled. The only downside appears to be that CSP is not implemented in IE (not until IE10, which apparently has limited support), so all BridgeDB's users running IE6 and IE7 on WindowsXP boxes in China (there are _a lot_ of these boxes in China) could still be attacked.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/15967Separate BridgeDB's CAPTCHA into another service2021-09-09T14:29:25ZIsis LovecruftSeparate BridgeDB's CAPTCHA into another serviceThis was first requested when my GSoC student a couple summers ago was hacking on a Twitter bridge distributor, so that twitter requests for bridges could use the CAPTCHAs to decrease automated requests.
Last week, [Mike Perry requested...This was first requested when my GSoC student a couple summers ago was hacking on a Twitter bridge distributor, so that twitter requests for bridges could use the CAPTCHAs to decrease automated requests.
Last week, [Mike Perry requested this](https://lists.torproject.org/pipermail/tor-dev/2015-May/008794.html), as part adding a mechanism to get new bridges directly from Tor Launcher.
Finally, Arturo also requested this today so that OONI probes running in censored countries can have an interface for getting bridges:
```
23:37 hellais | anyways it would be nice to have an API where I send a HTTP request and I get back some JSON with the captcha encoded in base64 and I can send back the solution to get bridges
23:38 isis | yep, that's exactly what we're going to do :)
23:39 isis | except we hadn't exactly decided on JSON, but yeah
23:39 isis | the captcha image is already base64, btw
23:42 isis | hellais: would these be bridges for bridge_reachability tests, or bridges just to get an ooniprobe capable of connecting to some (hopefully)-known-good-and-not-filtered version of the
internet, for like submitting reports and stuff
23:43 isis | hellais: err, that was meant as a question
23:46 hellais | the second
23:46 hellais | I would like to have this: https://gist.github.com/hellais/995793f88fc42727fb92
23:46 hellais | run when ooniprobe is first installed to check if the user needs some bridges
23:47 hellais | I think I'll put it in the setup.py or something
23:47 hellais | since ooniprobe relies on tor for reporting without a working tor, we can't collect the reports
23:48 hellais | parsing HTML with standard python libraries is just a bit messy and I was wondering if there was a better way
00:10 hellais | anyways I think I will end up making something that starts a web server and makes the user solve the CAPTCHA on the local webserver. Having to open a JPG file and input it into a shell
is so uncomfortable
00:13 hellais | but the JSON API would be nice nonetheless
```https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/15866BridgeDB has less bridges because the BridgeAuthority appears to be giving it...2020-06-27T13:43:05ZIsis LovecruftBridgeDB has less bridges because the BridgeAuthority appears to be giving it incorrect networkstatuses**tl;dr:** We _really_ need to redesign and rewrite the BridgeAuthority. For now, BridgeDB is going to ignore the BridgeAuthority's `networkstatus` documents.
There appears to be something quite wrong with the way the BridgeAuthority pr...**tl;dr:** We _really_ need to redesign and rewrite the BridgeAuthority. For now, BridgeDB is going to ignore the BridgeAuthority's `networkstatus` documents.
There appears to be something quite wrong with the way the BridgeAuthority produces its `networkstatus-bridges` documents.
[As explained](https://trac.torproject.org/projects/tor/ticket/9380#comment:39) on legacy/trac#9380, BridgeDB started verifying signatures and matching digests for the full chain of bridge descriptors from `networkstatus` → `server-descriptor` → `extrainfo`. Thus, if a bridge is missing from the BridgeAuthority's `networkstatus-bridges` document, then it doesn't exist as far as BridgeDB is concerned. This afternoon, [users were complaining](https://lists.torproject.org/pipermail/tor-talk/2015-April/037652.html) that BridgeDB was only giving one bridge at a time (which is normal behaviour when BridgeDB doesn't have enough bridges).
To get to the point, **Bridgedb doesn't have very many bridges because the `networkstatus-bridges` document is completely whack — it's missing 83.41% of the total bridges**. It's not that the file is empty. It's just missing most of the bridges that it should have, and instead it has strange networkstatus documents in it, like for bridges which don't exist anymore and documents which reference seemingly non-existent `server-descriptor`s.
This is what part of a second of descriptor parsing looks like (sanitised):
```
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge '6722DAAEADE603C9626975ED8C8CF545236C44A7' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge 'F151AC2EE601361D125D5E5963178038E606B440' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge '63E42362C38B0D482B9BED7CA3B6D8F513B85AC1' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge '8F0A9018A4313D0CFCBA79004F9DE5FE66E73368' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge 'FC80E087A8728AAD0A8FE946C5C4EEE2F937487D' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge '97255849FB90EAEDE3DDC9CDA088A1ECCF71FDC2' which wasn't in the networkstatus!
03:33:24 WARNING L149:Main.load() The server-descriptor digest for bridge '2A624DD84370EDAC58BD73D427B1BBFF53C72315' doesn't match the digest reported by the BridgeAuthority in the networkstatus doc
ument:
Digest reported in networkstatus: D47CC3D7FEACF75ABB780B0F63044CEB4D7101F4
Actual descriptor digest: 39C622B8C7C0CB90BFDE273149E57B6CAF06AAD7
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge 'E3C750F06B9043B2DAD4275613FBF355EAB161D2' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge '95374284A3A6B0C289DD8ED49B49A32DF769A677' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge 'A699637AAF2BB6DD2FDC338647BF5DBE668A79AC' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge 'ABD206AA7A2C607EAA641D8567A307E031968DBA' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge '265AD3890E6FE46E84EE2756815E7101976E4E76' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge '2038634774046BB0D58780AB4718462427E1A372' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge '6E2AD7E1D9A912058A895193FB94EB0AE2B91B7E' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge 'FFBD398A3BF169A9FD60620AE2C2C1CC1C9493DE' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge 'E83EB92BB3DE7FFA9AC188313A63E023809EAD44' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge '810AF92A276DC364969F16B4A27C8529E0D771B7' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge '3D73330F11479E32A0E88AAF4E7E2984A7F743BA' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge 'C2549EB8853561C8BB798B2661697E80579974AD' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge '7313AD77ED8AF12E4D91835CFB21BBCCDC900A13' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge '8FD5261825BC50EA557EBCFF92FABEE6749855B5' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge 'D096A70EFD67C1198DA0DBA06CDC1B55075FB326' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge '02327187D5A3F89F864200D3A697CA4B8C8246CC' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge 'C9D611438E7B127DD06D1CA49BCF39634C1E92EA' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge '2C398670D16EC6C311AE3B5B035D6154D1B871E2' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge '0BD5EEC61594FC25BF565C5DCB5B9C0F9F99B5F0' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge 'FB23D1A30043ABDD0C6DA9EAD428DF49BC65F7F0' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge '4B0A85A4FE8AB67F0F769FD1EC25C27B057271C5' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge '575A7C152ECDE01756564E89F74727F8C259FBA9' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge 'BE9182355E2A10303D7F69BCECD14EF89A568518' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge '0549DCE8B5FAE293BA94D5BEB81782C54AA37C3D' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge '9DFA242252B2D85C9889C7270D5B6C562E9AC711' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge '627BDCE8D86F4E4406D41A8B3081509CF9A99EA0' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge 'F7198BBF43EDBB32DFF7C7923A8799884471FFE1' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge '3DB7D81C77A164DA0EE5B1DB915C78047EDBB4B5' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge 'FA1670376088B544AF3C54D117E3325EF6977B50' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge '418AE2105849C379EBD8F416B5EF670793A4E719' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge 'EC17838F9B34A9009CD2CA8296B50AA4124EC963' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge '0C82FDAFFB41B5CC3C209C6DC50B33B03FA1C316' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge '20273A6DC581B92F6D30330D7BD81DFDE45A9A92' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge 'F8855C2CEB6FE2D5256795FFAFC072904790F334' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge '5426A87A1914A4414031390C48561AC6B80A502F' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge '3BFFE8B3AB2BEF7BB8D848687899739AF7676E6E' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge '32F8F2DA49B414374D22525A43783A3A757F1333' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge 'DCFECBFB14C241487E48117B82FC8D40B9C89FB5' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge 'B45D16748A0A458AAF1E1CF12F6A0E1470221AC1' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge '0C56BC8C6FA39D3D6B474B311412545B656FFDCB' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge '0D0870C71AAFDE28298748A7D6C1C7BADE3E648D' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge '22CA5908E13A94FFD9E3A549D3B5D297EC4C491A' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge '7DBC81F21827C3A08128D3E0E79772C78DCDC223' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge 'C96261D3C370A1CD0CEB47985B0130B1EF25D04E' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge '0D1B368FBB152B18348BBE0930DD3C891B208E9F' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge 'A938247AC831B1F9BE4F8AF24291A7D3402FB3E8' which wasn't in the networkstatus!
03:33:24 WARNING L144:Main.load() Received server descriptor for bridge '9758F5954682E7677CFC6389AD95F7B60BB8A7C5' which wasn't in the networkstatus!
```
Because of this, BridgeDB has only 901 bridges right now, when in reality, there are 5429 bridges.
My proposed solution is put a `THE_BRIDGE_AUTH_IS_A_BROKEN_PIECE_OF_SHIT = True` option in BridgeDB's config file, and ignore the BridgeAuthority altogether¹. Combined with other problems like legacy/trac#11216 and legacy/trac#15707, the BridgeAuthority now serves essentially no purpose beyond bridge ORPort reachability tests and being a wastebasket for whatever descriptors anyone wants to throw at it.
¹ BridgeDB will still parse networkstatuses for the Bridge flags. That's it.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/15707Tonga isn't deduplicating bridge-server-descriptors anymore2020-06-27T13:43:05ZIsis LovecruftTonga isn't deduplicating bridge-server-descriptors anymoreThe BridgeAuthority used to deduplicate `@type bridge-server-descriptor`s (but not `@type bridge-extrainfo`s). It isn't doing either now.
I can fix this on BridgeDB, trivially, because I've already got the `bridgedb.parse.descriptors.d...The BridgeAuthority used to deduplicate `@type bridge-server-descriptor`s (but not `@type bridge-extrainfo`s). It isn't doing either now.
I can fix this on BridgeDB, trivially, because I've already got the `bridgedb.parse.descriptors.deduplicate()` function for handling the extrainfos. Or… perhaps this was broken somehow during legacy/trac#14797 when we moved BridgeDB to polyanthum, like perhaps something was changed on Tonga? We could fix it on BridgeDB or Tonga, I have no preference; feel free to change the Component to something that makes more sense.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/15620Leekspin should be able to create HS descriptors2020-06-27T13:43:05ZIsis LovecruftLeekspin should be able to create HS descriptors[Leekspin](https://gitweb.torproject.org/user/isis/leekspin) should be taught to generate HS descriptors to help with fuzzing Tor's parsers. See e.g. legacy/trac#14847, legacy/trac#3523, legacy/trac#15554, legacy/trac#3522, etc., which a...[Leekspin](https://gitweb.torproject.org/user/isis/leekspin) should be taught to generate HS descriptors to help with fuzzing Tor's parsers. See e.g. legacy/trac#14847, legacy/trac#3523, legacy/trac#15554, legacy/trac#3522, etc., which all contain at least one person saying some variant of the phrase "untested because I don't have an HS desc".Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/15522Write Protobufs for any BridgeDB data which must be sent over a network or IP...2020-06-27T13:43:05ZIsis LovecruftWrite Protobufs for any BridgeDB data which must be sent over a network or IPC channelBridgeDB should have [Protobufs](https://developers.google.com/protocol-buffers/docs/overview) for any data structures which must be sent over either network or IPC channels. This includes data such as bridges parsed from Stem (which sho...BridgeDB should have [Protobufs](https://developers.google.com/protocol-buffers/docs/overview) for any data structures which must be sent over either network or IPC channels. This includes data such as bridges parsed from Stem (which should be sent to the database manager from legacy/trac#12031), any data which is going to be exported to CollecTor (e.g. if we were to redesign a new pool "assignments.log" format like for legacy/trac#2755 and exported that), and any data which the client-side Social Distributor (legacy/trac#7520) built into a Tor Browser extension plans to send to BridgeDB and vice-versa.
Protocol buffers have had extensive security reviews, are used extensively in many projects, and would provide automatic code generation for serialisers/marshallers for Python/Java/C++/C/Go, meaning that, for example, both Metrics and BridgeDB could use the same generated code to read the same data format.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/15517BridgeDB considers IPv6 clients in the same /64 to be "in the same subnet"2020-06-27T13:43:05ZIsis LovecruftBridgeDB considers IPv6 clients in the same /64 to be "in the same subnet"And an IPv6 `/48` is rather trivial to obtain. When discussing this in the IRC channel, several people immediately spoke up to say that they have an IPv6 `/48` subnet, which is equivalent to 65535 `/64`s. The current code (from legacy/t...And an IPv6 `/48` is rather trivial to obtain. When discussing this in the IRC channel, several people immediately spoke up to say that they have an IPv6 `/48` subnet, which is equivalent to 65535 `/64`s. The current code (from legacy/trac#4297 and [this commit](https://gitweb.torproject.org/user/isis/bridgedb.git/commit/?h=develop&id=3bee35c8d3977d0645bd57b8fc7bf4ef003538af)) at `bridgedb.Dist.uniformMap()` would allow anyone with an `/48` to pretend to be a maximum of 65535 clients to BridgeDB (which would still allow them to request IPv4 bridges, as well as Pluggable Transport bridges, I might add) and obtain a maximum of 65535 unique positions within a distributor's hashring per period, allowing the bridges within most hashrings to be entirely enumerated within a matter of a few hours.
As for fixing this bug, I planned to use (both for IPv4 and IPv6) whatever logic tor uses for the `EnforceDistinctSubnets` option. However, as it turns out, there may be a bug in that logic (legacy/trac#15518) with respect to IPv6.
I propose (from talking to people, and glancing at https://en.wikipedia.org/wiki/IPv6_subnetting_reference and https://www.arin.net/resources/request/ipv6_initial_assign.html) that BridgeDB switch to treating IPv6 `/32`s (the minimum ARIN allocation for an LIR) as distinct subnets, and treat clients within the same `/32` as coming from the same IP address.
[This was discovered while working on legacy/trac#4771 and legacy/trac#1839.]Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/15464BridgeDB's continuous integration setup steps should be separate scripts2020-06-27T13:43:06ZIsis LovecruftBridgeDB's continuous integration setup steps should be separate scripts…or Makefile directives.
weasel requested this at the Valencia developer meeting, in order to make it easier to get BridgeDB's test builds running on Jenkins (if we should ever wish to do so).
Currently, BridgeDB's CI uses Travis. The...…or Makefile directives.
weasel requested this at the Valencia developer meeting, in order to make it easier to get BridgeDB's test builds running on Jenkins (if we should ever wish to do so).
Currently, BridgeDB's CI uses Travis. The builds can be viewed [here](https://travis-ci.org/isislovecruft/bridgedb/builds). The script which controls the setup and testing procedure for these builds is BridgeDB's [.travis.yml file](https://gitweb.torproject.org/bridgedb.git/tree/.travis.yml?h=develop), which is basically a lot like Tor Browser's gitian descriptors, it's YAML with one command per line, organised into various sections (which in this case, are called in the order they happen to be in in the .travis.yml file). So pretty simple to convert.Isis LovecruftIsis Lovecruft