The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-11-30T18:08:10Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/32796Tor browser allows weak crypto to be used2022-11-30T18:08:10ZcypherpunksTor browser allows weak crypto to be usedI propose to disable all the crypto considered to be weak by default. Such as CBC mode.I propose to disable all the crypto considered to be weak by default. Such as CBC mode.Sponsor 131 - Phase 3 - Major ESR 102 Migrationma1ma1https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/27258font whitelist means we don't have to set gfx.downloadable_fonts.fallback_delay2022-11-10T21:33:53ZArthur Edelsteinfont whitelist means we don't have to set gfx.downloadable_fonts.fallback_delayIn 8455, "gfx.downloadable_fonts.fallback_delay" was set to -1 to avoid temporarily rendering a local font, which would allow its characters to be measured. But now that we whitelist fonts, it is probably OK to stop setting this pref. We...In 8455, "gfx.downloadable_fonts.fallback_delay" was set to -1 to avoid temporarily rendering a local font, which would allow its characters to be measured. But now that we whitelist fonts, it is probably OK to stop setting this pref. We should confirm that the fallback mechanism doesn't provide a whitelist bypass.Sponsor 131 - Phase 3 - Major ESR 102 Migrationrichardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/24686In Tor Browser context, should network.http.tailing.enabled be set to false?2022-10-14T19:38:30ZcypherpunksIn Tor Browser context, should network.http.tailing.enabled be set to false?Here's what `network.http.tailing.enabled` does: https://www.janbambas.cz/firefox-57-delays-requests-tracking-domains/ It depends on Disconnect's tracking list.
In Tor Browser context I'm not sure whether this would be beneficial.Here's what `network.http.tailing.enabled` does: https://www.janbambas.cz/firefox-57-delays-requests-tracking-domains/ It depends on Disconnect's tracking list.
In Tor Browser context I'm not sure whether this would be beneficial.Sponsor 131 - Phase 3 - Major ESR 102 Migrationrichardrichardhttps://gitlab.torproject.org/tpo/web/lego/-/issues/59Remove YEC banner from website(s)2023-01-06T20:27:51Zal smithRemove YEC banner from website(s)Hi! We can now remove the year-end campaign banner from torproject.org / donate.tpo / community.tpo / support.tpo (and anywhere else it might be living)Hi! We can now remove the year-end campaign banner from torproject.org / donate.tpo / community.tpo / support.tpo (and anywhere else it might be living)Year End Campaign 2022https://gitlab.torproject.org/tpo/web/donate-static/-/issues/104Remove donation ticker from donate.tpo2023-01-10T20:28:47Zal smithRemove donation ticker from donate.tpoHello! Now that the year-end campaign is over, we can remove the ticker from donate.tpo.Hello! Now that the year-end campaign is over, we can remove the ticker from donate.tpo.Year End Campaign 2022https://gitlab.torproject.org/tpo/web/tpo/-/issues/360Remove YEC banner from website(s)2023-01-06T20:26:11Zal smithRemove YEC banner from website(s)Hi! We can now remove the year-end campaign banner from torproject.org / donate.tpo / community.tpo / support.tpo (and anywhere else it might be living)Hi! We can now remove the year-end campaign banner from torproject.org / donate.tpo / community.tpo / support.tpo (and anywhere else it might be living)Year End Campaign 2022https://gitlab.torproject.org/tpo/web/donate-static/-/issues/97twitter metacard not appearing2022-11-07T22:06:55ZKeztwitter metacard not appearing@nicob pointed out in IRC that twitter is not showing our card image. i've checked with a few unofficial validators (<https://tweetpik.com/twitter-card-validator>, <https://www.bannerbear.com/tools/twitter-card-preview-tool/>) and they h...@nicob pointed out in IRC that twitter is not showing our card image. i've checked with a few unofficial validators (<https://tweetpik.com/twitter-card-validator>, <https://www.bannerbear.com/tools/twitter-card-preview-tool/>) and they have no issues. but on twitter, our card looks like this: ![image](/uploads/89374a3a73809ab58e8e5a86ad018c6b/image.png)
i think the issue is the robots.txt file i added to logo, it disallows crawlers from checking the /static directory (containing our card image), and twitter respects robots.txtYear End Campaign 2022https://gitlab.torproject.org/tpo/web/donate-static/-/issues/90Update donate.tpo for the year-end campaign 20222022-10-14T17:53:02Zal smithUpdate donate.tpo for the year-end campaign 2022We will need to update https://donate.torproject.org with the new design and swag assets for the year-end campaign, which is meant to launch October 13.
## Necessary updates
- [x] Header image (@nicob will provide)
- [x] Swag asset imag...We will need to update https://donate.torproject.org with the new design and swag assets for the year-end campaign, which is meant to launch October 13.
## Necessary updates
- [x] Header image (@nicob will provide)
- [x] Swag asset images for the $75 and $125 levels (@nicob will provide)
- [x] Add donation ticker to the page, to launch 00:00:00 October 13 UTC, with top limit for the match set at $100,000 (see the only ticker ticket I could find from last year here: #55)
- [x] Update text for $75 level (in comment below)
- [x] Update text for $125 level (in comment below)
- [x] Update "Choose your size and fit" text (in comment below)Year End Campaign 20222022-10-13https://gitlab.torproject.org/tpo/web/lego/-/issues/52Header banner for YEC '222022-10-19T18:53:39ZnicobHeader banner for YEC '22Hey @hackerncoder! This year we're aiming to launch the Year End Campaign by October 13th (with some wiggle room to the following week if necessary). We position this banner above the site header on torproject.org, donate.torproject.org...Hey @hackerncoder! This year we're aiming to launch the Year End Campaign by October 13th (with some wiggle room to the following week if necessary). We position this banner above the site header on torproject.org, donate.torproject.org, community.torproject.org and support.torproject.org (you can see last year's [on the wayback machine here](https://web.archive.org/web/20211108011121/https://www.torproject.org/)).
Here's a mockup of this year's banner for mobile pending any edits from @duncan:
![torproject-banner-mobile](/uploads/4e36cc05b506aca508088b65f5a8e7e8/torproject-banner-mobile.png)
Desktop:
![torproject-banner-desktop](/uploads/7e1e26cbb680fef06aac60ab2b0e81a1/torproject-banner-desktop.png)
You can inspect files here: [Figma](https://www.figma.com/file/B2ON9c7tewUb7FDjtUS5FZ/Process%3A-YEC-'22-Creative?node-id=270%3A2407#274080983)
Mobile background image:
- [yec-bg-mobile-2x](/uploads/b08774dd428d26e8ab00dca5b70597f6/yec-bg-mobile-2x.png)
- [yec-bg-mobile-3x](/uploads/d207ed15f0d42f642ac3c4c05e402dc1/yec-bg-mobile-3x.png)
Mobile foreground image:
- [yec-foreground-mobile-2x](/uploads/c4b28c1f58b4ef88d711a346f5b1ff8d/yec-foreground-mobile-2x.png)
- [yec-foreground-mobile-3x](/uploads/2da60f67a1b1011d5c66f1b9b9083b45/yec-foreground-mobile-3x.png)
Desktop background image:
* [yec-bg-desktop-banner-2x](https://gitlab.torproject.org/tpo/web/lego/uploads/004814f546b68f1c81d8b155e9f0b2ec/yec-bg-desktop-banner-2x.png)
* [yec-bg-desktop-banner-3x](https://gitlab.torproject.org/tpo/web/lego/uploads/e2e40df7ec6d37426ae761d76084f586/yec-bg-desktop-banner-3x.png)
Desktop foreground image:
- [yec-foreground-2x](/uploads/42d6b826c7bdf3396fef91d196b0e3f8/yec-foreground-2x_12x.png)
- [yec-foreground-3x](/uploads/eb064c9fa064c1568072de4538206502/yec-foreground-2x_13x.png)
Fonts:
* [Space Mono](https://fonts.google.com/specimen/Space+Mono?vfquery=mono&query=space)
* [Space Grotesk](https://fonts.google.com/specimen/Space+Grotesk?vfquery=mono&query=space)
* I don't have the best understanding of what the devs have been doing so far to make these fonts work best for localization, but I think everything you might need to reference is here: https://gitlab.torproject.org/tpo/applications/torbutton/-/merge_requests/92#note_2837686
Buttons:
- Most of the button states are in the figma file
- Focus is not in the file but should follow what's being implemented in about:tor, which I believe is a 2px `outline-offset`, 2px width, and `#C0FF00` for `outline-color`
Other notes:
- Minimum banner height should be 360px but will need to expand with localization
- Last year, there was this note from Duncan "I think it would work best if the button anchor links down to the main content area of donate.torproject.org" - not sure if that is the case again this year, tagging @smith here to weigh in
Let me know if you have any questions or if there's anything here that I should change. Thank you!!Year End Campaign 2022https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41303YEC 2022 Takeover for Desktop Stable2023-10-16T14:52:51ZrichardYEC 2022 Takeover for Desktop StableFor reference here is the torbutton MR from last year's: https://gitlab.torproject.org/tpo/applications/torbutton/-/merge_requests/64
Last I heard, YEC is scheduled to go live the week of October 17, but there's on stable scheduled near...For reference here is the torbutton MR from last year's: https://gitlab.torproject.org/tpo/applications/torbutton/-/merge_requests/64
Last I heard, YEC is scheduled to go live the week of October 17, but there's on stable scheduled near that time frame. So, we will add the functionality and gate it behind a date check.
@nicob @duncan We need assets please!Year End Campaign 2022henryhenryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40494tor_assertion_failed_(): Bug: ../src/feature/dirclient/dirclient.c:1257: dire...2021-11-03T13:55:05Zsamip537tor_assertion_failed_(): Bug: ../src/feature/dirclient/dirclient.c:1257: directory_initiate_request: Assertion or_addr_port->port || dir_addr_port->port failed;### Summary
Tor crashes with IPv6 enabled DirPort
### Steps to reproduce:
1. Deploy an LXC Debian 11 container
2. Install Tor on it
3. Comment all Directory hardening things in systemd files related to Tor.
4. Set torrc with the follo...### Summary
Tor crashes with IPv6 enabled DirPort
### Steps to reproduce:
1. Deploy an LXC Debian 11 container
2. Install Tor on it
3. Comment all Directory hardening things in systemd files related to Tor.
4. Set torrc with the following contents:
```
Log notice syslog
RunAsDaemon 1
DataDirectory /var/lib/tor
ORPort 443
ORPort [2001:DB8::1]:443
RelayBandwidthRate 5 MB
RelayBandwidthBurst 10 MB
AccountingMax 5 TB
AccountingStart month 3 15:00
DirPort [2001:DB8::1]:80
ExitPolicy reject *:*
```
5. Have it crash after 3-10 minutes from bandwidth self-test.
### What is the current bug behavior?
The whole Tor client crashes when set with DirPort with IPv6 address in brackets followed by port.
### What is the expected behavior?
It would not crash.
### Environment
- Which version of Tor are you using? 0.4.5.10
- Which operating system are you using? Debian 11, in an LXC container
- Which installation method did you use? Distribution package
### Relevant logs and/or screenshots
```
Oct 22 06:42:35 torrelay systemd[1]: Started Anonymizing overlay network for TCP.
Oct 22 06:42:35 torrelay Tor[6069]: Signaled readiness to systemd
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 5% (conn): Connecting to a relay
Oct 22 06:42:36 torrelay Tor[6069]: Opening Socks listener on /run/tor/socks
Oct 22 06:42:36 torrelay Tor[6069]: Opened Socks listener connection (ready) on /run/tor/socks
Oct 22 06:42:36 torrelay Tor[6069]: Opening Control listener on /run/tor/control
Oct 22 06:42:36 torrelay Tor[6069]: Opened Control listener connection (ready) on /run/tor/control
Oct 22 06:42:36 torrelay Tor[6069]: Unable to find IPv4 address for ORPort 443. You might want to specify IPv6Only to it or set an explicit address or set Address.
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 10% (conn_done): Connected to a relay
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 14% (handshake): Handshaking with a relay
Oct 22 06:42:36 torrelay Tor[6069]: External address seen and suggested by a directory authority: <snip>
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 15% (handshake_done): Handshake with a relay done
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 95% (circuit_create): Establishing a Tor circuit
Oct 22 06:42:37 torrelay Tor[6069]: Bootstrapped 100% (done): Done
Oct 22 06:43:36 torrelay Tor[6069]: Not advertising Directory Service support (Reason: AccountingMax enabled)
Oct 22 06:44:36 torrelay Tor[6069]: Now checking whether IPv4 ORPort <snip>:443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Oct 22 06:44:36 torrelay Tor[6069]: Now checking whether IPv6 ORPort [2001:DB8::1]:443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Oct 22 06:44:36 torrelay Tor[6069]: Self-testing indicates your ORPort [2001:DB8::1]:443 is reachable from the outside. Excellent.
Oct 22 06:45:37 torrelay Tor[6069]: Self-testing indicates your ORPort <snip>:443 is reachable from the outside. Excellent.
Oct 22 06:45:39 torrelay Tor[6069]: Performing bandwidth self-test...done.
Oct 22 06:48:37 torrelay Tor[6069]: tor_assertion_failed_(): Bug: ../src/feature/dirclient/dirclient.c:1257: directory_initiate_request: Assertion or_addr_port->port || dir_addr_port->port failed; aborting. (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: Tor 0.4.5.10: Assertion or_addr_port->port || dir_addr_port->port failed in directory_initiate_request at ../src/feature/dirclient/dirclient.c:1257: . Stack trace: (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(log_backtrace_impl+0x6c) [0x557a907880] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(tor_assertion_failed_+0x124) [0x557a914364] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(directory_initiate_request+0x714) [0x557a9d5424] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(router_do_reachability_checks+0x184) [0x557a8d27b8] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(connection_dir_reached_eof+0x13cc) [0x557a9d783c] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(+0x1993e4) [0x557a9a93e4] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(+0x68570) [0x557a878570] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /lib/aarch64-linux-gnu/libevent-2.1.so.7(+0x234e4) [0x7f9e42e4e4] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /lib/aarch64-linux-gnu/libevent-2.1.so.7(event_base_loop+0x50c) [0x7f9e42ef84] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(do_main_loop+0xec) [0x557a8799e0] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(tor_run_main+0x1c0) [0x557a8751b4] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(tor_main+0x54) [0x557a871734] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(main+0x20) [0x557a871220] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0xe8) [0x7f9dd5c218] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(+0x612a8) [0x557a8712a8] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay systemd[1]: tor@default.service: Main process exited, code=killed, status=6/ABRT
Oct 22 06:48:37 torrelay systemd[1]: tor@default.service: Failed with result 'signal'.
Oct 22 06:48:37 torrelay systemd[1]: tor@default.service: Consumed 12.377s CPU time.
Oct 22 06:48:37 torrelay systemd[1]: tor@default.service: Scheduled restart job, restart counter is at 5.
Oct 22 06:48:37 torrelay systemd[1]: Stopped Anonymizing overlay network for TCP.
Oct 22 06:48:37 torrelay systemd[1]: tor@default.service: Consumed 12.377s CPU time.
```
### Possible fixesTor: 0.4.5.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40370config: MetricsPort seems to keep wanting to open2021-05-17T13:04:35ZDavid Gouletdgoulet@torproject.orgconfig: MetricsPort seems to keep wanting to openSeveral users have reported this problem and I just stumble on it by enabling `MetricsPort` on a relay:
```
Apr 15 14:16:56.005 [notice] Opening Metrics listener on 127.0.0.1:9090 ...Several users have reported this problem and I just stumble on it by enabling `MetricsPort` on a relay:
```
Apr 15 14:16:56.005 [notice] Opening Metrics listener on 127.0.0.1:9090
Apr 15 14:16:56.005 [notice] Opened Metrics listener connection (ready) on 127.0.0.1:9090
[...]
Apr 15 14:17:00.370 [notice] Opening Metrics listener on 127.0.0.1:9090
Apr 15 14:17:00.370 [warn] Could not bind to 127.0.0.1:9090: Address already in use. Is Tor already running?
Apr 15 14:18:00.375 [notice] Opening Metrics listener on 127.0.0.1:9090
Apr 15 14:18:00.375 [warn] Could not bind to 127.0.0.1:9090: Address already in use. Is Tor already running?
...
```
The port works and is open but every minute, Tor seems to retry to open it. Possible backport candidate.Tor: 0.4.5.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40295Bug Report for Metrics Endpoint2021-04-16T14:16:05ZGusBug Report for Metrics EndpointFrom RT:
I am testing the metrics port from this issue:
https://gitlab.torproject.org/tpo/core/tor/-/issues/40063
The issue I am getting is `"connection_finished_flushing(): Bug: got unexpected conn type 20. (on Tor 0.4.5.6 )"`
My set...From RT:
I am testing the metrics port from this issue:
https://gitlab.torproject.org/tpo/core/tor/-/issues/40063
The issue I am getting is `"connection_finished_flushing(): Bug: got unexpected conn type 20. (on Tor 0.4.5.6 )"`
My setup is the following:
```
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.2 LTS
Release: 20.04
Codename: focal
```
```
$ tor --version
Tor version 0.4.5.6.
```
I added the following values to my torrc:
```
MetricsPort 127.0.0.1:9135
MetricsPortPolicy accept 127.0.0.1
```
Several issues arise:
a) Tor is not able to determine, that the Metrics Port has already been opened. Tor tried to open it again
b) Something inside tor crashes as soon as someone tries to access the metrics information.
I attached the log messages from syslog. [logfile.txt](/uploads/dfc846864430f16cc038447c64e04e55/logfile.txt)
Please note, that I am using tor for relay as well as for a hidden service.
I checked, there is nothing listening on port 9135. Tor has this port exclusively.
The metrics port is disabled again for my setup. If you need more information, please don't hesitate to ask.Tor: 0.4.5.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40107Bridge chooses IPv6 instead of IPv4 (as configured) for server transport 'obfs4'2021-02-24T12:14:47ZtoralfBridge chooses IPv6 instead of IPv4 (as configured) for server transport 'obfs4'Running a bridge at a Debian (buster stable) with 0.4.3.6-1~d10.buster+1 and 0.0.7-4+b12 brought the issue that configuring the server transport 'obfs4' according to the official Tor documentation to listen at IPv4 as
```
ServerTransport...Running a bridge at a Debian (buster stable) with 0.4.3.6-1~d10.buster+1 and 0.0.7-4+b12 brought the issue that configuring the server transport 'obfs4' according to the official Tor documentation to listen at IPv4 as
```
ServerTransportListenAddr obfs4 0.0.0.0:443
```
let the bridge choose IPv6:
```
Aug 16 09:44:57.000 [notice] Registered server transport 'obfs4' at '[::]:443'
```
I set ServerTransportListenAddr to the real IP address which helped:
```
# we have to explicitly set this (and NOT to "0.0.0.0:443" and "[..]:443" respectively)
ServerTransportListenAddr obfs4 <ip addr>:<obfs4 port>
```
This bridge behaviour effectively turnes the bridge in being unusable for obfs4 connections for me.
I tested the above with a connection from a local Tor client and from within Tails from a client location where only IPv4 was working.Tor: 0.4.5.x-post-stableGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41155Review Mozilla 1751450: Unsigned DLLs used during per-user installation on Wi...2022-11-23T13:39:41ZrichardReview Mozilla 1751450: Unsigned DLLs used during per-user installation on Windows, prevents use of AppLocker## https://bugzilla.mozilla.org/show_bug.cgi?id=1751450
More reasons we should codesign all of shipped dlls and exes on Windows## https://bugzilla.mozilla.org/show_bug.cgi?id=1751450
More reasons we should codesign all of shipped dlls and exes on WindowsSponsor 131 - Phase 4 - Browser Release Managementrichardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40577Make do-all-signing wait for android signed apks before the hash_signed_bundl...2023-08-17T23:19:49ZboklmMake do-all-signing wait for android signed apks before the hash_signed_bundles stepThe android signing is done separately (in parallel). The `do-all-signing` script should wait for the signed apks before starting the hash_signed_bundles step.The android signing is done separately (in parallel). The `do-all-signing` script should wait for the signed apks before starting the hash_signed_bundles step.Sponsor 131 - Phase 4 - Browser Release Managementboklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40574Improve android signing script2023-01-30T08:45:38ZboklmImprove android signing scriptIn #40513 we added the script used for signing APKs.
I think we can make the following improvements:
* downloading Android SDK build-tools if missing
* checking that needed packages are installed
* downloading *.apk files from pkgstage ...In #40513 we added the script used for signing APKs.
I think we can make the following improvements:
* downloading Android SDK build-tools if missing
* checking that needed packages are installed
* downloading *.apk files from pkgstage machine before signing them, and re-uploading them to pkgstage signing after
* using tbb_version from `set-config.tbb-version`Sponsor 131 - Phase 4 - Browser Release Managementboklmboklmhttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/81Snowflake stops working after large size tests2022-07-21T01:06:13ZitchyonionSnowflake stops working after large size tests
Snowflake, after some of the large message size tests, snowflake suddenly stopped being able to send/receive. The race app was still running, but starting/stopping the deployment seemed to fix the issue
Snowflake, after some of the large message size tests, snowflake suddenly stopped being able to send/receive. The race app was still running, but starting/stopping the deployment seemed to fix the issueSponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)itchyonionitchyonionhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40495Remove double signature verification in macos-signer-gatekeeper-signing2023-01-30T08:43:18ZboklmRemove double signature verification in macos-signer-gatekeeper-signingIn `macos-signer-gatekeeper-signing` it seems we are checking the signature twice: one time immediately after signing before creating the zip file, and an other time after extracting the zip file we just created. I'm wondering if the 2 s...In `macos-signer-gatekeeper-signing` it seems we are checking the signature twice: one time immediately after signing before creating the zip file, and an other time after extracting the zip file we just created. I'm wondering if the 2 signature checks are useful or if we can remove one.
I think in some cases the script fails in the middle because the signature verification takes a long time, which cause the unlocked keychain to timeout. We can also move the `security unlock ...` commands inside the `for LANG in $bundle_locales` to make sure it stays unlocked.
/cc @sysrqbSponsor 131 - Phase 4 - Browser Release Managementboklmboklmhttps://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40007Task 1.1 Get some manual vantage points in key regions, and generate automate...2022-02-11T16:40:07ZGabagaba@torproject.orgTask 1.1 Get some manual vantage points in key regions, and generate automated baseline measurements in each of themGet some manual vantage points in key regions, and automate scans of vanilla Tor, default Tor Browser bridges, vanilla and obfs4 bridges (both from bridgedb and unpublished), and meek.
- [ ] Pick key regions (possible China and Turkey, ...Get some manual vantage points in key regions, and automate scans of vanilla Tor, default Tor Browser bridges, vanilla and obfs4 bridges (both from bridgedb and unpublished), and meek.
- [ ] Pick key regions (possible China and Turkey, Belarus, Thailand, Uganda, Russia, India)
- [ ] Tools to start with
- [ ] Snowflake tests and STUN server tests
- [ ] Emma
- [ ] Marco
- [ ] OONI
- [ ] Bridgestrap
- [ ] Tor itself in various configsSponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)shelikhooshelikhoo