The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-09-01T23:42:21Zhttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/62Prepare for s28 PI meeting: May 10 20222022-09-01T23:42:21ZCecylia BocovichPrepare for s28 PI meeting: May 10 2022We've got to make slides, wrap up any ongoing work that we want to report, and coordinate with the rest of our group about what our story/goals are.
We should gather the information we need some days before May 11 (say, by May 5 latest)...We've got to make slides, wrap up any ongoing work that we want to report, and coordinate with the rest of our group about what our story/goals are.
We should gather the information we need some days before May 11 (say, by May 5 latest), so there is enough time to organize it into a coherent presentation and enough time to notice missing things (e.g. graphs and diagrams) and collect them too.Sponsor 28: ONLY PHASE 3 Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)2022-05-11https://gitlab.torproject.org/tpo/web/tpo/-/issues/301URGENT - Please post Software Engineer job to website2022-05-27T22:31:40ZErin WyattURGENT - Please post Software Engineer job to websitePlease post this job to the website as soon as possible. Thank you! :smile:
# Internet Freedom Nonprofit Seeks Software Engineer for Applications Team
May 11th 2022
The Tor Project, Inc., a 501(c)(3) nonprofit organization advancing...Please post this job to the website as soon as possible. Thank you! :smile:
# Internet Freedom Nonprofit Seeks Software Engineer for Applications Team
May 11th 2022
The Tor Project, Inc., a 501(c)(3) nonprofit organization advancing human rights and freedoms by creating and deploying free and open source anonymity and privacy technologies, is seeking an experienced systems programmer to work on the Applications team.
Our Applications Team’s main project is the Tor Browser but we have plans to develop other apps in the near future. We are looking for a full-time developer to join our team to help us with both Tor Browser development and future application development.
Regardless of whether you have all of the required experience, please apply! If you feel that you meet several of the qualifications, or could meet them with a little support, we would love to hear from you.
The team coordinates both synchronously and asynchronously via IRC, email, bug trackers, and some voice meetings. A personal commitment to free and open source software, good communication and documentation skills, and passion for contributing to the greater good are all essential.
This is a full-time, remote position. Salary for this position is $100k USD and there is voluntary opt-in salary transparency for employees and contractors.
## The Job:
- Evaluate and audit recent changes in Firefox, and understand how that affects Tor Browser users
- Support maintaining Tor Browser on top of recent versions of Firefox
- Improve Tor Browser’s security, privacy, and anonymity properties
- Collaborate with Mozilla and directly improve Firefox
- Simplify and improve Tor Browser's current protections
- Support the continuous integration testing framework and tests
- Improve Tor Browser's web compatibility
Our main codebases are a combination of multiple components that make Tor Browser (https://gitlab.torproject.org/tpo/applications/team/-/wikis/Development-Information/Codebases).
For a more detailed understanding of the full breadth and depth of the work you'd be doing, have a look at The Design and Implementation of the Tor Browser, especially The Design Requirements section at https://spec.torproject.org/torbrowser-design#DesignRequirements.
## Preferred Qualifications:
- Be comfortable working remotely with a geographically distributed team.
- Experience interacting with users and other developers online, including experience being confronted with differing ideas and opinions, while maintaining a high level of professionalism.
- Strong ability to become familiar with, modify, and maintain legacy codebases.
- Experience updating and maintaining software build systems.
- Distributed version control systems, including Git.
- Experience developing and debugging software in a Linux environment.
- Familiarity with: JavaScript, HTML, CSS; C++ and Rust; Kotlin and Java.
- Experience developing and debugging software for the Android platform.
- Familiarity and/or experience with writing add-ons and/or patches for Mozilla Firefox or other web browsers.
- Familiarity with web technologies and how the web works, especially the same-origin model and web tracking.
- Familiarity with browser fingerprinting defenses.
- Familiarity with Firefox's internal architecture, including its use of multiple processes and sandboxing.
Again, this is a wish list, and we do not expect any candidate to have experience in all these areas. If you you meet at least several of the qualifications, or could meet them with a little support, please apply!
## How to Apply
To apply, submit a cover letter, your CV/resume, and a link to a code sample or some non-trivial software project you have significantly contributed to. In your cover letter, please include the reason you want to work at the Tor Project and where you heard about this job.
IMPORTANT: Please email application materials **in PDF format** to job-dev at torproject dot org with "Applications Developer" in the subject line.
## About The Tor Project
The Tor Project's workforce is smart, committed, and hard working. We currently have a paid and contract staff of around 28 developers and operational support people, plus many thousands of volunteers who contribute to our work. The Tor Project is funded in part by government research and development grants, and in part by individual, foundation, and corporate donations.
Tor is for everyone, and we are actively working to build a team that represents people from all over the world - people from diverse ethnic, national, and cultural backgrounds; people from all walks of life. We encourage people subject to systemic bias to apply, including people of color, indigenous people, LGBTQIA+ people, women, and any other person who is part of a group that is underrepresented in tech.
We have long-standing community guidelines and cultural norms. Our community is committed to creating an inclusive and welcoming environment. Please read more here:
- The Tor Project Code of Conduct: https://gitweb.torproject.org/community/policies.git/tree/code_of_conduct.txt
- The Tor Project Social Contract: https://gitweb.torproject.org/community/policies.git/tree/social_contract.txt
- The Tor Project Statement of Values: https://gitweb.torproject.org/community/policies.git/tree/statement_of_values.txt
The Tor Project has a competitive benefits package, including a generous PTO policy, 16 paid holidays per year (including the week between Christmas and New Year's, when the office is closed), and flexible work schedule. Insurance benefits vary by employment status and country of residence.
The Tor Project, Inc., is an equal opportunity, affirmative action employer.2022-05-12https://gitlab.torproject.org/tpo/onion-services/onionmine/-/issues/17Adds HARICA's onion-csr tool2022-05-17T21:22:24ZSilvio RhattoAdds HARICA's onion-csr toolAdds [onion-csr](https://github.com/HARICA-official/onion-csr) as a submodule, a compilation procedure and a wrapper to it.Adds [onion-csr](https://github.com/HARICA-official/onion-csr) as a submodule, a compilation procedure and a wrapper to it.Sponsor 123: Tor Secure Access Package for USAGM [First Phase]Silvio RhattoSilvio Rhatto2022-05-13https://gitlab.torproject.org/tpo/tpa/nextcloud/-/issues/6enforce 2FA?2022-05-27T15:31:58ZGabagaba@torproject.orgenforce 2FA?Should we enforce 2FA for all users in the nextcloud instance? People are using the instance more than before and it may makes sense to help it secure.
What about server side encryption? Right now is not enabled.Should we enforce 2FA for all users in the nextcloud instance? People are using the instance more than before and it may makes sense to help it secure.
What about server side encryption? Right now is not enabled.micahmicah@torproject.orgmicahmicah@torproject.org2022-05-18https://gitlab.torproject.org/tpo/tpa/team/-/issues/40745Review new puppet-agent Debian package2022-06-13T14:01:50ZJérôme Charaouilavamind@torproject.orgReview new puppet-agent Debian packagePlease review my work on packaging the new version of puppet agent: https://salsa.debian.org/puppet-team/puppet-agent
The package should also eventually be available from experimental (it's currently sitting in NEW).Please review my work on packaging the new version of puppet agent: https://salsa.debian.org/puppet-team/puppet-agent
The package should also eventually be available from experimental (it's currently sitting in NEW).anarcatanarcat2022-05-19https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40488Prepare stable release 11.0.13 (Desktop+Android)2022-06-08T16:32:04ZrichardPrepare stable release 11.0.13 (Desktop+Android)<details>
<summary>Explanation of variables</summary>
- `$(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 buil...<details>
<summary>Explanation of variables</summary>
- `$(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`
- `$(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_
- [x] ***(Optional)*** Backport any required patches to Stable
- [x] 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
- [x] Open MR for the backport commits
- [x] 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)`
- [x] 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
- [x] ***(Optional)*** Backport any required patches to Stable
- [x] 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
- [x] Open MR for the backport commits
- [x] Merge + Push
- [x] 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)`
- [x] Push tag to origin
### **tba-translation** ***(Optional)***: https://git.torproject.org/translation.git
_TODO_
### **android-components** ***(Optional)***: https://gitlab.torproject.org/tpo/applications/android-components.git
_TODO_
### **tor-android-service** ***(Optional)***: https://git.torproject.org/tor-android-service.git
_TODO_
### **fenix** ***(Optional)***: https://gitlab.torproject.org/tpo/applications/fenix.git
_TODO_
</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
- [x] Update `rbm.conf`
- [x] `var/torbrowser_version` : update to next version
- [x] `var/torbrowser_build` : update to `$(TOR_BROWSER_BUILD_N)`
- [x] `var/torbrowser_incremental_from` : update to previous version
- [x] **IMPORTANT**: Really actually make sure this is the previous Desktop/Android version or else the `make incrementals-*` step will fail
- [x] Update `projects/firefox/config`
- [x] `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
- [x] 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`
- [x] 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
- [x] 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
- [x] 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`
- [x] `version` : update go version
- [x] `input_files/sha256sum` for `go` : update sha256sum of archive (sha256 sums are displayed on the go download page)
- [ ] ***(Android Only)*** Update allowed_addons.json by running (from `tor-browser-build` root)`./tools/fetch_allowed_addons.py > projects/tor-browser/allowed_addons.json
- [ ] Update `ChangeLog.txt`
- [ ] Open MR with above changes
- [ ] Begin build on `tb-build-03`
- [ ] Sign/Tag commit : `make signtag-(alpha|release)`
- [ ] Push tag to origin
### notify tor-qa
- [ ] Email tor-qa@lists.torproject.org
- [ ] Provide links to unsigned builds on `tb-build-03`
- [ ] Call out any new funcionality which needs testing
- [ ] Link to any known issues
### blog: https://gitlab.torproject.org/tpo/web/blog.git
- [x] Duplicate previous Stable or Alpha release blog post as appropriate to new directory under `content/blog/new-release-tor-browser-$(TOR_BROWSER_VERSION)` and update with info on release :
- [x] Update Tor Browser version numbers
- [ ] Note any ESR rebase
- [ ] Note any Rapid Release rebase
- [x] Link to any Firefox security updates
- [ ] Note any updates to :
- [ ] tor
- [ ] openssl
- [ ] go
- [ ] noscript
- [x] Convert ChangeLog.txt to markdown format used here by : `tor-browser-build/tools/changelog-format-blog-post`
- [x] Push to origin as new branch, open 'Draft :' MR
- [x] Remove draft from MR once signed-packages are uploaded
### website: https://gitlab.torproject.org/tpo/web/tpo.git
- [x] `databags/versions.ini` : Update the downloads versions
- `torbrowser-stable/version` : sort of a catch-all for latest stable version
- `torbrowser-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
- [x] Push to origin as new branch, open 'Draft :' MR
- [x] Remove draft from MR once signed-packages are uploaded
### signing
_TODO: boklm's fancy new signing+uploading scripts_
</details>2022-05-20https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40486Prepare alpha release 11.5a12 (Desktop+Android)2022-06-08T16:32:06ZrichardPrepare alpha release 11.5a12 (Desktop+Android)<details>
<summary>Explanation of variables</summary>
- `$(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 buil...<details>
<summary>Explanation of variables</summary>
- `$(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`
- `$(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_
- [x] ***(Optional)*** Backport any required patches to Stable
- [x] 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
- [x] Open MR for the backport commits
- [x] 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)`
- [x] 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
_TODO_
### **android-components** ***(Optional)***: https://gitlab.torproject.org/tpo/applications/android-components.git
_TODO_
### **tor-android-service** ***(Optional)***: https://git.torproject.org/tor-android-service.git
_TODO_
### **fenix** ***(Optional)***: https://gitlab.torproject.org/tpo/applications/fenix.git
_TODO_
</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
- [x] Update `rbm.conf`
- [x] `var/torbrowser_version` : update to next version
- [x] `var/torbrowser_build` : update to `$(TOR_BROWSER_BUILD_N)`
- [x] `var/torbrowser_incremental_from` : update to previous version
- [x] **IMPORTANT**: Really actually make sure this is the previous Desktop/Android version or else the `make incrementals-*` step will fail
- [x] Update `projects/firefox/config`
- [x] `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
- [x] 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`
- [x] 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
- [x] 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
- [x] 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`
- [x] `version` : update go version
- [x] `input_files/sha256sum` for `go` : update sha256sum of archive (sha256 sums are displayed on the go download page)
- [x] ***(Android Only)*** Update allowed_addons.json by running (from `tor-browser-build` root)`./tools/fetch_allowed_addons.py > projects/tor-browser/allowed_addons.json
- [x] Update `ChangeLog.txt`
- [x] Open MR with above changes
- [ ] Begin build on `tb-build-03`
- [x] Sign/Tag commit : `make signtag-(alpha|release)`
- [x] Push tag to origin
### notify tor-qa
- [ ] Email tor-qa@lists.torproject.org
- [ ] Provide links to unsigned builds on `tb-build-03`
- [ ] Call out any new funcionality which needs testing
- [ ] Link to any known issues
### blog: https://gitlab.torproject.org/tpo/web/blog.git
- [x] Duplicate previous Stable or Alpha release blog post as appropriate to new directory under `content/blog/new-release-tor-browser-$(TOR_BROWSER_VERSION)` and update with info on release :
- [x] Update Tor Browser version numbers
- [ ] Note any ESR rebase
- [ ] Note any Rapid Release rebase
- [x] Link to any Firefox security updates
- [ ] Note any updates to :
- [ ] tor
- [ ] openssl
- [ ] go
- [ ] noscript
- [x] Convert ChangeLog.txt to markdown format used here by : `tor-browser-build/tools/changelog-format-blog-post`
- [x] Push to origin as new branch, open 'Draft :' MR
- [x] Remove draft from MR once signed-packages are uploaded
### website: https://gitlab.torproject.org/tpo/web/tpo.git
- [x] `databags/versions.ini` : Update the downloads versions
- `torbrowser-stable/version` : sort of a catch-all for latest stable version
- `torbrowser-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
- [x] Push to origin as new branch, open 'Draft :' MR
- [x] Remove draft from MR once signed-packages are uploaded
### signing
_TODO: boklm's fancy new signing+uploading scripts_
</details>richardrichard2022-05-20https://gitlab.torproject.org/tpo/web/team/-/issues/37Extend merge permissions for web projects2022-09-08T14:00:45ZJérôme Charaouilavamind@torproject.orgExtend merge permissions for web projectsCurrently, when members of other teams such as comms or applications want to publish a blog post or a new software release, they need someone from the web team (who have `Maintainer` permissions in tpo/web projects) to accept (merge) the...Currently, when members of other teams such as comms or applications want to publish a blog post or a new software release, they need someone from the web team (who have `Maintainer` permissions in tpo/web projects) to accept (merge) their Merge Request and also to push the latest CI build to production.
This process puts extra load on the web team, as their intervention is required on all web changes, even though some changes are quite trivial and should not require any manual review of MRs. Furthermore, it also puts extra load on the other teams as they need to follow-up at different moments of the publishing process to ensure someone from the web team steps in, otherwise the process is blocked.
I would like to propose to grant the members of projects under [tpo/web](/tpo/web) with **Developper** permission, the power to accept Merge requests. This change would also allow them to trigger manual deployments to production. This way, we will avoid blocking on the web team for small, common and regular website updates. Of course, the web team will remain available to review all the other, more substantial or unusual website updates.
To make this change, under each project's `Settings -> Repository -> Protected branches`, for the `main` branch, the **Allowed to merge** option would change from `Maintainers` to `Maintainers + Developpers`. **Allowed to push** would remain set to `Maintainers` (so Developpers would still always need to submit MRs).
In order to ensure no one is granted permissions they should not have, we should, at the same time, verify that only core contributors of the Tor Project are assigned Developper permissions on these projects.
* [x] [tpo/web/blog](/tpo/web/blog)
* [x] [tpo/web/tpo](/tpo/web/tpo)
* [ ] ~~[tpo/web/donate-static](/tpo/web/donate-static)~~
* [ ] ~~[tpo/web/gettor-web](/tpo/web/gettor-web)~~
* [ ] ~~[tpo/web/manual](/tpo/web/manual)~~
* [ ] ~~[tpo/web/newsletter](/tpo/web/newsletter)~~
* [ ] ~~[tpo/web/research](/tpo/web/research)~~
* [ ] ~~[tpo/web/styleguide](/tpo/web/styleguide)~~
* [ ] ~~[tpo/web/support](/tpo/web/support)~~
/cc @gaba @gus @emmapeel @anarcat @kezGabagaba@torproject.orgGabagaba@torproject.org2022-05-20https://gitlab.torproject.org/tpo/community/relays/-/issues/45Relay Operator Meetup (May 21)2022-05-23T18:42:04ZGusRelay Operator Meetup (May 21)Tasks
* [x] Put together an agenda with the contribution of other teams and relay op community
* [x] BBB room - https://tor.meet.coop/gus-og0-x74-dzn
* [x] Publish the meetup invitation where our community hangout:
* [x] tor-relays ma...Tasks
* [x] Put together an agenda with the contribution of other teams and relay op community
* [x] BBB room - https://tor.meet.coop/gus-og0-x74-dzn
* [x] Publish the meetup invitation where our community hangout:
* [x] tor-relays mailing list
* [x] Twitter
* [x] Mastodon
* [ ] Tor Blog
* [x] r/TOR
* [x] Facilitate the meetup (Saturday, May 21)
* [x] Send the meetup notes to the tor-relays mailing list2022-05-21https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/3Create a local test environment for Conjure client, relay station, and bridge2022-06-30T16:27:34ZCecylia BocovichCreate a local test environment for Conjure client, relay station, and bridgeWe're going to have to work with Eric and the refraction networking relay station maintainers to deploy connect the various Conjure pieces we need. Ideally we'd set up a test environment to try out different details and designs first so ...We're going to have to work with Eric and the refraction networking relay station maintainers to deploy connect the various Conjure pieces we need. Ideally we'd set up a test environment to try out different details and designs first so we're not just testing everything in production.
I've done a Docker-based setup for testing refraction networking (a.k.a decoy routing) before with the [Slitheen test-env](https://gitlab.com/slitheen/test-env). Something similar might be repurposed here.Sponsor 30 - Objective 2.3Cecylia BocovichCecylia Bocovich2022-05-27https://gitlab.torproject.org/tpo/web/newsletter/-/issues/29May 2022 Newsletter2022-06-03T20:39:05Zal smithMay 2022 NewsletterGusGus2022-05-31https://gitlab.torproject.org/tpo/onion-services/onion-launchpad/-/issues/20Update conditional statement to note and direct to Onion Browser when on iOS2022-06-16T13:55:08ZrayaUpdate conditional statement to note and direct to Onion Browser when on iOSWe need to update the conditional statement to say "For iOS you can download **Onion Browser** from the link below" and it should redirect to the following link: https://onionbrowser.com/We need to update the conditional statement to say "For iOS you can download **Onion Browser** from the link below" and it should redirect to the following link: https://onionbrowser.com/Sponsor 123: Tor Secure Access Package for USAGM [First Phase]KezKez2022-05-31https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40505Prepare stable release 11.0.14 (Desktop+Android)2022-06-08T16:31:50ZrichardPrepare stable release 11.0.14 (Desktop+Android)<details>
<summary>Explanation of variables</summary>
- `$(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 buil...<details>
<summary>Explanation of variables</summary>
- `$(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`
- `$(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
- [x] ***(Optional)*** Rebase to `$(ESR_VERSION)`
- [x] Find the Firefox hg tag here : https://hg.mozilla.org/releases/mozilla-esr91/tags
- [x] `$(ESR_TAG)` : `FIREFOX_91_10_0esr_BUILD1`
- [x] Identify the hg patch associated with above hg tag, and find the equivalent `gecko-dev` git commit (search by commit message)
- [x] `gecko-dev` commit : `2010fcc588669fbdb36cf9953e126c4a6e176643`
- [x] 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`
- [x] Sign/Tag commit :
- Tag : `$(ESR_TAG)`
- Message : `Hg tag $(ESR_TAG)`
- [x] Push new branch and tag to origin
- [x] Rebase `tor-browser` patches
- [x] Perform rangediff to ensure nothing weird happened resolving conflicts
- `git range-diff $(ESR_TAG_PREV)..$(TOR_BROWSER_BRANCH_PREV) $(ESR_TAG)..$(TOR_BROWSER_BRANCH)`
- [x] 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
- [x] 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)`
- [x] 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
_TODO_
### **android-components** ***(Optional)***: https://gitlab.torproject.org/tpo/applications/android-components.git
_TODO_
### **tor-android-service** ***(Optional)***: https://git.torproject.org/tor-android-service.git
_TODO_
### **fenix** ***(Optional)***: https://gitlab.torproject.org/tpo/applications/fenix.git
_TODO_
</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
- [x] Update `rbm.conf`
- [x] `var/torbrowser_version` : update to next version
- [x] `var/torbrowser_build` : update to `$(TOR_BROWSER_BUILD_N)`
- [x] `var/torbrowser_incremental_from` : update to previous version
- [x] **IMPORTANT**: Really actually make sure this is the previous Desktop/Android version or else the `make incrementals-*` step will fail
- [x] Update `projects/firefox/config`
- [x] `git_hash` : update the $(FIREFOX_BUILD_N) section to match `tor-browser` tag
- [x] ***(Optional)*** `var/firefox_platform_version` : update to latest $(ESR_VERSION) if rebased
- [x] Check for NoScript updates here : https://addons.mozilla.org/en-US/firefox/addon/noscript
- [x] ***(Optional)*** If version available, update `noscript` section of `input_files` in `projects/tor-browser/config`
- [x] `URL`
- [x] `sha256sum`
- [x] 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
- [x] 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
- [x] 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)
- [x] ***(Optional)*** If new go version is available, update `projects/go/config`
- [ ] `version` : update go version
- [x] `input_files/sha256sum` for `go` : update sha256sum of archive (sha256 sums are displayed on the go download page)
- [x] ***(Android Only)*** Update allowed_addons.json by running (from `tor-browser-build` root)`./tools/fetch_allowed_addons.py > projects/tor-browser/allowed_addons.json
- [x] Update `ChangeLog.txt`
- [x] Open MR with above changes
- [x] Begin build on `tb-build-03`
- [x] Sign/Tag commit : `make signtag-(alpha|release)`
- [x] Push tag to origin
### notify tor-qa
- [x] Email tor-qa@lists.torproject.org
- [x] Provide links to unsigned builds on `tb-build-03`
- [ ] Call out any new functionality which needs testing
- [ ] Link to any known issues
### blog: https://gitlab.torproject.org/tpo/web/blog.git
- [x] Duplicate previous Stable or Alpha release blog post as appropriate to new directory under `content/blog/new-release-tor-browser-$(TOR_BROWSER_VERSION)` and update with info on release :
- [x] Update Tor Browser version numbers
- [x] Note any ESR rebase
- [ ] Note any Rapid Release rebase
- [x] Link to any Firefox security updates
- [x] Note any updates to :
- [ ] tor
- [ ] openssl
- [ ] go
- [x] noscript
- [x] Convert ChangeLog.txt to markdown format used here by : `tor-browser-build/tools/changelog-format-blog-post`
- [x] Push to origin as new branch, open 'Draft :' MR
- [x] Remove draft from MR once signed-packages are uploaded
- [x] Merge
### website: https://gitlab.torproject.org/tpo/web/tpo.git
- [x] `databags/versions.ini` : Update the downloads versions
- `torbrowser-stable/version` : sort of a catch-all for latest stable version
- `torbrowser-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
- [x] Push to origin as new branch, open 'Draft :' MR
- [x] Remove draft from MR once signed-packages are uploaded
- [x] Merge
### signing + publishing
- [x] Ensure builders have matching builds
- [x] On staging machine, ensure updated:
- [x] `tor-browser-build/tools/signing/set-config`
- [x] `NSS_DB_DIR` : location of the `nssdb7` directory
- [x] `tor-browser-build/tools/signing/set-config.hosts`
- [x] `ssh_host_builder` : ssh hostname of machine with unsigned builds
- **NOTE** : `tor-browser-build` is expected to be in the `$HOME` directory)
- [x] `ssh_host_linux_signer` : ssh hostname of linux signing machine
- [x] `ssh_host_macos_signer` : ssh hostname of macOS signing machine
- [x] `tor-browser-build/tools/signing/set-config.macos-notarization`
- [x] `macos_notarization_user` : the email login for a tor notariser Apple Developer account
- [x] `tor-browser-build/tools/signing/set-config.tbb-version`
- [x] `tbb_version` : tor browser version string, same as `var/torbrowser_version` in `rbm.conf` (examples: `11.5a12`, `11.0.13`)
- [x] `tbb_version_build` : the tor-browser-build build number (if `var/torbrowser_build` in `rbm.conf` is `buildN` then this value is `N`)
- [x] `tbb_version_type` : either `alpha` for alpha releases or `release` for stable releases
- [x] 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`
- [x] Update `staticiforme.torproject.org`:
- From `screen` session on `staticiforme.torproject.org`
- [x] Static update components : `static-update-component cdn.torproject.org && static-update-component dist.torproject.org`
- [x] Enable update responses :
- [ ] alpha: `./deploy_update_responses-alpha.sh`
- [x] release: `./deploy_update_responses-release.sh`
- [ ] ***(Android Only)*** : Publish APKs to Google Play
- [x] Log into https://play.google.com/apps/publish
- Select correct app:
- [x] Tor Browser
- [ ] Tor Browser Alpha
- [x] Navigate to `Release > Production` and click `Create new release` button
- [x] Upload the `*.multi.apk` APKs
- [ ] If necessary, update the 'Release Name' (should be automatically populated)
- [x] Update Release Notes
- [x] Next to 'Release notes', click `Copy from a previous release`
- [x] Edit blog post url to point to most recent blog post
- [x] Save, review, and configure rollout percentage
- [x] 25% rollout when publishing a scheduled update
- [ ] 100% rollout when publishing a security-driven release
- [x] ***Optional*** Update rollout percentage to 100% after confirmed no major issues
</details>richardrichard2022-05-31https://gitlab.torproject.org/tpo/community/training/-/issues/47Tor training with Derechos Digitales and OONI2023-06-30T17:20:58ZGusTor training with Derechos Digitales and OONIDerechos Digitales got in touch with us last week and we're planning to run two workshops about internet measurement, censorship and censorship circumvention in Latam.
OONI will hold the workshop about internet measurement and censorship...Derechos Digitales got in touch with us last week and we're planning to run two workshops about internet measurement, censorship and censorship circumvention in Latam.
OONI will hold the workshop about internet measurement and censorship, and we will talk about censorship circumvention.
These two workshops will happen on May so we can prepare HRDs to cover the national elections in Colombia.Sponsor 9 - Phase 5 - Usability and Community Intervention on Support for Democracy and Human RightsGusGus2022-05-31https://gitlab.torproject.org/tpo/tpa/team/-/issues/40692bullseye upgrades, second batch2024-02-06T18:22:34Zanarcatbullseye upgrades, second batchupgrade the following servers to Debian bullseye:
* [x] bacula-director-01 (@lavamind)
* [x] bungei (@lavamind) psql 13 upgrade @anarcat
* [x] carinatum @anarcat (triggered #40751)
* [x] check-01 @anarcat left tpo/network-health/exi...upgrade the following servers to Debian bullseye:
* [x] bacula-director-01 (@lavamind)
* [x] bungei (@lavamind) psql 13 upgrade @anarcat
* [x] carinatum @anarcat (triggered #40751)
* [x] check-01 @anarcat left tpo/network-health/exitmap#38 also generated tpo/network-health/metrics/exit-scanner#40004, tpo/network-health/metrics/tor-check#40007
* [x] colchicifolium @lavamind
* [x] crm-ext-01 @anarcat
* [x] crm-int-01 @anarcat
* [x] fallax @anarcat
* [x] gayi (yes, it needs to be upgraded, see #17202 ) @anarcat
* [x] ~~gettor-01 - sync with @meskio, AFK on may 2nd, <= 1800UTC otherwise @anarcat~~ no need, will be retired, see #40915
* [x] gitlab-02 @anarcat, planned for Monday, May 30 @ 17:00 UTC
* [x] henryi @anarcat
* [x] majus @lavamind
* [x] mandos-01 @lavamind
* [x] materculae @anarcat led to OOM issues? see #40750
* [x] meronense ~~- do *NOT* upgrade PostgreSQL until we figure out issues with PostgreSQL 13 (#40750 and #40761 )~~ things seem to have resolved themselves @anarcat see https://gitlab.torproject.org/tpo/tpa/team/-/issues/40809 for the Postgresql 13 upgrade
* [x] neriniflorum @lavamind
* [x] nevii @lavamind
* [x] ~~onionbalance-01~~ ([retired](https://gitlab.torproject.org/tpo/tpa/team/-/issues/40710))
* [x] onionbalance-02 @lavamind
* [x] onionoo-backend-01 @lavamind
* [x] onionoo-backend-02 @lavamind
* [x] onionoo-frontend-01 @lavamind
* [x] onionoo-frontend-02 @lavamind
* [x] polyanthum - sync with @meskio, AFK on may 2nd, <= 1800UTC otherwise, also deploy backports, see tpo/tpa/team#40758 @anarcat possibly caused tpo/anti-censorship/bridgedb#40049
* [x] rude @lavamind
* [x] staticiforme @anarcat
* [x] ~~subnotabile~~ to retire? see #40810Debian 11 bullseye upgradeanarcatanarcat2022-05-31https://gitlab.torproject.org/tpo/tpa/team/-/issues/33750Hosting BTCPayserver2023-06-22T15:47:42ZHiroHosting BTCPayserverBTCPayserver suggests to deploy and use the docker configuration in production.
The docker configuration is available via docker-compose: https://github.com/btcpayserver/btcpayserver-docker
BTCPay depends on several pieces of infrastru...BTCPayserver suggests to deploy and use the docker configuration in production.
The docker configuration is available via docker-compose: https://github.com/btcpayserver/btcpayserver-docker
BTCPay depends on several pieces of infrastructure, mainly:
- A lightweight block explorer (NBXplorer),
- A database (PostgreSQL or SQLite),
- A full node (eg. Bitcoin Core)
There can be more dependencies if you support more than just standard Bitcoin transactions, including:
- C-Lightning
- LitecoinD and other coin daemons
It seems the bitcoin client needs to be installed and synced locally, therefore I am a bit concerned about storage. On this issue the docker setup has some scripts to prune the synced data to approx 100GB: https://github.com/btcpayserver/btcpayserver-docker#how-i-can-prune-my-nodes
I am also concerned how to make this setup play nicely with our infrastructure.
It would be nice if we can have an idea of the setup that BTC is currently running for us. What are the requirements? How many coins are supported?
## checklist
Update: that service was setup at lunanode by @hiro in 2021, but never integrated properly with TPA infrastructure, so it's in an unknown state. We should rebuild it inside our infra, following this procedure:
1. [x] [backup the actual btcpayserver](https://docs.btcpayserver.org/Docker/#how-can-i-back-up-my-btcpay-server)
2. [x] create a VM inside our infra, using our normal setup procedures (so we have backups, monitoring, etc)
3. [x] deploy the thing [using their Docker procedures](https://docs.btcpayserver.org/Docker//) (which target ubuntu 18.04, but that we could possibly deploy on bullseye?), things to watch out for:
* that thing probably installs postgresql and docker and all sorts of things, maybe try to trim that down to debian packages as much as possible?
* this *generates* a docker-compose.yaml file (!?), see what it actually does?
* consider just using the `./build.sh` command to generate the compose file and start from there? see [what does btcpay-setup.sh do?](https://docs.btcpayserver.org/Docker/#again-what-does-btcpay-setupsh-do)
* note that we absolutely need to have *some* sort of "fragment" to keep the blockchain from exploding in size. the [current bitcoin blockchain is reaching 400GB](https://www.blockchain.com/charts/blocks-size) and [growing exponentially](https://www.statista.com/statistics/647523/worldwide-bitcoin-blockchain-size/). it seems like we're using the [opt-save-storage-s fragment](https://github.com/btcpayserver/btcpayserver-docker/blob/master/docker-compose-generator/docker-fragments/opt-save-storage-s.yml) which keeps it under 50GB
4. [x] restore the backup onto the new server, things to watch out for:
* will this take over payments?
5. [x] add btcpay.torproject.org to DNS, deprecate the `.net`
6. [x] flip the donate.tpo things so that they point to the `.org`, see https://gitlab.torproject.org/tpo/web/donate-static/-/merge_requests/76 and the [full migration procedure](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/service/BTCpayserver#full-migration-procedure)
7. [x] test donations on new server
8. [x] retire btcpay.torproject.net (see procedure below)
9. [x] fix credentials in password manager (remove old, tweak new, possibly audit)
10. [x] automate upgrades, backups (including postgresql?) (#40763)
server retirement procedure:
1. [x] announcement
2. [x] nagios (N/A)
3. [x] retire the host in fabric (no backups, not in puppet, nothing to do)
4. [x] remove from LDAP with `ldapvi` (not in LDAP)
5. [x] power-grep (removed from torproject.net zone)
6. [x] remove from tor-passwords (done, also reset the root pass on btcpayserver-02, which was missing)
7. [x] remove from DNSwl (N/A)
8. [x] remove from docs (nothing found)
9. [x] remove from racks (let's wait two more weeks)
10. [x] remove from reverse DNS (not set)
current specs of the machine:
```
ubuntu@btcpay:~$ df -h / /dev/vdc
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 20G 9.3G 11G 49% /
/dev/vdc 59G 49G 7.0G 88% /var/lib/docker/volumes/generated_bitcoin_datadir/_data/blocks
ubuntu@btcpay:~$ uptime
19:46:00 up 37 days, 8:36, 1 user, load average: 0.13, 0.27, 0.15
ubuntu@btcpay:~$ free -h
total used free shared buff/cache available
Mem: 2.0G 1.1G 114M 9.2M 799M 684M
Swap: 1.0G 682M 341M
ubuntu@btcpay:~$ uname -a
Linux btcpay 4.4.0-210-generic #242-Ubuntu SMP Fri Apr 16 09:57:56 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
```
in other words, we might want to give it 60GB of spinning rust (which is 10GB over the "50GB" we are trimming to), but otherwise fairly standard.
in the current setup, we seem to have the following components setup (looking at `/root/btcpayserver-docker/Generated/docker-compose.generated.yml`):
* nginx 1.16 (based on the [official docker image](https://hub.docker.com/_/nginx))
* nginx-gen (which is some container based on [docker-gen](https://hub.docker.com/r/btcpayserver/docker-gen), which ... generates config files?)
* btcpayserver (based on [their image](https://hub.docker.com/r/btcpayserver/btcpayserver) of course)
* bitcoind (based on [btcpayserver/bitcoin](https://hub.docker.com/r/btcpayserver/bitcoin) docker image)
* nbx explorer 2.2.5 (based on [nicolasdorier/nbxplorer](https://hub.docker.com/r/nicolasdorier/nbxplorer)
* lnd_bitcoin (for the "lighting network", based on [their image](https://hub.docker.com/r/btcpayserver/lnd))
* bitcoin_rtl (based on [ shahanafarooqui/rtl](https://hub.docker.com/r/shahanafarooqui/rtl), a webapp for the lightning network)
* postgresql 9.6.20 (!? based on the official image
* [btcpayserver/letsencrypt-nginx-proxy-companion](https://hub.docker.com/r/btcpayserver/letsencrypt-nginx-proxy-companion)
* [btcpayserver/tor](https://hub.docker.com/r/btcpayserver/tor) (yes, they have a tor container image)
* tor-gen, also based on [docker-gen](https://hub.docker.com/r/btcpayserver/docker-gen) to generate a config for the above containeranarcatanarcat2022-06-02https://gitlab.torproject.org/tpo/onion-services/onion-support/-/issues/95Setup Bypass Censorship Dashboard test environment(s)2022-06-16T12:52:56ZSilvio RhattoSetup Bypass Censorship Dashboard test environment(s)* [x] Setup a [Bypass Censorship Dashboard](https://gitlab.com/guardianproject/bypass-censorship/portal) test environment(s) according to the [docs](https://bypass.censorship.guide/admin/install.html).
* [x] Bonuses:
* [x] Merge requ...* [x] Setup a [Bypass Censorship Dashboard](https://gitlab.com/guardianproject/bypass-censorship/portal) test environment(s) according to the [docs](https://bypass.censorship.guide/admin/install.html).
* [x] Bonuses:
* [x] Merge request complementing the documentation.
* [x] Merge request with Docker Compose configuration.Sponsor 123: Tor Secure Access Package for USAGM [First Phase]Silvio RhattoSilvio Rhatto2022-06-03https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/2Create a Tor PT server for Conjure2022-06-30T16:27:34ZCecylia BocovichCreate a Tor PT server for ConjureThere's a few details we need to sort out for what the Conjure bridge is going to actually look like. The [refraction networking relay station code](https://github.com/refraction-networking/conjure) is responsible for negotiating IP endp...There's a few details we need to sort out for what the Conjure bridge is going to actually look like. The [refraction networking relay station code](https://github.com/refraction-networking/conjure) is responsible for negotiating IP endpoints with the Conjure client and speaking the server side of whichever obfuscation protocol the client chose (in our case this will likely be obfs4).
Once the relay station strips off this obfuscation layer, it should send the resulting traffic to our Conjure bridge. We might have to work with Eric and the refracton networking relay station maintainers to sort out the details, but this will ideally speak something like [Tor's ExtOrPort PT spec](https://gitweb.torproject.org/torspec.git/tree/pt-spec.txt#n373) sent over an encrypted connection with with the bridge and be able to carry information like the client's address so we can do metrics.Sponsor 30 - Objective 2.3Cecylia BocovichCecylia Bocovich2022-06-03https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40506Prepare alpha release 11.5a13 (Desktop+Android)2022-07-05T18:46:07ZrichardPrepare alpha release 11.5a13 (Desktop+Android)<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
- `$(...<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
- [x] ***(Optional)*** Update translations:
- **NOTE** : mandatory if we have added new string dependencies
- [x] ./localization/import-translations.sh
- [x] Update `install.rdf` file with new version
- [x] Sign/Tag commit :
- Tag : `$(TOR_LAUNCHER_VERSION)`
- Message `Tagging $(TOR_LAUNCHER_VERSION)`
- [x] Push `master` and tag to origin
### tor-browser: https://git.torproject.org/tor-browser.git
- [x] ***(Optional)*** Rebase to `$(ESR_VERSION)`
- [x] Find the Firefox hg tag here : https://hg.mozilla.org/releases/mozilla-esr91/tags
- [x] `$(ESR_TAG)` : `FIREFOX_91_10_0esr_BUILD1`
- [ ] Identify the hg patch associated with above hg tag, and find the equivalent `gecko-dev` git commit (search by commit message)
- [x] `gecko-dev` commit : `2010fcc588669fbdb36cf9953e126c4a6e176643`
- [x] 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`
- [x] Sign/Tag commit :
- Tag : `$(ESR_TAG)`
- Message : `Hg tag $(ESR_TAG)`
- [x] Push new branch and tag to origin
- [x] 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
- [x] 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)`
- [x] 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
- [x] Update `rbm.conf`
- [x] `var/torbrowser_version` : update to next version
- [x] `var/torbrowser_build` : update to `$(TOR_BROWSER_BUILD_N)`
- [x] `var/torbrowser_incremental_from` : update to previous version
- [x] **IMPORTANT**: Really actually make sure this is the previous Desktop version or else the `make incrementals-*` step will fail
- [ ] Update `projects/firefox/config`
- [x] `git_hash` : update the `$(FIREFOX_BUILD_N)` section to match `tor-browser` tag
- [x] ***(Optional)*** `var/firefox_platform_version` : update to latest $(ESR_VERSION) if rebased
- [x] ***(Android Only)*** Update `projects/geckoview/config`
- [x] `git_hash` : update the `$(GECKOVIEW_BUILD_N)` section to match `geckoview` tag
- [ ] ***(Optional)*** `var/geckoview_version` : update to latest `$(RR_VERSION)` if rebased
- [x] ***(Android Only, Optional)*** Update `projects/tba-translations/config`:
- [x] `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
- [x] ***(Android Only)*** Update allowed_addons.json by running (from `tor-browser-build` root)`./tools/fetch_allowed_addons.py > projects/tor-browser/allowed_addons.json
- [x] Check for NoScript updates here : https://addons.mozilla.org/en-US/firefox/addon/noscript
- [x] ***(Optional)*** If version available, update `noscript` section of `input_files` in `projects/tor-browser/config`
- [x] `URL`
- [x] `sha256sum`
- [x] 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
- [x] 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
- [x] 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)
- [x] ***(Optional)*** If new go version is available, update `projects/go/config`
- [x] `version` : update go version
- [x] `input_files/sha256sum` for `go` : update sha256sum of archive (sha256 sums are displayed on the go download page)
- [x] Update `ChangeLog.txt`
- [x] Ensure ChangeLog.txt is sync'd between alpha and stable branches
- [x] Open MR with above changes
- [x] Begin build on `$(BUILD_SERVER)`
- [x] Sign/Tag commit : `make signtag-(alpha|release)`
- [x] Push tag to origin
### notify stakeholders
- [x] Email tor-qa mailing list: tor-qa@lists.torproject.org
- [x] Provide links to unsigned builds on `$(BUILD_SERVER)`
- [x] Call out any new functionality which needs testing
- [ ] Link to any known issues
- [x] Email Tails dev mailing list: tails-dev@boum.org
- [x] Provide links to unsigned builds on `$(BUILD_SERVER)`
### blog: https://gitlab.torproject.org/tpo/web/blog.git
- [x] Duplicate previous Stable or Alpha release blog post as appropriate to new directory under `content/blog/new-release-tor-browser-$(TOR_BROWSER_VERSION)` and update with info on release :
- [x] Update Tor Browser version numbers
- [x] Note any ESR rebase
- [ ] Note any Rapid Release rebase
- [x] Link to any Firefox security updates
- [x] Note any updates to :
- [x] tor
- [ ] openssl
- [ ] go
- [x] noscript
- [x] Convert ChangeLog.txt to markdown format used here by : `tor-browser-build/tools/changelog-format-blog-post`
- [x] Push to origin as new branch, open 'Draft :' MR
- [ ] Remove draft from MR once signed-packages are uploaded
- [ ] Merge
### website: https://gitlab.torproject.org/tpo/web/tpo.git
- [x] `databags/versions.ini` : Update the downloads versions
- `torbrowser-stable/version` : sort of a catch-all for latest stable version
- `torbrowser-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
- [x] 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
- [x] ***(Android Only)*** : *TODO*
- [x] 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`
- [x] Update `staticiforme.torproject.org`:
- From `screen` session on `staticiforme.torproject.org`
- [x] Static update components : `static-update-component cdn.torproject.org && static-update-component dist.torproject.org`
- [x] Enable update responses :
- [x] alpha: `./deploy_update_responses-alpha.sh`
- [ ] release: `./deploy_update_responses-release.sh`
- [ ] ***(Android Only)*** : Publish APKs to Google Play
- [x] Log into https://play.google.com/apps/publish
- Select correct app:
- [ ] Tor Browser
- [x] Tor Browser Alpha
- [x] Navigate to `Release > Production` and click `Create new release` button
- [x] Upload the `*.multi.apk` APKs
- [x] If necessary, update the 'Release Name' (should be automatically populated)
- [x] Update Release Notes
- [x] Next to 'Release notes', click `Copy from a previous release`
- [x] Edit blog post url to point to most recent blog post
- [x] Save, review, and configure rollout percentage
- [x] 25% rollout when publishing a scheduled update
- [ ] 100% rollout when publishing a security-driven release
- [x] ***Optional*** Update rollout percentage to 100% after confirmed no major issues
</details>boklmboklm2022-06-07https://gitlab.torproject.org/tpo/onion-services/onion-support/-/issues/109Write a script to gather EOTK stats from logs hosted on AWS S3 buckets2022-06-03T12:44:53ZSilvio RhattoWrite a script to gather EOTK stats from logs hosted on AWS S3 bucketsWrite a script to gather EOTK stats. Related to [this Bypass Censorship Dashboard issue](https://gitlab.com/guardianproject/bypass-censorship/analytics-dashboard/-/issues/1).Write a script to gather EOTK stats. Related to [this Bypass Censorship Dashboard issue](https://gitlab.com/guardianproject/bypass-censorship/analytics-dashboard/-/issues/1).Sponsor 123: Tor Secure Access Package for USAGM [First Phase]Silvio RhattoSilvio Rhatto2022-06-08