Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2024-03-08T12:58:24Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40337AWS warning about public IAM credentials for SQS rendezvous2024-03-08T12:58:24ZCecylia BocovichAWS warning about public IAM credentials for SQS rendezvousI got the following email from AWS:
```
We have become aware that the AWS Access Key AKIA5AIF4WJJXS7YHEG3 , belonging to IAM User SQS-client ,
along with the corresponding Secret Key is publicly available online at
https://github.com/n...I got the following email from AWS:
```
We have become aware that the AWS Access Key AKIA5AIF4WJJXS7YHEG3 , belonging to IAM User SQS-client ,
along with the corresponding Secret Key is publicly available online at
https://github.com/net4people/bbs/issues/335#issue-2157478835 .
Your security is important to us and this exposure of your account’s IAM credentials poses a security
risk to your AWS account, could lead to excessive charges from unauthorized activity, and violates
the AWS Customer Agreement or other agreement with us governing your use of our Services.
```
They probably have some automated tools to search for secret keys in Github repositories.
I have replied to the open support ticket to confirm that the sharing of credentials was intentional. Hopefully they will allow us to continue to use them.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/issues/40013version is reported as lyrebird-0.0.142024-03-04T19:48:23Ztoralfversion is reported as lyrebird-0.0.14shouldn't it be 0.1.0 ?shouldn't it be 0.1.0 ?meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/58Better Invitation Encoding2024-03-01T11:43:41ZonyinyangBetter Invitation EncodingThe Lox invitation endpoint currently returns a string of bytes formatted like:
```
{"invite":92,149,13,240,159,9,236,1,141,15,246,61,49,4,53,142,229,56,160,137,155,86,127,166,223,8,80,114,117,17,210,3,2,0,0,0,5,36,19,41,86,145,241,114...The Lox invitation endpoint currently returns a string of bytes formatted like:
```
{"invite":92,149,13,240,159,9,236,1,141,15,246,61,49,4,53,142,229,56,160,137,155,86,127,166,223,8,80,114,117,17,210,3,2,0,0,0,5,36,19,41,86,145,241,114,93,58,10,118,162,141,183,53,200,168,179,108,34,222,21,15,252,195,121,92,185,187,78,126,17,67,153,113,32,87,109,232,90,104,27,162,141,83,26,121,195,47,249,109,50,104,220,136,183,111,7,8,93,53,3,12}
```
This is probably not ideal for a user to paste into the browser, though maybe it is fine?
We should check with the ux team to see if they have suggestions for a better user experience and consider changing this (and the interface) to accept a more user-friendly invite.Lox Ready for Open Testing Callonyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40336Should we default enable SQS rendezvous of Snowflake in built-in bridge?2024-02-28T17:55:43Zsnowflake_user_40314Should we default enable SQS rendezvous of Snowflake in built-in bridge?The current default rendezvous(domain fronting) is [expect to stop work](https://lists.torproject.org/pipermail/anti-censorship-team/2023-October/000328.html).
Current 13.0.10 do not enable SQS rendezvous by default.The current default rendezvous(domain fronting) is [expect to stop work](https://lists.torproject.org/pipermail/anti-censorship-team/2023-October/000328.html).
Current 13.0.10 do not enable SQS rendezvous by default.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40335No release for version 2.9.02024-02-27T16:41:36ZPonchoNo release for version 2.9.0Hi there
Some time ago, you've tagged version 2.9.0
It's available under https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/tags
But there is no corresponding release under https://gitlab.torproject.org/...Hi there
Some time ago, you've tagged version 2.9.0
It's available under https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/tags
But there is no corresponding release under https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/releases and the release job was skipped https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/jobs/471273
Not sure whether this is all on purpose or if something went wrong. Therefore, opening this issue.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/57Create a detailed workflow for investigating and responding to blocked Lox br...2024-02-26T17:32:10ZonyinyangCreate a detailed workflow for investigating and responding to blocked Lox bridgesThough automating the detection of blocked bridges has been a [long term goal](https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40035), discussed [here](https://gitlab.torproject.org/tpo/anti-censorship/rdsy...Though automating the detection of blocked bridges has been a [long term goal](https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40035), discussed [here](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/112) as well, we should have a detailed workflow for how we will handle getting reports of blocked bridges, how often we will manually update bridge statuses for Lox bridges and who will be responsible for these updates during our test deployment.Lox Ready for Open Testing Callonyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/gettor-project/OnionSproutsBot/-/issues/59@gettor_bot on Telegram does not work2024-03-26T10:20:35Znina@gettor_bot on Telegram does not workit shows "loading" but nothing happensit shows "loading" but nothing happensmeskiomeskio@torproject.orgmeskiomeskio@torproject.org2024-02-22https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/890.7.3 rejected from mozilla2024-03-28T04:37:33Zmeskiomeskio@torproject.org0.7.3 rejected from mozillaWe got this email:
> Due to issues discovered during the review process, one or more versions of your add-on Snowflake will be disabled on addons.mozilla.org in 14 day(s). Please
> see the reviewer’s comments below for more information.
...We got this email:
> Due to issues discovered during the review process, one or more versions of your add-on Snowflake will be disabled on addons.mozilla.org in 14 day(s). Please
> see the reviewer’s comments below for more information.
>
> ********
> Details:
> - Reproducing the submitted release version based on the provided source code package and instructions failed.
>
> You can access the console output at https://paste.mozilla.org/kOCS6sFe
> Environment used for building: Node 20.10.0, npm 10.2.3 on Ubuntu 22.04 LTS x64 (10GB RAM, 6 CPUs)
>
> Please test your build in a clean environment to make sure it is reproducible. If necessary, update the source code package and/or the instructions to
> reproduce.
> Please read through the instructions at https://extensionworkshop.com/documentation/publish/source-code-submission/ .
>
> Version(s) affected:
> 0.7.3
> ********
>
> Please address the issues raised in the reviewer's notes and inquire about any unclear items. Afterwards, please upload a new version of your add-on at
> https://addons.mozilla.org/en-US/developers/addon/torproject-snowflake/versions.
>
> To respond, please reply to this email or visit https://addons.mozilla.org/en-US/developers/addon/torproject-snowflake/versions. If we do not hear from you
> within 14 day(s) of this notification, these versions will be removed from addons.mozilla.org. Current users of these versions will be unaffected.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40334Post upgrade2024-02-17T22:19:10ZLinus Nordberglinus@torproject.orgPost upgrade- [x] apt autoremove; apt remove '~c'
- [x] apt-mark auto rsyslog && apt autoremove # https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html- [x] apt autoremove; apt remove '~c'
- [x] apt-mark auto rsyslog && apt autoremove # https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.htmlhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40333Perform upgrade2024-02-17T21:55:05ZLinus Nordberglinus@torproject.orgPerform upgrade- [x] APT sources prepared
- [x] apt update && apt -o APT::Get::Trivial-Only=true full-upgrade
- [x] apt upgrade --without-new-pkgs
- [x] apt full-upgrade
- [x] reboot- [x] APT sources prepared
- [x] apt update && apt -o APT::Get::Trivial-Only=true full-upgrade
- [x] apt upgrade --without-new-pkgs
- [x] apt full-upgrade
- [x] reboothttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40332Prepare upgrade2024-02-17T10:41:33ZLinus Nordberglinus@torproject.orgPrepare upgrade- [x] systemd-resolved installed? no
- [x] apt purge ifupdown
- [x] upgrade 11.8 -> 11.9
- [x] apt autopurge; apt purge \\~c
- [x] find /etc -name '*.dpkg-*' -o -name '*.ucf-*' -o -name '*.merge-error'
- [x] dpkg --audit
- [x] apt-mark s...- [x] systemd-resolved installed? no
- [x] apt purge ifupdown
- [x] upgrade 11.8 -> 11.9
- [x] apt autopurge; apt purge \\~c
- [x] find /etc -name '*.dpkg-*' -o -name '*.ucf-*' -o -name '*.merge-error'
- [x] dpkg --audit
- [x] apt-mark showhold
- [x] dpkg --get-selections '*' > /root/dpkg-get-selections && (umask 0077; tar cf /root/2024-02-17-backup.tar -C / root etc var/lib/dpkg var/lib/apt/extended_states)https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40331Verify console access2024-02-17T09:27:48ZLinus Nordberglinus@torproject.orgVerify console accesshttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/56Increase the Lox Bridge Pool2024-02-28T11:06:12ZonyinyangIncrease the Lox Bridge PoolFor testing purposes, we spun up a few bridges to add to the Lox bridge pool. Before we release Lox for open testing, we should add some more. We decided it would make sense to increase the bridge pool to 10 bridges and do some internal ...For testing purposes, we spun up a few bridges to add to the Lox bridge pool. Before we release Lox for open testing, we should add some more. We decided it would make sense to increase the bridge pool to 10 bridges and do some internal testing with that number first before releasing to the wider communityLox Ready for Open Testing Callmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40330Collect metrics for binned counts of client polls per country for each rendez...2024-03-12T11:29:00ZCecylia BocovichCollect metrics for binned counts of client polls per country for each rendezvous methodWe now collect metrics on [poll counts for each rendezvous method](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/243). To learn about potential censorship events it would be useful to a...We now collect metrics on [poll counts for each rendezvous method](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/243). To learn about potential censorship events it would be useful to also collect binned polling counts per country by adding a line:
```
client-[method]-ips [CC=NUM,CC=NUM,...,CC=NUM] NL
```
for each rendezvous method.
I think it's safer to still collect poll counts rather than unique IPs for clients to avoid the necessity of storing (even hashed) seen addresses in memory. The main trick is in how we learn the client's IP address to perform a country code lookup in the geoip database. For the domain fronting rendezvous method, we could use the `X-Forwarded-For` header, but SQS does not offer details on the IP that sent the message. One way to do this is to pull the client IP out of the SDP offer. We already have some code for processing ice candidates and [removing local addresses](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/35984c0876273adb810ab3cc558464ba786aafcd/common/util/util.go#L70-L99). Something similar could be done to extract the client IP.mpumpuhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40328snowflake deb runs as root, and it should do something safer than that2024-02-27T11:24:09ZRoger Dingledinesnowflake deb runs as root, and it should do something safer than thatI installed the snowflake-proxy deb (version 2.5.1-1+b3) and used "systemctl start snowflake-proxy" to tell it to start.
Now I have a proxy process running as root! Wow, I did not expect this.
Should we make a separate user and run the...I installed the snowflake-proxy deb (version 2.5.1-1+b3) and used "systemctl start snowflake-proxy" to tell it to start.
Now I have a proxy process running as root! Wow, I did not expect this.
Should we make a separate user and run the snowflake proxy as that user? Or is it secretly dropping privileges and the root part is not accurate?https://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/55Bridge replace flakey II2024-02-27T11:25:08ZonyinyangBridge replace flakey IIThe `bridge_replace` function is flakey again after adjusting the logic to remove spare buckets first and adding the `ReplaceSuccess::Removed` option.`The `bridge_replace` function is flakey again after adjusting the logic to remove spare buckets first and adding the `ReplaceSuccess::Removed` option.`Lox Ready for Open Testing Callonyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/54Blocked spare or undistributed bridges2024-02-27T11:28:28ZonyinyangBlocked spare or undistributed bridgesWhen written, Lox did not consider that spare/undistributed bridges may become blocked.
In Lox's threat model, if bridges aren't distributed, this shouldn't happen. However, since rdsys is the source of truth for whether or not bridges a...When written, Lox did not consider that spare/undistributed bridges may become blocked.
In Lox's threat model, if bridges aren't distributed, this shouldn't happen. However, since rdsys is the source of truth for whether or not bridges are blocked, it's theoretically possible that a spare or undistributed bridge may be marked as blocked in a certain region in rdsys, despite that bridge not having been distributed.
In reality though, _might_ a bridge actually be marked as blocked if it hasn't been distributed (i.e., if it only exists in a spare bucket)?
One way I'm imagining this _could_ happen is if a particular block of bridges that have a common feature are blocked. We may assume, or test these bridges for reachability, and determine that they are blocked, regardless of whether or not they have been distributed. However, I think in most situations like this we would not consider these bridges as being blocked as a result of a censor blocking a bridge they learned about through Lox. In this case, we could just call these bridges `not-working` and replace them with `working` bridges rather than marking them as blocked and allowing migrations to new buckets.
If there are additional instances where bridges that are not distributed are marked as blocked though, these bridges should be handled differently. There's no point in having marked a spare bridge as blocked since it hasn't been distributed, so it should just be removed. The Lox authority currently does not include this logic, but could if necessary. Probably Lox will have to be deployed for sometime before we can definitively say whether or not there is any reason to consider this problem.onyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/bridge-port-scan/-/issues/9Create a CI pipeline2024-02-15T16:40:54ZKezCreate a CI pipelineThis project could benefit from a CI pipeline. It would make sure that no broken builds make their way into the main branch.
PortScan is outside the tpo/web namespace, so it often gets forgotten during lego updates. A scheduled pipeline...This project could benefit from a CI pipeline. It would make sure that no broken builds make their way into the main branch.
PortScan is outside the tpo/web namespace, so it often gets forgotten during lego updates. A scheduled pipeline could update lego and attempt a build to make sure no future lego updates break PortScan.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40327snowflake-01: Rotate snowflake-server.log2024-02-27T11:28:05ZLinus Nordberglinus@torproject.orgsnowflake-01: Rotate snowflake-server.log`/var/log/snowflake-server/snowflake-server.log` size is at 1.3G and should be rotated and compressed.
Should the process(es) writing to the file be informed somehow? Like what is done by logrotate(8) prerotate and postrotate.`/var/log/snowflake-server/snowflake-server.log` size is at 1.3G and should be rotated and compressed.
Should the process(es) writing to the file be informed somehow? Like what is done by logrotate(8) prerotate and postrotate.Linus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40326snowflake-01: Fetch Debia packages over HTTPS instead of over onions2024-01-30T16:50:16ZLinus Nordberglinus@torproject.orgsnowflake-01: Fetch Debia packages over HTTPS instead of over onionsDebian's onions for packages, especially 2s4yqjx5... for ftp.do, has become unreliable to the point where unattended-upgrades seems to be failing night after night.
Going back to HTTPS is kinda sad but not too bad IMO.Debian's onions for packages, especially 2s4yqjx5... for ftp.do, has become unreliable to the point where unattended-upgrades seems to be failing night after night.
Going back to HTTPS is kinda sad but not too bad IMO.Linus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.org