Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found

Target

Select target project
  • cohosh/tor-browser-build
  • seb/tor-browser-build
  • Cortex65/tor-browser-build
  • gus/tor-browser-build
  • shelikhoo/tor-browser-build-2
  • meskio/tor-browser-build
  • msimonelli/tor-browser-build
  • dcf/tor-browser-build
  • ma1/tor-browser-build
  • dragjkngj/tor-browser-build
  • aguestuser/tor-browser-build
  • phw/tor-browser-build
  • yanmaani/tor-browser-build
  • acat/tor-browser-build
  • gk/tor-browser-build
  • boklm/tor-browser-build
  • tpo/applications/tor-browser-build
  • brade/tor-browser-build
  • sysrqb/tor-browser-build
  • JeremyRand/tor-browser-build
  • pierov/tor-browser-build
  • jla2040/tor-browser-build
  • dan/tor-browser-build
  • Sushrut1101/tor-browser-build
  • guest475646844/tor-browser-build
  • morgan/tor-browser-build
  • FlexFoot/tor-browser-build
  • Mynacol/tor-browser-build
  • NoisyCoil/tor-browser-build
  • murmelurmel/tor-browser-build
  • rustybird/tor-browser-build
  • jwilde/tor-browser-build
  • onyinyang/tor-browser-build
  • securitybrahh/tor-browser-build
  • Noino/tor-browser-build
  • ahf/tor-browser-build
  • cypherpunks1/tor-browser-build
  • henry/tor-browser-build
  • brizental/tor-browser-build
