The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-03-05T19:13:47Zhttps://gitlab.torproject.org/tpo/community/team/-/issues/96Call for testers - TBA Alpha Connect Assist2024-03-05T19:13:47ZGusCall for testers - TBA Alpha Connect AssistApplications Team is implementing "connect assist" on TBA and it would be nice to collect users feedback. We should create a Call for Testers on the Forum.
Connect Assist is available on 13.5a3 alpha.
```
## Connect assist comes to And...Applications Team is implementing "connect assist" on TBA and it would be nice to collect users feedback. We should create a Call for Testers on the Forum.
Connect Assist is available on 13.5a3 alpha.
```
## Connect assist comes to Android
This alpha is the first release with Desktop's censorship circumvention feature (connect assist) available on Android! You can try it out for yourself by navigating to the `Settings > Tor Network` and selecting `Enable beta connection features`.
**NOTE**: This feature is very much in development and is still quiet brittle and liable to breakage. Do *not* toggle this option if you value your current Tor Browser for Android Alpha configuration. If this option gets the app into an unusable state, you can get back to the legacy bootstrapping system by clearing the app's storage and cache via the Android system settings. Of course, doing so will also delete any existing configuration options so please do not enable this option if this would be a problem for you.
When this feature ships in 13.5 in late spring/early summer 2024, Android users connecting from censored networks should have the exact same bootstrapping functionality Desktop users currently have. If they are unable to connect to the Tor Network, Tor Browser will query the anti-censorship backend to determine which pluggable transports and bridges they need to use based upon their locale and the current censorship landscape. The browser will then attempt to bootstrap once more with the new settings applied. Our hope is that this will take a lot of the guesswork out of connecting to the Tor Network for our mobile users, and ensure unfettered network access during censorship events.
For now we expect this new bootstrapping UX to be buggy, but we wanted to get it into the hands of users as early as possible so we can iterate and find and fix bugs as early as possible.
```Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & TibetGusGus2024-03-01https://gitlab.torproject.org/tpo/community/l10n/-/issues/40124O4.1: Localize all UI modified in this project.2024-02-12T13:49:23ZGabagaba@torproject.orgO4.1: Localize all UI modified in this project.The text of this activity is:
"We will coordinate the volunteer localization of UI components of all new and modified tools in this project into traditional and simplified Chinese. This process involves reviewing the strings, reaching o...The text of this activity is:
"We will coordinate the volunteer localization of UI components of all new and modified tools in this project into traditional and simplified Chinese. This process involves reviewing the strings, reaching out to the translator community, answering translator questions in Transifex, and publishing the reviewed content."
The modified tools in Sponsor 96 are:
- OnionSproutBot UI
- Tor Browser for Desktop (webtunnel UI, snowflake UI and manual)
- Tor Browser for Android (connect assist): (translations will happen in February and March
- Lox: translations will happen in February and March
- OnionShare: Desktop, Android and iOS
- Orbot web
- Rebranding of OnionShare iOS for users in Chinaemmapeelemmapeel2024-03-01https://gitlab.torproject.org/tpo/ux/design/-/issues/91Draw Network Health, Coding/Dev, Fundraising illustrations2024-02-07T17:54:01ZnicobDraw Network Health, Coding/Dev, Fundraising illustrations#### Design estimate
* complexity: medium (3 days)
* uncertainty: low (1.1)
* total: 3-3.3 days
* actual:
---
* [ ] Vectorize Network Health illustration
* [ ] Vectorize Coding/Dev illustration
* [ ] Vectorize Fundraising illustrations#### Design estimate
* complexity: medium (3 days)
* uncertainty: low (1.1)
* total: 3-3.3 days
* actual:
---
* [ ] Vectorize Network Health illustration
* [ ] Vectorize Coding/Dev illustration
* [ ] Vectorize Fundraising illustrationsdesign-dot MVPnicobnicob2024-03-04https://gitlab.torproject.org/tpo/ux/design/-/issues/92Explore treatment and style for hands in illustrations2024-02-07T17:54:15ZnicobExplore treatment and style for hands in illustrations#### Design estimate
* complexity: medium (3 days)
* uncertainty: low (1.1)
* total: 3-3.3 days
* actual:
---
Explore different treatments with hands across the illustration set to determine a consistent style that works across concepts.#### Design estimate
* complexity: medium (3 days)
* uncertainty: low (1.1)
* total: 3-3.3 days
* actual:
---
Explore different treatments with hands across the illustration set to determine a consistent style that works across concepts.design-dot MVPnicobnicob2024-03-07https://gitlab.torproject.org/tpo/core/onionmasq/-/issues/70Add support for Snowflake2024-03-27T17:31:16ZetaAdd support for SnowflakeThe current PT support only does obfs4. We probably want snowflake too.The current PT support only does obfs4. We probably want snowflake too.VPN pre-alpha 06Micah Elizabeth ScottMicah Elizabeth Scott2024-03-07https://gitlab.torproject.org/tpo/tpa/team/-/issues/41216move legacy git redirections to the static mirror infrastructure2024-03-27T15:29:01Zanarcatmove legacy git redirections to the static mirror infrastructureOnce all lagacy Git repositories have been migrated to GitLab (#41215), the redirections can be moved from gitweb (`vineale`) to the static mirror system.Once all lagacy Git repositories have been migrated to GitLab (#41215), the redirections can be moved from gitweb (`vineale`) to the static mirror system.legacy Git infrastructure retirement (TPA-RFC-36)2024-03-08https://gitlab.torproject.org/tpo/tpa/team/-/issues/41215forcibly migrate remaining Gitolite repositories to GitLab2024-03-26T20:51:17Zanarcatforcibly migrate remaining Gitolite repositories to GitLabAs part of the Gitolite retirement procedure (TPA-RFC-36, #41180), migrate remaining repositories from Gitolite to GitLab.
The goal is to complete this from within 12 months of the announcement, or 3 months from the original due date of...As part of the Gitolite retirement procedure (TPA-RFC-36, #41180), migrate remaining repositories from Gitolite to GitLab.
The goal is to complete this from within 12 months of the announcement, or 3 months from the original due date of this ticket, that is, before 2024-06-08, at which point the servers are supposed to be retired.
The actual list of repositories to migrate should probably be added here and users warned about the impeding change one last time. An inventory will have previously been made in #41214.
In TPA-RFC-36, the following was established:
> ## Per-repository particularities
>
> This section documents the fate of some repositories we are aware
> of. If you can think of specific changes that need to happen to
> repositories that are unusual, please do report them to TPA so they
> can be included in this proposal.
>
> ### idle repositories
>
> Repositories that did not have any new commit in the last two years
> are considered "idled" and should be migrated or archived to GitLab by
> their owners. Failing that, TPA will *archive* the repositories in the
> GitLab `legacy/` namespace before final deadline.
>
> ### user repositories
>
> There are 358 repositories under the `user/` namespace, owned by 70
> distinct users.
>
> Those repositories must be migrated to their corresponding user on the
> GitLab side.
>
> If the Gitolite user does not have a matching user on GitLab, their
> repositories will be moved under the `legacy/gitolite/user/` namespace
> in GitLab, owned by the GitLab admin doing the migration.
>
> ### "mirror" and "extern" repositories
>
> Those repositories will be migrated to, and archived in, GitLab within
> a month of the adoption of this proposal.
>
> ### Applications team repositories
>
> [See tpo/tpa/team#41181.]
So, as a task list, per repos:
- [ ] 5 `mirror` or `extern` (migrate and archive)
- [ ] 12 TPA (see #41219)
- [x] 49 migrated
- [ ] 87 `Attic` (migrate and archive)
- [ ] 97 `Other` (migrate, archive "idle" repositories)
- [ ] 288 `user` (migrate and archive)
See https://gitlab.torproject.org/tpo/tpa/team/-/issues/41214#note_2983291 for how those numbers were established.legacy Git infrastructure retirement (TPA-RFC-36)2024-03-08https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/126Research about designing an armored bridge line sharing URL format2024-03-04T15:32:16ZshelikhooResearch about designing an armored bridge line sharing URL formatTor's bridge line format is well suited for professional developers and power users on desktop environments. However, for other users the current bridge line does not work so well because:
1. The bridge line contains white space and oth...Tor's bridge line format is well suited for professional developers and power users on desktop environments. However, for other users the current bridge line does not work so well because:
1. The bridge line contains white space and other special characters that could make it hard to copy and paste correctly.
2. When the bridge line was corrupted, the client software can neither detect it, nor correct it. This results in user confusion as the corrupted bridge line results in silent error.
3. User tries to edit the bridge line without understanding how it works internally. This results in inconsistency between how the user expects a bridge line to work and how it actually works.
This ticket tracks the research and discussion about creating a new bridge line format specialized in sharing to address the issues mentioned.
Let's make some initial discussion before I write the full spec and write a reference implementation.
## Goals and non-goals
This armored bridge line format will try to:
1. auto detect/auto correct error occurred during transmission. Give the user explicit feedback when the bridge line is corrupted and avoid silent errors.
2. improve its operating system integration, allowing the user to click on the armored bridge line and be redirected to a bridge line recipient application.
3. avoid any characters or design that could make it harder to transmit the bridge line correctly.
4. signal user not to modify the shared bridge line by intuitively
It won't:
1. try to replace the current bridge line format. It is used to share bridge lines, and original bridge line format will still be accepted by all Tor applications and shown to users by default. The current bridge line format will still be the way bridge configurations are represented.
2. prevent users from editing bridge lines. Users still will be able to edit the bridge line once it is decoded from armored format.
3. prevent the bridge line from being censored or detected by authority.
## Expected Usage Context
This armored bridge line design will be used exclusively for sharing.
Specifically:
1. On Tor Browser, there will be a share bridge line button, when clicked, an armored bridge line will be converted from an ordinary bridge line, and shown to the user as plain text and QR code.
2. The user support team will share an armored bridge line generated from Tor Browser or command line tool to users requesting a bridge when appropriate.
3. Users can share armored bridge lines with each other.
4. Tor client implementations MAY support armored bridge line input. It is optional since this design is targeted toward ordinary users, and Tor Browser already supports converting bridge lines between different forms with command line tools. Advanced users can just use command line tools to convert bridge lines between its different formats.
## Internal design (for discussion)
The 2 way convention between armored bridge line and ordinary bridge line is through a sequence of reversible transform steps. Some of them are optional(under discussion), and may or may not be included in the final design. There are no dynamic or skipable step in the final version of the design.
### Compression (optional)
A compression like 7 bit UTF8 can be used to reduce the length of the final url string.
It will however make conversion more complex to implement.
### All or none transform (optional)
A all or none transform(AONT) like [SAEP+](http://crypto.stanford.edu/~dabo/abstracts/saep.html) can make sure the final output is completely random looking, polymorphic without any resemblance of underlying data.
This ensures:
1. Data are covered by checksum(see SAEP+ design), so any corruption will be detected.
2. Because data are encoded differently each time, if the final output contains a censored keyword, the user can just try again.
3. there will be less observable patterns in the final URL, preventing users from attempting to modify or interpreting it. The users will need to use a supported application to process the armored bridge line.
4. (less of a concern for Tor ecosystem) prevent client implementation from ignoring the checksum and process anyway.
This is a complex transform step.
### Checksum (if All or none transform step is not used) (optional)
Use a CRC64 or SHA-3 to generate a checksum to detect corruption.
This step should be skipped if AONT step was used.
### Forward error correction (optional)
Split the data into chunks and use Reed Solomon coding to encode the data and generate recovery shreds.
When the bridge line is corrupted, forward error correction attempts to repair content directly, without asking the user to try again. This non-interactive repair makes it easier for the user to get the bridge line working, without asking and waiting for assistance. Some environments like bad email clients/line breakers corrupt the content each time it processes it, retry itself won't work and frustrate users.
This is a complex transform step.
### URLSafe base64 encoding without padding + concreted
URL safe base64 encoding without padding will convert the binary result of previous steps into a URL safe string. If there is more than one shard of contents, they will be concreted with ~ symbol, which is URL safe and not used by URL safe base64.
### URL Prefix
The final string will be prefixed with either `bridgeprefix:?` or `https://bridgeprefix/#` to allow it to be clicked and be redirected to Tor client application by operating system.shelikhooshelikhoo2024-03-08https://gitlab.torproject.org/tpo/web/dev/-/issues/15Get staging site ready for review by TPO2024-03-14T14:33:01ZGabagaba@torproject.orgGet staging site ready for review by TPO- [x] repo: force-push new HUGO site into https://gitlab.torproject.org/tpo/web/dev (@anxhelo )
- [ ] staging: use pages for it until build pipeline is ready (@lavamind )
- [ ] triage/clean issues in web/dev (gaba)
- [ ] edit/curate cont...- [x] repo: force-push new HUGO site into https://gitlab.torproject.org/tpo/web/dev (@anxhelo )
- [ ] staging: use pages for it until build pipeline is ready (@lavamind )
- [ ] triage/clean issues in web/dev (gaba)
- [ ] edit/curate content (gaba)
- [ ] send to tor-internal for review
@anxhelo please fill free to force-push your code into this repo.anxheloanxhelo2024-03-15https://gitlab.torproject.org/tpo/ux/design/-/issues/93Draw rollerskate for alternative relay/speed illustration2024-02-07T17:54:47ZnicobDraw rollerskate for alternative relay/speed illustration#### Design estimate
* complexity: small (1 day)
* uncertainty: low (1.1)
* total: 1-1.1 days
* actual:
---
Vectorize alternative rollerskate illustration from an original sketch in the Running a Relay skamp set.#### Design estimate
* complexity: small (1 day)
* uncertainty: low (1.1)
* total: 1-1.1 days
* actual:
---
Vectorize alternative rollerskate illustration from an original sketch in the Running a Relay skamp set.design-dot MVPnicobnicob2024-03-19https://gitlab.torproject.org/tpo/team/-/issues/186Code Audit for Sponsor 1012024-03-19T18:04:53ZGabagaba@torproject.orgCode Audit for Sponsor 101- [x] Create RFPT
- [ ] Send to DRL for approval
- [ ] Send to auditors
- [ ] Choose an auditor to start work- [x] Create RFPT
- [ ] Send to DRL for approval
- [ ] Send to auditors
- [ ] Choose an auditor to start workGabagaba@torproject.orgGabagaba@torproject.org2024-03-20https://gitlab.torproject.org/tpo/tpa/team/-/issues/41372pg backups filling up on bungei2024-03-26T15:15:15Zanarcatpg backups filling up on bungeisimilar to #41361 except now it's the `/srv/backups/pg` partition that's filling up...
1 year graph:
![image](/uploads/6500ce9736e25737fd16357e8d1f0d19/image.png)
https://grafana.torproject.org/d/zbCoGRjnz/disk-usage?orgId=1&from=now-1...similar to #41361 except now it's the `/srv/backups/pg` partition that's filling up...
1 year graph:
![image](/uploads/6500ce9736e25737fd16357e8d1f0d19/image.png)
https://grafana.torproject.org/d/zbCoGRjnz/disk-usage?orgId=1&from=now-1y&to=now&var-class=All&var-instance=bungei.torproject.org
30 days:
![image](/uploads/8b193a1cc848d97cde37ab43b49d2c77/image.png)
https://grafana.torproject.org/d/zbCoGRjnz/disk-usage?orgId=1&from=now-30d&to=now&var-class=All&var-instance=bungei.torproject.org
change rate is -1TB per month according to grafana.
/cc @gkanarcatanarcat2024-03-21https://gitlab.torproject.org/tpo/team/-/issues/269s144 report2024-03-19T19:40:45ZGabagaba@torproject.orgs144 report2024-03-25https://gitlab.torproject.org/tpo/team/-/issues/265Draft agenda2024-03-25T17:38:08ZGabagaba@torproject.orgDraft agendaGabagaba@torproject.orgGabagaba@torproject.org2024-03-26https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/136renew Docker-Sponsored Open Source Program2024-03-26T10:35:25Zmeskiomeskio@torproject.orgrenew Docker-Sponsored Open Source ProgramThe billing tab of our docker organization says:
> Your Docker-Sponsored Open Source status will expire on Apr 15, 2024.
> To keep your Docker-Sponsored Open Source status, look for our email containing renewal information and follow t...The billing tab of our docker organization says:
> Your Docker-Sponsored Open Source status will expire on Apr 15, 2024.
> To keep your Docker-Sponsored Open Source status, look for our email containing renewal information and follow the link within to reapply.
I got the mentioned email. I was assuming it was a phishing email as the renew link points to *docker.my.site.com*, but I guess is legit (site.com is a salesforce domain and the DKIM of the email looks valid):
```
We would like to kindly remind you that your current subscription to
the Docker-Sponsored Open Source Program is set to expire in 45 days.
We highly value your participation in the program and would like to
invite you to renew your subscription.
[1]Click Here to Renew
By renewing, you'll continue to benefit from the program's offerings
if your project still meets the [2] qualification criteria. An annual
Docker Team subscription will be allocated to the following project
organization: Docker ID - thetorproject
Here are the benefits you'll continue to enjoy:
* Autobuilds
* Free team seats
* Rate-limit removal for all users pulling public images from your
project namespace
* Sponsored OSS badge on Docker Hub and being prioritized in search
results
* Usage reporting
Before you proceed with the renewal application, we kindly request
that you take a moment to complete a [3]brief survey. Your feedback
in the survey does not impact the review of your application; it will
only be used to inform improvements to the program so that we can
better serve the open-source community.
If you have any questions or encounter any technical issues during
the renewal process, please don't hesitate to contact
support@docker.com. Our team is here to assist you and ensure a
smooth renewal experience.
Thank you!
The Docker Team
```
Anyway, I guess we should follow the email instructions and renew the subscription. Depending on how much work is that we might want to consider more seriously to move to our gitlab container registry (#121)meskiomeskio@torproject.orgmeskiomeskio@torproject.org2024-03-28https://gitlab.torproject.org/tpo/ux/design/-/issues/61Draw new illustration set2024-03-27T14:34:40ZdonutsDraw new illustration setDuring the hackweek, @nicob worked on a prototype for a new illustration style:
![new-illustration-style](/uploads/5e7358be99ff09fcd647a6389eacbf25/new-illustration-style.png)
And it looks great!
The next steps are to:
0. Maybe docum...During the hackweek, @nicob worked on a prototype for a new illustration style:
![new-illustration-style](/uploads/5e7358be99ff09fcd647a6389eacbf25/new-illustration-style.png)
And it looks great!
The next steps are to:
0. Maybe document the basic rules for the style? I attempted to describe it here: [Figma / design-dot / Pages](https://www.figma.com/file/nIpahk0b9VMaeEnubiO33g/design-dot?type=design&node-id=291%3A10068&mode=design&t=fHze76LK0jCQsL6Y-1)
1. Create and agree on a list of themes to illustrate for the base set
2. Draw the illustrations!design-dot MVPnicobnicob2024-03-28https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/185Distribute a single bridge in the QR code2024-03-04T15:30:36ZboyskaDistribute a single bridge in the QR codeThe current implementation of BridgeDB gives the user 3 bridges, and a QR code including them all.
It's a well-acknowledged fact that it's very difficult to scan this huge QR code from a smartphone.
It's almost impossible to scan it from...The current implementation of BridgeDB gives the user 3 bridges, and a QR code including them all.
It's a well-acknowledged fact that it's very difficult to scan this huge QR code from a smartphone.
It's almost impossible to scan it from a piece of paper.
It would therefore be great if the QR could include only a single bridge. While this would make the QR code slightly less useful, it would also make it much more _usable_.
I know that #40052+ is already tracking improvements for QR codes. However, they are mostly independent:
- To get one bridge per QR code, bridgedb#40052 is not needed
- Changing the format to a proper URI doesn't imply we will be switching to one-bridge-per-QR-code.
I can see two possible implementations:
1. Provide 3 bridges and 1 QR code. The QR code only includes data for one of the bridges.
2. Provide 3 bridges and 3 QR codes.
In Tails, we will be shipping QR code scanning [in 5.8](https://tails.boum.org/news/test_5.8-beta1/). This is expected to happen around December 20. It would be great if BridgeDB could distribute more usable QR codes by that time!shelikhooshelikhoo2024-03-29https://gitlab.torproject.org/tpo/web/tpo/-/issues/420Press mentions for 2022 - 2023 needed on website2024-03-12T00:32:37ZemmapeelPress mentions for 2022 - 2023 needed on websiteOur [Press](https://www.torproject.org/press/) page shows articles up until 2021-12-29.Our [Press](https://www.torproject.org/press/) page shows articles up until 2021-12-29.pavelpavel2024-03-31https://gitlab.torproject.org/tpo/tpa/team/-/issues/41538Create new email address for use with CiviCRM relationship management2024-03-25T16:59:30Zal smithCreate new email address for use with CiviCRM relationship managementHi TPA,
Fundraising + Mathieu need a new email address created for a function we're introducing in CiviCRM. (It will allow us to BCC an email address to automatically add a record of that email to an individual's records in CiviCRM. You...Hi TPA,
Fundraising + Mathieu need a new email address created for a function we're introducing in CiviCRM. (It will allow us to BCC an email address to automatically add a record of that email to an individual's records in CiviCRM. You can see the overarching ticket here: https://gitlab.torproject.org/tpo/web/civicrm/-/issues/112.)
I'm requesting `crm@torproject.org`.
Please let me know if there's anything I need to do to facilitate this. :) Thanks!Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.org2024-03-31https://gitlab.torproject.org/tpo/web/lego/-/issues/50Use `mailto:gettor@...?body=...` links wherever the gettor email is mentioned2024-02-22T15:39:24ZWofWcawofwca@protonmail.comUse `mailto:gettor@...?body=...` links wherever the gettor email is mentionedExample link:
<mailto:gettor@torproject.org?body=windows%20en_US>
If you click this link, this will tell the handler to prefill the body with `windows en_US`. Maybe could also add something else, like a comment about "replace `windows`...Example link:
<mailto:gettor@torproject.org?body=windows%20en_US>
If you click this link, this will tell the handler to prefill the body with `windows en_US`. Maybe could also add something else, like a comment about "replace `windows` with `linux` if you need to, and `en_US` with the name of your locale <a link to locales list>".
For example, on gettor.torproject.org we could generate such a link, instead of just giving verbal instructions. Also we could add "OS" and "locale" `<select>`s and change the link based on that, and try to detect the locale and OS for default values.
Also there needs to be a "copy" button as currently in Chromium and Gecko it appears that if you right-click and copy the link, it only copies the email address.
This should allow to share such a link more easily as you don't have to add instructions along with email address.
We could also add such links to the response emails as well (e.g. if the user did not specify the OS) - maybe make a table with OS as columns, language as rows and links as cells.
But I shall warn that removing the instructions and only relying on such links is probably not good because they don't always do what I described. For example, if you set Chromium as the `mailto` link handler, and do not set up any handler websites inside the browser, clicking such link will do nothing.
I don't know where else this email is mentioned, maybe this can help https://gitlab.torproject.org/tpo/anti-censorship/gettor-project/gettor/-/issues/87
And I'm not sure if this is the right place for this issue, maybe https://gitlab.torproject.org/tpo/anti-censorship/gettor-project is more appropriate, feel free to move it.
Related: https://gitlab.torproject.org/tpo/anti-censorship/gettor-project/gettor/-/issues/64Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.org2024-03-31