Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2023-08-09T09:25:06Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/23webtunnel bridge doesn't need to set "PublishServerDescriptor 1" in torrc2023-08-09T09:25:06ZRoger Dingledinewebtunnel bridge doesn't need to set "PublishServerDescriptor 1" in torrcThe WebTunnel README suggests to set
```
PublishServerDescriptor 1
```
That's the default value, i.e. I don't think that line is needed for anything or changes anything.
Does something break without it? If not we could simplify the ins...The WebTunnel README suggests to set
```
PublishServerDescriptor 1
```
That's the default value, i.e. I don't think that line is needed for anything or changes anything.
Does something break without it? If not we could simplify the instructions a little bit.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/22Connection reset by peer while reading response header from upstream2023-07-14T07:12:36ZJacobo NájeraConnection reset by peer while reading response header from upstream
Hi
My bridge is presenting the following error.
```
2023/07/11 23:27:06 [error] 45213#45213: *17 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: xxx.xxx.xxx.xxx, server: hostname, r...
Hi
My bridge is presenting the following error.
```
2023/07/11 23:27:06 [error] 45213#45213: *17 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: xxx.xxx.xxx.xxx, server: hostname, request: "GET /path HTTP/1.1", upstream: "http://127.0.0.1:15000/path", host: "hostname"
```
Setup
- Debian 11
- Docker version 24.0.4, build 3713ee1
- Certbot
- nginx (1.18.0-6.1+deb11u3)
- thetorproject/webtunnel-bridge:latest
- containrrr/watchtower
Config
Docker compose .env
```
URL=https://domain/path
OPERATOR_EMAIL=user@domain.tld
BRIDGE_NICKNAME=xxxxxxxxx
GENEDORPORT=48945
```
nginx.conf
```
#WebSocket Support
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
```
/etc/nginx/sites-enabled/ default
```
location /path {
proxy_pass http://127.0.0.1:15000;
proxy_http_version 1.1;
###Set WebSocket headers ####
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
### Set Proxy headers ####
proxy_set_header Accept-Encoding "";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
add_header Front-End-Https on;
proxy_redirect off;
}
```https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40278Snowflake failed to connect on Android 11 and above2024-01-10T16:06:45ZGedshSnowflake failed to connect on Android 11 and aboveThis issue causes Snowflake to be unable to establish a connection on Android 11 and above when the app's target SDK level is above 29.
It is related to the Go x/mobile issue https://github.com/golang/go/issues/40569
The problem is loc...This issue causes Snowflake to be unable to establish a connection on Android 11 and above when the app's target SDK level is above 29.
It is related to the Go x/mobile issue https://github.com/golang/go/issues/40569
The problem is located in the Pion library https://github.com/pion/ice/blob/214c86c5cfbc40fa9adbbea59081bd64c8b65d7c/agent.go#L327 which calls https://pkg.go.dev/github.com/mingyech/transport/v2/stdnet#Net.UpdateInterfaces which is forbidden on Android 11.
Snowflake log:
```go
2023/07/09 17:40:03 snowflake-client 2.5.1
2023/07/09 17:40:03 Started SOCKS listener at [scrubbed].
2023/07/09 17:40:17 SOCKS accepted: {[scrubbed] utls-imitate=hellorandomizedalpn map[utls-imitate:[hellorandomizedalpn]]}
2023/07/09 17:40:17
--- Starting Snowflake Client ---
2023/07/09 17:40:17 Using ICE servers:
2023/07/09 17:40:17 url: stun:stun.bluesip.net:3478
2023/07/09 17:40:17 url: stun:stun.epygi.com:3478
2023/07/09 17:40:17 url: stun:stun.stunprotocol.org:3478
2023/07/09 17:40:17 url: stun:stun.voys.nl:3478
2023/07/09 17:40:17 url: stun:stun.uls.co.za:3478
2023/07/09 17:40:17 url: stun:stun.sonetel.net:3478
2023/07/09 17:40:17 url: stun:stun.antisip.com:3478
2023/07/09 17:40:17 Rendezvous using Broker at: https://snowflake-broker.torproject.net.global.prod.fastly.net/
2023/07/09 17:40:17 Domain fronting using: cdn.sstatic.net
2023/07/09 17:40:17 ---- SnowflakeConn: begin collecting snowflakes ---
2023/07/09 17:40:17 ---- SnowflakeConn: starting a new session ---
2023/07/09 17:40:17 ---- SnowflakeConn: begin stream 3 ---
2023/07/09 17:40:17 redialing on same connection
2023/07/09 17:40:17 WebRTC: Collecting a new Snowflake. Currently at [0/1]
2023/07/09 17:40:17 snowflake-421fa3a84195d6e9 connecting...
2023/07/09 17:40:17 WebRTC: DataChannel created
2023/07/09 17:40:17 Failed to prepare offer failed to create network: route ip+net: netlinkrib: permission denied
2023/07/09 17:40:17 WebRTC: closing DataChannel
2023/07/09 17:40:17 WebRTC: closing PeerConnection
2023/07/09 17:40:17 WebRTC: Closing
2023/07/09 17:40:17 WebRTC: failed to create network: route ip+net: netlinkrib: permission denied Retrying...
2023/07/09 17:40:17 NAT Type: unrestricted
```Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetshelikhooshelikhoo2023-08-31https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/128Modern firewall-penetration protocols for Tor in China2023-08-11T09:50:26ZcomputerscotModern firewall-penetration protocols for Tor in ChinaReports on https://github.com/net4people/bbs/issues and https://forum.torproject.org say that both obfs4 and snowflake are blocked by the GFW. There are also doubts about whether the new WebTunnel pluggable transport will work. The GFW d...Reports on https://github.com/net4people/bbs/issues and https://forum.torproject.org say that both obfs4 and snowflake are blocked by the GFW. There are also doubts about whether the new WebTunnel pluggable transport will work. The GFW detects and blocks WebSocket-based proxies.
This is a proof-of-concept for more modern firewall-penetration protocols.
To test these protocols in action, set up an Xray server and client using the latest techniques, for example, https://cscot.pages.dev/2023/07/02/xray-reality-h2. If you follow the sample configuration in that article, you will have a SOCKS5 proxy listening on port `10808` on your client.
Download and install the Tor Browser from https://www.torproject.org.
When you run the Tor Browser for the first time, click **Configure Connection**.
Scroll down and click the **Settings** button at the bottom to configure how you connect to the internet. Check **I use a proxy to connect to the Internet**. The type is **SOCKS5**, the address is `127.0.0.1`, and the port is `10808`. Click **OK**.
I have found it more reliable to click **Select a Built-In Bridge**. This should not be necessary, since the Xray server is already outside the GFW. Perhaps it helps because built-in bridges are faster than random entry nodes. Select **obfs4**. Click **Connect**.
Now you can test your connection by trying to reach a Tor-only site.
BBC News in simplified Chinese:
```
https://www.bbcweb3hytmzhn5d532owbu6oqadra5z3ar726vq5kgwwn6aucdccrad.onion/zhongwen/simp
```
DW News in simplified Chinese:
```
https://www.dwnewsgngmhlplxy6o2twtfgjnrnjxbegbwqx6wnotdhkzt562tszfid.onion/zh/?zhongwen=simp
```
New York Times in simplified Chinese:
```
https://cn.nytimesn7cgmftshazwhfgzm37qxb44r64ytbb2dj3x62d2lljsciiyd.onion
```
![dw-onion-simplified-chinese](/uploads/37794d56098885a7979eb2230e140737/dw-onion-simplified-chinese.png)meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/21panic: assignment to entry in nil map2023-10-25T15:45:08Zcomputerscotpanic: assignment to entry in nil map```
Jul 04 13:31:06.000 [debug] process_read_lines(): Read line from process: "VERSION 1"
Jul 04 13:31:06.000 [info] handle_proxy_line(): Got a line from managed proxy '/var/lib/torwebtunnel/webtunnel': (VERSION 1)
Jul 04 13:31:06.000 [d...```
Jul 04 13:31:06.000 [debug] process_read_lines(): Read line from process: "VERSION 1"
Jul 04 13:31:06.000 [info] handle_proxy_line(): Got a line from managed proxy '/var/lib/torwebtunnel/webtunnel': (VERSION 1)
Jul 04 13:31:06.000 [debug] read_to_chunk(): Read 313 bytes. 313 on inbuf.
Jul 04 13:31:06.000 [debug] process_read_lines(): Read line from process: "panic: assignment to entry in nil map"
Jul 04 13:31:06.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/var/lib/torwebtunnel/webtunnel' reported via standard error: panic: assignment to entry in nil map
Jul 04 13:31:06.000 [debug] process_read_lines(): Read line from process: ""
Jul 04 13:31:06.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/var/lib/torwebtunnel/webtunnel' reported via standard error:
Jul 04 13:31:06.000 [debug] process_read_lines(): Read line from process: "goroutine 1 [running]:"
Jul 04 13:31:06.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/var/lib/torwebtunnel/webtunnel' reported via standard error: goroutine 1 [running]:
Jul 04 13:31:06.000 [debug] process_read_lines(): Read line from process: "gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/goptlib.Args.Add(...)"
Jul 04 13:31:06.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/var/lib/torwebtunnel/webtunnel' reported via standard error: gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/goptlib.Args.Add(...)
Jul 04 13:31:06.000 [debug] process_read_lines(): Read line from process: " /root/go/pkg/mod/gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/goptlib@v1.4.0/args.go:32"
Jul 04 13:31:06.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/var/lib/torwebtunnel/webtunnel' reported via standard error: /root/go/pkg/mod/gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/goptlib@v1.4.0/args.go:32
Jul 04 13:31:06.000 [debug] process_read_lines(): Read line from process: "main.main()"
Jul 04 13:31:06.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/var/lib/torwebtunnel/webtunnel' reported via standard error: main.main()
```shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40277Specialize ClientMap for ClientID2024-01-07T23:43:45ZDavid Fifielddcf@torproject.orgSpecialize ClientMap for ClientIDThe [`ClientMap.SendQueue`](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/58c3121c6b3afe54ddb31edc5efca613142bbe4e/common/turbotunnel/clientmap.go#L56)
function is the first actual Snowflake func...The [`ClientMap.SendQueue`](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/58c3121c6b3afe54ddb31edc5efca613142bbe4e/common/turbotunnel/clientmap.go#L56)
function is the first actual Snowflake function
that appears in a CPU profile of snowflake-server:
[snowflake-server.2023-06-28T10_47_29Z.cpu.prof](/uploads/7b0f409a90bdc95b4bba169df794649a/snowflake-server.2023-06-28T10_47_29Z.cpu.prof)
```
$ go tool pprof -text 'snowflake-server.2023-06-28T10:47:29Z.cpu.prof'
File: snowflake-server.20230628.c3e2f91b.prof
Type: cpu
Time: Jun 28, 2023 at 10:47am (UTC)
Duration: 1hrs, Total samples = 63696.55s (1769.24%)
Showing nodes accounting for 52749.47s, 82.81% of 63696.55s total
Dropped 1622 nodes (cum <= 318.48s)
flat flat% sum% cum cum%
17749.19s 27.87% 27.87% 17749.19s 27.87% runtime/internal/syscall.Syscall6
3813.60s 5.99% 33.85% 3813.60s 5.99% runtime.epollwait
2380.75s 3.74% 37.59% 8172.14s 12.83% runtime.selectgo
1915.76s 3.01% 40.60% 1915.76s 3.01% runtime.memmove
1770.22s 2.78% 43.38% 2580.39s 4.05% runtime.lock2
1269.98s 1.99% 45.37% 1341.07s 2.11% runtime.casgstatus
1046.43s 1.64% 47.01% 1291.14s 2.03% runtime.unlock2
998.18s 1.57% 48.58% 2658.96s 4.17% runtime.sellock
905.56s 1.42% 50.00% 3656.57s 5.74% runtime.mallocgc
867.74s 1.36% 51.36% 871.58s 1.37% runtime.(*waitq).dequeue (inline)
826.43s 1.30% 52.66% 826.43s 1.30% crypto/aes.gcmAesEnc
789.16s 1.24% 53.90% 2709.70s 4.25% github.com/xtaci/kcp-go/v5.(*KCP).flush
617.51s 0.97% 54.87% 7628.15s 11.98% runtime.schedule
572.20s 0.9% 55.77% 2542.47s 3.99% gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/v2/common/turbotunnel.(*ClientMap).SendQueue
538.09s 0.84% 56.61% 538.09s 0.84% runtime.futex
513.24s 0.81% 57.42% 513.24s 0.81% runtime.procyield
445.32s 0.7% 58.12% 466.23s 0.73% runtime.findObject
```
It only accounts for 1% of total CPU time,
or 4% if you count the cumulative contribution of the mutex lock/unlock
and the operations on the inner map,
but it's still a hot spot.
In the branch https://gitlab.torproject.org/dcf/snowflake/-/commits/sendqueue-clientid/
I have a change to make `ClientMap` assume it is always dealing with a `ClientID`,
not just any `net.Addr`.
The change makes `ClientMap.SendQueue` faster in `BenchmarkSendQueue`.https://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/23Lox bridge_table HashMaps should find the next available key2023-08-02T14:37:24ZonyinyangLox bridge_table HashMaps should find the next available keyAs a follow up to the discussion in !11, we need some way to find the next available key for Lox bridge_table's HashMaps.
This issue tracks the implementation of a `find_next_available_key` function.As a follow up to the discussion in !11, we need some way to find the next available key for Lox bridge_table's HashMaps.
This issue tracks the implementation of a `find_next_available_key` function.onyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/22Lox Distributor not properly parsing empty ResourceDiff2023-06-29T18:26:24ZCecylia BocovichLox Distributor not properly parsing empty ResourceDiffAfter trying a deployment of the lox distributor with no resources allocated to it (#19), the distributor crashed when trying to marshall the received json from the rdsys backend into a ResourceDiff struct.
I got the following error:
``...After trying a deployment of the lox distributor with no resources allocated to it (#19), the distributor crashed when trying to marshall the received json from the rdsys backend into a ResourceDiff struct.
I got the following error:
```
$ RUST_BACKTRACE=1 ./bin/lox-distributor conf/lox-config.json
Listening on 127.0.0.1:8001
thread 'tokio-runtime-worker' panicked at 'called `Option::unwrap()` on a `None` value', crates/lox-distributor/src/main.rs:91:44
stack backtrace:
0: rust_begin_unwind
at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panicking.rs:578:5
1: core::panicking::panic_fmt
at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/panicking.rs:67:14
2: core::panicking::panic
at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/panicking.rs:117:5
3: lox_distributor::main::{{closure}}::{{closure}}
4: tokio::runtime::task::raw::poll
5: tokio::runtime::scheduler::multi_thread::worker::Context::run_task
6: tokio::runtime::task::raw::poll
7: tokio::runtime::task::UnownedTask<S>::run
```
And the received json looked like this:
```
{
"new": {
"obfs4": null,
"scramblesuit": []
},
"changed": null,
"gone": null,
"full_update": true
}
```
I suspect the problem lies with the list of `obfs4` bridges being `null` rather than an empty list `[]`. The difference between obfs4 and scramblesuit here is that the lox distributor was configured to receive obfs4 only but requested both obfs4 and scramblesuit bridges.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/21Store Lox bridge table and spent credential tables in a disk-backed database2023-10-23T18:11:04ZonyinyangStore Lox bridge table and spent credential tables in a disk-backed databaseAs part of #6, the Lox distributor, particularly the context manager, needs to keep a record of the Lox bridge table and the spent credential ids for each of the Lox credential types on some kind of disk-backed database that can be read ...As part of #6, the Lox distributor, particularly the context manager, needs to keep a record of the Lox bridge table and the spent credential ids for each of the Lox credential types on some kind of disk-backed database that can be read in at start up in the case of a catastrophic failure and potentially be used to restore from a previous state. This might be needed if, for example, all of the bridges in an area got blocked due to a censor's new technique that could identify all of a certain type of bridge by protocol (by no fault of Lox users). In such a case, many users will be locked out of their trust buckets and some users may have already attempted to migrate to new bridges and had their credentials updated with a penalty. If the bridges blocked by protocol could be replaced with a new type of bridge, it might be desirable to roll back the spent credential id tables to an earlier state and allow users to replay credentials used after a certain date.onyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/168Change labelling of resources failing tests from `gone`2023-11-07T00:20:13ZonyinyangChange labelling of resources failing tests from `gone`After discussing with @meskio about how rdsys sends updates (every time there is a reconnect) and how often these will occur (possibly as often as every 10 minutes), we may need to reconsider the previous changes to indicate `gone` resou...After discussing with @meskio about how rdsys sends updates (every time there is a reconnect) and how often these will occur (possibly as often as every 10 minutes), we may need to reconsider the previous changes to indicate `gone` resources. Since `changed` and `gone` resources are not sent in full updates and are only sent in between full updates, it seems that it might make more sense to keep resources that changed or are failing tests in the list that will be sent as `new` bridges during a full update, since otherwise they might get missed. Then, instead of using the `gone` or `changed` label to decide what to do with these resources, determine what to do with them based on the `LastPassed` time or changed values (OID?). This should only require minor changes to rdsys as well as changes to the [lox-distributor](https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/tree/main/crates/lox-distributor) to check the `lastPassed` field in resources to make sure that it isn't older than a specified amount of time and handle it as `gone` resources are currently handled if so.
@cohosh do you have any thoughts on this?onyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/167Add lox distributor type with no allocated bridges2023-11-09T03:49:09ZCecylia BocovichAdd lox distributor type with no allocated bridgesLet's add a new distributor type called "lox" that doesn't take any bridges but has it's own authentication token and will accept bridges that specify `BridgeDistribution lox` in their torrc file.
We'll need to do the following things
-...Let's add a new distributor type called "lox" that doesn't take any bridges but has it's own authentication token and will accept bridges that specify `BridgeDistribution lox` in their torrc file.
We'll need to do the following things
- [x] Add a lox distributor to rdsys's config file
- [x] Create a service for the lox distributor so it is restarted if `rdsys-frontend-01` goes down
- [x] Add the lox distributor binary to /srv/rdsys.torproject.org/bin on `rdsys-frontend-01`
- [x] Add the lox distributor config file to /srv/rdsys.torproject.org/conf on `rdsys-frontend-01`
- [x] Generate and add an API token for the lox distributorCecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/166gettor-updater: Error fetching downloads.json2023-06-28T15:02:01Zmeskiomeskio@torproject.orggettor-updater: Error fetching downloads.jsonSince TB 12.5 gettor updater is failing.
```
Error fetching downloads.json: json: cannot unmarshal number into Go struct field downloadsLinks.version of type string
```Since TB 12.5 gettor updater is failing.
```
Error fetching downloads.json: json: cannot unmarshal number into Go struct field downloadsLinks.version of type string
```Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40276Try reducing allocations in encapsulation.ReadData2023-11-21T04:19:58ZDavid Fifielddcf@torproject.orgTry reducing allocations in encapsulation.ReadDataIn the branch https://gitlab.torproject.org/dcf/snowflake/-/commits/encapsulation-readdata-buffer
(commit https://gitlab.torproject.org/dcf/snowflake/-/commit/9ac64239b4bff07cb016d7c2609eae66a92483c8)
I have a patch to make `encapsulatio...In the branch https://gitlab.torproject.org/dcf/snowflake/-/commits/encapsulation-readdata-buffer
(commit https://gitlab.torproject.org/dcf/snowflake/-/commit/9ac64239b4bff07cb016d7c2609eae66a92483c8)
I have a patch to make `encapsulation.ReadData` fill a provided buffer rather than allocate a new buffer on every call.
This function is part of the hot read loop and is probably respondible
for a large part of garbage collection pressure.
I am going to test this change on a production bridge to see if it helps.
/cc @linusDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/20Documentation about server file2023-10-25T15:46:06ZJacobo NájeraDocumentation about server fileI am trying to install a webtunnel server. I am not understand the following instruction in the documentation:
### Get Environment Ready
```
#copy server file to server
scp server root@$SERVER_ADDRESS:/var/lib/torwebtunnel/webtunnel
`...I am trying to install a webtunnel server. I am not understand the following instruction in the documentation:
### Get Environment Ready
```
#copy server file to server
scp server root@$SERVER_ADDRESS:/var/lib/torwebtunnel/webtunnel
```
Where is server file? whe i tried it:
ssh: connect to host ip port 22: Connection timed out
lost connection
Thanks, Jacoboshelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/127Some links in the wiki go to .onion when being on .org2023-06-28T09:53:32Zcomputer_freakSome links in the wiki go to .onion when being on .orgBeing on https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/home#projects-that-the-team-maintains but all links except the last one try to send me to the `.onion` version.Being on https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/home#projects-that-the-team-maintains but all links except the last one try to send me to the `.onion` version.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/20Figure out how to serve the encrypted bridge table to users2023-08-01T17:07:20ZCecylia BocovichFigure out how to serve the encrypted bridge table to usersLox credentials only contain an index into an encrypted table of bridge lines. Users must download the entire encrypted bridge table periodically in order to find and decrypt their bridges to preserve their anonymity and prevent the Lox ...Lox credentials only contain an index into an encrypted table of bridge lines. Users must download the entire encrypted bridge table periodically in order to find and decrypt their bridges to preserve their anonymity and prevent the Lox distributor from learning which users were assigned which bridges.
This can be a rather large download, and for obvious reasons must be done automatically and in a censorship-resistant way.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40067webtunnel bridges are only distributed if 'I need IPv6' box is ticked2023-07-04T14:10:16Zmeskiomeskio@torproject.orgwebtunnel bridges are only distributed if 'I need IPv6' box is tickedAs bridges have IPv6 addresses webtunnel only distribute them if the user specifically ask for IPv6 bridges. Let's fix that.As bridges have IPv6 addresses webtunnel only distribute them if the user specifically ask for IPv6 bridges. Let's fix that.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/connectivity-measurement/logcollector/-/issues/5Add Conjoure Pluggable Transport Support2023-08-01T17:05:38ZshelikhooAdd Conjoure Pluggable Transport SupportConjure is a new pluggable transport based on refraction routing.
This issue track the support for conjure in WebTunnel.
(See also: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/33)Conjure is a new pluggable transport based on refraction routing.
This issue track the support for conjure in WebTunnel.
(See also: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/33)shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/docker-snowflake-proxy/-/issues/12build and upload docker-hub image for 2.6.02023-06-26T09:11:45Ztrinity-1686abuild and upload docker-hub image for 2.6.0`thetorproject/snowflake-proxy:latest` is currently 2.5.1, and there is no 2.6.0 tag available.`thetorproject/snowflake-proxy:latest` is currently 2.5.1, and there is no 2.6.0 tag available.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/gettor-project/OnionSproutsBot/-/issues/53Not updating after a release2023-10-16T18:37:23Zmeskiomeskio@torproject.orgNot updating after a releaseAfter 12.5 release onionsproutsbot keeps distributing 12.0.6. I don't see any evident error in the logs. Restarting the service doesn't change anything, and if I remove the db it keeps trying to get 12.0.6 and fails because the installer...After 12.5 release onionsproutsbot keeps distributing 12.0.6. I don't see any evident error in the logs. Restarting the service doesn't change anything, and if I remove the db it keeps trying to get 12.0.6 and fails because the installers are not in the downloads page anymore.
I'm not sure how this is happening, I'm checking and the url configured to fecth the json releases is https://aus1.torproject.org/torbrowser/update_3/release/ which seems to contain only links to 12.5.meskiomeskio@torproject.orgmeskiomeskio@torproject.org