The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-02-22T14:52:08Zhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1161"Missing previous key" warnings on restarting onion service2024-02-22T14:52:08ZNick Mathewson"Missing previous key" warnings on restarting onion serviceSometimes (but not always) when I restart an onion service, I get a bunch of warnings like this:
```
2023-12-13T13:25:58Z ERROR tor_hsservice::ipt_mgr: HS service hewwo missing previous key ArtiPath("hs/hewwo/ipts/k_hss_ntor+398509d88033...Sometimes (but not always) when I restart an onion service, I get a bunch of warnings like this:
```
2023-12-13T13:25:58Z ERROR tor_hsservice::ipt_mgr: HS service hewwo missing previous key ArtiPath("hs/hewwo/ipts/k_hss_ntor+398509d88033d16af8ef891fd3970d6f189e4a215ea6b40ebab6ea080c29dad4"), regenerating
2023-12-13T13:25:58Z ERROR tor_hsservice::ipt_mgr: HS service hewwo missing previous key ArtiPath("hs/hewwo/ipts/k_sid+398509d88033d16af8ef891fd3970d6f189e4a215ea6b40ebab6ea080c29dad4"), regenerating
2023-12-13T13:25:58Z ERROR tor_hsservice::ipt_mgr: HS service hewwo missing previous key ArtiPath("hs/hewwo/ipts/k_hss_ntor+44b23ce9420e67a94dd88c5529832adcaee6f8af227382e6d41daf643ca5ee82"), regenerating
2023-12-13T13:25:58Z ERROR tor_hsservice::ipt_mgr: HS service hewwo missing previous key ArtiPath("hs/hewwo/ipts/k_sid+44b23ce9420e67a94dd88c5529832adcaee6f8af227382e6d41daf643ca5ee82"), regenerating
2023-12-13T13:25:58Z ERROR tor_hsservice::ipt_mgr: HS service hewwo missing previous key ArtiPath("hs/hewwo/ipts/k_hss_ntor+3c8775e01e11ed6f6ea72a8057f425253d4584d7ff52c0487fbf88ffa32b18d3"), regenerating
2023-12-13T13:25:58Z ERROR tor_hsservice::ipt_mgr: HS service hewwo missing previous key ArtiPath("hs/hewwo/ipts/k_sid+3c8775e01e11ed6f6ea72a8057f425253d4584d7ff52c0487fbf88ffa32b18d3"), regenerating
```
There are two problems here:
First, these should not be at `ERROR`: We should only use ERROR for fatal problems.
Second, they really shouldn't be happening.
@diziet @gabi-250 Any idea what's up here?Ian Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/tpa/status-site/-/issues/39consider embedding cstate in our common web headers2023-12-12T15:04:53Zanarcatconsider embedding cstate in our common web headersSince cstate 5.5.2, we can embed it in other websites magically:
https://github.com/cstate/html-embed
There are two UIs, the dot indicator ([example](https://cstate-embed.pages.dev/dot-indicator)) and a [popup](https://cstate-embed.pag...Since cstate 5.5.2, we can embed it in other websites magically:
https://github.com/cstate/html-embed
There are two UIs, the dot indicator ([example](https://cstate-embed.pages.dev/dot-indicator)) and a [popup](https://cstate-embed.pages.dev/dialog).
I'm not super sure where it would be best to fit this, we don't seem to link to the status page from the main frontpage for starters... maybe it could go in the bottom footer, next to "Contact"?
Maybe the "dot" UI could be used in the common footer, and a popup could be added on support.tpo?
@donuts @kez @lavamind opinions?https://gitlab.torproject.org/tpo/web/team/-/issues/49test- and staging- sites are indexed by google2024-01-09T19:47:34ZKeztest- and staging- sites are indexed by googlein donate#13 mattlav discovered that google is indexing our testing and staging sites, and sometimes a search returns results for one of those sites instead of our actual production sites.
we should modify the robots.txt files for these...in donate#13 mattlav discovered that google is indexing our testing and staging sites, and sometimes a search returns results for one of those sites instead of our actual production sites.
we should modify the robots.txt files for these sites to block indexing across the entire sitehttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41038Add RPM dependencies to README2024-01-31T09:52:09ZNoisyCoilAdd RPM dependencies to READMEAs mentioned in #40644, the Tor Browser (both v13.0 and v13.5) currently builds on Fedora without issues. It would be nice to see the needed RPM build dependencies added to [README](README). In attachment you'll find a patch that does th...As mentioned in #40644, the Tor Browser (both v13.0 and v13.5) currently builds on Fedora without issues. It would be nice to see the needed RPM build dependencies added to [README](README). In attachment you'll find a patch that does that.
Again as mentioned in #40644, `newuidmap` and `newgidmap` come pre-installed with the `shadow-utils` package in Fedora 39, so they certainly don't need to be installed separately. `perl-ph`, on the other hand, contains the `.ph` headers which one would otherwise generate using `h2ph`, as documented for Arch Linux.
[0001-Add-RPM-dependencies-to-README.patch](/uploads/8af7a7a7b307b65cf8ce6e4ca1642950/0001-Add-RPM-dependencies-to-README.patch)NoisyCoilNoisyCoilhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41033Prepare Tor Browser Stable 13.0.82023-12-21T16:38:32ZPier Angelo VendramePrepare Tor Browser Stable 13.0.8<details>
<summary>Explanation of variables</summary>
- `$(BUILD_SERVER)` : the server the main builder is using to build a tor-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 tor-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 tor-browser tags, labels, etc
- **example** : `91.6.0`
- `$(TOR_BROWSER_MAJOR)` : the Tor Browser major version
- **example** : `11`
- `$(TOR_BROWSER_MINOR)` : the Tor Browser minor version
- **example** : either `0` or `5`; Alpha's is always `(Stable + 5) % 10`
- `$(TOR_BROWSER_VERSION)` : the Tor 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 `$(TOR_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`
- `$(TOR_BROWSER_BUILD_N)` : the tor-browser build revision for a given Tor Browser release; used in tagging git commits
- **example** : `build2`
- **NOTE** : A project's `$(BUILD_N)` and `$(TOR_BROWSER_BUILD_N)` may be the same, but it is possible for them to diverge. For example :
- if we have multiple Tor Browser releases on a given ESR branch the two will become out of sync as the `$(BUILD_N)` value will increase, while the `$(TOR_BROWSER_BUILD_N)` value may stay at `build1` (but the `$(TOR_BROWSER_VERSION)` will increase)
- if we have build failures unrelated to `tor-browser`, the `$(TOR_BROWSER_BUILD_N)` value will increase while the `$(BUILD_N)` will stay the same.
- `$(TOR_BROWSER_VERSION)` : the published Tor Browser version
- **example** : `11.5a6`, `11.0.7`
- `$(TBB_BUILD_TAG)` : the `tor-browser-build` build tag used to build a given Tor Browser version
- **example** : `tbb-12.0.7-build1`
</details>
**NOTE** It is assumed that the `tor-browser` stable rebase and security backport tasks have been completed
<details>
<summary>Building</summary>
### tor-browser-build: https://gitlab.torproject.org/tpo/applications/tor-browser-build.git
Tor Browser Stable lives in the various `maint-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)` (and possibly more specific) branches
- [x] Update `rbm.conf`
- [x] `var/torbrowser_version` : update to next version
- [x] `var/torbrowser_build` : update to `$(TOR_BROWSER_BUILD_N)`
- [x] ***(Desktop Only)***`var/torbrowser_incremental_from` : update to previous Desktop version
- **IMPORTANT**: Really *actually* make sure this is the previous Desktop version or else the `make torbrowser-incrementals-*` step will fail
- [ ] Update Desktop-specific build configs
- [ ] Update `projects/firefox/config`
- [ ] `browser_build` : update to match `tor-browser` tag
- [ ] ***(Optional)*** `var/firefox_platform_version` : update to latest `$(ESR_VERSION)` if rebased
- [ ] Update `projects/translation/config`:
- [ ] run `make list_translation_updates-release` to get updated hashes
- [ ] `steps/base-browser/git_hash` : update with `HEAD` commit of project's `base-browser` branch
- [ ] `steps/base-browser-fluent/git_hash` : update with `HEAD` commit of project's `basebrowser-newidentityftl` branch
- [ ] `steps/tor-browser/git_hash` : update with `HEAD` commit of project's `tor-browser` branch
- [ ] `steps/fenix/git_hash` : update with `HEAD` commit of project's `fenix-torbrowserstringsxml` branch
- [ ] Update Android-specific build configs
- [ ] Update `projects/geckoview/config`
- [ ] `browser_build` : update to match `tor-browser` tag
- [ ] ***(Optional)*** `var/geckoview_version` : update to latest `$(ESR_VERSION)` if rebased
- [ ] ***(Optional)*** Update `projects/tor-android-service/config`
- [ ] `git_hash` : update with `HEAD` commit of project's `main` branch
- [ ] ***(Optional)*** Update `projects/application-services/config`:
**NOTE** we don't currently have any of our own patches for this project
- [ ] `git_hash` : update to appropriate git commit associated with `$(ESR_VERSION)`
- [ ] ***(Optional)*** Update `projects/android-components/config`:
- [ ] `android_components_build` : update to match stable android-components tag
- [ ] ***(Optional)*** Update `projects/fenix/config`
- [ ] `fenix_build` : update to match fenix tag
- [ ] Update allowed_addons.json by running (from `tor-browser-build` root):
- `./tools/fetch_allowed_addons.py > projects/browser/allowed_addons.json`
- [ ] Update common build configs
- [ ] 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`
- [ ] Check for OpenSSL updates here : https://www.openssl.org/source/
- [ ] ***(Optional)*** If new 1.X.Y version available, update `projects/openssl/config`
- [ ] `version` : update to next 1.X.Y version
- [ ] `input_files/sha256sum` : update to sha256 sum of source tarball
- [ ] Check for zlib updates here: https://github.com/madler/zlib/releases
- [ ] **(Optional)** If new tag available, update `projects/zlib/config`
- [ ] `version` : update to next release tag
- [ ] Check for tor updates here : https://gitlab.torproject.org/tpo/core/tor/-/tags
- [ ] ***(Optional)*** Update `projects/tor/config`
- [ ] `version` : update to latest non `-alpha` tag (ping dgoulet or ahf if unsure)
- [ ] Check for go updates here : https://golang.org/dl
- **NOTE** : Tor Browser Stable uses the latest of the *previous* Stable major series go version (apart from the transition phase from Tor Browser Alpha to Stable, in which case Tor Browser Stable may use the latest major series go version)
- [ ] ***(Optional)*** Update `projects/go/config`
- [ ] `version` : update go version
- [ ] `input_files/sha256sum` for `go` : update sha256sum of archive (sha256 sums are displayed on the go download page)
- [ ] Check for manual updates by running (from `tor-browser-build` root): `./tools/fetch-manual.py`
- [ ] ***(Optional)*** If new version is available:
- [ ] Upload the downloaded `manual_$PIPELINEID.zip` file to `tb-build-02.torproject.org`
- [ ] Deploy to `tb-builder`'s `public_html` directory:
- `sudo -u tb-builder cp manual_$PIPELINEID.zip ~/../tb-builder/public_html/.`
- [ ] Update `projects/manual/config`:
- [ ] Change the `version` to `$PIPELINEID`
- [ ] Update `sha256sum` in the `input_files` section
- [x] Update `ChangeLog.txt`
- [x] Ensure ChangeLog.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.txt` and adjust its output
- **NOTE** : If you used the issue number, you will need to write the Tor Browser version manually
- [ ] ***(Optional)*** Under `All Platforms` include any version updates for:
- [ ] Translations
- [ ] OpenSSL
- [ ] NoScript
- [ ] zlib
- [ ] tor daemon
- [ ] ***(Optional)*** Under `Windows + macOS + Linux` include updates for:
- [ ] Firefox
- [ ] ***(Optional)*** Under `Android`, include updates for:
- [ ] Geckoview
- [ ] ***(Optional)*** Under `Build System/All Platforms` include updates for:
- [ ] Go
- [x] Open MR with above changes
- [x] Merge
- [x] Sign/Tag commit: `make torbrowser-signtag-release`
- [x] Push tag to `origin`
- [x] Build on at least one of:
- Run `make torbrowser-release && make torbrowser-incrementals-release`
- [x] Tor Project build machine
- [x] Local developer machine
- [x] Submit build request to Mullvad infrastructure:
- **NOTE** this requires a devmole authentication token
- Run `make torbrowser-kick-devmole-build`
- [x] Ensure builders have matching builds
</details>
<details>
<summary>Communications</summary>
### notify stakeholders
<details>
<summary>email template</summary>
Subject:
Tor Browser $(TOR_BROWSER_VERION) (Android, Windows, macOS, Linux)
Body:
Hello All,
Unsigned Tor Browser $(TOR_BROWSER_VERSION) release candidate builds are now available for testing:
- https://tb-build-05.torproject.org/~$(BUILDER)/builds/release/unsigned/$(TOR_BROWSER_VERSION)/
The full changelog can be found here:
- https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/blob/$(TBB_BUILD_TAG)/ChangeLog.txt
</details>
- [ ] Email tor-qa mailing list: tor-qa@lists.torproject.org
- ***(Optional)*** Additional information:
- [ ] Note any new functionality which needs testing
- [ ] Link to any known issues
- [x] Email packagers:
- Recipients:
- Tails dev mailing list: tails-dev@boum.org
- Guardian Project: nathan@guardianproject.info
- torbrowser-launcher: micah@micahflee.com
- FreeBSD port: freebsd@sysctl.cz <!-- Gitlab user maxfx -->
- OpenBSD port: caspar@schutijser.com <!-- Gitlab user cschutijser -->
- [ ] ***(Optional)*** Note any changes which may affect packaging/downstream integration
</details>
<details>
<summary>Signing</summary>
### signing
- **NOTE** : In practice, it's most efficient to have the blog post and website updates ready to merge, since signing doesn't take very long
- [x] On `$(STAGING_SERVER)`, ensure updated:
- [x] `tor-browser-build` is on the right commit: `git tag -v tbb-$(TOR_BROWSER_VERSION)-$(TOR_BROWSER_BUILD_N) && git checkout tbb-$(TOR_BROWSER_VERSION)-$(TOR_BROWSER_BUILD_N)`
- [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/tor-browser-update-responses.git`
- [x] `tor-browser-build/tools/signing/set-config.tbb-version`
- `tbb_version` : tor 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.torbrowser`
- **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 cdn.torproject.org && static-update-component dist.torproject.org`
- [x] Enable update responses : `sudo -u tb-release ./deploy_update_responses-release.sh`
- [x] Remove old release data from following places:
- **NOTE** : Skip this step if we need to hold on to older versions for some reason (for example, this is an Andoid or Desktop-only release, or if we need to hold back installers in favor of build-to-build updates if there are signing issues, etc)
- [x] `/srv/cdn-master.torproject.org/htdocs/aus1/torbrowser`
- [ ] `/srv/dist-master.torproject.org/htdocs/torbrowser`
- [x] Static update components (again) : `static-update-component cdn.torproject.org && static-update-component dist.torproject.org`
- [ ] Publish APKs to Google Play:
- Log into https://play.google.com/apps/publish
- Select `Tor Browser` app
- Navigate to `Release > Production` and click `Create new release` button:
- Upload the `tor-browser-android-*.apk` APKs
- Update Release Name to Tor Browser version number
- Update Release Notes
- Next to 'Release notes', click `Copy from a previous release`
- Edit blog post url to point to most recent blog post
- Save, review, and configure rollout percentage
- [ ] 25% rollout when publishing a scheduled update
- [ ] 100% rollout when publishing a security-driven release
- [ ] Update rollout percentage to 100% after confirmed no major issues
</details>
<details>
<summary>Signature verification</summary>
<details>
<summary>Check whether the .exe files got properly signed and timestamped</summary>
```
# Point OSSLSIGNCODE to your osslsigncode binary
pushd tor-browser-build/${channel}/signed/$TORBROWSER_VERSION
OSSLSIGNCODE=/path/to/osslsigncode
../../../tools/authenticode_check.sh
popd
```
</details>
<details>
<summary>Check whether the MAR files got properly signed</summary>
```
# Point NSSDB to your nssdb containing the mar signing certificate
# Point SIGNMAR to your signmar binary
# Point LD_LIBRARY_PATH to your mar-tools directory
pushd tor-browser-build/${channel}/signed/$TORBROWSER_VERSION
NSSDB=/path/to/nssdb
SIGNMAR=/path/to/mar-tools/signmar
LD_LIBRARY_PATH=/path/to/mar-tools/
../../../tools/marsigning_check.sh
popd
```
</details>
</details>
<details>
<summary>Publishing</summary>
### website: https://gitlab.torproject.org/tpo/web/tpo.git
- [x] `databags/versions.ini` : Update the downloads versions
- `torbrowser-stable/version` : sort of a catch-all for latest stable version
- `torbrowser-alpha/version` : sort of a catch-all for latest stable version
- `torbrowser-*-stable/version` : platform-specific stable versions
- `torbrowser-*-alpha/version` : platform-specific alpha versions
- `tor-stable`,`tor-alpha` : set by tor devs, do not touch
- [x] Push to origin as new branch, open 'Draft :' MR
- [x] Remove `Draft:` from MR once signed-packages are uploaded
- [x] Merge
- [x] Publish after CI passes and builds are published
### blog: https://gitlab.torproject.org/tpo/web/blog.git
- [x] Duplicate previous Stable or Alpha release blog post as appropriate to new directory under `content/blog/new-release-tor-browser-$(TOR_BROWSER_VERSION)` and update with info on release :
- [x] Run `tools/signing/create-blog-post` which should create the new blog post from a template (edit set-config.blog to set you local blog directory)
- [ ] Update Tor Browser version numbers
- [ ] Note any ESR rebase
- [ ] Link to any Firefox security updates from ESR upgrade
- [ ] Link to any Android-specific security backports
- [ ] Note any updates to :
- tor
- OpenSSL
- NoScript
- [ ] Convert ChangeLog.txt to markdown format used here by :
- `tor-browser-build/tools/changelog-format-blog-post`
- [x] Push to origin as new branch, open `Draft:` MR
- [x] Remove `Draft:` from MR once signed-packages are uploaded
- [x] Merge
- [x] Publish after CI passes and website has been updated
### tor-announce mailing list
<details>
<summary>email template</summary>
Subject:
New Release: Tor Browser $(TOR_BROWSER_VERSION) (Android, Windows, macOS, Linux)
Body:
Hi everyone,
Tor Browser $(TOR_BROWSER_VERSION) has now been published for all platforms. For details please see our blog post:
- $(BLOG_POST_URL)
</details>
- [x] Email tor-announce mailing list: tor-announce@lists.torproject.org
- **(Optional)** Additional information:
- [x] Link to any known issues
</details>https://gitlab.torproject.org/tpo/tpa/status-site/-/issues/38fix upstream release tracking2023-12-11T20:46:25Zanarcatfix upstream release trackingIn https://gitlab.torproject.org/tpo/tpa/status-site/-/merge_requests/48, renovate figured out there was something new in the report, and issued a merge request. While that's somewhat useful, it's going to be too noisy for us: we don't w...In https://gitlab.torproject.org/tpo/tpa/status-site/-/merge_requests/48, renovate figured out there was something new in the report, and issued a merge request. While that's somewhat useful, it's going to be too noisy for us: we don't want to upgrade deps every time upstream makes a commit. We want to chase releases.
It's not clear to me how to do this with submodules, so some more research might be required. Another option is to drop renovate here completely and roll our own git checker for tags. Or implement that in renovate ourselves.
For now I've closed !48 so we shouldn't be bugged about that *particular* upgrade, but I think before long we'll have another MR about another upstream commit, so we'll want to figure out a better way soon.https://gitlab.torproject.org/tpo/core/arti/-/issues/1140Better approach for using WalkDir with fs-mistrust2023-11-28T20:35:11ZNick MathewsonBetter approach for using WalkDir with fs-mistrustThis is not urgent, but we should provide a better way to use `fs-mistrust` with `walkdir`.
See discussion at https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1769?commit_id=b0101894eff82baa26dd066c00e4dd6027965c9e#note_297...This is not urgent, but we should provide a better way to use `fs-mistrust` with `walkdir`.
See discussion at https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1769?commit_id=b0101894eff82baa26dd066c00e4dd6027965c9e#note_2970121 for background and the current good-enough-for-now approach.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42305(Semi-)Automatically merge translation resources across tor browser releases ...2024-03-26T20:31:08Zhenry(Semi-)Automatically merge translation resources across tor browser releases (desktop)/cc @emmapeel @pierov
When I had my time offline the week before last I wrote a script to which takes a `tor-browser` or `firefox-android` translation file (`.dtd`, `.properties`, `.ftl`, or android `.xml`), and a new and an old branch.../cc @emmapeel @pierov
When I had my time offline the week before last I wrote a script to which takes a `tor-browser` or `firefox-android` translation file (`.dtd`, `.properties`, `.ftl`, or android `.xml`), and a new and an old branch name, and merges the versions found in both branches together with a comment added for strings that will be dropped at the next release. Here is the initial draft of the script if you want a quick look: [combine-translation-versions.py](/uploads/83cf1424566cf3b3222e6a60682bcc56/combine-translation-versions.py)
We could use the output as the `en-US` source files for weblate, combining both the strings needed for the next release as well as for the current stable release. The idea being that in tor-browser we can stop trying to maintain all the old strings in the current development branch that are still needed for the current stable release. And we can avoid having to manual clean ups of old strings, like in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42221.
E.g., if we have `tor-browser.ftl` in tor-browser-xxx-13.5 with the content
```
string1 = String 1
new-string = New String
string2 = String 2
```
and in tor-browser-xxx-13.0 with the content
```
old-string = Old String
string1 = String 1
string2 = String 2
```
the script would output
```
string1 = String 1
new-string = New String
string2 = String 2
## Will be unused in Tor Browser 13.5!
old-string = Old String
```
The reason I add the comment is to provide a little notification to weblate translators in the "Source string description" to let them know that a string has a short lifetime. Weblate doesn't support descriptions for `.dtd` though so it won't work for that format.
@emmapeel and @pierov what do you think? And where would we want to run this script?
I guess we basically want to merge the translations files from both the branch used for current nightly and current stable. I'm not sure if this can be automatically pulled from `tor-browser-build` in a convenient way, or whether we would need some manual input.henryhenryhttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/39Make lox-distributor listening port configurable2024-01-22T15:15:35ZCecylia BocovichMake lox-distributor listening port configurableRight now we have the lox distributor [hard-coded to listen on port 8001](https://gitlab.torproject.org/tpo/anti-censorship/lox/-/blob/main/crates/lox-distributor/src/main.rs?ref_type=heads#L351). We should make this configurable.Right now we have the lox distributor [hard-coded to listen on port 8001](https://gitlab.torproject.org/tpo/anti-censorship/lox/-/blob/main/crates/lox-distributor/src/main.rs?ref_type=heads#L351). We should make this configurable.https://gitlab.torproject.org/tpo/core/arti/-/issues/1134Create new introduction circuit when DosParams changes2024-02-22T14:55:45ZNick MathewsonCreate new introduction circuit when DosParams changesWhen the DosParams extension changes, we should create new circuits to our introduction points with the updated value.
From a comment introduced in arti!1740:
```rust
// TODO HSS:
//
// We want to make a new introduction ci...When the DosParams extension changes, we should create new circuits to our introduction points with the updated value.
From a comment introduced in arti!1740:
```rust
// TODO HSS:
//
// We want to make a new introduction circuit if our dos parameters change,
// which means that we should possibly be watching for changes in our
// configuration. Right now, though, we only copy out the configuration
// on startup.
```Arti: Onion service supporthttps://gitlab.torproject.org/tpo/core/arti/-/issues/1132Make sure the publisher handles upload failures gracefully2023-12-04T18:01:18Zgabi-250Make sure the publisher handles upload failures gracefully```
// TODO HSS: if upload_all fails, we don't reattempt the upload until a state
// change is triggered by an external event (such as a consensus or IPT change)
``````
// TODO HSS: if upload_all fails, we don't reattempt the upload until a state
// change is triggered by an external event (such as a consensus or IPT change)
```Arti: Onion service supportgabi-250gabi-250https://gitlab.torproject.org/tpo/core/arti/-/issues/1130Revisit descriptor publisher rate-limiting logic2023-12-04T18:01:18Zgabi-250Revisit descriptor publisher rate-limiting logicWe have several TODOs about deciding whether our current rate-limiting approach is good enough, or if we should rate-limit uploads on a per-hsdir basis.We have several TODOs about deciding whether our current rate-limiting approach is good enough, or if we should rate-limit uploads on a per-hsdir basis.Arti: Onion service supportgabi-250gabi-250https://gitlab.torproject.org/tpo/core/arti/-/issues/1128Use a postage::watch channel for receiving onion svc config changes in publis...2024-01-11T18:46:12Zgabi-250Use a postage::watch channel for receiving onion svc config changes in publisher.~~This is needed by the publisher (if the config changes, it may need to republish the descriptor).~~
This now exists, and just needs to get used.~~This is needed by the publisher (if the config changes, it may need to republish the descriptor).~~
This now exists, and just needs to get used.Arti: Onion service supporthttps://gitlab.torproject.org/tpo/core/arti/-/issues/1126Consider making arti_pattern() usable more generally2024-01-13T21:11:31Zgabi-250Consider making arti_pattern() usable more generallyContext https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1733#note_2966402Context https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1733#note_2966402Arti: Onion service supportgabi-250gabi-250https://gitlab.torproject.org/tpo/core/arti/-/issues/1123Descriptor publisher status2024-01-09T16:43:48Zgabi-250Descriptor publisher statusImplement `Publisher::status()`.Implement `Publisher::status()`.Arti: Onion service supportgabi-250gabi-250https://gitlab.torproject.org/tpo/core/arti/-/issues/1122Review descriptor publisher docs2024-01-29T14:58:49Zgabi-250Review descriptor publisher docsArti: Onion service supportgabi-250gabi-250https://gitlab.torproject.org/tpo/core/arti/-/issues/1116Create a KeyDenotatorViaFromStrAndDisplay helper trait or d-a macro2023-12-07T19:03:31Zgabi-250Create a KeyDenotatorViaFromStrAndDisplay helper trait or d-a macroArti: Onion service supportgabi-250gabi-250https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42272Use a single QR code for multiple traditional bridge lines (≤3)2024-01-30T15:01:17ZdonutsUse a single QR code for multiple traditional bridge lines (≤3)See https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036/designs/lox-qr.png.See https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036/designs/lox-qr.png.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42271Transition non-Lox bridges (i.e. built-in, requested, added) to use the new b...2024-01-30T15:01:22ZdonutsTransition non-Lox bridges (i.e. built-in, requested, added) to use the new bridge card formatSee the Figma file: [Figma / Tor Browser 13.5 / lox](https://www.figma.com/file/rWgMwiiFTDFp4ujuP3PKbq/Tor-Browser-13.5?type=design&node-id=151%3A9289&mode=design&t=wDYnw2iq2A868OmH-1)See the Figma file: [Figma / Tor Browser 13.5 / lox](https://www.figma.com/file/rWgMwiiFTDFp4ujuP3PKbq/Tor-Browser-13.5?type=design&node-id=151%3A9289&mode=design&t=wDYnw2iq2A868OmH-1)henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42266Create "Find more bridges" sub-section within bridge settings2024-01-30T15:00:25ZdonutsCreate "Find more bridges" sub-section within bridge settingsSee: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036/designs/lox-not-connected.pngSee: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036/designs/lox-not-connected.pnghenryhenry