rdsys issueshttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues2022-02-25T16:10:05Zhttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/91Start versioning rdsys2022-02-25T16:10:05ZGabagaba@torproject.orgStart versioning rdsysRdsys will be deployed in production very soon. It would be good to version it so we keep track of what is being deployed each time.Rdsys will be deployed in production very soon. It would be good to version it so we keep track of what is being deployed each time.Deploy RDSYS alongside BridgeDBmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/63Moat bucket shouldn't have non-obfs4/vanilla bridges2022-02-09T17:43:56ZGusMoat bucket shouldn't have non-obfs4/vanilla bridgesWhile doing some data visualization for https://gitlab.torproject.org/tpo/network-health/team/-/issues/115#note_2750865, I noticed that we have more than 200 bridges without any pluggable transport enabled on Moat bucket. Talking with Ri...While doing some data visualization for https://gitlab.torproject.org/tpo/network-health/team/-/issues/115#note_2750865, I noticed that we have more than 200 bridges without any pluggable transport enabled on Moat bucket. Talking with Richard, it looks like Tor Browser only requests obfs4 bridges using Moat. So, these bridges aren't being used at all.
We could reallocate these vanilla bridges on another bucket and move more obfs4 bridges from other buckets to Moat, as this is the most popular way to fetch Tor bridges.
![bridgedb-buckets](/uploads/38a68c2cf8f5fe6a23c4aeb78833de2c/bridgedb-buckets.png)
[moat-bucket-non-obfs4-bridges_2021-09-23T21_50_49.71273-03_00.csv](/uploads/6b29282f32d0a72c13a7a45fce16af56/moat-bucket-non-obfs4-bridges_2021-09-23T21_50_49.71273-03_00.csv)Deploy RDSYS alongside BridgeDBmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/62parse bridge-descriptors file and fix networkstatus parser2021-10-12T14:53:47Zmeskiomeskio@torproject.orgparse bridge-descriptors file and fix networkstatus parserCurrently we are using [zoossh](https://github.com/NullHypothesis/zoossh) to parse the network status file. But zoossh seems to be meant to parse CollecTor files, which are different than the files provided to rdsys.
Can we fork/patch z...Currently we are using [zoossh](https://github.com/NullHypothesis/zoossh) to parse the network status file. But zoossh seems to be meant to parse CollecTor files, which are different than the files provided to rdsys.
Can we fork/patch zoossh to work for us? Or should we write our own parser?Deploy RDSYS alongside BridgeDBmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/57Make a new distributor for BridgeDB2021-09-29T17:19:00ZGabagaba@torproject.orgMake a new distributor for BridgeDBAs we are going to be running rdsys with bridgedb as a first step, we need to have a distributor in rdsys to give bridges to bridgedb.
- [ ] bridgedb distributor in rdsys
- [ ] modify bridgedb to get files from rdsys instead of bridge a...As we are going to be running rdsys with bridgedb as a first step, we need to have a distributor in rdsys to give bridges to bridgedb.
- [ ] bridgedb distributor in rdsys
- [ ] modify bridgedb to get files from rdsys instead of bridge authoritiesDeploy RDSYS alongside BridgeDBmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/39Honour the operator's choice of distribution method2023-03-24T18:17:15ZCecylia BocovichHonour the operator's choice of distribution methodThe Tor specification allows bridge operators to choose their bridge distribution method. Right now in rdsys the distribution method is chosen randomly. If we decide to support this feature, we'll need to figure out a way to give this pr...The Tor specification allows bridge operators to choose their bridge distribution method. Right now in rdsys the distribution method is chosen randomly. If we decide to support this feature, we'll need to figure out a way to give this preference a higher priority than the random assignmentDeploy RDSYS alongside BridgeDBmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/38Parse network-status and bridge-descriptors documents from the bridge authority2021-09-21T14:46:38ZCecylia BocovichParse network-status and bridge-descriptors documents from the bridge authoritySee the [BridgeDB specification](https://gitweb.torproject.org/torspec.git/tree/bridgedb-spec.txt) for a full explanation of how these descriptors are used. Right now rdsys only parses the extrainfo documents, but the network-status docu...See the [BridgeDB specification](https://gitweb.torproject.org/torspec.git/tree/bridgedb-spec.txt) for a full explanation of how these descriptors are used. Right now rdsys only parses the extrainfo documents, but the network-status document is useful for checking the `running` flag, and either the network-status or bridge-descriptors document is necessary to get the bridge IP address and port for vanilla bridges.
- [x] Evaluate https://github.com/NullHypothesis/zoossh to use in rdsysDeploy RDSYS alongside BridgeDBCecylia BocovichCecylia Bocovich2021-08-30https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/13Monitor rdsys using monit2022-02-22T15:11:37ZPhilipp Winterphw@torproject.orgMonitor rdsys using monitLet's create monitoring targets for rdsys once it's deployed. Here's what's worth monitoring:
1. Rdsys's distributors, e.g. HTTPS and Salmon. Each of these distributors is a separate process and can die independently.
2. ~~Rdsys's backen...Let's create monitoring targets for rdsys once it's deployed. Here's what's worth monitoring:
1. Rdsys's distributors, e.g. HTTPS and Salmon. Each of these distributors is a separate process and can die independently.
2. ~~Rdsys's backend. Its registration API is open to the public and would be a great monitoring target.~~Deploy RDSYS alongside BridgeDBmeskiomeskio@torproject.orgmeskiomeskio@torproject.org