The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-11-30T14:16:53Zhttps://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/issues/58Estimate DB grow rate over time2023-11-30T14:16:53ZHiroEstimate DB grow rate over timeWe should estimate how the network grew over time since we are collecting data in order to have an idea of how much space we will need for the DB we are building.
See: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41372#note_2959888We should estimate how the network grew over time since we are collecting data in order to have an idea of how much space we will need for the DB we are building.
See: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41372#note_2959888HiroHirohttps://gitlab.torproject.org/tpo/applications/rbm/-/issues/40063RBM's chroot fails in Fedora2023-11-24T09:18:03ZNoisyCoilRBM's chroot fails in Fedora[Line 98 in file `container`](container#L98) causes RBM's chroot to fail when building the Tor Browser on Fedora (39). The build fails during the first call to [`copy_file_to`](container#L107), due to the `chown` command not being found ...[Line 98 in file `container`](container#L98) causes RBM's chroot to fail when building the Tor Browser on Fedora (39). The build fails during the first call to [`copy_file_to`](container#L107), due to the `chown` command not being found inside the chroot. In turn, this happens because of the clearing of `$PATH` implicit in [line 98](container#L98). Neither Debian nor on Ubuntu show this behavior.
While changing `chown` to `/usr/bin/chown` on [line 113](container#L113) fixes [`copy_file_to`](container#L107), a better fix is to re-set `$PATH` after clearing the environment:
```
fcopy('/etc/resolv.conf', "$rootfsdir/etc/resolv.conf");
local %ENV = ();
+ local $ENV{"PATH"} = "/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin";
path("$rootfsdir/etc/hosts")->append("\n127.0.1.1 rbm\n")
unless grep { m/^127.0.1.1 rbm$/ } path("$rootfsdir/etc/hosts")->lines;
```
Of course, `/usr/local/bin` and `/usr/local/sbin` are probably superfluous.https://gitlab.torproject.org/tpo/anti-censorship/gettor-project/OnionSproutsBot/-/issues/55@gettor_bot on Telegram does not work2023-11-06T12:01:00Znina@gettor_bot on Telegram does not workIt does not react to the commands.
Reported by two users and confirmed by meIt does not react to the commands.
Reported by two users and confirmed by memeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41377Install golang compiler in rdsys-test-012023-11-03T09:45:47Zmeskiomeskio@torproject.orgInstall golang compiler in rdsys-test-01We'll need to compile the rdsys binaries on that machine. Can we get golang installed there?We'll need to compile the rdsys binaries on that machine. Can we get golang installed there?anarcatanarcathttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41376Update howto/postgresql recovery procedure2023-11-02T18:49:34ZJérôme Charaouilavamind@torproject.orgUpdate howto/postgresql recovery procedureThe current recovery steps in the wiki don't work for PostgreSQL version 12 and later.
This is because `recovery.conf` in the database directory is no longer supported. The `restore_command` config must be placed in `postgresql.conf`.
...The current recovery steps in the wiki don't work for PostgreSQL version 12 and later.
This is because `recovery.conf` in the database directory is no longer supported. The `restore_command` config must be placed in `postgresql.conf`.
```
Nov 01 22:25:43 rude postgresql@15-main[30560]: 2023-11-01 22:25:43 UTC [30565-1] LOG: starting PostgreSQL 15.3 (Debian 15.3-0+deb12u1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
Nov 01 22:25:43 rude postgresql@15-main[30560]: 2023-11-01 22:25:43 UTC [30565-2] LOG: listening on IPv4 address "0.0.0.0", port 5432 Nov 01 22:25:43 rude postgresql@15-main[30560]: 2023-11-01 22:25:43 UTC [30565-3] LOG: listening on IPv6 address "::", port 5432
Nov 01 22:25:43 rude postgresql@15-main[30560]: 2023-11-01 22:25:43 UTC [30565-4] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
Nov 01 22:25:43 rude postgresql@15-main[30560]: 2023-11-01 22:25:43 UTC [30568-1] LOG: database system was interrupted; last known up at 2023-11-01 18:52:52 UTC
Nov 01 22:25:43 rude postgresql@15-main[30560]: 2023-11-01 22:25:43 UTC [30568-2] FATAL: using recovery command file "recovery.conf" is not supported
Nov 01 22:25:43 rude postgresql@15-main[30560]: 2023-11-01 22:25:43 UTC [30565-5] LOG: startup process (PID 30568) exited with exit code 1
Nov 01 22:25:43 rude postgresql@15-main[30560]: 2023-11-01 22:25:43 UTC [30565-6] LOG: aborting startup due to startup process failure
Nov 01 22:25:43 rude postgresql@15-main[30560]: 2023-11-01 22:25:43 UTC [30565-7] LOG: database system is shut down
```
From the [12.0 release notes](https://www.postgresql.org/docs/release/12.0/):
> recovery.conf is no longer used, and the server will not start if that file exists. recovery.signal and standby.signal files are now used to switch into non-primary mode.
In addition, after adding the restore directive, a `restore.signal` file must be create din the database directory to trigger the recovery process.
```
Nov 01 22:33:31 rude postgresql@15-main[31198]: 2023-11-01 22:33:31 UTC [31203-1] LOG: starting PostgreSQL 15.3 (Debian 15.3-0+deb12u1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
Nov 01 22:33:31 rude postgresql@15-main[31198]: 2023-11-01 22:33:31 UTC [31203-2] LOG: listening on IPv4 address "0.0.0.0", port 5432
Nov 01 22:33:31 rude postgresql@15-main[31198]: 2023-11-01 22:33:31 UTC [31203-3] LOG: listening on IPv6 address "::", port 5432
Nov 01 22:33:31 rude postgresql@15-main[31198]: 2023-11-01 22:33:31 UTC [31203-4] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
Nov 01 22:33:31 rude postgresql@15-main[31198]: 2023-11-01 22:33:31 UTC [31206-1] LOG: database system was interrupted; last known up at 2023-11-01 18:52:52 UTC
Nov 01 22:33:31 rude postgresql@15-main[31198]: 2023-11-01 22:33:31 UTC [31206-2] LOG: invalid checkpoint record
Nov 01 22:33:31 rude postgresql@15-main[31198]: 2023-11-01 22:33:31 UTC [31206-3] FATAL: could not locate required checkpoint record
Nov 01 22:33:31 rude postgresql@15-main[31198]: 2023-11-01 22:33:31 UTC [31206-4] HINT: If you are restoring from a backup, touch "/var/lib/postgresql/15/main/recovery.signal" and add required recovery options.
Nov 01 22:33:31 rude postgresql@15-main[31198]: If you are not restoring from a backup, try removing the file "/var/lib/postgresql/15/main/backup_label".
Nov 01 22:33:31 rude postgresql@15-main[31198]: Be careful: removing "/var/lib/postgresql/15/main/backup_label" will result in a corrupt cluster if restoring from a backup.
Nov 01 22:33:31 rude postgresql@15-main[31198]: 2023-11-01 22:33:31 UTC [31203-5] LOG: startup process (PID 31206) exited with exit code 1
Nov 01 22:33:31 rude postgresql@15-main[31198]: 2023-11-01 22:33:31 UTC [31203-6] LOG: aborting startup due to startup process failure
Nov 01 22:33:31 rude postgresql@15-main[31198]: 2023-11-01 22:33:31 UTC [31203-7] LOG: database system is shut down
```Debian 12 bookworm upgradeJérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42222Fix TorDomainIsolator initialization on Android2023-11-06T20:47:38ZPier Angelo VendrameFix TorDomainIsolator initialization on AndroidIn TBA 13.0aX and 13.0.X (until 13.0.2) the domain isolator is not being initialized incorrectly.
It seems the `TorStartupService` isn't being loaded (even though I'm quite sure it looks like exactly the one we had in Torbutton).
I don...In TBA 13.0aX and 13.0.X (until 13.0.2) the domain isolator is not being initialized incorrectly.
It seems the `TorStartupService` isn't being loaded (even though I'm quite sure it looks like exactly the one we had in Torbutton).
I don't know if it's due to the XPCOM changes that happened between 102 and 115, or if it's just because of the various refactors.
Since we don't have a circuit display, the only way to notice this is going to different sites that show the IP address, and notice that they have the same one, but we'd expect them to be isolated.
Some Tor-friendly ones are:
- https://check.torproject.org/
- https://www.wtfismyip.com/
- https://myip.wtf/ (same as the previous one, but different FP domain for TBB :smile:)
- https://mullvad.net/en/check
When we finally start working on tests we should also have a test that checks circuit FPI.Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/35Create a telegram distributor for open invitations with rate limiting through...2024-01-08T15:49:44ZonyinyangCreate a telegram distributor for open invitations with rate limiting through the age of accountsFrom the [Lox Roadmap](https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/wikis/Lox-Roadmap) we want a telegram bot that can be used to request Lox open invitations.From the [Lox Roadmap](https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/wikis/Lox-Roadmap) we want a telegram bot that can be used to request Lox open invitations.onyinyangonyinyanghttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40998Prepare Mullvad Browser Alpha 13.5a22023-11-28T18:09:51ZrichardPrepare Mullvad Browser Alpha 13.5a2<details>
<summary>Explanation of variables</summary>
- `$(BUILD_SERVER)` : the server the main builder is using to build a mullvad-browser release
- `$(BUILDER)` : whomever is building the release on the $(BUILD_SERVER)
- **example...<details>
<summary>Explanation of variables</summary>
- `$(BUILD_SERVER)` : the server the main builder is using to build a mullvad-browser release
- `$(BUILDER)` : whomever is building the release on the $(BUILD_SERVER)
- **example** : `pierov`
- `$(STAGING_SERVER)` : the server the signer is using to to run the signing process
- `$(ESR_VERSION)` : the Mozilla defined ESR version, used in various places for building mullvad-browser tags, labels, etc
- **example** : `91.6.0`
- `$(MULLVAD_BROWSER_MAJOR)` : the Mullvad Browser major version
- **example** : `11`
- `$(MULLVAD_BROWSER_MINOR)` : the Mullvad Browser minor version
- **example** : either `0` or `5`; Alpha's is always `(Stable + 5) % 10`
- `$(MULLVAD_BROWSER_VERSION)` : the Mullvad Browser version in the format
- **example** : `12.5a3`, `12.0.3`
- `$(BUILD_N)` : a project's build revision within a its branch; this is separate from the `$(MULLVAD_BROWSER_BUILD_N)` value; many of the Firefox-related projects have a `$(BUILD_N)` suffix and may differ between projects even when they contribute to the same build.
- **example** : `build1`
- `$(MULLVAD_BROWSER_BUILD_N)` : the mullvad-browser build revision for a given Mullvad Browser release; used in tagging git commits
- **example** : `build2`
- **NOTE** : A project's `$(BUILD_N)` and `$(MULLVAD_BROWSER_BUILD_N)` may be the same, but it is possible for them to diverge. For **example** :
- if we have multiple Mullvad Browser releases on a given ESR branch the two will become out of sync as the `$(BUILD_N)` value will increase, while the `$(MULLVAD_BROWSER_BUILD_N)` value may stay at `build1` (but the `$(MULLVAD_BROWSER_VERSION)` will increase)
- if we have build failures unrelated to `mullvad-browser`, the `$(MULLVAD_BROWSER_BUILD_N)` value will increase while the `$(BUILD_N)` will stay the same.
- `$(MULLVAD_BROWSER_VERSION)` : the published Mullvad Browser version
- **example** : `11.5a6`, `11.0.7`
- `$(MB_BUILD_TAG)` : the `tor-browser-build` build tag used to build a given Mullvad Browser version
- **example** : `mb-12.0.7-build1`
</details>
**NOTE** It is assumed that the `tor-browser` alpha rebase and security backport tasks have been completed
**NOTE** This can/is often done in conjunction with the equivalent Tor Browser release prep issue
<details>
<summary>Building</summary>
### tor-browser-build: https://gitlab.torproject.org/tpo/applications/tor-browser-build.git
Mullvad Browser Alpha (and Nightly) are on the `main` branch
- [x] Update `rbm.conf`
- [x] `var/torbrowser_version` : update to next version
- [x] `var/torbrowser_build` : update to `$(MULLVAD_BROWSER_BUILD_N)`
- [x] `var/torbrowser_incremental_from` : update to previous Desktop version
- **NOTE**: We try to build incrementals for the previous 3 desktop versions except in the case of a watershed update
- **IMPORTANT**: Really *actually* make sure this is the previous Desktop version or else the `make mullvadbrowser-incrementals-*` step will fail
- [x] Update build configs
- [x] Update `projects/firefox/config`
- [x] `browser_build` : update to match `mullvad-browser` tag
- [ ] ***(Optional)*** `var/firefox_platform_version` : update to latest `$(ESR_VERSION)` if rebased
- [x] Update `projects/translation/config`:
- [x] run `make list_translation_updates-alpha` to get updated hashes
- [x] `steps/base-browser/git_hash` : update with `HEAD` commit of project's `base-browser` branch
- [ ] `steps/mullvad-browser/git_hash` : update with `HEAD` commit of project's `mullvad-browser` branch
- [x] Update common build configs
- [x] Check for NoScript updates here : https://addons.mozilla.org/en-US/firefox/addon/noscript
- [ ] ***(Optional)*** If new version available, update `noscript` section of `input_files` in `projects/browser/config`
- [ ] `URL`
- [ ] `sha256sum`
- [x] Check for uBlock-origin updates here : https://addons.mozilla.org/en-US/firefox/addon/ublock-origin/
- [x] ***(Optional)*** If new version available, update `ublock-origin` section of `input_files` in `projects/browser/config`
- [x] `URL`
- [x] `sha256sum`
- [x] Check for Mullvad Privacy Companion updates here : https://github.com/mullvad/browser-extension/releases
- [ ] ***(Optional)*** If new version available, update `mullvad-extension` section of `input_files` in `projects/browser/config`
- [ ] `URL`
- [ ] `sha256sum`
- [x] Update `ChangeLog-MB.txt`
- [x] Ensure ChangeLog-MB.txt is sync'd between alpha and stable branches
- [x] Check the linked issues: ask people to check if any are missing, remove the not fixed ones
- [x] Run `tools/fetch-changelogs.py $(TOR_BROWSER_VERSION)` or `tools/fetch-changelogs.py '#$(ISSUE_NUMBER)'`
- Make sure you have `requests` installed (e.g., `apt install python3-requests`)
- The first time you run this script you will need to generate an access token; the script will guide you
- [x] Copy the output of the script to the beginning of `ChangeLog-MB.txt` and update its output
- [x] Version
- [x] Browser Name
- [x] Release Date
- [x] Under `All Platforms` include any version updates for:
- NoScript
- uBlock-origin
- Mullvad Browser Extension
- Firefox
- [x] Open MR with above changes
- [x] Build the MR after initial review on at least two of:
- [x] Tor Project build machine
- [ ] Mullvad build machine
- [x] Local developer machine
- [x] Ensure builders have matching builds
- [x] Merge
- [x] Sign+Tag
- **NOTE** this must be done by one of:
- boklm
- dan
- ma1
- pierov
- richard
- [x] Run: `make mullvadbrowser-signtag-alpha`
- [x] Push tag to `origin`
</details>
<details>
<summary>QA</summary>
### send the build
- [ ] Email Mullvad QA: support@mullvad.net, rui@mullvad.net
<details>
<summary>email template</summary>
Subject:
New build: Mullvad Browser $(MULLVAD_BROWSER_VERION) (unsigned)
Body:
unsigned builds: https://tb-build-05.torproject.org/~$(BUILDER)/builds/mullvadbrowser/alpha/unsigned/$(MB_BUILD_TAG)
changelog:
...
</details>
- ***(Optional)*** Add additional information:
- [ ] Note any new functionality which needs testing
- [ ] Link to any known issues
</details>
<details>
<summary>Signing</summary>
### signing
- [x] Assign this issue to the signer, one of:
- boklm
- richard
- [x] On `$(STAGING_SERVER)`, ensure updated:
- [x] `tor-browser-build/tools/signing/set-config.hosts`
- `ssh_host_builder` : ssh hostname of machine with unsigned builds
- **NOTE** : `tor-browser-build` is expected to be in the `$HOME` directory)
- `ssh_host_linux_signer` : ssh hostname of linux signing machine
- [x] `tor-browser-build/tools/signing/set-config.rcodesign-appstoreconnect`
- `appstoreconnect_api_key_path` : path to json file containing appstoreconnect api key infos
- [x] `set-config.update-responses`
- `update_responses_repository_dir` : directory where you cloned `git@gitlab.torproject.org:tpo/applications/mullvad-browser-update-responses.git`
- [x] `tor-browser-build/tools/signing/set-config.tbb-version`
- `tbb_version` : mullvad browser version string, same as `var/torbrowser_version` in `rbm.conf` (examples: `11.5a12`, `11.0.13`)
- `tbb_version_build` : the tor-browser-build build number (if `var/torbrowser_build` in `rbm.conf` is `buildN` then this value is `N`)
- `tbb_version_type` : either `alpha` for alpha releases or `release` for stable releases
- [x] On `$(STAGING_SERVER)` in a separate `screen` session, ensure tor daemon is running with SOCKS5 proxy on the default port 9050
- [x] run do-all-signing script:
- `cd tor-browser-build/tools/signing/`
- `./do-all-signing.mullvadbrowser`
- **NOTE**: at this point the signed binaries should have been copied to `staticiforme`
- [x] Update `staticiforme.torproject.org`:
- From `screen` session on `staticiforme.torproject.org`:
- [x] Static update components : `static-update-component dist.torproject.org`
- [x] Remove old release data from `/srv/dist-master.torproject.org/htdocs/mullvadbrowser`
- [x] Static update components (again) : `static-update-component dist.torproject.org`
</details>
<details>
<summary>Publishing</summary>
### mullvad-browser (github): https://github.com/mullvad/mullvad-browser/
- [x] Assign this issue to someone with mullvad commit access, one of:
- richard
- [x] Push this release's associated `mullvad-browser.git` branch to github
- [x] Push this release's associated tags to github:
- [x] Firefox ESR tag
- **example** : `FIREFOX_102_12_0esr_BUILD1,`
- [x] `base-browser` tag
- **example** : `base-browser-102.12.0esr-12.0-1-build1`
- [x] `mullvad-browser` tag
- **example** : `mullvad-browser-102.12.0esr-12.0-1-build1`
- [x] Sign+Tag additionally the `mullvad-browser.git` `firefox` commit used in build:
- **Tag**: `$(MULLVAD_BROWSER_VERSION)`
- **example** : `12.5a7`
- **Message**: `$(ESR_VERSION)esr-based $(MULLVAD_BROWSER_VERSION)`
- **example** : `102.12.0esr-based 12.5a7`
- [x] Push tag to github
### email
- [x] Email Mullvad with release information: support@mullvad.net, rui@mullvad.net
<details>
<summary>email template</summary>
Subject:
New build: Mullvad Browser $(MULLVAD_BROWSER_VERION) (signed)
Body:
signed builds: https://dist.torproject.org/mullvadbrowser/$(MULLVAD_BROWSER_VERSION)
update_response hashes: $(MULLVAD_UPDATE_RESPONSES_HASH)
changelog:
...
</details>
</details>
<details>
<summary>Downstream</summary>
### notify packagers
- [ ] **(Optional, Once Mullvad Updates their Github Releases Page)** Email downstream consumers:
- **NOTE**: This is an optional step and only necessary close a major release/transition from alpha to stable, or if there are major packing changes these developers need to be aware of
<details>
<summary>email template</summary>
Hello!
Mullvad-Browser $(MULLVAD_BROWSER_VERSION) packages are available, so you should all update your respective downstream packages.
Release builds can be found here:
- https://github.com/mullvad/mullvad-browser/releases/tag/$(MULLVAD_BROWSER_VERSION)
</details>
- flathub package maintainer: proletarius101@protonmail.com
- arch package maintainer: bootctl@gmail.com
- nixOS package maintainer: dev@felschr.com
</details>richardrichardhttps://gitlab.torproject.org/tpo/community/support/-/issues/40129Update Forum guide:"Tor blocked in Russia - how to circumvent censorship"2023-11-04T02:03:55ZGusUpdate Forum guide:"Tor blocked in Russia - how to circumvent censorship"Let's review and update the Forum guide "Tor blocked in Russia - how to circumvent censorship".
https://forum.torproject.org/t/tor-blocked-in-russia-how-to-circumvent-censorship/982Let's review and update the Forum guide "Tor blocked in Russia - how to circumvent censorship".
https://forum.torproject.org/t/tor-blocked-in-russia-how-to-circumvent-censorship/982ninaninahttps://gitlab.torproject.org/tpo/community/hackweek/-/issues/29Document how to verify reproducibility of build of a mullvad/tor browser release2023-11-30T16:16:39ZboklmDocument how to verify reproducibility of build of a mullvad/tor browser release# About the project
* Contact: @boklm
* Chat: #tor-browser-dev on `irc.oftc.net`
* Video room: no
# Participants
- @boklm
# Summary
I think many users don't know that our builds are reproducible, or how they can rebuild to verify...# About the project
* Contact: @boklm
* Chat: #tor-browser-dev on `irc.oftc.net`
* Video room: no
# Participants
- @boklm
# Summary
I think many users don't know that our builds are reproducible, or how they can rebuild to verify that they get a matching build.
We could generate a `reproducible-build.txt` file in the release directory containing the following informations:
* which git repository to clone
* which commit to checkout
* which command to use to start the build
* which sha256sums to expect after the build finished
* how to remove embedded signatures from exe and mar files we publish to check that they match the unsigned build
# Skills
Need to know how to build Tor Browser.
# Links
* tpo/applications/tor-browser-build#40997Hackweek 2023boklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42214Fluent migration: security level2024-03-26T20:59:30ZhenryFluent migration: security levelMigrate "securityLevel.properties" to Fluent.Migrate "securityLevel.properties" to Fluent.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42211Fluent migration: new identity2024-03-21T09:57:00ZhenryFluent migration: new identityMigrate "newIdentity.properties" to Fluent.Migrate "newIdentity.properties" to Fluent.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42209Fluent migration: tor circuit2024-03-26T13:41:53ZhenryFluent migration: tor circuitMigrate tor circuit strings found in "torbutton.dtd" and "torbutton.properties" to Fluent.Migrate tor circuit strings found in "torbutton.dtd" and "torbutton.properties" to Fluent.henryhenryhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41373please update my key in the TPA keyring2023-11-07T15:39:49Ziwakehplease update my key in the TPA keyringMy key is available here:
https://keys.openpgp.org/search?q=iwakeh%40torproject.org
or
https://pgp.mit.edu/pks/lookup?search=iwakeh%40torproject.org&op=index
Many thanks,
iwakehMy key is available here:
https://keys.openpgp.org/search?q=iwakeh%40torproject.org
or
https://pgp.mit.edu/pks/lookup?search=iwakeh%40torproject.org&op=index
Many thanks,
iwakehanarcatanarcathttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42203Fluent migration: about dialog2024-03-21T13:33:26ZhenryFluent migration: about dialogMigrate "aboutDialog.dtd" to Fluent.Migrate "aboutDialog.dtd" to Fluent.henryhenryhttps://gitlab.torproject.org/tpo/web/manual/-/issues/152Add front desk and cdr.link office hours2024-02-26T17:00:16ZGusAdd front desk and cdr.link office hourshttps://forum.torproject.org/t/psa-updated-tor-user-support-office-hours-2023/9926https://forum.torproject.org/t/psa-updated-tor-user-support-office-hours-2023/9926ebanamebanam@torproject.orgebanamebanam@torproject.orghttps://gitlab.torproject.org/tpo/team/-/issues/228October report for s1452023-11-27T12:14:33ZGabagaba@torproject.orgOctober report for s145https://gitlab.torproject.org/tpo/tpa/team/-/issues/41370whatsapp user in rdsys-frontend-012023-11-13T15:22:47Zmeskiomeskio@torproject.orgwhatsapp user in rdsys-frontend-01I will need a user 'whatsapp' in rdsys-frontend-01 to deploy the whatsapp gettor bot. Everybody from anti-censorship team should have sudo access to it (@cohosh, @meskio, @onyinyang and @shelikhoo).
Thank you.I will need a user 'whatsapp' in rdsys-frontend-01 to deploy the whatsapp gettor bot. Everybody from anti-censorship team should have sudo access to it (@cohosh, @meskio, @onyinyang and @shelikhoo).
Thank you.Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/web/donate-static/-/issues/132Remove / move links on donate.tpo2023-10-31T17:58:09Zal smithRemove / move links on donate.tpoHopefully this is an easy modification that will make a big difference in information clarity.
1. Please remove "Donate more than $1000 and become a Champion of Privacy!" -> this is not a motivator for folks to donate at the moment, we ...Hopefully this is an easy modification that will make a big difference in information clarity.
1. Please remove "Donate more than $1000 and become a Champion of Privacy!" -> this is not a motivator for folks to donate at the moment, we very rarely see unsolicited $1K donations.
2. Please add either a button or a link to "CRYPTOCURRENCY" (https://donate.torproject.org) under the HOW WOULD YOU LIKE TO DONATE header. This is by far the most frequent question we are asked on social / by email -- "why don't you accept cryptocurrency!" -- we need to increase the visibility of this information, otherwise we're missing out on donations.
![signal-2023-10-25-101821_002](/uploads/f6dd6b168f51380e47a98a09a26dbe19/signal-2023-10-25-101821_002.png)
cc: @anarcatJérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/community/hackweek/-/issues/22Arti key manager documentation2023-11-30T16:16:39Zgabi-250Arti key manager documentation# About the project
* Contact: @gabi-250
* Chat: #tor-dev on `irc.oftc.net`
* Video room: TBD
# Participants
- @gabi-250
- etc
# Summary
The Arti team has been implementing a key management backend for handling the
various keys a...# About the project
* Contact: @gabi-250
* Chat: #tor-dev on `irc.oftc.net`
* Video room: TBD
# Participants
- @gabi-250
- etc
# Summary
The Arti team has been implementing a key management backend for handling the
various keys and certificates required by Arti to operate (see
https://gitlab.torproject.org/tpo/core/arti/-/issues/728 for a brief
overview).
The projects I'm proposing here aim to improve the various bits of documentation related to key
management in Arti.
## Project A: Set up a protocol name registry
The main (and currently only) Arti key store is an on-disk store that stores
keys in OpenSSH key format.
Some of the key types we need to support don't have a
predefined SSH public key [algorithm name], so we've had to
define several custom SSH algorithm names (for example, we have a custom
algorithm name for x25519 keys, which don't have a predefined algorithm name).
See
https://gitlab.torproject.org/tpo/core/arti/-/issues/936 and
https://gitlab.torproject.org/tpo/core/arti/-/issues/1049 for more details.
As per [RFC4251 § 6], our custom ssh algorithm names use the
`<something@subdomain.torproject.org>` format.
**In order to manage the local
namespacing of our (Tor Project's) custom SSH algorithm names, we will need a
protocol name registry**. This protocol name registry will live in
[torspec](https://gitlab.torproject.org/tpo/core/torspec) repo.
This [comment] lists the algorithm strings that will need to be documented, and
can be used as a starting point for this project.
## Project B: Improve documentation in the tor-keymgr crate
I think the documentation of the `tor-keymgr` crate could use some improvements:
* the `ArtiNativeKeystore` docs are very sparse (i.e. we should at least
document the key format it's using)
* it would be nice to have some docs explaining how to implement a custom key
store
* it would be nice to have some docs explaining how to mock a `Keystore`
* etc
## Project C: Document Arti's future key management CLI
We will eventually want to have a CLI for managing keys in Arti.
We should document various use-cases for it, and the corresponding command
invocation (i.e. its arguments).
(This may or may not be within the scope of Hackweek).
# Skills
* Git/GitLab.
* Markdown.
* Writing documentation.
Project A requires some knowledge (or willingness to learn) about
the OpenSSH key format used for keys stored in the Arti key store.
Project B requires some knowledge (or willingness to learn) about
the internals of Arti's key manager/key store implementations.
# Links
* a sketch of the [key manager/keystore
APIs](https://gitlab.torproject.org/tpo/core/arti/-/blob/8598f8902ed76d3302701934b86bb54b74a4326f/doc/dev/notes/key-management.md)
we have in Arti
* the currently supported key types are listed
[here](https://gitlab.torproject.org/tpo/core/arti/-/blob/8598f8902ed76d3302701934b86bb54b74a4326f/doc/dev/notes/key-management-paths.md)
* a more comprehensive (but somewhat out of date) list of keys that we want to
support can be found
[here](https://gitlab.torproject.org/tpo/core/arti/-/blob/8598f8902ed76d3302701934b86bb54b74a4326f/doc/dev/notes/key-management-keygen.md)
[algorithm name]: https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-19
[RFC4251 § 6]: https://www.rfc-editor.org/rfc/rfc4251.html#section-6
[comment]: https://gitlab.torproject.org/tpo/core/arti/-/blob/8598f8902ed76d3302701934b86bb54b74a4326f/crates/tor-keymgr/src/key_type/ssh.rs#L22-91Hackweek 2023gabi-250gabi-250