39 results
Show changes
Commits on Source (819)
719 additional commits have been omitted to prevent performance issues.
Expand all Hide whitespace changes
Inline Side-by-side
Showing
with 2287 additions and 582 deletions
.gitignore
View file @ 136839a7
......@@ -2,10 +2,19 @@
/hg_clones
/gclient
/out
/release
/alpha
/nightly
/torbrowser
/basebrowser
/mullvadbrowser
/testbuild
/rbm.local.conf
/logs
/tmp
# Old build directories, let's keep them anyway
/release
/alpha
/nightly
# This file is used to test the updater, and whoever is interested in doing so,
# should provide their file.
/projects/firefox/marsigner.der
.gitlab/issue_templates/Backport.md 0 → 100644
View file @ 136839a7
<!--
Title:
Backport tor-browser-build-browser#12345: Title of Issue
This is an issue for tracking back-porting a patch-set (e.g. from main to maint-14.0)
-->
## Backport Patchset
### Book-keeping
#### Gitlab Issue(s)
- tor-browser#12345
- mullvad-browser#123
- tor-browser-build#12345
#### Merge Request(s)
- tor-browser-build!1234
#### Target Channels
- [ ] maint-14.0
- [ ] maint-13.5
### Notes
<!-- whatever additional info, context, etc that would be helpful for backporting -->
/label ~"Apps::Type::Backport"
.gitlab/issue_templates/Release Prep - Mullvad Browser Alpha.md 0 → 100644
View file @ 136839a7
# Release Prep Mullvad Browser Alpha
- **NOTE** It is assumed the `mullvad-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>Explanation of variables</summary>
- `${BUILD_SERVER}`: the server the main builder is using to build a 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 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`
- **⚠️ WARNING**: 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`
- `${RELEASE_DATE}`: the intended release date of this browser release; for ESR schedule-driven releases, this should match the upstream Firefox release date
- **example**: `2024-10-29`
</details>
<details>
<summary>Build Configuration</summary>
### mullvad-browser: https://gitlab.torproject.org/tpo/applications/mullvad-browser.git
- [ ] Tag `mullvad-browser` commit:
- **example**: `mullvad-browser-128.4.0esr-14.5-1-build1`
- Run:
```bash
./tools/browser/sign-tag.mullvadbrowser alpha ${BUILD_N}
```
### tor-browser-build: https://gitlab.torproject.org/tpo/applications/tor-browser-build.git
Mullvad Browser Alpha (and Nightly) are on the `main` branch
- [ ] Changelog bookkeeping:
- Ensure all commits to `mullvad-browser` and `tor-browser-build` for this release have an associated issue linked to this release preparation issue
- Ensure each issue has a platform (~Windows, ~MacOS, ~Linux, ~Desktop, ~"All Platforms") and potentially ~"Build System" labels
- [ ] Create a release preparation branch from the `main` branch
- [ ] Run release preparation script:
- **NOTE**: You can omit the `--mullvad-browser` argument if this is for a joint Tor and Mullvad Browser release
- **⚠️ WARNING**: You may need to manually update the `firefox/config` file's `browser_build` field if `mullvad-browser.git` has not yet been tagged (e.g. if security backports have not yet been merged and tagged)
```bash
./tools/relprep.py --mullvad-browser --date ${RELEASE_DATE} ${MULLVAD_BROWSER_VERSION}
```
- [ ] Review build configuration changes:
- [ ] `rbm.conf`
- [ ] `var/torbrowser_version`: updated to next browser version
- [ ] `var/torbrowser_build`: updated to `${MULLVAD_BROWSER_BUILD_N}`
- [ ] `var/browser_release_date`: updated to build date. For the build to be reproducible, the date should be in the past when building.
- **⚠️ WARNING**: If we have updated `var/torbrowser_build` without updating the `firefox` tag, then we can leave this unchanged to avoid forcing a firefox re-build (e.g. when bumping `var/torbrowser_build` to build2, build3, etc due to non-firefox related build issues)
- [ ] `var/browser_platforms`: updated to enable the platforms included in this release
- [ ] `var/torbrowser_incremental_from`: updated to previous Desktop version
- **NOTE**: We try to build incrementals for the previous 3 desktop versions
- **⚠️ WARNING**: Really *actually* make sure this is the previous Desktop version or else the `make mullvadbrowser-incrementals-*` step will fail
- [ ] `projects/firefox/config`
- [ ] `browser_build`: updated to match `mullvad-browser` tag
- [ ] ***(Optional)*** `var/firefox_platform_version`: updated to latest `${ESR_VERSION}` if rebased
- [ ] ***(Optional)*** `projects/translation/config`:
- [ ] `steps/base-browser/git_hash`: updated with `HEAD` commit of project's `base-browser` branch
- [ ] `steps/mullvad-browser/git_hash`: updated with `HEAD` commit of project's `mullvad-browser` branch
- [ ] ***(Optional)*** `projects/browser/config`:
- [ ] ***(Optional)*** NoScript: https://addons.mozilla.org/en-US/firefox/addon/noscript
- [ ] `URL` updated
- **⚠️ WARNING**: If preparing the release manually, updating the version number in the url is not sufficient, as each version has a random unique id in the download url
- [ ] `sha256sum` updated
- [ ] ***(Optional)*** uBlock-origin: https://addons.mozilla.org/en-US/firefox/addon/ublock-origin
- [ ] `URL` updated
- **⚠️ WARNING**: If preparing the release manually, updating the version number in the url is not sufficient, as each version has a random unique id in the download url
- [ ] `sha256sum` updated
- [ ] ***(Optional)*** Mullvad Browser extension: https://github.com/mullvad/browser-extension/releases
- [ ] `URL` updated
- [ ] `sha256sum` updated
- [ ] `ChangeLog-MB.txt`: ensure correctness
- Browser name correct
- Release date correct
- No Android updates
- All issues added under correct platform
- ESR updates correct
- Component updates correct
- [ ] Open MR with above changes, using the template for release preparations
- **NOTE**: target the `main` branch
- [ ] Merge
- [ ] Sign+Tag
- **NOTE** this must be done by one of:
- boklm
- dan
- ma1
- morgan
- pierov
- Run:
```bash
make mullvadbrowser-signtag-alpha
```
- [ ] Push tag to `upstream`
- [ ] Build the tag:
- Run:
```bash
make mullvadbrowser
```
- [ ] Tor Project build machine
- [ ] Local developer machine
- [ ] Submit build request to Mullvad infrastructure:
- **NOTE** this requires a devmole authentication token
- **NOTE** this also requires you be connected to Gothenburg Mulvad VPN exit `se-got-wg-101`
- Run:
```bash
make mullvadbrowser-kick-devmole-build
```
</details>
<details>
<summary>Signing</summary>
### release signing
- [ ] Assign this issue to the signer, one of:
- boklm
- ma1
- morgan
- pierov
- [ ] Ensure all builders have matching builds
- [ ] On `${STAGING_SERVER}`, ensure updated:
- **NOTE** Having a local git branch with `main` as the upstream branch with these values saved means you only need to periodically `git pull --rebase`
- [ ] `tor-browser-build` is on the right commit: `git tag -v mb-${MULLVAD_BROWSER_VERSION}-${MULLVAD_BROWSER_BUILD_N} && git checkout mb-${MULLVAD_BROWSER_VERSION}-${MULLVAD_BROWSER_BUILD_N}`
- [ ] `tor-browser-build/tools/signing/set-config.hosts`
- `ssh_host_builder`: ssh hostname of machine with unsigned builds
- `ssh_host_linux_signer`: ssh hostname of linux signing machine
- `builder_tor_browser_build_dir`: path on `ssh_host_builder` to root of builder's `tor-browser-build` clone containing unsigned builds
- [ ] `tor-browser-build/tools/signing/set-config.rcodesign-appstoreconnect`
- `appstoreconnect_api_key_path`: path to json file containing appstoreconnect api key infos
- [ ] `set-config.update-responses`
- `update_responses_repository_dir`: directory where you cloned `git@gitlab.torproject.org:tpo/applications/mullvad-browser-update-responses.git`
- [ ] On `${STAGING_SERVER}` in a separate `screen` session, ensure tor daemon is running with SOCKS5 proxy on the default port 9050
- [ ] On `${STAGING_SERVER}` in a separate `screen` session, run do-all-signing script:
- Run:
```bash
cd tor-browser-build/tools/signing/ && ./do-all-signing.mullvadbrowser
```
- **NOTE**: on successful execution, the signed binaries and mars should have been copied to `staticiforme` and update responses pushed
</details>
<details>
<summary>Publishing</summary>
### website
- [ ] On `staticiforme.torproject.org`, remove old release and publish new:
- [ ] `/srv/dist-master.torproject.org/htdocs/mullvadbrowser`
- Run:
```bash
static-update-component dist.torproject.org
```
### mullvad-browser (GitHub): https://github.com/mullvad/mullvad-browser/
- [ ] Assign this issue to someone with mullvad commit access, one of:
- boklm
- ma1
- morgan
- pierov
- [ ] 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`
- [ ] Push this release's associated `mullvad-browser.git` branch to github
- [ ] Push this release's associated tags to github:
- [ ] Firefox ESR tag
- **example**: `FIREFOX_102_12_0esr_BUILD1`
- [ ] `base-browser` tag
- **example**: `base-browser-102.12.0esr-12.0-1-build1`
- [ ] `mullvad-browser` build tag
- **example**: `mullvad-browser-102.12.0esr-12.0-1-build1`
- [ ] `mullvad-browser` release tag
- **example**: `12.0.11`
</details>
<details>
<summary>Communications</summary>
### Mullvad
- [ ] Email Mullvad with release information:
- **Recipients**
- Mullvad support alias: support@mullvadvpn.net
- Rui Hildt: rui@mullvad.net
```
support@mullvadvpn.net, rui@mullvad.net,
```
- **Subject**
```
New build: Mullvad Browser ${MULLVAD_BROWSER_VERSION} (signed)
```
- **Body**
```
Hello,
Branch+Tags have been pushed to Mullvad's GitHub repo.
- signed builds: https://dist.torproject.org/mullvadbrowser/${MULLVAD_BROWSER_VERSION}
- update_response hashes: ${MULLVAD_UPDATE_RESPONSES_HASH}
* https://gitlab.torproject.org/tpo/applications/mullvad-browser-update-responses
changelog:
# paste changelog as quote here
...
```
### packagers
- [ ] **(Optional, Once Packages are pushed to GitHub)**
- **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
- **Recipients**
- flathub package maintainer: proletarius101@protonmail.com
- arch package maintainer: bootctl@gmail.com
- nixOS package maintainer: dev@felschr.com
```
proletarius101@protonmail.com, bootctl@gmail.com, dev@felschr.com,
```
- **Subject**
```
Mullvad Browser ${MULLVAD_BROWSER_VERSION} released
```
- **Body**
```
Hello!
This is a major alpha release which may require changes in your respective downstream packages once it stabilises.
The latest alpha builds can be found here:
- https://github.com/mullvad/mullvad-browser/releases?q=prerelease%3Atrue
```
</details>
/label ~"Apps::Type::ReleasePreparation"
/label ~"Sponsor 131"
.gitlab/issue_templates/Release Prep - Mullvad Browser Stable.md 0 → 100644
View file @ 136839a7
# Release Prep Mullvad Browser Stable
- **NOTE** It is assumed the `mullvad-browser` release 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>Explanation of variables</summary>
- `${BUILD_SERVER}`: the server the main builder is using to build a 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 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`
- **⚠️ WARNING**: 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`
- `${RELEASE_DATE}`: the intended release date of this browser release; for ESR schedule-driven releases, this should match the upstream Firefox release date
- **example**: `2024-10-29`
</details>
<details>
<summary>Build Configuration</summary>
### mullvad-browser: https://gitlab.torproject.org/tpo/applications/mullvad-browser.git
- [ ] Tag `mullvad-browser` commit:
- **example**: `mullvad-browser-128.3.0esr-14.0-1-build1`
- Run:
```bash
./tools/browser/sign-tag.mullvadbrowser stable ${BUILD_N}
```
### tor-browser-build: https://gitlab.torproject.org/tpo/applications/tor-browser-build.git
Mullvad Browser Stable is on the `maint-${MULLVAD_BROWSER_MAJOR}.${MULLVAD_BROWSER_MINOR}` branch
- [ ] Changelog bookkeeping:
- Ensure all commits to `mullvad-browser` and `tor-browser-build` for this release have an associated issue linked to this release preparation issue
- Ensure each issue has a platform (~Windows, ~MacOS, ~Linux, ~Desktop, ~"All Platforms") and potentially ~"Build System" labels
- [ ] Create a release preparation branch from the current `maint-XX.Y` branch
- [ ] Run release preparation script:
- **NOTE**: You can omit the `--mullvad-browser` argument if this is for a joint Tor and Mullvad Browser release
- **⚠️ WARNING**: You may need to manually update the `firefox/config` file's `browser_build` field if `mullvad-browser.git` has not yet been tagged (e.g. if security backports have not yet been merged and tagged)
```bash
./tools/relprep.py --mullvad-browser --date ${RELEASE_DATE} ${MULLVAD_BROWSER_VERSION}
```
- [ ] Review build configuration changes:
- [ ] `rbm.conf`
- [ ] `var/torbrowser_version`: updated to next browser version
- [ ] `var/torbrowser_build`: updated to `${MULLVAD_BROWSER_BUILD_N}`
- [ ] `var/browser_release_date`: updated to build date. For the build to be reproducible, the date should be in the past when building.
- **⚠️ WARNING**: If we have updated `var/torbrowser_build` without updating the `firefox` tag, then we can leave this unchanged to avoid forcing a firefox re-build (e.g. when bumping `var/torbrowser_build` to build2, build3, etc due to non-firefox related build issues)
- [ ] `var/torbrowser_incremental_from`: updated to previous Desktop version
- **NOTE**: We try to build incrementals for the previous 3 desktop versions
- **⚠️ WARNING**: Really *actually* make sure this is the previous Desktop version or else the `make mullvadbrowser-incrementals-*` step will fail
- [ ] `projects/firefox/config`
- [ ] `browser_build`: updated to match `mullvad-browser` tag
- [ ] ***(Optional)*** `var/firefox_platform_version`: updated to latest `${ESR_VERSION}` if rebased
- [ ] ***(Optional)*** `projects/translation/config`:
- [ ] `steps/base-browser/git_hash`: updated with `HEAD` commit of project's `base-browser` branch
- [ ] `steps/mullvad-browser/git_hash`: updated with `HEAD` commit of project's `mullvad-browser` branch
- [ ] ***(Optional)*** `projects/browser/config`:
- [ ] ***(Optional)*** NoScript: https://addons.mozilla.org/en-US/firefox/addon/noscript
- [ ] `URL` updated
- **⚠️ WARNING**: If preparing the release manually, updating the version number in the url is not sufficient, as each version has a random unique id in the download url
- [ ] `sha256sum` updated
- [ ] ***(Optional)*** uBlock-origin: https://addons.mozilla.org/en-US/firefox/addon/ublock-origin
- [ ] `URL` updated
- **⚠️ WARNING**: If preparing the release manually, updating the version number in the url is not sufficient, as each version has a random unique id in the download url
- [ ] `sha256sum` updated
- [ ] ***(Optional)*** Mullvad Browser extension: https://github.com/mullvad/browser-extension/releases
- [ ] `URL` updated
- [ ] `sha256sum` updated
- [ ] `ChangeLog-MB.txt`: ensure correctness
- Browser name correct
- Release date correct
- No Android updates
- All issues added under correct platform
- ESR updates correct
- Component updates correct
- [ ] Open MR with above changes, using the template for release preparations
- **NOTE**: target the `maint-14.0` branch
- [ ] Merge
- [ ] Sign+Tag
- **NOTE** this must be done by one of:
- boklm
- dan
- ma1
- morgan
- pierov
- Run:
```bash
make mullvadbrowser-signtag-release
```
- [ ] Push tag to `upstream`
- [ ] Build the tag:
- Run:
```bash
make mullvadbrowser-release && make mullvadbrowser-incrementals-release
```
- Tor Project build machine
- Local developer machine
- [ ] Submit build request to Mullvad infrastructure:
- **NOTE** this requires a devmole authentication token
- **NOTE** this also requires you be connected to Gothenburg Mulvad VPN exit `se-got-wg-101`
- Run:
```bash
make mullvadbrowser-kick-devmole-build
```
</details>
<details>
<summary>Signing</summary>
### release signing
- [ ] Assign this issue to the signer, one of:
- boklm
- ma1
- morgan
- pierov
- [ ] Ensure all builders have matching builds
- [ ] On `${STAGING_SERVER}`, ensure updated:
- **NOTE** Having a local git branch with `maint-14.0` as the upstream branch with these values saved means you only need to periodically `git pull --rebase` and update the `set-config.tbb-version` file
- [ ] `tor-browser-build` is on the right commit: `git tag -v mb-${MULLVAD_BROWSER_VERSION}-${MULLVAD_BROWSER_BUILD_N} && git checkout mb-${MULLVAD_BROWSER_VERSION}-${MULLVAD_BROWSER_BUILD_N}`
- [ ] `tor-browser-build/tools/signing/set-config.hosts`
- `ssh_host_builder`: ssh hostname of machine with unsigned builds
- `ssh_host_linux_signer`: ssh hostname of linux signing machine
- `builder_tor_browser_build_dir`: path on `ssh_host_builder` to root of builder's `tor-browser-build` clone containing unsigned builds
- [ ] `tor-browser-build/tools/signing/set-config.rcodesign-appstoreconnect`
- `appstoreconnect_api_key_path`: path to json file containing appstoreconnect api key infos
- [ ] `set-config.update-responses`
- `update_responses_repository_dir`: directory where you cloned `git@gitlab.torproject.org:tpo/applications/mullvad-browser-update-responses.git`
- [ ] `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
- [ ] On `${STAGING_SERVER}` in a separate `screen` session, ensure tor daemon is running with SOCKS5 proxy on the default port 9050
- [ ] On `${STAGING_SERVER}` in a separate `screen` session, run do-all-signing script:
- Run:
```bash
cd tor-browser-build/tools/signing/ && ./do-all-signing.mullvadbrowser
```
- **NOTE**: on successful execution, the signed binaries and mars should have been copied to `staticiforme` and update responses pushed
</details>
<details>
<summary>Publishing</summary>
### website
- [ ] On `staticiforme.torproject.org`, remove old release and publish new:
- [ ] `/srv/dist-master.torproject.org/htdocs/mullvadbrowser`
- Run:
```bash
static-update-component dist.torproject.org
```
### mullvad-browser (GitHub): https://github.com/mullvad/mullvad-browser/
- [ ] Assign this issue to someone with mullvad commit access, one of:
- boklm
- ma1
- morgan
- pierov
- [ ] 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`
- [ ] Push this release's associated `mullvad-browser.git` branch to github
- [ ] Push this release's associated tags to github:
- [ ] Firefox ESR tag
- **example**: `FIREFOX_102_12_0esr_BUILD1`
- [ ] `base-browser` tag
- **example**: `base-browser-102.12.0esr-12.0-1-build1`
- [ ] `mullvad-browser` build tag
- **example**: `mullvad-browser-102.12.0esr-12.0-1-build1`
- [ ] `mullvad-browser` release tag
- **example**: `12.0.11`
</details>
<details>
<summary>Communications</summary>
### Mullvad
- [ ] Email Mullvad with release information:
- **Recipients**
- Mullvad support alias: support@mullvadvpn.net
- Rui Hildt: rui@mullvad.net
```
support@mullvadvpn.net, rui@mullvad.net
```
- **Subject**
```
New build: Mullvad Browser ${MULLVAD_BROWSER_VERSION} (signed)
```
- **Body**
```
Hello,
Branch+Tags have been pushed to Mullvad's GitHub repo.
- signed builds: https://dist.torproject.org/mullvadbrowser/${MULLVAD_BROWSER_VERSION}
- update_response hashes: ${MULLVAD_UPDATE_RESPONSES_HASH}*
* https://gitlab.torproject.org/tpo/applications/mullvad-browser-update-responses
changelog:
# paste changelog as quote here
...
```
### packagers
- [ ] **(Once Packages are pushed to GitHub)**
- **Recipients**
- flathub package maintainer: proletarius101@protonmail.com
- arch package maintainer: bootctl@gmail.com
- nixOS package maintainer: dev@felschr.com
```
proletarius101@protonmail.com, bootctl@gmail.com, dev@felschr.com,
```
- **Subject**
```
Mullvad Browser ${MULLVAD_BROWSER_VERSION} released
```
- **Body**
```
Hello!
Mullvad-Browser packages are available, so you should update your respective downstream packages.
The latest release builds can be found here:
- https://github.com/mullvad/mullvad-browser/releases?q=prerelease%3Afalse
```
### merge requests
- [ ] **(Once Packages are pushed to GitHub)**
- [ ] homebrew: https://github.com/Homebrew/homebrew-cask/blob/master/Casks/m/mullvad-browser.rb
- **NOTE**: a bot seems to pick this up without needing our intervention these days
- **NOTE**: should just need to update `version` and `sha256` to latest
</details>
/label ~"Apps::Type::ReleasePreparation"
/label ~"Sponsor 131"
.gitlab/issue_templates/Release Prep - Tor Browser Alpha.md 0 → 100644
View file @ 136839a7
# Release Prep Tor Browser Alpha
- **NOTE** It is assumed the `tor-browser` alpha rebase and security backport tasks have been completed
- **NOTE** This can/is often done in conjunction with the equivalent Mullvad Browser release prep issue
<details>
<summary>Explanation of variables</summary>
- `${BUILD_SERVER}`: the server the main builder is using to build a 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 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`
- **⚠️ WARNING**: 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.5a7-build1`
- `${RELEASE_DATE}`: the intended release date of this browser release; for ESR schedule-driven releases, this should match the upstream Firefox release date
- **example**: `2024-10-29`
</details>
<details>
<summary>Build Configuration</summary>
### tor-browser: https://gitlab.torproject.org/tpo/applications/tor-browser.git
- [ ] Tag `tor-browser` in tor-browser.git
- **example**: `tor-browser-128.4.0esr-14.5-1-build1`
- Run:
```bash
./tools/browser/sign-tag.torbrowser alpha ${BUILD_N}
```
### tor-browser-build: https://gitlab.torproject.org/tpo/applications/tor-browser-build.git
Tor Browser Alpha (and Nightly) are on the `main` branch
- [ ] Changelog bookkeeping:
- Ensure all commits to `tor-browser` and `tor-browser-build` for this release have an associated issue linked to this release preparation issue
- Ensure each issue has a platform (~Windows, ~MacOS, ~Linux, ~Android, ~Desktop, ~"All Platforms") and potentially ~"Build System" labels
- [ ] Create a release preparation branch from the `main` branch
- [ ] Run release preparation script:
- **NOTE**: You can omit the `--tor-browser` argument if this is for a jointt Tor and Mullvad Browser release
- **⚠️ WARNING**: You may need to manually update the `firefox/config` and `geckoview/config` files' `browser_build` field if `tor-browser.git` has not yet been tagged (e.g. if security backports have not yet been merged and tagged)
```bash
./tools/relprep.py --tor-browser --date ${RELEASE_DATE} ${TOR_BROWSER_VERSION}
```
- [ ] Review build configuration changes:
- [ ] `rbm.conf`
- [ ] `var/torbrowser_version`: updated to next browser version
- [ ] `var/torbrowser_build`: updated to `${TOR_BROWSER_BUILD_N}`
- [ ] `var/browser_release_date`: updated to build date. For the build to be reproducible, the date should be in the past when building.
- **⚠️ WARNING**: If we have updated `var/torbrowser_build` without updating the `firefox` or `geckoview` tags, then we can leave this unchanged to avoid forcing a firefox re-build (e.g. when bumping `var/torbrwoser_build` to build2, build3, etc due to non-firefox related build issues)
- [ ] `var/browser_platforms`: updated to enable the platforms included in this release
- [ ] ***(Desktop Only)*** `var/torbrowser_incremental_from`: updated to previous Desktop version
- **NOTE**: We try to build incrementals for the previous 3 desktop versions
- **⚠️ WARNING**: Really *actually* make sure this is the previous Desktop version or else the `make torbrowser-incrementals-*` step will fail
- [ ] `projects/firefox/config`
- [ ] `browser_build`: updated to match `tor-browser` tag
- [ ] ***(Optional)*** `var/firefox_platform_version`: updated to latest `${ESR_VERSION}` if rebased
- [ ] `projects/geckoview/config`
- [ ] `browser_build`: updated to match `tor-browser` tag
- [ ] ***(Optional)*** `var/firefox_platform_version`: updated to latest `${ESR_VERSION}` if rebased
- [ ] ***(Optional)*** `projects/translation/config`:
- [ ] `steps/base-browser/git_hash`: updated with `HEAD` commit of project's `base-browser` branch
- [ ] `steps/tor-browser/git_hash`: updated with `HEAD` commit of project's `tor-browser` branch
- [ ] `steps/fenix/git_hash`: updated with `HEAD` commit of project's `fenix-torbrowserstringsxml` branch
- [ ] ***(Optional)*** `projects/browser/config`:
- [ ] ***(Optional)*** NoScript: https://addons.mozilla.org/en-US/firefox/addon/noscript
- [ ] `URL` updated
- **⚠️ WARNING**: If preparing the release manually, updating the version number in the url is not sufficient, as each version has a random unique id in the download url
- [ ] `sha256sum` updated
- [ ] ***(Optional)*** `projects/openssl/config`: https://www.openssl.org/source/
- **NOTE**: Only if new LTS version (3.0.X currrently) available
- [ ] `version`: updated to next LTS version
- [ ] `input_files/sha256sum`: updated to sha256 sum of source tarball
- [ ] **(Optional)** `projects/zlib/config`: https://github.com/madler/zlib/releases
- **NOTE**: Only if new tag available
- [ ] `version`: updated to next release tag
- [ ] **(Optional)** `projects/zstd/config`: https://github.com/facebook/zstd/releases
- **NOTE**: Only if new tag available; Android-only for now
- [ ] `version`: updated to next release tag
- [ ] `git_hash`: updated to the commit corresponding to the tag (we don't check signatures for Zstandard)
- [ ] **(Optional)** `projects/tor/config` https://gitlab.torproject.org/tpo/core/tor/-/tags
- [ ] `version`: updated to latest `-alpha` tag or release tag if newer (ping **dgoulet** or **ahf** if unsure)
- [ ] **(Optional)** `projects/go/config` https://go.dev/dl
- **NOTE**: In general, Tor Browser Alpha uses the latest Stable major series Go version, but there are sometimes exceptions. Check with the anti-censorship team before doing a major version update in case there is incompatibilities.
- [ ] `version`: updated go version
- [ ] `input_files/sha256sum` for `go`: update sha256sum of archive (sha256 sums are displayed on the go download page)
- [ ] **(Optional)** `projects/manual/config`
- [ ] `version`: updated to latest pipeline id
- [ ] `input_files/shasum` for `manual`: updated to manual hash
- [ ] Upload the downloaded `manual_${PIPELINEID}.zip` file to `tb-build-02.torproject.org`
- [ ] Deploy to `tb-builder`'s `public_html` directory:
- Run:
```bash
sudo -u tb-builder cp manual_${PIPELINEID}.zip ~tb-builder/public_html/.
```
- `sudo` documentation for TPO machines: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/doc/accounts#changingresetting-your-passwords
- [ ] `ChangeLog-TBB.txt`: ensure correctness
- Browser name correct
- Release date correct
- No Android updates on a desktop-only release and vice-versa
- All issues added under correct platform
- ESR updates correct
- Component updates correct
- [ ] Open MR with above changes, using the template for release preparations
- **NOTE**: target the `main` branch
- [ ] Merge
- [ ] Sign+Tag
- **NOTE** this must be done by one of:
- boklm
- dan
- ma1
- morgan
- pierov
- Run:
```bash
make torbrowser-signtag-alpha
```
- [ ] Push tag to `upstream`
- [ ] Build the tag:
- Run:
```bash
make torbrowser
```
- [ ] Tor Project build machine
- [ ] Local developer machine
- [ ] Submit build request to Mullvad infrastructure:
- **NOTE** this requires a devmole authentication token
- **NOTE** this also requires you be connected to Gothenburg Mulvad VPN exit `se-got-wg-101`
- Run:
```bash
make torbrowser-kick-devmole-build
```
</details>
<details>
<summary>Website</summary>
### downloads: https://gitlab.torproject.org/tpo/web/tpo.git
- [ ] `databags/versions.ini`: Update the downloads versions
- `torbrowser-stable/version`: catch-all for latest stable version
- `torbrowser-alpha/version`: catch-all for latest alpha version
- `torbrowser-*-stable/version`: platform-specific stable versions
- `torbrowser-*-alpha/version`: platform-specific alpha versions
- [ ] Push to origin as new branch and create MR
- [ ] Review
- [ ] Merge
- **⚠️ WARNING**: Do not deploy yet!
### blog: https://gitlab.torproject.org/tpo/web/blog.git
- [ ] Generate release blog post
- Run:
```bash
./tools/signing/create-blog-post.torbrowser
```
- **NOTE** this script creates the new blog post from a template (edit `./tools/signing/set-config.blog` to set you local blog directory)
- [ ] **(Optional)** Note any ESR update
- [ ] **(Optional)** Thank any users which have contributed patches
- [ ] **(Optional)** Draft any additional sections for new features which need testing, known issues, etc
- [ ] Push to origin as new branch and open MR
- [ ] Review
- [ ] Merge
- **⚠️ WARNING**: Do not deploy yet!
</details>
<details>
<summary>Signing</summary>
### release signing
- [ ] Assign this issue to the signer, one of:
- boklm
- ma1
- morgan
- pierov
- [ ] Ensure all builders have matching builds
- [ ] On `${STAGING_SERVER}`, ensure updated:
- **NOTE** Having a local git branch with `main` as the upstream branch with these values saved means you only need to periodically `git pull --rebase`
- [ ] `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}`
- [ ] `tor-browser-build/tools/signing/set-config.hosts`
- `ssh_host_builder`: ssh hostname of machine with unsigned builds
- `ssh_host_linux_signer`: ssh hostname of linux signing machine
- `builder_tor_browser_build_dir`: path on `ssh_host_builder` to root of builder's `tor-browser-build` clone containing unsigned builds
- [ ] `tor-browser-build/tools/signing/set-config.rcodesign-appstoreconnect`
- `appstoreconnect_api_key_path`: path to json file containing appstoreconnect api key infos
- [ ] `set-config.update-responses`
- `update_responses_repository_dir`: directory where you cloned `git@gitlab.torproject.org:tpo/applications/tor-browser-update-responses.git`
- [ ] On `${STAGING_SERVER}` in a separate `screen` session, ensure tor daemon is running with SOCKS5 proxy on the default port 9050
- [ ] On `${STAGING_SERVER}` in a separate `screen` session, run do-all-signing script:
- Run:
```bash
cd tor-browser-build/tools/signing/ && ./do-all-signing.torbrowser
```
- **NOTE**: on successful execution, the signed binaries and mars should have been copied to `staticiforme` and update responses pushed
</details>
<details>
<summary>Signature verification</summary>
<details>
<summary>Check whether the .exe files got properly signed and timestamped</summary>
```bash
# Point OSSLSIGNCODE to your osslsigncode binary
pushd tor-browser-build/torbrowser/${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>
```bash
# Point NSS_DB_DIR to your nssdb dir containing the mar signing certificate
# (check tools/marsigning_check.sh source code for details)
# Point SIGNMAR to your signmar binary
# Point LD_LIBRARY_PATH to your mar-tools directory
pushd tor-browser-build/torbrowser/${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
- [ ] On `staticiforme.torproject.org`, static update components:
- Run:
```bash
static-update-component cdn.torproject.org && static-update-component dist.torproject.org
```
- [ ] Deploy `tor-website` MR
- [ ] Deploy `tor-blog` MR
- [ ] On `staticiforme.torproject.org`, enable update responses:
- Run:
```bash
sudo -u tb-release ./deploy_update_responses-alpha.sh
```
- [ ] On `staticiforme.torproject.org`, remove old release:
- **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)
- [ ] `/srv/cdn-master.torproject.org/htdocs/aus1/torbrowser`
- [ ] `/srv/dist-master.torproject.org/htdocs/torbrowser`
- Run:
```bash
static-update-component cdn.torproject.org && static-update-component dist.torproject.org
```
### Google Play: https://play.google.com/apps/publish
- [ ] Publish APKs to Google Play:
- Select `Tor Browser (Alpha)` 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>Communications</summary>
### tor-announce mailing list
- [ ] Email tor-announce mailing list
- **Recipients**
```
tor-announce@lists.torproject.org
```
- **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}
Changelog:
# paste changelog as quote here
```
### packagers
- [ ] ***(Optional, only around build/packaging changes)*** Email packagers:
- **Recipients**
- Tails dev mailing list: tails-dev@boum.org
- Guardian Project: nathan@guardianproject.info
- FreeBSD port: freebsd@sysctl.cz <!-- Gitlab user maxfx -->
- OpenBSD port: caspar@schutijser.com <!-- Gitlab user cschutijser -->
- torbrowser-launcher: mail@asciiwolf.com <!-- Gitlab user asciiwolf -->
- Anti-Censorship: meskio@torproject.org <!-- Gitlab user meskio -->
```
tails-dev@boum.org, nathan@guardianproject.info, freebsd@sysctl.cz, caspar@schutijser.com, mail@asciiwolf.com, meskio@torproject.org,
```
- **Subject**
```
New Release: Tor Browser ${TOR_BROWSER_VERSION} (Android, Windows, macOS, Linux)
```
- [ ] Note any changes which may affect packaging/downstream integration
### downstream projects
- [ ] ***(Optional, only after internal API-breaking changes)*** Email downstream project maintainers:
- **Recipients**
- selenium-tor: matzfan@tempr.email <!-- Forum user Noino -->
```
matzfan@tempr.email
```
- **Subject**
```
Breaking Changes in Tor Browser ${TOR_BROWSER_VERSION}
```
- [ ] Note any internal API changes which may affect browser automation
### upstream services
- [ ] ***(Optional, after ESR migration)*** Email external partners:
- [ ] Cloudflare: ask-research@cloudflare.com
- **NOTE**: We need to provide them with updated user agent string so they can update their internal machinery to prevent Tor Browser users from getting so many CAPTCHAs
- [ ] Startpage: admin@startpage.com
- **NOTE**: Startpage also needs the updated user-agent string for better experience on their onion service sites.
</details>
/label ~"Apps::Type::ReleasePreparation"
.gitlab/issue_templates/Release Prep - Tor Browser Legacy.md 0 → 100644
View file @ 136839a7
# Release Prep Tor Browser Legacy
- **NOTE** It is assumed the `tor-browser` release rebase and security backport tasks have been completed
<details>
<summary>Explanation of variables</summary>
- `${BUILD_SERVER}`: the server the main builder is using to build a 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 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`
- **⚠️ WARNING**: 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.5a7-build1`
- `${RELEASE_DATE}`: the intended release date of this browser release; for ESR schedule-driven releases, this should match the upstream Firefox release date
- **example**: `2024-10-29`
</details>
<details>
<summary>Build Configuration</summary>
### tor-browser: https://gitlab.torproject.org/tpo/applications/tor-browser.git
- [ ] Tag `tor-browser` in tor-browser.git
- **example**: `tor-browser-115.17.0esr-13.5-1-build1`
- Run:
```bash
./tools/browser/sign-tag.torbrowser legacy ${BUILD_N}
```
### tor-browser-build: https://gitlab.torproject.org/tpo/applications/tor-browser-build.git
Tor Browser Legacy is on the `maint-13.5` branch
- [ ] Changelog bookkeeping:
- Ensure all commits to `tor-browser` and `tor-browser-build` for this release have an associated issue linked to this release preparation issue
- Ensure each issue has a platform (~Windows, ~MacOS, ~Desktop, ~"All Platforms") and potentially ~"Build System" labels
- [ ] Create a release preparation branch from the `maint-13.5` branch
- [ ] Run release preparation script:
- **⚠️ WARNING**: You may need to manually update the `firefox/config` file's `browser_build` field if `tor-browser.git` has not yet been tagged (e.g. if security backports have not yet been merged and tagged)
```bash
./tools/relprep.py --tor-browser --date ${RELEASE_DATE} ${TOR_BROWSER_VERSION}
```
- [ ] Review build configuration changes:
- [ ] `rbm.conf`
- [ ] `var/torbrowser_version`: updated to next browser version
- [ ] `var/torbrowser_build`: updated to `${TOR_BROWSER_BUILD_N}`
- [ ] `var/browser_release_date`: updated to build date. For the build to be reproducible, the date should be in the past when building.
- **⚠️ WARNING**: If we have updated `var/torbrowser_build` without updating the `firefox`, then we can leave this unchanged to avoid forcing a firefox re-build (e.g. when bumping `var/torbrwoser_build` to build2, build3, etc due to non-firefox related build issues)
- [ ] ***(Desktop Only)*** `var/torbrowser_incremental_from`: updated to previous Desktop version
- **NOTE**: We try to build incrementals for the previous 3 desktop versions
- **⚠️ WARNING**: Really *actually* make sure this is the previous Desktop version or else the `make torbrowser-incrementals-*` step will fail
- [ ] `projects/firefox/config`
- [ ] `browser_build`: updated to match `tor-browser` tag
- [ ] ***(Optional)*** `var/firefox_platform_version`: updated to latest `${ESR_VERSION}` if rebased
- [ ] ***(Optional)*** `projects/translation/config`:
- [ ] `steps/base-browser/git_hash`: updated with `HEAD` commit of project's `base-browser` branch
- [ ] `steps/tor-browser/git_hash`: updated with `HEAD` commit of project's `tor-browser` branch
- [ ] ***(Optional)*** `projects/browser/config`:
- [ ] ***(Optional)*** NoScript: https://addons.mozilla.org/en-US/firefox/addon/noscript
- [ ] `URL` updated
- **⚠️ WARNING**: If preparing the release manually, updating the version number in the url is not sufficient, as each version has a random unique id in the download url
- [ ] `sha256sum` updated
- [ ] ***(Optional)*** `projects/openssl/config`: https://www.openssl.org/source/
- **NOTE**: Only if new LTS version (3.0.X currrently) available
- [ ] `version`: updated to next LTS version
- [ ] `input_files/sha256sum`: updated to sha256 sum of source tarball
- [ ] **(Optional)** `projects/zlib/config`: https://github.com/madler/zlib/releases
- **NOTE**: Only if new tag available
- [ ] `version`: updated to next release tag
- [ ] **(Optional)** `projects/zstd/config`: https://github.com/facebook/zstd/releases
- **NOTE**: Only if new tag available
- [ ] `version`: updated to next release tag
- [ ] `git_hash`: updated to the commit corresponding to the tag (we don't check signatures for Zstandard)
- [ ] **(Optional)** `projects/tor/config` https://gitlab.torproject.org/tpo/core/tor/-/tags
- [ ] `version`: updated to latest non `-alpha` tag or release tag if newer (ping **dgoulet** or **ahf** if unsure)
- [ ] **(Optional)** `projects/go/config` https://go.dev/dl
- [ ] `go_1_22`: updated to latest 1.22 version
- [ ] `input_files/sha256sum` for `go`: update sha256sum of archive (sha256 sums are displayed on the go download page)
- [ ] **(Optional)** `projects/manual/config`
- [ ] `version`: updated to latest pipeline id
- [ ] `input_files/shasum` for `manual`: updated to manual hash
- [ ] Upload the downloaded `manual_${PIPELINEID}.zip` file to `tb-build-02.torproject.org`
- [ ] Deploy to `tb-builder`'s `public_html` directory:
- Run:
```bash
sudo -u tb-builder cp manual_${PIPELINEID}.zip ~tb-builder/public_html/.
```
- `sudo` documentation for TPO machines: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/doc/accounts#changingresetting-your-passwords
- [ ] `ChangeLog-TBB.txt`: ensure correctness
- Browser name correct
- Release date correct
- No Android updates
- All issues added under correct platform
- ESR updates correct
- Component updates correct
- [ ] Open MR with above changes, using the template for release preparations
- **NOTE**: target the `maint-13.5` branch
- [ ] Merge
- [ ] Sign+Tag
- **NOTE** this must be done by one of:
- boklm
- dan
- ma1
- morgan
- pierov
- Run:
```bash
make torbrowser-signtag-release
```
- [ ] Push tag to `upstream`
- [ ] Build the tag:
- Run:
```bash
make torbrowser-release && make torbrowser-incrementals-release
```
- [ ] Tor Project build machine
- [ ] Local developer machine
- [ ] Submit build request to Mullvad infrastructure:
- **NOTE** this requires a devmole authentication token
- **NOTE** this also requires you be connected to Gothenburg Mulvad VPN exit `se-got-wg-101`
- Run:
```bash
make torbrowser-kick-devmole-build
```
</details>
<details>
<summary>Website</summary>
### blog: https://gitlab.torproject.org/tpo/web/blog.git
- [ ] Generate release blog post
- Run:
```bash
./tools/signing/create-blog-post.torbrowser
```
- **NOTE** this script creates the new blog post from a template (edit `./tools/signing/set-config.blog` to set you local blog directory)
- [ ] **(Optional)** Note any ESR update
- [ ] **(Optional)** Thank any users which have contributed patches
- [ ] **(Optional)** Draft any additional sections for new features which need testing, known issues, etc
- [ ] Push to origin as new branch and open MR
- [ ] Review
- [ ] Merge
- **⚠️ WARNING**: Do not deploy yet!
</details>
<details>
<summary>Signing</summary>
### release signing
- [ ] Assign this issue to the signer, one of:
- boklm
- ma1
- morgan
- pierov
- [ ] Ensure all builders have matching builds
- [ ] On `${STAGING_SERVER}`, ensure updated:
- **NOTE** Having a local git branch with `maint-13.5` as the upstream branch with these values saved means you only need to periodically `git pull --rebase` and update the `set-config.tbb-version` file
- [ ] `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}`
- [ ] `tor-browser-build/tools/signing/set-config.hosts`
- `ssh_host_builder`: ssh hostname of machine with unsigned builds
- `ssh_host_linux_signer`: ssh hostname of linux signing machine
- `builder_tor_browser_build_dir`: path on `ssh_host_builder` to root of builder's `tor-browser-build` clone containing unsigned builds
- [ ] `tor-browser-build/tools/signing/set-config.rcodesign-appstoreconnect`
- `appstoreconnect_api_key_path`: path to json file containing appstoreconnect api key infos
- [ ] `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
- [ ] On `${STAGING_SERVER}` in a separate `screen` session, ensure tor daemon is running with SOCKS5 proxy on the default port 9050
- [ ] On `${STAGING_SERVER}` in a separate `screen` session, run do-all-signing script:
- Run:
```bash
cd tor-browser-build/tools/signing/ && ./do-all-signing.torbrowser
```
- **NOTE**: on successful execution, the signed binaries and mars should have been copied to `staticiforme` and update responses pushed
</details>
<details>
<summary>Signature verification</summary>
<details>
<summary>Check whether the .exe files got properly signed and timestamped</summary>
```bash
# Point OSSLSIGNCODE to your osslsigncode binary
pushd tor-browser-build/torbrowser/${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>
```bash
# 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/torbrowser/${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
- [ ] On `staticiforme.torproject.org`, static update components:
- Run:
```bash
static-update-component cdn.torproject.org && static-update-component dist.torproject.org
```
- [ ] Deploy `tor-blog` MR
- [ ] On `staticiforme.torproject.org`, remove old release:
- **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)
- [ ] `/srv/cdn-master.torproject.org/htdocs/aus1/torbrowser`
- [ ] `/srv/dist-master.torproject.org/htdocs/torbrowser`
- Run:
```bash
static-update-component cdn.torproject.org && static-update-component dist.torproject.org
```
- [ ] **(Optional)** Generate and deploy new update responses
- **NOTE**: This is only required if there will be no corresponding 14.0 release (i.e. this is an emergency legacy-only 13.5 release). Normally, legacy update responses are generated and deployed as part of the 14.0 release.
- **⚠️ WARNING**: This is a little bit off the beaten track, ping boklm or morgan if you have any doubts
- From the `maint-14.0` branch:
- [ ] Update `rbm.conf`
- [ ] `var/torbrowser_legacy_version`: update to `${TOR_BROWSER_VERSION}`
- **NOTE** this is the browser version for the legacy branch, not the 14.0 branch
- [ ] `var/torbrowser_legacy_platform_version`: update to `${ESR_VERSION}`
- **NOTE** this is ESR version for the legacy branch, not the 14.0 branch
- [ ] Generate update responses:
- Run:
```bash
make torbrowser-update_responses-release
```
- [ ] Commit new update responses to tor-browser-update-responses.git:
- Run:
```bash
updaterespdir=/path/to/tor-browser-update-responses.git
cp torbrowser/release/update-responses/update-responses-release-${TOR_BROWSER_VERSION}.tar "$updaterespdir"
cd "$updaterespdir"
git pull
rm -Rf update_3/release
tar -C update_3 update-responses-release-${TOR_BROWSER_VERSION}.tar
rm update-responses-release-${TOR_BROWSER_VERSION}.tar
git add update_3/release
git commit -m "release: new version, ${TOR_BROWSER_VERSION}"
git push
# print the commit hash and copy past it for the next step
git show -s --format=%H
```
- On `staticiforme.torproject.org`, deploy new update responses:
- [ ] Enable update responses, passing the commit hash as argument (replace $commit):
```bash
sudo -u tb-release ./deploy_update_responses-release.sh $commit
```
</details>
<details>
<summary>Communications</summary>
### tor-announce mailing list
- [ ] Email tor-announce mailing list
- **Recipients**
```
tor-announce@lists.torproject.org
```
- **Subject**
```
New Release: Tor Browser ${TOR_BROWSER_VERSION} (Windows, macOS)
```
- **Body**
```
Hi everyone,
Tor Browser ${TOR_BROWSER_VERSION} has now been published for legacy Windows and macOS platforms. For details please see our blog post:
- ${BLOG_POST_URL}
Changelog:
# paste changelog as quote here
```
</details>
/label ~"Apps::Type::ReleasePreparation"
.gitlab/issue_templates/Release Prep - Tor Browser Stable.md 0 → 100644
View file @ 136839a7
# Release Prep Tor Browser Stable
- **NOTE** It is assumed the `tor-browser` release rebase and security backport tasks have been completed
- **NOTE** This can/is often done in conjunction with the equivalent Mullvad Browser release prep issue
<details>
<summary>Explanation of variables</summary>
- `${BUILD_SERVER}`: the server the main builder is using to build a 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 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`
- **⚠️ WARNING**: 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.5a7-build1`
- `${RELEASE_DATE}`: the intended release date of this browser release; for ESR schedule-driven releases, this should match the upstream Firefox release date
- **example**: `2024-10-29`
</details>
<details>
<summary>Build Configuration</summary>
### tor-browser: https://gitlab.torproject.org/tpo/applications/tor-browser.git
- [ ] Tag `tor-browser` in tor-browser.git
- **example**: `tor-browser-128.4.0esr-14.0-1-build1`
- Run:
```bash
./tools/browser/sign-tag.torbrowser stable ${BUILD_N}
```
### tor-browser-build: https://gitlab.torproject.org/tpo/applications/tor-browser-build.git
Tor Browser Stable is on the `maint-${TOR_BROWSER_MAJOR}.${TOR_BROWSER_MINOR}` branch
- [ ] Changelog bookkeeping:
- Ensure all commits to `tor-browser` and `tor-browser-build` for this release have an associated issue linked to this release preparation issue
- Ensure each issue has a platform (~Windows, ~MacOS, ~Linux, ~Android, ~Desktop, ~"All Platforms") and potentially ~"Build System" labels
- [ ] Create a release preparation branch from the current `maint-XX.Y` branch
- [ ] Run release preparation script:
- **NOTE**: You can omit the `--tor-browser` argument if this is for a joint Tor and Mullvad Browser release
- **⚠️ WARNING**: You may need to manually update the `firefox/config` and `geckoview/config` files' `browser_build` field if `tor-browser.git` has not yet been tagged (e.g. if security backports have not yet been merged and tagged)
```bash
./tools/relprep.py --tor-browser --date ${RELEASE_DATE} ${TOR_BROWSER_VERSION}
```
- [ ] Review build configuration changes:
- [ ] `rbm.conf`
- [ ] `var/torbrowser_version`: updated to next browser version
- [ ] `var/torbrowser_build`: updated to `${TOR_BROWSER_BUILD_N}`
- [ ] `var/browser_release_date`: updated to build date. For the build to be reproducible, the date should be in the past when building.
- **⚠️ WARNING**: If we have updated `var/torbrowser_build` without updating the `firefox` or `geckoview` tags, then we can leave this unchanged to avoid forcing a firefox re-build (e.g. when bumping `var/torbrwoser_build` to build2, build3, etc due to non-firefox related build issues)
- [ ] ***(Desktop Only)*** `var/torbrowser_incremental_from`: updated to previous Desktop version
- **NOTE**: We try to build incrementals for the previous 3 desktop versions
- **⚠️ WARNING**: Really *actually* make sure this is the previous Desktop version or else the `make torbrowser-incrementals-*` step will fail
- [ ] `var/torbrowser_legacy_version`: updated to latest legacy Tor Browser version
- [ ] `var/torbrowser_legacy_platform_version`: updated to latest legacy Tor Browser ESR version
- [ ] `projects/firefox/config`
- [ ] `browser_build`: updated to match `tor-browser` tag
- [ ] ***(Optional)*** `var/firefox_platform_version`: updated to latest `${ESR_VERSION}` if rebased
- [ ] `projects/geckoview/config`
- [ ] `browser_build`: updated to match `tor-browser` tag
- [ ] ***(Optional)*** `var/firefox_platform_version`: updated to latest `${ESR_VERSION}` if rebased
- [ ] ***(Optional)*** `projects/translation/config`:
- [ ] `steps/base-browser/git_hash`: updated with `HEAD` commit of project's `base-browser` branch
- [ ] `steps/tor-browser/git_hash`: updated with `HEAD` commit of project's `tor-browser` branch
- [ ] `steps/fenix/git_hash`: updated with `HEAD` commit of project's `fenix-torbrowserstringsxml` branch
- [ ] ***(Optional)*** `projects/browser/config`:
- [ ] ***(Optional)*** NoScript: https://addons.mozilla.org/en-US/firefox/addon/noscript
- [ ] `URL` updated
- **⚠️ WARNING**: If preparing the release manually, updating the version number in the url is not sufficient, as each version has a random unique id in the download url
- [ ] `sha256sum` updated
- [ ] ***(Optional)*** `projects/openssl/config`: https://www.openssl.org/source/
- **NOTE**: Only if new LTS version (3.0.X currrently) available
- [ ] `version`: updated to next LTS version
- [ ] `input_files/sha256sum`: updated to sha256 sum of source tarball
- [ ] **(Optional)** `projects/zlib/config`: https://github.com/madler/zlib/releases
- **NOTE**: Only if new tag available
- [ ] `version`: updated to next release tag
- [ ] **(Optional)** `projects/zstd/config`: https://github.com/facebook/zstd/releases
- **NOTE**: Only if new tag available; Android-only for now
- [ ] `version`: updated to next release tag
- [ ] `git_hash`: updated to the commit corresponding to the tag (we don't check signatures for Zstandard)
- [ ] **(Optional)** `projects/tor/config` https://gitlab.torproject.org/tpo/core/tor/-/tags
- [ ] `version`: updated to latest non `-alpha` tag or release tag if newer (ping **dgoulet** or **ahf** if unsure)
- [ ] **(Optional)** `projects/go/config` https://go.dev/dl
- **NOTE**: In general, Tor Browser Alpha uses the latest Stable major series Go version, but there are sometimes exceptions. Check with the anti-censorship team before doing a major version update in case there is incompatibilities.
- [ ] `version`: updated go version
- [ ] `input_files/sha256sum` for `go`: update sha256sum of archive (sha256 sums are displayed on the go download page)
- [ ] **(Optional)** `projects/manual/config`
- [ ] `version`: updated to latest pipeline id
- [ ] `input_files/shasum` for `manual`: updated to manual hash
- [ ] Upload the downloaded `manual_${PIPELINEID}.zip` file to `tb-build-02.torproject.org`
- [ ] Deploy to `tb-builder`'s `public_html` directory:
- Run:
```bash
sudo -u tb-builder cp manual_${PIPELINEID}.zip ~tb-builder/public_html/.
```
- `sudo` documentation for TPO machines: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/doc/accounts#changingresetting-your-passwords
- [ ] `ChangeLog-TBB.txt`: ensure correctness
- Browser name correct
- Release date correct
- No Android updates on a desktop-only release and vice-versa
- All issues added under correct platform
- ESR updates correct
- Component updates correct
- [ ] Open MR with above changes, using the template for release preparations
- **NOTE**: target the `maint-14.0` branch
- [ ] Merge
- [ ] Sign+Tag
- **NOTE** this must be done by one of:
- boklm
- dan
- ma1
- morgan
- pierov
- Run:
```bash
make torbrowser-signtag-release
```
- [ ] Push tag to `upstream`
- [ ] Build the tag:
- Run:
```bash
make torbrowser-release && make torbrowser-incrementals-release
```
- Tor Project build machine
- Local developer machine
- [ ] Submit build request to Mullvad infrastructure:
- **NOTE** this requires a devmole authentication token
- **NOTE** this also requires you be connected to Gothenburg Mulvad VPN exit `se-got-wg-101`
- Run:
```bash
make torbrowser-kick-devmole-build
```
</details>
<details>
<summary>Website</summary>
### downloads: https://gitlab.torproject.org/tpo/web/tpo.git
- [ ] `databags/versions.ini`: Update the downloads versions
- `torbrowser-stable/version`: catch-all for latest stable version
- `torbrowser-alpha/version`: catch-all for latest alpha version
- `torbrowser-*-stable/version`: platform-specific stable versions
- `torbrowser-*-alpha/version`: platform-specific alpha versions
- [ ] Push to origin as new branch and create MR
- [ ] Review
- [ ] Merge
- **⚠️ WARNING**: Do not deploy yet!
### blog: https://gitlab.torproject.org/tpo/web/blog.git
- [ ] Generate release blog post
- Run:
```bash
./tools/signing/create-blog-post.torbrowser
```
- **NOTE** this script creates the new blog post from a template (edit `./tools/signing/set-config.blog` to set you local blog directory)
- [ ] **(Optional)** Note any ESR update
- [ ] **(Optional)** Thank any users which have contributed patches
- [ ] **(Optional)** Draft any additional sections for new features which need testing, known issues, etc
- [ ] Push to origin as new branch and open MR
- [ ] Review
- [ ] Merge
- **⚠️ WARNING**: Do not deploy yet!
</details>
<details>
<summary>Signing</summary>
### release signing
- [ ] Assign this issue to the signer, one of:
- boklm
- ma1
- morgan
- pierov
- [ ] Ensure all builders have matching builds
- [ ] Verify the associated legacy `maint-13.5` release has been signed and deployed
- **⚠️ WARNING**: Do not continue if the legacy channel has not been fully signed and published yet; it is needed for update-response generation!
- **NOTE** Stable releases without a corresponding legacy release may ignore this
- [ ] On `${STAGING_SERVER}`, ensure updated:
- **NOTE** Having a local git branch with `maint-14.0` as the upstream branch with these values saved means you only need to periodically `git pull --rebase` and update the `set-config.tbb-version` file
- [ ] `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}`
- [ ] `tor-browser-build/tools/signing/set-config.hosts`
- `ssh_host_builder`: ssh hostname of machine with unsigned builds
- `ssh_host_linux_signer`: ssh hostname of linux signing machine
- `builder_tor_browser_build_dir`: path on `ssh_host_builder` to root of builder's `tor-browser-build` clone containing unsigned builds
- [ ] `tor-browser-build/tools/signing/set-config.rcodesign-appstoreconnect`
- `appstoreconnect_api_key_path`: path to json file containing appstoreconnect api key infos
- [ ] `set-config.update-responses`
- `update_responses_repository_dir`: directory where you cloned `git@gitlab.torproject.org:tpo/applications/tor-browser-update-responses.git`
- [ ] `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
- [ ] On `${STAGING_SERVER}` in a separate `screen` session, ensure tor daemon is running with SOCKS5 proxy on the default port 9050
- [ ] On `${STAGING_SERVER}` in a separate `screen` session, run do-all-signing script:
- Run:
```bash
cd tor-browser-build/tools/signing/ && ./do-all-signing.torbrowser
```
- **NOTE**: on successful execution, the signed binaries and mars should have been copied to `staticiforme` and update responses pushed
</details>
<details>
<summary>Signature verification</summary>
<details>
<summary>Check whether the .exe files got properly signed and timestamped</summary>
```bash
# Point OSSLSIGNCODE to your osslsigncode binary
pushd tor-browser-build/torbrowser/${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>
```bash
# 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/torbrowser/${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
- [ ] On `staticiforme.torproject.org`, static update components:
- Run:
```bash
static-update-component cdn.torproject.org && static-update-component dist.torproject.org
```
- [ ] Deploy `tor-website` MR
- [ ] Deploy `tor-blog` MR
- [ ] On `staticiforme.torproject.org`, enable update responses:
- Run:
```bash
sudo -u tb-release ./deploy_update_responses-release.sh
```
- [ ] On `staticiforme.torproject.org`, remove old release:
- **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)
- [ ] `/srv/cdn-master.torproject.org/htdocs/aus1/torbrowser`
- [ ] `/srv/dist-master.torproject.org/htdocs/torbrowser`
- Run:
```bash
static-update-component cdn.torproject.org && static-update-component dist.torproject.org
```
### Google Play: https://play.google.com/apps/publish
- [ ] Publish APKs to Google Play:
- 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>Communications</summary>
### tor-announce mailing list
- [ ] Email tor-announce mailing list
- **Recipients**
```
tor-announce@lists.torproject.org
```
- **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}
Changelog:
# paste changelog as quote here
```
### packagers
- [ ] Email packagers:
- **Recipients**
- Tails dev mailing list: tails-dev@boum.org
- Guardian Project: nathan@guardianproject.info
- FreeBSD port: freebsd@sysctl.cz <!-- Gitlab user maxfx -->
- OpenBSD port: caspar@schutijser.com <!-- Gitlab user cschutijser -->
- torbrowser-launcher: mail@asciiwolf.com <!-- Gitlab user asciiwolf -->
- Anti-Censorship: meskio@torproject.org <!-- Gitlab user meskio -->
```
tails-dev@boum.org, nathan@guardianproject.info, freebsd@sysctl.cz, caspar@schutijser.com, mail@asciiwolf.com, meskio@torproject.org,
```
- **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}
Changelog:
# paste changelog as quote here
```
- [ ] Note any changes which may affect packaging/downstream integration
</details>
/label ~"Apps::Type::ReleasePreparation"
.gitlab/issue_templates/Release Prep.md deleted 100644 → 0
View file @ 440faf03
<details>
<summary>Explanation of variables</summary>
- `$(BUILD_SERVER)` : the server the main builder is using to build a tor-browser release
- `$(STAGING_SERVER)` : the server the signer is using to to run the signing process
- `$(TOR_LAUNCHER_VERSION)` : version of `tor-launcher`, used in tags
- example : `0.2.33`
- `$(ESR_VERSION)` : the Mozilla defined ESR version, used in various places for building tor-browser tags, labels, etc
- example : `91.6.0`
- `$(ESR_TAG)` : the Mozilla defined hg (Mercurial) tag associated with `$(ESR_VERSION)`
- exmaple : `FIREFOX_91_7_0esr_BUILD2`
- `$(ESR_TAG_PREV)` : the Mozilla defined hg (Mercurial) tag associated with the previous ESR version when rebasing (ie, the ESR version we are rebasing from)
- `$(RR_VERSION)` : the Mozilla defined 'Rapid Relese' version, used in various places for building geckoview tags, labels, etc
- example : `96.0.3`
- `$(RR_TAG)` : the Mozilla defined hg (Mercurial) tag associated with `$(ESR_VERSION)`
- exmaple : `FIREFOX_96_0_3_RELEASE`
- `$(RR_TAG_PREV)` : the Mozilla defined hg (Mercurial) tag associated with the previous ESR version when rebasing (ie, the ESR version we are rebasing from)
- `$(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`
- `$(FIREFOX_BUILD_N)` : the firefox build revision within a given `tor-browser` branch; this is separate from the `$(TOR_BROWSER_BUILD_N) ` value
- example : `build1`
- `$(GECKOVIEW_BUILD_N)` : like `$(FIREFOX_BUILD_N)` but for geckoview branches
- `$(FENIX_BUILD_N)` : like `$(FIREFOX_BUILD_N)` but for fenix branches
- `$(TOR_BROWSER_BUILD_N)` : the tor-browser build revision for a given Tor Browser release; used in tagging git commits
- example : `build2`
- **NOTE** : `$(FIREFOX_BUILD_N)` and `$(TOR_BROWSER_BUILD_N)` typically are 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 `$(FIREFOX_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 `$(FIREFOX_BUILD_N)` will stay the same.
- `$(TOR_BROWSER_VERSION)` : the published Tor Browser version
- example : `11.5a6`, `11.0.7`
- `$(TOR_BROWSER_BRANCH)` : the full name of tor-browser branch
- typically of the form: `tor-browser-$(ESR_VERSION)esr-$(TOR_BROWSER_MAJOR).$(TOR-BROWSER_MINOR)-1`
- `$(TOR_BROWSER_BRANCH_PREV)` : the full name of the previous tor-browser branch (when rebasing)
- `$(GECKOVIEW_BRANCH)` : the full name of geckoview branch
- typically of the form: `tor-browser-$(RR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR-BROWSER_MINOR)-1`
- `$(GECKOVIEW_BRANCH_PREV)` : the full name of the previous geckoview branch (when rebasing)
</details>
<details>
<summary>Desktop</summary>
### **torbutton** ***(Optional)***: https://git.torproject.org/torbutton.git
- [ ] ***(Optional)*** Update translations :
- **NOTE** : mandatory if we have added new string dependencies
- [ ] `./import-translations.sh`
- [ ] Commit with message `Translation updates
- **NOTE** : only add files which are already being tracked
- [ ] *(Optional)* Backport to maintenance branch if present
- [ ] fixup! `tor-browser`'s `Bug 10760 : Integrate TorButton to TorBrowser core` issue to point to updated `torbutton` commit
### **tor-launcher** ***(Optional)***: https://git.torproject.org/tor-launcher.git
- [ ] ***(Optional)*** Update translations:
- **NOTE** : mandatory if we have added new string dependencies
- [ ] ./localization/import-translations.sh
- [ ] Update `install.rdf` file with new version
- [ ] Sign/Tag commit :
- Tag : `$(TOR_LAUNCHER_VERSION)`
- Message `Tagging $(TOR_LAUNCHER_VERSION)`
- [ ] Push `master` and tag to origin
### tor-browser: https://git.torproject.org/tor-browser.git
- [ ] ***(Optional)*** Rebase to `$(ESR_VERSION)`
- [ ] Find the Firefox hg tag here : https://hg.mozilla.org/releases/mozilla-esr91/tags
- [ ] `$(ESR_TAG)` : `INSERT_TAG_HERE`
- [ ] Identify the hg patch associated with above hg tag, and find the equivalent `gecko-dev` git commit (search by commit message)
- [ ] `gecko-dev` commit : `INSERT_COMMIT_HASH_HERE`
- [ ] Create new `tor-browser` branch with the discovered `gecko-dev` commit as `HEAD` named `tor-browser-$(ESR_VERSION)esr-$(TOR_BROWSER_MAJOR).$(TOR-BROWSER_MINOR)-1`
- [ ] Sign/Tag commit :
- Tag : `$(ESR_TAG)`
- Message : `Hg tag $(ESR_TAG)`
- [ ] Push new branch and tag to origin
- [ ] Rebase `tor-browser` patches
- [ ] Perform rangediff to ensure nothing weird happened resolving conflicts
- `git range-diff $(ESR_TAG_PREV)..$(TOR_BROWSER_BRANCH_PREV) $(ESR_TAG)..$(TOR_BROWSER_BRANCH)`
- [ ] Open MR for the rebase
- [ ] _TODO: tag base firefox no-tor browser_
- [ ] ***(Optional)*** Backport any required patches to Stable
- [ ] cherry-pick patches on top of rebased branch (issues to backport should have `Backport` label and be linked to the associated `Release Prep` issue
- [ ] Close associated `Backport` issues
- [ ] Open MR for the backport commits
- [ ] Sign/Tag commit :
- Tag : `tor-browser-$(ESR_VERSION)esr-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1-$(FIREFOX_BUILD_N)`
- Message : `Tagging $(FIREFOX_BUILD_N) for $(ESR_VERSION)esr-based (alpha|stable)`
- [ ] Push tag to origin
</details>
<details>
<summary>Android</summary>
### **geckoview**: https://git.torproject.org/tor-browser.git
- [ ] ***(Optional)*** Rebase to `$(RR_VERSION)`
- [ ] Find the Firefox hg tag here : https://hg.mozilla.org/releases/mozilla-release/tags
- [ ] `$(RR_TAG)` : `INSERT_TAG_HERE`
- [ ] Identify the hg patch associated with above hg tag, and find the equivalent `gecko-dev` git commit (search by commit message)
- [ ] `gecko-dev` commit : `INSERT_COMMIT_HASH_HERE`
- [ ] Create new `geckoview` branch with the discovered `gecko-dev` commit as `HEAD` named `geckoview-$(RR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR-BROWSER_MINOR)-1`
- [ ] Sign/Tag commit :
- Tag : `$(RR_TAG)`
- Message : `Hg tag $(RR_TAG)`
- [ ] Push new branch and tag to origin
- [ ] Rebase `geckoview` patches
- [ ] Perform rangediff to ensure nothing weird happened resolving conflicts
- `git range-diff $(RR_TAG_PREV)..$(GECKOVIEW_BRANCH_PREV) $(RR_TAG)..$(GECKOVIEW_BRANCH)`
- [ ] Open MR for the rebase
- [ ] Merge + Push
- [ ] ***(Optional)*** Backport any required patches to Stable
- [ ] cherry-pick patches on top of rebased branch (issues to backport should have `Backport` label and be linked to the associated `Release Prep` issue
- [ ] Close associated `Backport` issues
- [ ] Open MR for the backport commits
- [ ] Merge + Push
- [ ] Sign/Tag commit :
- Tag : `geckoview-$(RR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1-$(FIREFOX_BUILD_N)`
- Message : `Tagging $(FIREFOX_BUILD_N) for $(RR_VERSION)-based (alpha|stable)`
- [ ] Push tag to origin
### **tba-translation** ***(Optional)***: https://git.torproject.org/translation.git
- [ ] Fetch latest and identify new HEAD of `fenix-torbrowserstringsxml` branch
- [ ] `origin/fenix-torbrowserstringsxml` : `INSERT COMMIT HASH HERE`
### **android-components** ***(Optional)***: https://gitlab.torproject.org/tpo/applications/android-components.git
- [ ] ***(Optional)*** Rebase to `$(RR_VERSION)`
- Upstream git repo : https://github.com/mozilla-mobile/android-components.git
- [ ] Identify the `mozilla-mobile` git tag to start from
- Seem to be in the form `v$(RR_VERSION)` (for example, `v99.0.3`)
- [ ] Create new branch from tag named `android-components-$(RR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1`
- [ ] Push new branch to origin
- [ ] Rebase `android-components` patches
- [ ] Perform rangediff to ensure nothing weird happened resolving conflicts
- [ ] Open MR for the rebase
- [ ] Merge + Push
- [ ] ***(Optional)*** Backport any required patches to Stable
- [ ] cherry-pick patches on top of rebased branch (issues to backport should have `Backport` label and be linked to the associated `Release Prep` issue
- [ ] Close associated `Backport` issues
- [ ] Open MR for the backport commits
- [ ] Merge + Push
- [ ] Sign/Tag commit:
- Tag : `android-components-$(RR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1-$(BUILD_N)`
- Message: `Tagging $(BUILD_N) for $(RR_VERSION)-based (alpha|stable)`
- [ ] Push tag to origin
### **tor-android-service** ***(Optional)***: https://git.torproject.org/tor-android-service.git
- [ ] Fetch latest and identify new HEAD of `master` branch
- [ ] `origin/master` : `INSERT COMMIT HASH HERE`
### **fenix** ***(Optional)***: https://gitlab.torproject.org/tpo/applications/fenix.git
- [ ] ***(Optional)*** Rebase to `$(RR_VERSION)`
- Upstream git repo : https://github.com/mozilla-mobile/fenix.git
- [ ] Identify the `mozilla-mobile` git tag to start from
- Seem to be in the form `v$(RR_VERSION)` (for example, `v96.3.0`)
- [ ] Create new branch from tag named `tor-browser-$(RR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1`
- **NOTE** : it is weird but we do use `tor-browser` here rather than `fenix`
- [ ] Push new branch to origin
- [ ] Rebase `fenix` patches
- [ ] Perform rangediff to ensure nothing weird happened resolving conflicts
- [ ] Open MR for the rebase
- [ ] Merge + Push
- ***(Optional)*** Backport any required patches to Stable
- [ ] ***(Optional)*** Backport any required patches to Stable
- [ ] cherry-pick patches on top of rebased branch (issues to backport should have `Backport` label and be linked to the associated `Release Prep` issue
- [ ] Close associated `Backport` issues
- [ ] Open MR for the backport commits
- [ ] Merge + Push
- [ ] Sign/Tag commit:
- Tag : `tor-browser-$(RR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1-$(BUILD_N)`
- Message: `Tagging $(BUILD_N) for $(RR_VERSION)-based (alpha|stable)`
- [ ] Push tag to origin
</details>
<details>
<summary>Build/Signing/Publishing</summary>
### tor-browser-build: https://git.torproject.org/builders/tor-browser-build.git
Tor Browser Alpha (and Nightly) are on the `master` branch, while Stable lives in the various `$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-maint` (and possibly more specific) branches
- [ ] Update `rbm.conf`
- [ ] `var/torbrowser_version` : update to next version
- [ ] `var/torbrowser_build` : update to `$(TOR_BROWSER_BUILD_N)`
- [ ] `var/torbrowser_incremental_from` : update to previous version
- [ ] **IMPORTANT**: Really actually make sure this is the previous Desktop version or else the `make incrementals-*` step will fail
- [ ] Update `projects/firefox/config`
- [ ] `git_hash` : update the `$(FIREFOX_BUILD_N)` section to match `tor-browser` tag
- [ ] ***(Optional)*** `var/firefox_platform_version` : update to latest $(ESR_VERSION) if rebased
- [ ] ***(Android Only)*** Update `projects/geckoview/config`
- [ ] `git_hash` : update the `$(GECKOVIEW_BUILD_N)` section to match `geckoview` tag
- [ ] ***(Optional)*** `var/geckoview_version` : update to latest `$(RR_VERSION)` if rebased
- [ ] ***(Android Only, Optional)*** Update `projects/tba-translations/config`:
- [ ] `git_hash` : update with HEAD commit of project's `fenix-torbrowserstringsxml` branch
- [ ] ***(Android Only, Optional)*** Update `projects/tor-android-service/config`
- [ ] `git_hash` : update with HEAD commit of project's `master` branch
- [ ] ***(Android Only, Optionl)*** Update `projects/fenix/config`
- [ ] `git_hash` : update the `$(FENIX_BUILD_N)` section to match `fenix` tag
- [ ] ***(Optional)*** `var/fenix_version` : update to latest `$(RR_VERSION)` if rebased
- [ ] ***(Android Only)*** Update allowed_addons.json by running (from `tor-browser-build` root)`./tools/fetch_allowed_addons.py > projects/tor-browser/allowed_addons.json
- [ ] Check for NoScript updates here : https://addons.mozilla.org/en-US/firefox/addon/noscript
- [ ] ***(Optional)*** If version available, update `noscript` section of `input_files` in `projects/tor-browser/config`
- [ ] `URL`
- [ ] `sha256sum`
- [ ] Check for openssl updates here : https://github.com/openssl/openssl/tags
- [ ] ***(Optional)*** If new 1.X.Y series tag available, update `projects/openssl/config`
- [ ] `version` : update to next 1.X.Y release tag
- [ ] `input_files/sha256sum` : update to sha256 sum of source tarball
- [ ] Check for tor updates here : https://gitlab.torproject.org/tpo/core/tor/-/tags ; Tor Browser Alpha uses `-alpha` tagged tor, while stable uses the stable series
- [ ] ***(Optional)*** If new tor version is available, update `projects/tor/config`
- [ ] `version` : update to next release tag
- [ ] Check for go updates here : https://golang.org/dl (Tor Browser Alpha uses the latest Stable go version, while Tor Browser Stable uses the latest of the previous Stable major series version (eg: if Tor Browser Alpha is on the go1.17 series, Tor Browser Stable is on the go1.16 series)
- [ ] ***(Optional)*** If new go version is available, 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)
- [ ] Update `ChangeLog.txt`
- [ ] Ensure ChangeLog.txt is sync'd between alpha and stable branches
- [ ] Open MR with above changes
- [ ] Begin build on `$(BUILD_SERVER)`
- [ ] Sign/Tag commit : `make signtag-(alpha|release)`
- [ ] Push tag to origin
### notify stakeholders
- [ ] Email tor-qa mailing list: tor-qa@lists.torproject.org
- [ ] Provide links to unsigned builds on `$(BUILD_SERVER)`
- [ ] Call out any new functionality which needs testing
- [ ] Link to any known issues
- [ ] Email Tails dev mailing list: tails-dev@boum.org
- [ ] Provide links to unsigned builds on `$(BUILD_SERVER)`
### blog: https://gitlab.torproject.org/tpo/web/blog.git
- [ ] 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 :
- [ ] Update Tor Browser version numbers
- [ ] Note any ESR rebase
- [ ] Note any Rapid Release rebase
- [ ] Link to any Firefox security updates
- [ ] Note any updates to :
- [ ] tor
- [ ] openssl
- [ ] go
- [ ] noscript
- [ ] Convert ChangeLog.txt to markdown format used here by : `tor-browser-build/tools/changelog-format-blog-post`
- [ ] Push to origin as new branch, open 'Draft :' MR
- [ ] Remove draft from MR once signed-packages are uploaded
- [ ] Merge
### website: https://gitlab.torproject.org/tpo/web/tpo.git
- [ ] `databags/versions.ini` : Update the downloads versions
- `torbrowser-stable/version` : sort of a catch-all for latest stable version
- `torbrowser-stable/win32` : tor version in the expert bundle
- `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
- [ ] Push to origin as new branch, open 'Draft :' MR
- [ ] Remove draft from MR once signed-packages are uploaded
- [ ] Merge
### signing + publishing
- [ ] Ensure builders have matching builds
- [ ] On `$(STAGING_SERVER)`, ensure updated:
- [ ] `tor-browser-build/tools/signing/set-config`
- [ ] `NSS_DB_DIR` : location of the `nssdb7` directory
- [ ] `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
- [ ] `ssh_host_macos_signer` : ssh hostname of macOS signing machine
- [ ] `tor-browser-build/tools/signing/set-config.macos-notarization`
- [ ] `macos_notarization_user` : the email login for a tor notariser Apple Developer account
- [ ] `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
- [ ] On `$(STAGING_SERVER)` in a separate `screen` session, run the macOS proxy script:
- `cd tor-browser-build/tools/signing/`
- `./macos-signer-proxy`
- [ ] On `$(STAGING_SERVER)` in a separate `screen` session, ensure tor daemon is running with SOCKS5 proxy on the default port 9050
- [ ] ***(Android Only)*** : *TODO*
- [ ] run do-all-signing script:
- `cd tor-browser-build/tools/signing/`
- `./do-all-signing.sh`
- **NOTE**: at this point the signed desktop binaries should have been copied to `staticiforme`
- [ ] Update `staticiforme.torproject.org`:
- From `screen` session on `staticiforme.torproject.org`
- [ ] Static update components : `static-update-component cdn.torproject.org && static-update-component dist.torproject.org`
- [ ] Enable update responses :
- [ ] alpha: `./deploy_update_responses-alpha.sh`
- [ ] release: `./deploy_update_responses-release.sh`
- [ ] ***(Android Only)*** : Publish APKs to Google Play
- [ ] Log into https://play.google.com/apps/publish
- Select correct app:
- [ ] Tor Browser
- [ ] Tor Browser Alpha
- [ ] Navigate to `Release > Production` and click `Create new release` button
- [ ] Upload the `*.multi.apk` APKs
- [ ] If necessary, update the 'Release Name' (should be automatically populated)
- [ ] 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
- [ ] ***Optional*** Update rollout percentage to 100% after confirmed no major issues
### tor-announce mailing list
- [ ] ***(Stable release only)*** : send an email to tor-announce@lists.torproject.org, using the same content as the blog post and subject "Tor Browser $version is released".
</details>
/label ~"Release Prep"
.gitlab/issue_templates/Uplift.md 0 → 100644
View file @ 136839a7
<!--
Title:
Uplift tor-browser-build#12345: Title of Issue
This is an issue for tracking uplift of a patch-set to an upstream build-dependency (e.g. MinGW, clang, etc)
-->
## Uplift Patchset
### Book-keeping
#### Gitlab Issue(s)
- tor-browser-build#12345
#### Merge Request(s)
- tor-browser-build!1234
#### Upstream Project Issue(s):
### Notes
<!-- whatever additional info, context, etc that would be helpful for uplifting -->
/label ~"Apps::Type::Uplift"
.gitlab/merge_request_templates/default.md 0 → 100644
View file @ 136839a7
## Merge Info
<!-- Bookkeeping information for release management -->
### Issues
#### Resolves
- tor-browser-build#xxxxx
- tor-browser#xxxxx
- mullvad-browser#xxxxx
#### Related
- tor-browser-build#xxxxx
- tor-browser#xxxxx
- mullvad-browser#xxxxx
### Merging
<!-- This block tells the merger where commits need to be merged and future code archaeologists where commits were *supposed* to be merged -->
#### Target Branches
- [ ] **`main`**: esr128-14.5
- [ ] **`maint-14.0`**: esr128-14.0
- [ ] **`maint-13.5`**: esr115-13.5
### Backporting
#### Timeline
- [ ] **No Backport (preferred)**: patchset for the next major stable
- [ ] **Immediate**: patchset needed as soon as possible
- [ ] **Next Minor Stable Release**: patchset that needs to be verified in nightly before backport
- [ ] **Eventually**: patchset that needs to be verified in alpha before backport
#### (Optional) Justification
- [ ] **Emergency security update**: patchset fixes CVEs, 0-days, etc
- [ ] **Censorship event**: patchset enables censorship circumvention
- [ ] **Critical bug-fix**: patchset fixes a bug in core-functionality
- [ ] **Consistency**: patchset which would make development easier if it were in both the alpha and release branches; developer tools, build system changes, etc
- [ ] **Sponsor required**: patchset required for sponsor
- [ ] **Other**: please explain
### Issue Tracking
- [ ] Link resolved issues with appropriate [Release Prep issue](https://gitlab.torproject.org/groups/tpo/applications/-/issues/?sort=updated_desc&state=opened&label_name%5B%5D=Apps%3A%3AType%3A%3AReleasePreparation&first_page_size=20) for changelog generation
### Uplifting
- [ ] Patchset is a candidate for uplift to upstream projects (e.g. mingw, clang, etc)
### Review
#### Request Reviewer
- [ ] Request review from an applications developer depending on modified system:
- **NOTE**: if the MR modifies multiple areas, please `/cc` all the relevant reviewers (since gitlab only allows 1 reviewer)
- **accessibility** : henry
- **android** : clairehurst, dan
- **build system** : boklm
- **extensions** : ma1
- **firefox internals (XUL/JS/XPCOM)** : jwilde, ma1
- **fonts** : pierov
- **frontend (implementation)** : henry
- **frontend (review)** : donuts, morgan
- **localization** : henry, pierov
- **macOS** : clairehurst, dan
- **nightly builds** : boklm
- **rebases/release-prep** : boklm, dan, ma1, morgan, pierov
- **security** : jwilde, ma1
- **signing** : boklm, morgan
- **updater** : pierov
- **windows** : jwilde, morgan
- **misc/other** : morgan, pierov
#### Change Description
<!-- Whatever context the reviewer needs to effectively review the patchset; if the patch includes UX updates be sure to include screenshots/video of how any new behaviour -->
#### How Tested
<!-- Description of steps taken to verify the change -->
.gitlab/merge_request_templates/relprep.md 0 → 100644
View file @ 136839a7
## Release Prep
### Issues
#### Resolves
- tor-browser-build#xxxxx
- tor-browser-build#xxxxx
#### Related
- tor-browser-build#xxxxx
- tor-browser#xxxxx
- mullvad-browser#xxxxx
### Self-review + reviewer's template
- [ ] `rbm.conf` updates:
- [ ] `var/torbrowser_version`
- [ ] `var/torbrowser_build`: should be `build1`, unless bumping a previous release preparation
- [ ] `var/browser_release_date`: must not be in the future when we start building
- [ ] `var/torbrowser_incremental_from` (not needed for Android-only releases)
- [ ] `var/torbrowser_legacy_version` (For Tor Browser 14.0.x stable releases only)
- [ ] `var/torbrowser_legacy_platform_version` (For Tor Browser 14.0.x stable releases only)
- [ ] Tag updates:
- [ ] [Firefox](https://gitlab.torproject.org/tpo/applications/tor-browser/-/tags)
- [ ] Geckoview - should match Firefox
- **NOTE**: Tags might be speculative in the release preparation: i.e., they might not exist yet.
- [ ] Addon updates:
- [ ] [NoScript](https://addons.mozilla.org/en-US/firefox/addon/noscript/)
- [ ] [uBlock Origin](https://addons.mozilla.org/en-US/firefox/addon/ublock-origin/) (Mullvad Browser only)
- [ ] [Mullvad Browser Extension](https://github.com/mullvad/browser-extension/releases) (Mullvad Browser only)
- ⚠️ **IMPORTANT**: For AMO extension (NoScript and uBlock), updating the version in the URL is not enough, check that also a numeric ID from the URL has changed
- [ ] Tor and dependencies updates (Tor Browser only)
- [ ] [Tor](https://gitlab.torproject.org/tpo/core/tor/-/tags)
- [ ] [OpenSSL](https://www.openssl.org/source/): we stay on the latest LTS channel (currently 3.0.x)
- [ ] [zlib](https://github.com/madler/zlib/releases)
- [ ] [Zstandard](https://github.com/facebook/zstd/releases) (Android only, at least for now)
- [ ] [Go](https://go.dev/dl): avoid major updates, unless planned
- [ ] Manual version update (Tor Browser only, optional)
- [ ] Changelogs
- [ ] Check the browser name
- [ ] Check the version
- [ ] Check the release date
- [ ] Check we include only the platform we're releasing for (e.g., no Android in desktop-only releases)
- [ ] Check all the updates from above are reported in the changelogs
- [ ] Check for major errors
- If you find errors such as platform or category (build system) please adjust the issue label accordingly
- You can run `tools/relprep.py --only-changelogs --date $date $version` to update only the changelogs
### Review
#### Request Reviewer
- [ ] Request review from a release engineer: boklm, dan, ma1, morgan, pierov
#### Change Description
.gitmodules
View file @ 136839a7
[submodule "rbm"]
path = rbm
url = https://git.torproject.org/builders/rbm.git
url = https://gitlab.torproject.org/tpo/applications/rbm.git
ChangeLog-MB.txt 0 → 120000
View file @ 136839a7
projects/browser/Bundle-Data/Docs-MB/ChangeLog.txt
\ No newline at end of file
ChangeLog-TBB.txt 0 → 120000
View file @ 136839a7
projects/browser/Bundle-Data/Docs-TBB/ChangeLog.txt
\ No newline at end of file
ChangeLog.txt deleted 120000 → 0
View file @ 440faf03
projects/tor-browser/Bundle-Data/Docs/ChangeLog.txt
\ No newline at end of file
LICENSE
View file @ 136839a7
......@@ -2,7 +2,7 @@ This file contains the license for the build recipes and tools used in
the Tor Browser development process, that are included in this repository.
For the license of specific components included in Tor Browser, see
directory projects/tor-browser/Bundle-Data/Docs/Licenses.
directory projects/browser/Bundle-Data/Docs/Licenses.
===============================================================================
......
Makefile
View file @ 136839a7
This diff is collapsed.
README
View file @ 136839a7
......@@ -12,13 +12,16 @@ newuidmap and newgidmap commands.
The sources of most components are downloaded using git, which needs to
be installed.
Zstandard (zstd) is used to compress some tarballs and needs to be
installed. You'll also need tar >= 1.31, for zstd support.
You also need a few perl modules installed:
- YAML::XS
- File::Basename
- Getopt::Long
- Template
- IO::Handle
- IO::CaptureOutput
- Capture::Tiny
- JSON
- File::Temp
- Path::Tiny
......@@ -31,27 +34,62 @@ You also need a few perl modules installed:
- Data::UUID
- Data::Dump
- DateTime
- XML::Writer
- Parallel::ForkManager
If you are running Debian or Ubuntu, you can install them with:
# apt-get install libyaml-libyaml-perl libtemplate-perl libdatetime-perl \
libio-handle-util-perl libio-all-perl \
libio-captureoutput-perl libjson-perl libpath-tiny-perl \
libstring-shellquote-perl libsort-versions-perl \
libdigest-sha-perl libdata-uuid-perl libdata-dump-perl \
libfile-copy-recursive-perl libfile-slurp-perl git \
uidmap
# apt-get install libdata-dump-perl libdata-uuid-perl libdatetime-perl \
libdigest-sha-perl libfile-copy-recursive-perl \
libfile-slurp-perl libio-all-perl libcapture-tiny-perl \
libio-handle-util-perl libjson-perl \
libparallel-forkmanager-perl libpath-tiny-perl \
libsort-versions-perl libstring-shellquote-perl \
libtemplate-perl libxml-libxml-perl libxml-writer-perl \
libyaml-libyaml-perl git uidmap zstd
If you are running Fedora, CentOS or RHEL, you can install them with:
# dnf install "perl(YAML::XS)" "perl(File::Basename)" "perl(Getopt::Long)" \
"perl(Template)" "perl(IO::Handle)" "perl(Capture::Tiny)" \
"perl(JSON)" "perl(File::Temp)" "perl(Path::Tiny)" \
"perl(File::Path)" "perl(File::Slurp)" \
"perl(File::Copy::Recursive)" "perl(String::ShellQuote)" \
"perl(Sort::Versions)" "perl(Digest::SHA)" "perl(Data::UUID)" \
"perl(Data::Dump)" "perl(DateTime)" "perl(XML::Writer)" \
"perl(Parallel::ForkManager)" perl-ph git zstd
If you are running an Arch based system, you should be able to install them with:
# pacman -S perl-datetime perl-path-tiny perl-yaml perl-yaml-libyaml \
perl-yaml-tiny perl-template-toolkit perl-capture-tiny \
perl-file-copy-recursive perl-string-shellquote \
perl-sort-versions perl-data-uuid perl-data-dump perl-json \
perl-digest-sha1 perl-io-all perl-file-slurp perl-sys-syscall \
perl-parallel-forkmanager perl-xml-libxml perl-lwp-protocol-https \
zstd
On Arch based systems you also need to generate some .ph files RBM expects:
# cd /usr/include/sys; h2ph syscall.h
# cd /usr/include/; h2ph asm/unistd.h asm/unistd_64.h bits/syscall.h
The build system is based on rbm, which is included as a git submodule
in the rbm/ directory. You can fetch the rbm git submodule by running
'make submodule-update'.
The build uses user_namespaces(7), which are disabled by default on Debian.
To enable them you can use the following command as root:
The build uses user_namespaces(7), which are disabled by default on Debian
and on Ubuntu v24.04 and later. To enable them on Debian you can use the
following command as root:
# sysctl -w kernel.unprivileged_userns_clone=1
You can enable them permanently by adding the setting to /etc/sysctl.d/
To enable them on Ubuntu v24.04 and later, you can use the following command
as root:
# sysctl -w kernel.apparmor_restrict_unprivileged_userns=0
You can enable them permanently by adding the settings to /etc/sysctl.d/
The user you use to build needs to have a range of subordinate uids and
gids in /etc/subuid and /etc/subgid. Most of the time they are added by
......@@ -70,9 +108,10 @@ channel you want to build:
$ make torbrowser-alpha
$ make torbrowser-nightly
You can find the build result in the directory release/unsigned/$version
or alpha/unsigned/$version for release or alpha builds. The result of
nightly can be found in the nightly/$version directory.
You can find the build result in the directory
torbrowser/release/unsigned/$version or torbrowser/alpha/unsigned/$version
for release or alpha builds. The result of nightly can be found in the
torbrowser/nightly/$version directory.
If you want to build for a specific platform only, append the platform
name to the makefile target:
......@@ -81,7 +120,7 @@ name to the makefile target:
$ make torbrowser-nightly-linux-i686
$ make torbrowser-nightly-windows-i686
$ make torbrowser-nightly-windows-x86_64
$ make torbrowser-nightly-osx-x86_64
$ make torbrowser-nightly-macos
$ make torbrowser-nightly-android-armv7
$ make torbrowser-nightly-android-aarch64
$ make torbrowser-nightly-android-x86
......@@ -95,9 +134,9 @@ mar file will be created. If you want to base your testbuild on the latest
nightly code insted, rename rbm.local.conf.example to rbm.local.conf
and adapt the torbrowser-testbuild option accordingly.
Similar makefile targets exist for building Base Browser instead of
Tor Browser. To build Base Browser, replace `torbrowser` by `basebrowser`
in the target name.
Similar makefile targets exist for building Base Browser and Privacy Browser
instead of Tor Browser. To build Base Browser, replace `torbrowser` by
`basebrowser` in the target name. For Privacy Browser, use `privacybrowser`.
Updating git sources
......@@ -155,18 +194,9 @@ Automated builds using tbb-testsuite
------------------------------------
The Tor Browser testsuite scripts can also be used to do nightly builds
and publish the build logs. The recommended way to do that is to use
the ansible roles from the tools/ansible directory. See next section
for details.
Using ansible to set up a nightly build machine
-----------------------------------------------
The directory tools/ansible contains some ansible roles to set up a
nightly build machine. You can look at the playbook defined in
boklm-tbb-nightly-build.yml and variables in group_vars/boklm-tbb-nightly/
for an example of how it can be used.
and publish the build logs. This page has some information about the
setup we use for nightly builds:
https://gitlab.torproject.org/tpo/applications/tor-browser/-/wikis/Nightly_Builds_Setup
Signing builds
......@@ -209,15 +239,19 @@ of containers: the container-image project is still called, but it will
just create an empty file instead of a real container image.
The build without containers is currently only supported for the Android
builds, and will require that you run Debian Buster and install build
dependencies for all the components that are built. This can be done
with the following command:
# apt-get install build-essential python automake libtool zip unzip \
autoconf2.13 openjdk-8-jdk gettext-base autotools-dev \
automake autoconf libtool autopoint libssl-dev \
pkg-config zlib1g-dev libparallel-forkmanager-perl \
libfile-slurp-perl bzip2 xz-utils apksigner yasm
builds, and will require that you run Debian Bullseye or Bookworm and
install build dependencies for all the components that are built. This can
be done with the following command:
# apt-get install 7zip apksigner autoconf autoconf2.13 automake autopoint \
autotools-dev bison bsdiff build-essential bzip2 \
gettext-base gyp jq libfile-slurp-perl \
libparallel-forkmanager-perl libssl-dev libtool libtool \
openjdk-11-jdk pkg-config python3 python3-venv tcl unzip \
wget xz-utils yasm zip zlib1g-dev
Note that Debian Bullseye requires the bullseye-backports repository to
get the 7zip package.
Common Build Errors
......
doc/HACKING.txt
View file @ 136839a7
......@@ -44,13 +44,13 @@ In each of those places, an option can be defined:
The targets are usually used to select:
- the platform: torbrowser-linux-x86_64, torbrowser-linux-i686,
torbrowser-windows-i686, torbrowser-windows-x86_64, torbrowser-osx-x86_64,
torbrowser-windows-i686, torbrowser-windows-x86_64, torbrowser-macos,
torbrowser-android-armv7, torbrowser-android-aarch64, torbrowser-android-x86,
torbrowser-android-x86_64
- the channel: release, nightly, alpha
The targets torbrowser-linux-x86_64, torbrowser-linux-i686,
torbrowser-windows-i686, torbrowser-windows-x86_64, torbrowser-osx-x86_64,
torbrowser-windows-i686, torbrowser-windows-x86_64, torbrowser-macos,
torbrowser-android-armv7, torbrowser-android-x86, torbrowser-android-aarch64,
torbrowser-android-x86_64 are special cases. They do not contain options
directly, instead they contain a list of other targets. For instance, the
......@@ -99,8 +99,8 @@ You can use the following template syntax in the build scripts:
# do something for linux
[% ELSIF c("var/windows") -%]
# do something for windows
[% ELSIF c("var/osx") -%]
# do something for osx
[% ELSIF c("var/macos") -%]
# do something for macOS
[% END -%]
You can also use var/linux-x86_64 and var/linux-i686 for things that
......@@ -117,9 +117,9 @@ depending on the target:
windows-i686:
var:
do_something: 'do something for windows'
osx-x86_64:
macos-x86_64:
var:
do_something: 'do something for osx'
do_something: 'do something for macos'
And in the build script, use:
......@@ -154,7 +154,7 @@ $platform should be one of the following:
- torbrowser-windows-x86_64
- torbrowser-osx-x86_64
- torbrowser-macos
- torbrowser-android-armv7
......@@ -174,10 +174,10 @@ If the component you are looking at has many dependencies, the display
can take some time as various build_id values need to be computed. If
you don't care about the accuracy of input and output file names, you
can add '--target no_build_id' to the command line. For instance, if you
want to look at the build script for the tor-browser component (which
want to look at the build script for the browser component (which
has a lot of dependencies), you can use:
$ ./rbm/rbm showconf tor build --target alpha --target \
$ ./rbm/rbm showconf browser build --target alpha --target \
torbrowser-linux-x86_64 --target no_build_id
The same type of commands can be used to look at any option values,
......@@ -363,7 +363,7 @@ introduced by the testbuild target is the output directory.
By default the testbuild is based on the alpha build. All the options
can have a different definition for the alpha, release and nightly builds.
Usually the git_hash option has a different definition for the nightly
builds in order to point to the master branch.
builds in order to point to the main branch.
If you want your testbuild target to create builds based on nightly
rather than alpha, you can edit your rbm.local.conf file and uncomment
......