Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2020-06-27T13:43:18Zhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/10239Payment for bridges (and effects this would have)2020-06-27T13:43:18ZTracPayment for bridges (and effects this would have)It is theoretically possible to accept payment (e.g. via bitcion) and use this payment to set up a custom bridge. This bridge would then only be shared with the identity that has made payment for it.
There are a few advantages to handin...It is theoretically possible to accept payment (e.g. via bitcion) and use this payment to set up a custom bridge. This bridge would then only be shared with the identity that has made payment for it.
There are a few advantages to handing out bridges in this way:
- This method of handing out bridges is non-exhaustive. The more bridge requests come in, the more bridges will be created.
- The bridge will be shared with one identity exclusively and will be used at their discretion. It becomes more difficult to block the user of a bridge.
- Bitcoin is being traded in Iran, China, etc.
- No need to search for a working bridge every week. (I assume this is an issue?).
Some disadvantages:
- This method is undemocratic. Privacy would become better for those with more resources.
- This method centralizes power when it becomes the main method to get a bridge. In the event that this method becomes popular, more parties might implement this scheme. Some state might start to issue payed-for bridges (at a competitive rate) to a significant amount of users, and then kill all the bridges at their discretion. Not sure how much of an issue this would be in practice.
Possible side-effect:
- More capital control. Although in the case of China, bitcoin will probably not be blocked.
Open questions:
- Can it be automated to create unique bridges? (That are not all in the same block).
**Trac**:
**Username**: tmphttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/10314Think of strategy for deprecating pluggable transports (e.g. obfs2)2020-06-27T13:44:01ZGeorge KadianakisThink of strategy for deprecating pluggable transports (e.g. obfs2)Currently, most bridges (the 70%) run obfs3+obfs2 and the rest run only obfs2.
China has an active probing module for obfs2 and not for obfs3, so using obfs2 in China is bad currently. It doesn't allow you to bypass censorship and it mi...Currently, most bridges (the 70%) run obfs3+obfs2 and the rest run only obfs2.
China has an active probing module for obfs2 and not for obfs3, so using obfs2 in China is bad currently. It doesn't allow you to bypass censorship and it might also burn the bridge (if they ever decide to do IP-based censorship and not IP/TCP-based censorship).
We should think of how to deprecate obfs2. A good starting point would be to completely remove it from obfsproxy (by removing the code) and also stop suggesting it via BridgeDB.
We should think if there are any problems with the above approach, and how we can improve it.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/10333Indexing list-like objects by 0L in Bridges.getConfigLine2020-06-27T13:43:18ZIsis LovecruftIndexing list-like objects by 0L in Bridges.getConfigLineThis bug occurs because, in the function `bridgedb.Bridges.getConfigLine()`, the following lines determine ― when a request comes in ― the client's position in the hashring:
```
if not request: request = 'default'
digest...This bug occurs because, in the function `bridgedb.Bridges.getConfigLine()`, the following lines determine ― when a request comes in ― the client's position in the hashring:
```
if not request: request = 'default'
digest = get_hmac_fn('Order-Or-Addresses')(request)
pos = long(digest[:8], 16) # lower 8 bytes -> long
```
Later on, in the same function, `pos` modulo the number of addresses this `Bridge` has, is used to index the collected/filtered addresses. Similarly, `pos` modulo the number of ports in the portlist is used to index the portlist:
```
# default ip, orport should get a chance at being selected
if isinstance(self.ip, addressClass):
addresses.insert(0,(self.ip, addr.PortList(self.orport)))
if addresses:
address,portlist = addresses[pos % len(addresses)]
if isinstance(address, ipaddr.IPv6Address): ip = "[%s]"%address
else: ip = "%s"%address
orport = portlist[pos % len(portlist)]
```
Meaning that the fewer number of addresses/ports there are, the higher the chance that the `pos` will be modulo some small number which is a factor. For example, if there is only one address, this would be something like:
```
>>>from bridgedb import Bridges
>>> digest = Bridges.get_hmac_fn('Order-Or-Addresses')('default')
>>> pos = long(digest[:8], 16)
>>> pos
3790090317L
>>> pos % 1
0L
```
Which causes the following bug. What is extra strange is that the ValueError from trying to index these list-like things with a `0L` doesn't seem to occur on the addresses, only on the `orport = portlist[…` line. Though, it's also worth noting that the `'default'` value used in the hmac generation is usually a client's IP address, truncated to the /24. This means that this indexing-by-0L bug will occur
rather indeterminately.
```
(bridgedb)∃!isisⒶwintermute:(fix/9462-refactor-netstatus-parsers_r9462C *+$=)~/code/torproject/bridgedb ∴ bridgedb
Unhandled Error
Traceback (most recent call last):
File "/home/isis/.virtualenvs/bridgedb/local/lib/python2.7/site-packages/twisted/protocols/basic.py", line 571, in dataReceived
why = self.lineReceived(line)
File "/home/isis/.virtualenvs/bridgedb/local/lib/python2.7/site-packages/twisted/web/http.py", line 1619, in lineReceived
self.allContentReceived()
File "/home/isis/.virtualenvs/bridgedb/local/lib/python2.7/site-packages/twisted/web/http.py", line 1694, in allContentReceived
req.requestReceived(command, path, version)
File "/home/isis/.virtualenvs/bridgedb/local/lib/python2.7/site-packages/twisted/web/http.py", line 790, in requestReceived
self.process()
--- <exception caught here> ---
File "/home/isis/.virtualenvs/bridgedb/local/lib/python2.7/site-packages/twisted/web/server.py", line 189, in process
self.render(resrc)
File "/home/isis/.virtualenvs/bridgedb/local/lib/python2.7/site-packages/twisted/web/server.py", line 238, in render
body = resrc.render(self)
File "/home/isis/.virtualenvs/bridgedb/local/lib/python2.7/site-packages/bridgedb-0.0.1_274_g594a221_dirty-py2.7.egg/bridgedb/HTTPServer.py", line 140, in render
return self.getBridgeRequestAnswer(request)
File "/home/isis/.virtualenvs/bridgedb/local/lib/python2.7/site-packages/bridgedb-0.0.1_274_g594a221_dirty-py2.7.egg/bridgedb/HTTPServer.py", line 218, in getBridgeRequestAnswer
) for b in bridges)
File "/home/isis/.virtualenvs/bridgedb/local/lib/python2.7/site-packages/bridgedb-0.0.1_274_g594a221_dirty-py2.7.egg/bridgedb/HTTPServer.py", line 218, in <genexpr>
) for b in bridges)
File "/home/isis/.virtualenvs/bridgedb/local/lib/python2.7/site-packages/bridgedb-0.0.1_274_g594a221_dirty-py2.7.egg/bridgedb/Bridges.py", line 192, in getConfigLine
orport = portlist[pos % len(portlist)]
File "/home/isis/.virtualenvs/bridgedb/local/lib/python2.7/site-packages/bridgedb-0.0.1_274_g594a221_dirty-py2.7.egg/bridgedb/parse/addr.py", line 372, in __getitem__
return portlist[portlist.index(port)]
exceptions.ValueError: 0L is not in list
^C
```Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/10362Deploy FTE as a pluggable transport in PTTBBs2020-06-27T13:44:01ZGeorge KadianakisDeploy FTE as a pluggable transport in PTTBBsThis is the ticket to organize the deployment of FTE as a new pluggable transport in PTTBBs.
Kevin posted a release announcement here:
https://lists.torproject.org/pipermail/tor-dev/2013-December/005929.html
We need to review and audit...This is the ticket to organize the deployment of FTE as a new pluggable transport in PTTBBs.
Kevin posted a release announcement here:
https://lists.torproject.org/pipermail/tor-dev/2013-December/005929.html
We need to review and audit the code before we deploy this. Then we need to include it in our next PTTBBs.kpdyerkpdyerhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/10385Replace BridgeDB's use of python-gpgme with python-gnupg2020-06-27T13:43:18ZIsis LovecruftReplace BridgeDB's use of python-gpgme with python-gnupgDue to concerns which I've pointed out in [#5463](https://trac.torproject.org/projects/tor/ticket/5463#comment:11), we should assess the effort needed to replace BridgeDB's use of the python-gpgme module with [python-gnupg](https://pypi....Due to concerns which I've pointed out in [#5463](https://trac.torproject.org/projects/tor/ticket/5463#comment:11), we should assess the effort needed to replace BridgeDB's use of the python-gpgme module with [python-gnupg](https://pypi.python.org/pypi/gnupg) (full disclosure: I wrote and maintain it). I'm recommending the one I maintain because I've auditted most of the GnuPG Python module/wrappers out there and they are all _terrible_. If someone else knows of another one which doesn't completely suck, feel free to use that instead.
Before starting work on this, someone should assess the effort required so that we can decide if it's worth it to go through with the switch.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/10412IPv6 Support By Pluggable Transport2020-06-27T13:44:01ZMatthew FinkelIPv6 Support By Pluggable TransportTor clients can't send a proxy request for an ipv6 address connection to a pluggable transport if the PT says it supports socks4. This is not so good because IPv6 addresses are becoming more prevalent. The three options, as I see them, a...Tor clients can't send a proxy request for an ipv6 address connection to a pluggable transport if the PT says it supports socks4. This is not so good because IPv6 addresses are becoming more prevalent. The three options, as I see them, are:
- Change pt-spec to state that PTs can support either socks4a or socks5 (and change Tor and implementation to adhere to this)
- If a PT supports IPv6 addresses then it must use SOCKS5
- Allow a PT to claim it supports both socks4 and socks5 in the CMETHOD line and Tor will need to decide which SOCKS version to use depending on the IP version.
The first one seems like a good idea. The second requires no spec change but will cause some pain with existing PTs. The last seems useful but requires a lot of modifications and so it's unnecessary.
(Thanks to dcf1 and arma for their help)George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/10446BridgeDB is/was using a GeoIP module which is incompatible with virtualenvs2020-06-27T13:43:18ZIsis LovecruftBridgeDB is/was using a GeoIP module which is incompatible with virtualenvs```
04:07 [ (isis) ) sysrqb: i realised yesterday that we're actually using the wrong GeoIP module in bridgedb's requirements.txt
04:08 [ (isis) ) although the one we're using, pygeoip.GeoIP, is compatible (at least it has all the same f...```
04:07 [ (isis) ) sysrqb: i realised yesterday that we're actually using the wrong GeoIP module in bridgedb's requirements.txt
04:08 [ (isis) ) although the one we're using, pygeoip.GeoIP, is compatible (at least it has all the same functions we're using from the the GeoIP one)
04:09 [ (isis) ) i am thinking that perhaps we should keep using the "wrong" one, since it is compatible
04:10 [ (isis) ) because the "wrong" one (the pygeoip one) installs cleanly in a virtualenv, while the other one does not
04:10 [ (isis) ) i think they both require the same underlying deps, libgeoip-dev and geoip-database in Debian
04:11 [ (isis) ) which means that my README instructions which said that bridgedb requires tor-geoipdb were also wrong
```Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/10517Fail to launch FteProxy (pre-compilled bundles)2020-06-27T13:44:01ZTracFail to launch FteProxy (pre-compilled bundles)To prepare a trip in china, i decided to try differents pluggable transports, to check if these were working well (at least with an uncensored connection). I tried the Tor official pluggable transports bundle (with obsfproxy and flashpro...To prepare a trip in china, i decided to try differents pluggable transports, to check if these were working well (at least with an uncensored connection). I tried the Tor official pluggable transports bundle (with obsfproxy and flashproxy) and it worked well, than i tried to launch the FteProxy pluggable transports bundle, but it didn't worked. When i start Vidalia, the progression bar stays blocked on "Starting", and on "Parsing GEOIP IPv6 file .\Data\Tor\geoip6." in the journal.
I don't know why it doesn't work, because there is no error message or bug signaled, it justs freeze and seems loads. I already has the problem with the regular tor browser bundle in another computer, but i resolved the problem by deleting all the browser bundles and download another one.
Maybe it's provoqued by the new version of Tor (3.5, with Tor Launcher instead of Vidalia), i don't know.
However i hope this bug is resolvable (but everything is, right ?).
Thanks to reply !
**Trac**:
**Username**: Azertherionhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/10559BridgeDB writes `keyid=` before fingerprints2020-06-27T13:43:18ZIsis LovecruftBridgeDB writes `keyid=` before fingerprintsWhile testing for legacy/trac#9499, I realised that if I request https://127.0.0.1:6789/bridges?transport=obfs3 (localhost because it's a local test instance) then BridgeDB hands back bridge lines like this:
```
obfs3 245.102.100.252:236...While testing for legacy/trac#9499, I realised that if I request https://127.0.0.1:6789/bridges?transport=obfs3 (localhost because it's a local test instance) then BridgeDB hands back bridge lines like this:
```
obfs3 245.102.100.252:23619 keyid=59ca743e89b508e16b8c7c6d2290efdfd14eea98
```
which is wrong and will need to be fixed before we hand out fingerprints. This should be easy, just figure out where this string is getting added and kill it with fire.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/10629PT spec changes for better interoperability with other projects2021-11-08T19:56:38ZXimin LuoPT spec changes for better interoperability with other projectsI spoke with the i2p guys today and here are some of their suggestions for the PT spec. These would make it easier for them (and future other projects) to use Tor's PTs.
Major improvements:
- better spec documentation
- less Tor jarg...I spoke with the i2p guys today and here are some of their suggestions for the PT spec. These would make it easier for them (and future other projects) to use Tor's PTs.
Major improvements:
- better spec documentation
- less Tor jargon, split Tor-specific information into separate sections (e.g. Tor env vars)
- some guidelines for non-Tor programs to use PTs
- better handling of per-endpoint config params such as pubkeys, instead of current hack via SOCKS auth params
Smaller enhancements, "good to have":
- possibility of letting a single process to act as both a client (outgoing) and server (incoming).
- flashproxy must allow client-specific remote endpoints (already as legacy/trac#10196)
- don't trust the entire localhost machine to make outgoing connections, e.g. if one users wants to run his own instance. two options here:
- SSL connection with user/pass to the SOCKS transport client
- use unix domain sockets. This also frees up ports, which is extra-useful in PT composition. Doesn't work on windows, though.Tor: unspecifiedYawning AngelYawning Angelhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/10671Pluggable Transports: Improve method of transferring parameters to client-sid...2022-11-03T15:40:02ZGeorge KadianakisPluggable Transports: Improve method of transferring parameters to client-side transportsCurrently, client-side pluggable transports (like scramblesuit) that need parameters (like shared-secrets, etc.) are supposed to get them through the SOCKS protocol. Specifically, Tor is supposed to shove the shared-secret in the usernam...Currently, client-side pluggable transports (like scramblesuit) that need parameters (like shared-secrets, etc.) are supposed to get them through the SOCKS protocol. Specifically, Tor is supposed to shove the shared-secret in the username/password fields of the SOCKS handshake.
Apart from the solution being ugly and super hacky it also imposes a size limit to our parameters, since SOCKS5 has a maximum length of 512 bytes of username/password (legacy/trac#9163). SOCKS5 is needed since it's the only SOCKS version that officially supports IPv6.
As a more permanent solution than legacy/trac#9163 we should think of how to improve this situation. At least three ways come in mind:
a) We use the reserved `METHOD` field of the SOCKS protocol to define our own authentication method (see section 3 of http://csocks.altervista.org/rfc/rfc1928.txt). Then we use this new authentication method to pass parameters to pluggable transports.
This seems cleaner than before, but we still piggyback on the authentication mechanism (which means that if we ever wanted to password protect obfsproxy's SOCKS listener we can't) so it's not perfect. Also many libraries might not support reserved authentication methods, which means that some monkey patching will be needed.
b) We design and specify our own SOCKS protocol. SOCKS kinda sucks for PTs anyway (legacy/trac#7153). I don't like this idea, because I don't like homebrewed protocols and it will require significant specification/development efforts to replace all the current uses of SOCKS in PTs.
c) We write yet another metadata protocol that happens after SOCKS but before application-layer data is transferred to obfsproxy. It's the equivalent of Extended ORPort for the client-side, and it might be useful for other information apart from client-side parameters. I don't like this solution either.
d) We define an environment varialbe similar to `TOR_PT_SERVER_TRANSPORT_OPTIONS` but for the client-side. Unfortunately, the client-side parameters are dynamic (parameters are different for different destination addresses) so the environment variable will also need to include the destination bridge address along with the parameter. Furthermore, if we ever wanted to make parameters completely dynamic (so that they change after Tor startup) this solution might complicate matters. Still this is not terribly bad (since we already parse env vars and we already do something similar on the server side), but it's not good either.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/10672Send mail to bridge operators and inform them of pluggable transports2020-06-27T13:44:00ZGeorge KadianakisSend mail to bridge operators and inform them of pluggable transportsAs part of the efforts to increase the number of obfsbridges, we should gather the Contact addresses of bridge operators that don't do pluggable transports and drop them an email asking them to start using obfsproxy etc.
I think sysrqb ...As part of the efforts to increase the number of obfsbridges, we should gather the Contact addresses of bridge operators that don't do pluggable transports and drop them an email asking them to start using obfsproxy etc.
I think sysrqb is collecting the spam list. The list will contain around 300 to 400 addresses. My plan is to send them an email, set the Reply-To field to tor-assistants (or should this be tor-relays?) and inform them that replies will be sent to a mailing list. Please raise your voice if you think this is nuts.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/10677Run unit tests for pluggable transports when building Tor Browser Bundle2021-11-08T19:58:01ZkpdyerRun unit tests for pluggable transports when building Tor Browser Bundledcf and I were recently discussing the dependencies between pluggable transports in the Tor Browser Bundle. As an example obfsproxy, flashproxy, and fteproxy all rely on pyptlib.
In these cases it is important that we have sanity checks...dcf and I were recently discussing the dependencies between pluggable transports in the Tor Browser Bundle. As an example obfsproxy, flashproxy, and fteproxy all rely on pyptlib.
In these cases it is important that we have sanity checks to ensure that when one of these components is upgraded, it doesn't break any of the pluggable transports. It's tedious to manually verify that each pluggable transport works.
It appears that nearly all of the pluggable transports have unit tests. A simple sanity check, running all unit tests for all PTs during the build, is probably a good idea.kpdyerkpdyerhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/10678Gitian OSX Build Fails due to missing .tar.xz file2020-06-27T13:44:00ZkpdyerGitian OSX Build Fails due to missing .tar.xz fileWhen building the 3.6-beta branch of [1], I get the following error.
As a temporary workaround, it is possible to manually download [2] directly and put it in `gitian-builder/inputs`.
```
****** Starting Tor Component of Mac Bundle (1/...When building the 3.6-beta branch of [1], I get the following error.
As a temporary workaround, it is possible to manually download [2] directly and put it in `gitian-builder/inputs`.
```
****** Starting Tor Component of Mac Bundle (1/4 for Mac) ******
[snip]
copy-to-target inputs/multiarch-darwin11-cctools127.2-gcc42-5666.3-llvmgcc42-2336.1-Linux-120724.tar.xz build/
rsync: link_stat "/home/ubuntu/sandbox/gitian-builder/inputs/multiarch-darwin11-cctools127.2-gcc42-5666.3-llvmgcc42-2336.1-Linux-120724.tar.xz" failed: No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1070) [sender=3.0.9]
./bin/gbuild:22:in `system!': failed to run copy-to-target inputs/multiarch-darwin11-cctools127.2-gcc42-5666.3-llvmgcc42-2336.1-Linux-120724.tar.xz build/ (RuntimeError)
from ./bin/gbuild:87:in `build_one_configuration'
from ./bin/gbuild:85:in `each'
from ./bin/gbuild:85:in `build_one_configuration'
from ./bin/gbuild:224
from ./bin/gbuild:219:in `each'
from ./bin/gbuild:219
from ./bin/gbuild:217:in `each'
from ./bin/gbuild:217
make: *** [build-beta] Error 1
```
[1] https://git.torproject.org/user/dcf/tor-browser-bundle.git
[2] https://mingw-and-ndk.googlecode.com/files/multiarch-darwin11-cctools127.2-gcc42-5666.3-llvmgcc42-2336.1-Linux-120724.tar.xzkpdyerkpdyerhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/10679"make match" fails to validate sha256 checksums2020-06-27T13:44:00Zkpdyer"make match" fails to validate sha256 checksumsUpon successful completion of building the 3.6-beta branch of [1], "make match" fails to correctly validate binary packages.
```
$ make match
./check-match.sh versions
--2014-01-18 10:56:58-- https://people.torproject.org/~linus/builds...Upon successful completion of building the 3.6-beta branch of [1], "make match" fails to correctly validate binary packages.
```
$ make match
./check-match.sh versions
--2014-01-18 10:56:58-- https://people.torproject.org/~linus/builds/3.5.1/sha256sums.txt
Resolving people.torproject.org (people.torproject.org)... 2620:0:6b0:b:1a1a:0:26e5:4818, 38.229.72.24
Connecting to people.torproject.org (people.torproject.org)|2620:0:6b0:b:1a1a:0:26e5:4818|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 6072 (5.9K) [text/plain]
Saving to: `sha256sums.txt'
100%[============================================================>] 6,072 --.-K/s in 0.007s
2014-01-18 10:56:59 (891 KB/s) - `sha256sums.txt' saved [6072/6072]
--2014-01-18 10:56:59-- https://people.torproject.org/~linus/builds/3.5.1/sha256sums.txt.asc
Resolving people.torproject.org (people.torproject.org)... 2620:0:6b0:b:1a1a:0:26e5:4818, 38.229.72.24
Connecting to people.torproject.org (people.torproject.org)|2620:0:6b0:b:1a1a:0:26e5:4818|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 836 [text/plain]
Saving to: `sha256sums.txt.asc'
100%[============================================================>] 836 --.-K/s in 0s
2014-01-18 10:56:59 (21.2 MB/s) - `sha256sums.txt.asc' saved [836/836]
gpg: keyring `/tmp/tmp.dbVtqBLbzn/secring.gpg' created
gpg: keyring `/tmp/tmp.dbVtqBLbzn/pubring.gpg' created
gpg: /tmp/tmp.dbVtqBLbzn/trustdb.gpg: trustdb created
gpg: key 23291265: public key "Linus Nordberg <linus@nordberg.se>" imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
gpg: no ultimately trusted keys found
gpg: Signature made Fri 17 Jan 2014 02:21:48 AM PST using RSA key ID 23291265
gpg: Good signature from "Linus Nordberg <linus@nordberg.se>"
gpg: aka "Linus Nordberg <linus@nordu.net>"
gpg: aka "Linus Nordberg <linus@torproject.org>"
gpg: aka "[jpeg image of size 2906]"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 8C4C D511 095E 982E B0EF BFA2 1E8B F349 2329 1265
diff: ../sha256sums.txt: No such file or directory
make: *** [match] Error 1
```
[1] https://git.torproject.org/user/dcf/tor-browser-bundle.gitkpdyerkpdyerhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/10723Create a staging instance for BridgeDB2020-06-27T13:43:18ZIsis LovecruftCreate a staging instance for BridgeDBBridgeDB needs a staging instance for checking that a new release works as expected when deployed.
This staging instance should have it's own setup/deployment scripts (probably in the bridgedb-admin repo). Ideally it should be able to t...BridgeDB needs a staging instance for checking that a new release works as expected when deployed.
This staging instance should have it's own setup/deployment scripts (probably in the bridgedb-admin repo). Ideally it should be able to take some sort of argument for which release/commit/branch to install and fire up as the staging instance, and other than that it should be as much as possible like the normal staging scripts.
Anything else I'm missing? Any suggestions?Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/10724Make BridgeDB's use of Stability.addOrUpdateBridgeHistory() configurable.2020-06-27T13:43:17ZIsis LovecruftMake BridgeDB's use of Stability.addOrUpdateBridgeHistory() configurable.I thought I remembered a ticket where sysrqb stated something to the effect of
> I profiled the startup of BridgeDB, and 80% of the ~25 minute startup time is spent in the `Stability.addOrUpdateBridgeHistory()` function...
but now I c...I thought I remembered a ticket where sysrqb stated something to the effect of
> I profiled the startup of BridgeDB, and 80% of the ~25 minute startup time is spent in the `Stability.addOrUpdateBridgeHistory()` function...
but now I can't find it. Either way, it's true that most of the startup time is spent in this function. During that time, the servers are down, because BridgeDB's database transactions aren't threaded (see legacy/trac#5232). That function is called from `Main.load()`; it collects all the timestamps for all bridges, does a lot of expensive `sort()`ing of them, and then the transactions... and I'm not even certain if Metrics uses this data (or if anything uses this data).
I kind of don't want to touch it until I understand more about why it was put there, but for the staging instance (legacy/trac#10723) startup times of ~25 minutes is rather painful. I propose adding a `COLLECT_TIMESTAMPS` option in the config file, and if `False` then skip that block of code in `Main.load()`.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/10725Write a Completely Spec-Compliant Bridge Descriptor Parser2020-06-27T13:43:17ZMatthew FinkelWrite a Completely Spec-Compliant Bridge Descriptor ParserThis would be very useful in many contexts (and it's inexistance has been noted recently on numerous occassions). Now, someone should write it and we should decide where it should live. Is it a stand-alone module? Is it integrated into S...This would be very useful in many contexts (and it's inexistance has been noted recently on numerous occassions). Now, someone should write it and we should decide where it should live. Is it a stand-alone module? Is it integrated into Stem? Do we maintain both so we can appease the small scripts that don't need Stem?
Note: This should support both sanitized and unsanitized descriptors.
Adjust the Component when something is decided.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/10737POST arguments to bridges.torproject.org are dropped if entering a CAPTCHA fails2020-06-27T13:43:17ZIsis LovecruftPOST arguments to bridges.torproject.org are dropped if entering a CAPTCHA failsIf a user goes to https://bridges.torproject.org/bridges?transport=obfs2 and then enters the CAPTCHA incorrectly, they are redirected to https://bridges.torproject.org/bridges and the original POST arguments specifying requested transpor...If a user goes to https://bridges.torproject.org/bridges?transport=obfs2 and then enters the CAPTCHA incorrectly, they are redirected to https://bridges.torproject.org/bridges and the original POST arguments specifying requested transports/IP version/etc. are dropped.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/10770pluggable-transport/websocket.git has no license2020-06-27T13:44:00ZRoger Dingledinepluggable-transport/websocket.git has no licensehttps://gitweb.torproject.org/pluggable-transports/websocket.git/tree
is missing anything resembling a license. Is it meant to be free software?https://gitweb.torproject.org/pluggable-transports/websocket.git/tree
is missing anything resembling a license. Is it meant to be free software?David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.org