The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-04-03T20:32:16Zhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41103do-not-reply@crm bounces2023-04-03T20:32:16Zanarcatdo-not-reply@crm bouncesi just got a complaint about a bounce sent by crm-int-01. it seems like someone responded to the unsubscribe confirmation emails from civicrm and got a bounce. (and then they complained about the bounce too of course, but that's besides ...i just got a complaint about a bounce sent by crm-int-01. it seems like someone responded to the unsubscribe confirmation emails from civicrm and got a bounce. (and then they complained about the bounce too of course, but that's besides the point.)
we shouldn't bounce when people write to `do-not-reply@crm.torproject.org` and instead devnull those email.Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40821The update details URL is wrong in alphas2023-10-03T15:35:41ZPier Angelo VendrameThe update details URL is wrong in alphasI've tried to check the update details in the just updated 12.5a4, but it sent me to a wrong URL: https://blog.torproject.org/new-release-tor-browser-125a4, instead of https://blog.torproject.org/new-alpha-release-tor-browser-125a4/ (`al...I've tried to check the update details in the just updated 12.5a4, but it sent me to a wrong URL: https://blog.torproject.org/new-release-tor-browser-125a4, instead of https://blog.torproject.org/new-alpha-release-tor-browser-125a4/ (`alpha` is missing).
This URL is generated with the info form `projects/release/update_responses_config.yml`.richardrichardhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41102check-01 maxes a gigabit again2023-04-12T13:23:32Zanarcatcheck-01 maxes a gigabit againit looks like check-01 is misbhaving again.
i noticed this while debugging I/O problems with crm-int-01 (tpo/web/civicrm#97, private project). i have found that check-01 was doing about 819mbps on fsn-node-07, and that the node itself ...it looks like check-01 is misbhaving again.
i noticed this while debugging I/O problems with crm-int-01 (tpo/web/civicrm#97, private project). i have found that check-01 was doing about 819mbps on fsn-node-07, and that the node itself was maxed out, because it was *also* hosting relay-01 which is happily pushing 250mbps on the wire right now.
i'm in the process of migrating check-01 to its secondary (fsn-node-05).
here's a traffic graph of the node and its instances before the migration:
![image](/uploads/92edf78e378209150724b0bdae6b1b8f/image.png)
https://grafana.torproject.org/d/53QNFNtZz/traffic-per-class?orgId=1&var-class=All&var-node=check-01.torproject.org%3A9100&var-node=crm-int-01.torproject.org%3A9100&var-node=fsn-node-07.torproject.org%3A9100&var-node=henryi.torproject.org%3A9100&var-node=polyanthum.torproject.org%3A9100&var-node=relay-01.torproject.org%3A9100&var-node=fsn-node-05.torproject.org%3A9100&from=now-24h&to=now
you can clearly see how the traffic "flatlines" somewhere below 1gbps. i bet it could go much higher, possibly in the 10gig range, if we let it.
last time we dealt with this (in #40842), we identified the following next steps:
> 1. check if traffic comes from the same IP addresses, then;
> 1. block or rate-limit the IPs
> 1. consider automating this with fail2ban
> 1. if this is legitimate traffic, consider creating a new VM with DNS RR distribution
> 1. if that's not enough, consider adding an nginx cache in front (with per-IP caching of course)
/cc @hiro @lavamindJérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/web/donate-neo/-/issues/1add crypto wallet addresses2023-03-24T19:16:22ZKezadd crypto wallet addressescontext donate-static#111
we need to add the crypto wallet addresses to donate-neo. i think the best way to handle this is to add a `CRYPTO_WALLET_ADDRESSES: dict[str, str]` setting to settings.py. we don't change the addresses, so we d...context donate-static#111
we need to add the crypto wallet addresses to donate-neo. i think the best way to handle this is to add a `CRYPTO_WALLET_ADDRESSES: dict[str, str]` setting to settings.py. we don't change the addresses, so we don't need to store them in the database or expose them in the admin interface.2023-04-30https://gitlab.torproject.org/tpo/tpa/team/-/issues/41101CVE-2023–26604: local privilege escalation via sudo and systemd2023-03-21T20:24:35ZJérôme Charaouilavamind@torproject.orgCVE-2023–26604: local privilege escalation via sudo and systemdSudo rules involving `systemctl status` may lead to privilege escalation on systems running systemd < 247, which including `buster`, the `oldstable` Debian distribution.
https://scribe.nixnet.services/@zenmoviefornotification/saidov-max...Sudo rules involving `systemctl status` may lead to privilege escalation on systems running systemd < 247, which including `buster`, the `oldstable` Debian distribution.
https://scribe.nixnet.services/@zenmoviefornotification/saidov-maxim-cve-2023-26604-c1232a526ba7Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/network-health/metrics/website/-/issues/40086Populate bridgedb-metrics entry on https://metrics.torproject.org/collector.html2023-11-13T15:56:01ZGeorg KoppenPopulate bridgedb-metrics entry on https://metrics.torproject.org/collector.htmlWe have https://metrics.torproject.org/collector.html#bridgedb-metrics but there is nothing explained on how we parse or deal with those metrics. The spec for that is https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/blob/main...We have https://metrics.torproject.org/collector.html#bridgedb-metrics but there is nothing explained on how we parse or deal with those metrics. The spec for that is https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/blob/main/doc/bridgedb-metrics-spec.txt. We should look over our code and compare it to the spec and make sure both match and then document the steps on collector.html.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/issues/19Add missing fields to the bandwidth_record table2023-06-14T16:36:47ZGeorg KoppenAdd missing fields to the bandwidth_record tableI was double-checking the [`bandwidth-file-spec`]() making sure we have every item mentioned there accounted for in our table. I think here are the missing ones that still need to get added:
```
rtt
relay_recent_measurement_failure_count...I was double-checking the [`bandwidth-file-spec`]() making sure we have every item mentioned there accounted for in our table. I think here are the missing ones that still need to get added:
```
rtt
relay_recent_measurement_failure_count
relay_recent_measurements_excluded_near_count
relay_recent_measurements_excluded_old_count
relay_recent_measurements_excluded_few_count
under_min_report
unmeasured
vote
xoff_recv
xoff_sent
```HiroHirohttps://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/issues/18Pick up `tor_version` in bandwidth table2023-06-14T16:44:29ZGeorg KoppenPick up `tor_version` in bandwidth tableAfter https://gitlab.torproject.org/tpo/network-health/metrics/library/-/issues/40017 gets deployed we should change the `bandwidth_file` table so it picks up `tor_version`.After https://gitlab.torproject.org/tpo/network-health/metrics/library/-/issues/40017 gets deployed we should change the `bandwidth_file` table so it picks up `tor_version`.HiroHirohttps://gitlab.torproject.org/tpo/core/arti/-/issues/789Refactor TargetInfo::may_share_circuit_with to share code with relays_can_sha...2024-03-12T14:04:20ZNick MathewsonRefactor TargetInfo::may_share_circuit_with to share code with relays_can_share_circuitSee discussion at https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1065#note_2887655
These functions share logic, and should probably be refactored to be the same function, or call the same function.See discussion at https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1065#note_2887655
These functions share logic, and should probably be refactored to be the same function, or call the same function.Arti: Onion service supportNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/120Enable remoting in Mullvad Browser for better OS integration2023-03-22T12:08:19ZrichardEnable remoting in Mullvad Browser for better OS integrationFrom discussion here: https://gitlab.torproject.org/tpo/applications/privacy-browser/-/issues/62From discussion here: https://gitlab.torproject.org/tpo/applications/privacy-browser/-/issues/62richardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40820Prepare Tor Browser Stable 12.0.62023-06-15T07:29:01ZrichardPrepare Tor Browser Stable 12.0.6<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
- `$(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)
- `$(TOR_BROWSER_MAJOR)` : the Tor Browser major version
- example : `11`
- `$(TOR_BROWSER_MINOR)` : the Tor Browser minor version
- example : either `0` or `5`; Alpha's is always `(Stable + 5) % 10`
- `$(TOR_BROWSER_VERSION)` : the Tor Browser version in the format
- example: `12.5a3`, `12.0.3`
- `$(BUILD_N)` : a project's build revision within a its branch; this is separate from the `$(TOR_BROWSER_BUILD_N)` value; many of the Firefox-related projects have a `$(BUILD_N)` suffix and may differ between projects even when they contribute to the same build.
- example : `build1`
- `$(TOR_BROWSER_BUILD_N)` : the tor-browser build revision for a given Tor Browser release; used in tagging git commits
- example : `build2`
- **NOTE** : A project's `$(BUILD_N)` and `$(TOR_BROWSER_BUILD_N)` may be the same, but it is possible for them to diverge. For example :
- if we have multiple Tor Browser releases on a given ESR branch the two will become out of sync as the `$(BUILD_N)` value will increase, while the `$(TOR_BROWSER_BUILD_N)` value may stay at `build1` (but the `$(TOR_BROWSER_VERSION)` will increase)
- if we have build failures unrelated to `tor-browser`, the `$(TOR_BROWSER_BUILD_N)` value will increase while the `$(BUILD_N)` will stay the same.
- `$(TOR_BROWSER_VERSION)` : the published Tor Browser version
- example : `11.5a6`, `11.0.7`
</details>
**NOTE** It is assumed that the `tor-browser` rebase and security backport tasks have been completed
<details>
<summary>Build Configs</summary>
### tor-browser-build: https://gitlab.torproject.org/tpo/applications/tor-browser-build.git
Tor Browser Stable lives in the various `maint-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)` (and possibly more specific) branches
- [x] Update `rbm.conf`
- [x] `var/torbrowser_version` : update to next version
- [x] `var/torbrowser_build` : update to `$(TOR_BROWSER_BUILD_N)`
- [x] ***(Desktop Only)***`var/torbrowser_incremental_from` : update to previous Desktop version
- **IMPORTANT**: Really *actually* make sure this is the previous Desktop version or else the `make incrementals-*` step will fail
- [x] Update Desktop-specific build configs
- [x] Update `projects/firefox/config`
- [x] `browser_build` : update to match `tor-browser` tag
- [ ] ***(Optional)*** `var/firefox_platform_version` : update to latest `$(ESR_VERSION)` if rebased
- [x] Update `projects/translation/config`:
- [x] run `make list_translation_updates-release` to get updated hashes
- [x] `steps/base-browser/git_hash` : update with `HEAD` commit of project's `base-browser` branch
- [x] `steps/base-browser-fluent/git_hash` : update with `HEAD` commit of project's `basebrowser-newidentityftl` branch
- [x] `steps/tor-browser/git_hash` : update with `HEAD` commit of project's `tor-browser` branch
- [x] `steps/fenix/git_hash` : update with `HEAD` commit of project's `fenix-torbrowserstringsxml` branch
- [x] Update Android-specific build configs
- [x] ***(Optional)*** Update `projects/geckoview/config`
- [x] `browser_build` : update to match `tor-browser` tag
- [ ] ***(Optional)*** `var/geckoview_version` : update to latest `$(ESR_VERSION)` if rebased
- [ ] ***(Optional)*** Update `projects/tor-android-service/config`
- [ ] `git_hash` : update with `HEAD` commit of project's `main` branch
- [ ] ***(Optional)*** Update `projects/application-services/config`:
**NOTE** we don't currently have any of our own patches for this project
- [ ] `git_hash` : update to appropriate git commit associated with `$(ESR_VERSION)`
- [ ] ***(Optional)*** Update `projects/android-components/config`:
- [ ] `android_components_build` : update to match android-components tag
- [ ] ***(Optional)*** Update `projects/fenix/config`
- [ ] `fenix_build` : update to match fenix tag
- [ ] ***(Optional)*** `var/fenix_version` : update to latest `$(ESR_VERSION)` if rebased
- [x] Update allowed_addons.json by running (from `tor-browser-build` root):
- `./tools/fetch_allowed_addons.py > projects/browser/allowed_addons.json`
- [ ] Update common build configs
- [x] Check for NoScript updates here : https://addons.mozilla.org/en-US/firefox/addon/noscript
- [ ] ***(Optional)*** If new version available, update `noscript` section of `input_files` in `projects/browser/config`
- [ ] `URL`
- [ ] `sha256sum`
- [x] Check for OpenSSL updates here : https://www.openssl.org/source/
- [ ] ***(Optional)*** If new 1.X.Y version available, update `projects/openssl/config`
- [ ] `version` : update to next 1.X.Y version
- [ ] `input_files/sha256sum` : update to sha256 sum of source tarball
- [x] Check for zlib updates here: https://github.com/madler/zlib/releases
- [ ] **(Optional)** If new tag available, update `projects/zlib/config`
- [ ] `version` : update to next release tag
- [x] Check for tor updates here : https://gitlab.torproject.org/tpo/core/tor/-/tags
- [ ] ***(Optional)*** Update `projects/tor/config`
- [ ] `version` : update to latest non `-alpha` tag (ping dgoulet or ahf if unsure)
- [x] Check for go updates here : https://golang.org/dl
- **NOTE** : Tor Browser Stable uses the latest of the *previous* Stable major series go version (apart from the transition phase from Tor Browser Alpha to Stable, in which case Tor Browser Stable may use the latest major series go version)
- [x] ***(Optional)*** Update `projects/go/config`
- [ ] `version` : update go version
- [ ] `input_files/sha256sum` for `go` : update sha256sum of archive (sha256 sums are displayed on the go download page)
- [x] Update the manual : https://gitlab.torproject.org/tpo/web/manual/-/jobs/
- [x] Download the `artifacts.zip` file from latest build stage row (download icon button on the right)
- [x] Rename it to `manual_$PIPELINEID.zip`
- [x] Upload it to people.tpo
- [x] Update `projects/manual/config`
- [x] Change the version to `$PIPELINEID`
- [x] Update the hash in the input_files section
- [x] Update the URL if you have uploaded to a different people.tpo home
- [x] Update `ChangeLog.txt`
- [x] Ensure ChangeLog.txt is sync'd between alpha and stable branches
- [x] Check the linked issues: ask people to check if any are missing, remove the not fixed ones
- [x] Run `tools/fetch-changelogs.py $(TOR_BROWSER_VERSION)` or `tools/fetch-changelogs.py '#$(ISSUE_NUMBER)'`
- Make sure you have `requests` installed (e.g., `apt install python3-requests`)
- The first time you run this script you will need to generate an access token; the script will guide you
- [x] Copy the output of the script to the beginning of `ChangeLog.txt` and adjust its output
- If you used the issue number, you will need to write the Tor Browser version manually
- [x] Include any version updates for:
- [x] translations
- [ ] OpenSSL
- [ ] NoScript
- [x] Go
- [ ] zlib
- [x] Include any ESR rebase for Firefox and GeckoView
- [x] Open MR with above changes
- [x] Begin build on `$(BUILD_SERVER)` (and fix any issues which come up and update MR)
- [x] Merge
- [x] Sign/Tag commit: `make torbrowser-signtag-release`
- [x] Push tag to `origin`
</details>
<details>
<summary>Communications</summary>
### notify stakeholders
<details>
<summary>email template</summary>
Hello All,
Unsigned Tor Browser $(TOR_BROWSER_VERSION) release candidate builds are now available for testing:
- https://tb-build-05.torproject.org/~$(BUILDER)/builds/release/unsigned/$(TOR_BROWSER_VERSION)/
The full changelog can be found here:
- https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/raw/maint-12.0/projects/browser/Bundle-Data/Docs/ChangeLog.txt
</details>
- [x] Email tor-qa mailing list: tor-qa@lists.torproject.org
- Additional information:
- [ ] Note any new functionality which needs testing
- [ ] Link to any known issues
- [x] Email downstream consumers:
- Recipients:
- Tails dev mailing list: tails-dev@boum.org
- Guardian Project: nathan@guardianproject.info
- torbrowser-launcher: micah@micahflee.com
- FreeBSD port: freebsd@sysctl.cz <!-- Gitlab user maxfx -->
- OpenBSD port: caspar@schutijser.com <!-- Gitlab user cschutijser -->
- [ ] Note any changes which may affect packaging/downstream integration
- [ ] Email upstream stakeholders:
- ***(Optional, after ESR migration)*** 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
</details>
<details>
<summary>Signing</summary>
### signing + publishing
- [x] 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
- [x] `tor-browser-build/tools/signing/set-config.hosts`
- `ssh_host_builder` : ssh hostname of machine with unsigned builds
- **NOTE** : `tor-browser-build` is expected to be in the `$HOME` directory)
- `ssh_host_linux_signer` : ssh hostname of linux signing machine
- `ssh_host_macos_signer` : ssh hostname of macOS signing machine
- [x] `tor-browser-build/tools/signing/set-config.macos-notarization`
- `macos_notarization_user` : the email login for a tor notariser Apple Developer account
- [x] `set-config.update-responses`
- `update_responses_repository_dir` : directory where you cloned `git@gitlab.torproject.org:tpo/applications/tor-browser-update-responses.git`
- [x] `tor-browser-build/tools/signing/set-config.tbb-version`
- `tbb_version` : tor browser version string, same as `var/torbrowser_version` in `rbm.conf` (examples: `11.5a12`, `11.0.13`)
- `tbb_version_build` : the tor-browser-build build number (if `var/torbrowser_build` in `rbm.conf` is `buildN` then this value is `N`)
- `tbb_version_type` : either `alpha` for alpha releases or `release` for stable releases
- [x] On `$(STAGING_SERVER)` in a separate `screen` session, run the macOS proxy script:
- `cd tor-browser-build/tools/signing/`
- `./macos-signer-proxy`
- [x] On `$(STAGING_SERVER)` in a separate `screen` session, ensure tor daemon is running with SOCKS5 proxy on the default port 9050
- [x] apk signing : copy signed `*multi.apk` files to the unsigned build outputs directory
- [x] run do-all-signing script:
- `cd tor-browser-build/tools/signing/`
- `./do-all-signing.sh`
- **NOTE**: at this point the signed binaries should have been copied to `staticiforme`
- [x] Update `staticiforme.torproject.org`:
- From `screen` session on `staticiforme.torproject.org`:
- [x] Static update components : `static-update-component cdn.torproject.org && static-update-component dist.torproject.org`
- [x] Enable update responses : `sudo -u tb-release ./deploy_update_responses-release.sh`
- [ ] Remove old release data from following places:
- **NOTE** : Skip this step if the current release is Android or Desktop *only*
- [ ] `/srv/cdn-master.torproject.org/htdocs/aus1/torbrowser`
- [ ] `/srv/dist-master.torproject.org/htdocs/torbrowser`
- [x] Static update components (again) : `static-update-component cdn.torproject.org && static-update-component
- [x] Publish APKs to Google Play:
- Log into https://play.google.com/apps/publish
- Select `Tor Browser` app
- Navigate to `Release > Production` and click `Create new release` button:
- Upload the `*.multi.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
- [x] 25% rollout when publishing a scheduled update
- [ ] 100% rollout when publishing a security-driven release
- [x] Update rollout percentage to 100% after confirmed no major issues
</details>
<details>
<summary>Publishing</summary>
### website: https://gitlab.torproject.org/tpo/web/tpo.git
- [x] `databags/versions.ini` : Update the downloads versions
- `torbrowser-stable/version` : sort of a catch-all for latest stable version
- `torbrowser-alpha/version` : sort of a catch-all for latest stable version
- `torbrowser-*-stable/version` : platform-specific stable versions
- `torbrowser-*-alpha/version` : platform-specific alpha versions
- `tor-stable`,`tor-alpha` : set by tor devs, do not touch
- [x] Push to origin as new branch, open 'Draft :' MR
- [x] Remove `Draft:` from MR once signed-packages are uploaded
- [x] Merge
- [x] Publish after CI passes and builds are published
### blog: https://gitlab.torproject.org/tpo/web/blog.git
- [x] Duplicate previous Stable or Alpha release blog post as appropriate to new directory under `content/blog/new-release-tor-browser-$(TOR_BROWSER_VERSION)` and update with info on release :
- [x] Update Tor Browser version numbers
- [x] Note any ESR rebase
- [x] Link to any Firefox security updates from ESR upgrade
- [x] Link to any Android-specific security backports
- [x] Note any updates to :
- tor
- OpenSSL
- 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
- [x] Publish after CI passes and website has been updated
### tor-announce mailing list
- [x] 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>richardrichardhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41100Tor Browser-specific NoScript update channel2023-03-21T15:33:40Zma1Tor Browser-specific NoScript update channel### The problem
The Tor Browser currently ships with the official AMO stable release of the NoScript extension, which therefore is updated from Mozilla's servers.
Per Mozilla's policy, each update of this kind requires a manual review f...### The problem
The Tor Browser currently ships with the official AMO stable release of the NoScript extension, which therefore is updated from Mozilla's servers.
Per Mozilla's policy, each update of this kind requires a manual review from AMO's editorial staff to be signed and published, which can take several days.
Without Mozilla's signature, extensions cannot be installed in the Tor Browser.
This situation becomes problematic when we need to ship a security update, possibly for a problem which is already known.
### Proposed solution
Since self-hosted extensions (i.e. extensions which specify their own non-Mozilla update URL) get signed by Mozilla after an automated validation process which takes minutes, we can self-host a parallel version of latest NoScript stable with an update URL pointing to TPO infrastructure.
We would need to serve
1. an `update.xml` file with the update info, which would get about 1 ping per day per Tor Browser user
2. the ~1MB `xpi` file of the latest NoScript to be downloaded if the ping determines the currently installed one is outdated
We would also need a mean to update both the `xml` and the `xpi` files.
cc @richard @pierovJérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41682Add base-browser nightly mar signing key2023-03-22T11:48:47ZboklmAdd base-browser nightly mar signing keyWe need to add the nightly mar signing key as `toolkit/mozapps/update/updater/nightly_aurora_level3_primary.der` and `toolkit/mozapps/update/updater/nightly_aurora_level3_secondary.der`.We need to add the nightly mar signing key as `toolkit/mozapps/update/updater/nightly_aurora_level3_primary.der` and `toolkit/mozapps/update/updater/nightly_aurora_level3_secondary.der`.boklmboklmhttps://gitlab.torproject.org/tpo/network-health/tor-weather/-/issues/33Node down subscription does not appear to work2023-03-22T10:09:59ZGeorg KoppenNode down subscription does not appear to workYesterday I tested the current deployment more and subscribed `Najdorf` to the node-down subscription (wait 2h) + the guard flag one (wait 1h). Then I went to the relay and took it down. Now, almost a day later I still did not get a noti...Yesterday I tested the current deployment more and subscribed `Najdorf` to the node-down subscription (wait 2h) + the guard flag one (wait 1h). Then I went to the relay and took it down. Now, almost a day later I still did not get a notification.
I wonder where to look at weather.tpo for some logs. @sarthikg : do you know where I should look for some logs for trying to figure out what's going on?
@kez: this might block https://gitlab.torproject.org/tpo/tpa/team/-/issues/41034.Sarthik Guptasarthikg@icloud.comSarthik Guptasarthikg@icloud.comhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41099update my openpgp key in db.torproject.org2023-03-17T21:49:39Zmeskiomeskio@torproject.orgupdate my openpgp key in db.torproject.orgMy key in db.torproject.org will expire in few weeks. I have extended the expiration date of the same [key](/uploads/5f50d24059168a4f76e6c3c878016faa/meskio.asc). Can you update it there?
Thank you.My key in db.torproject.org will expire in few weeks. I have extended the expiration date of the same [key](/uploads/5f50d24059168a4f76e6c3c878016faa/meskio.asc). Can you update it there?
Thank you.https://gitlab.torproject.org/tpo/network-health/team/-/issues/294Set bwscanner_cc back to 12023-09-21T12:08:11ZGeorg KoppenSet bwscanner_cc back to 1We tried to get our upload implementation properly in shape for the 1.6 release but failed so far: there are still a bunch of issues to debug (see: e.g. sbws#40152) and we are not risking at that point getting a proper 1.6 out by having ...We tried to get our upload implementation properly in shape for the 1.6 release but failed so far: there are still a bunch of issues to debug (see: e.g. sbws#40152) and we are not risking at that point getting a proper 1.6 out by having upload enabled by default. Rather, we'll ship the best upload version we currently have but it will be off by default due to `bwscanner_cc` being `1` in the consensus.Sponsor 61 - Making the Tor network faster & more reliable for users in Internet-repressive placesGeorg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/web/newsletter/-/issues/34Add March 2023 newsletter to newsletter.torproject.org2023-03-16T19:02:51Zal smithAdd March 2023 newsletter to newsletter.torproject.orgHi @lavamind or @kez, can you help me by adding the latest newsletter to the site, following the practice of previous editions? (Usually Gus helps me but he's not available this week).
Files:
[03.2023_newsletter_-_html.txt](/uploads/93...Hi @lavamind or @kez, can you help me by adding the latest newsletter to the site, following the practice of previous editions? (Usually Gus helps me but he's not available this week).
Files:
[03.2023_newsletter_-_html.txt](/uploads/93e061f216bb57b94003cb4fb570f928/03.2023_newsletter_-_html.txt)
[03.2023_newsletter_-_plain_text.txt](/uploads/baab1449721123bc3e810d5fe616ff25/03.2023_newsletter_-_plain_text.txt)
Subject: Tor News | Status of the Tor network, Tor user support on WhatsApp, welcome new board membershttps://gitlab.torproject.org/tpo/team/-/issues/141Bottomline the creation of the schedule for CR's meetup2023-04-20T18:15:01ZGabagaba@torproject.orgBottomline the creation of the schedule for CR's meetupGabagaba@torproject.orgGabagaba@torproject.org2023-04-13https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/118Mullvad Browser 12.0a7 Release Prep2023-03-24T16:02:16ZrichardMullvad Browser 12.0a7 Release Preprichardrichardhttps://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/117Prepare Mullvad Browser release 12.0a62023-03-24T16:33:03ZrichardPrepare Mullvad Browser release 12.0a6richardrichard