June 2022 - tor-project - lists.torproject.org

Are there countries where using Tor is illegal?
by Cristian Consonni 11 May '25

11 May '25

Hi, (Sorry if this question has already been asked in the past, feel free to point me to the relevant resources.) I know that the legal FAQs by the EFF state that: «we believe that running a Tor relay — including an exit relay that allows people to anonymously send and receive traffic — is legal under U.S. law.»[1] I also know there is a list of countries for which there is legislation that exclude communication service providers from liability. They are indicated in the Legal of the Tor Exit Guidelines page[2], they are USA, Germany, Netherlands, Austria, France, and Sweden. >From some articles in the press[3a][3b] it may be illegal - depending on how you interpret the wording[*] - to use Tor (and other technologies such as VPNs or proxies) in the UAE, with fines ranging in the millions of dirhams (hundreds of thousand of dollars). A couple of weeks ago it was discussed - on this list as well - that a law was introduced to the state parliament to ban Tor[4a][4b]. This follows a case of some months ago of a Russian Tor exit node operator being arrested for inciting mass riots and terrorism[4c][4d]. The idea of blocking VPNs or Tor seems to have already been considered in the past[4e]. This infographic about pluggable transports[5] suggests access to the Tor network is censored or limited in China, Uzbekistan, Iran, and Kazakhstan. Tor being censored orblocked may be different from it being illegal. What about other countries? Is there a place where I can find more about this topic? Cristian [1]: https://www.torproject.org/eff/tor-legal-faq.html.en [2]: https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines [3a]: http://www.emirates247.com/news/emirates/dh500-000-fine-if-you-use-fraud-ip… [3b]: http://news.softpedia.com/news/people-caught-using-vpns-tor-or-proxies-in-t… [*]: «Whoever uses a fraudulent computer network protocol address (IP address) by using a false address or a third-party address by any other means for the purpose of committing a crime or preventing its discovery» [4a]: https://lists.torproject.org/pipermail/tor-talk/2017-June/043293.html [4b]: https://trac.torproject.org/projects/tor/ticket/22055 [4c]: https://lists.torproject.org/pipermail/tor-talk/2017-April/043109.html [4d]: https://techcrunch.com/2017/04/24/dmitry-bogatov-tor-russia/ [4e]; https://torrentfreak.com/vpn-and-tor-ban-looming-on-the-horizon-for-russia-… [5]: https://www.torproject.org/images/PT/2016-07-how-to-use-PT.png

4 3

Tor's Hackweek Demo Session on July 1st at 1600 UTC
by Gaba 30 Jun '22

30 Jun '22

Hi! Tomorrow at 1600 UTC we will have the presentation of what different teams worked on during this hackweek. It will be in the same BBB room https://tor.meet.coop/gab-dpb-9zt-7tq Friday July 1st at 1600 UTC ROOM: https://tor.meet.coop/gab-dpb-9zt-7tq see you there! gaba -- pronouns she/her/they GPG Fingerprint EE3F DF5C AD91 643C 21BE 8370 180D B06C 59CA BD19

1 0

TPA-RFC-35: GitLab email address changes
by Antoine Beaupré 29 Jun '22

29 Jun '22

Summary: headers in GitLab email notifications are changing, you may need to update your email filters # Background I am working on building a development server for GitLab, where we can go wild testing things without breaking the production environment. For email to work there, I need a configuration that is separate from the current production server. Unfortunately, the email address used by the production GitLab server doesn't include the hostname of the server (`gitlab.torproject.org`) and only the main domain name (`torproject.org`) which makes it needlessly difficult to add new configurations. Finally, using the full service name (`gitlab.torproject.org`) address means that the GitLab server will be able to keep operating email services even if the main email service goes down. # Proposal This changes the headers: From: gitlab(a)torproject.org Reply-To: gitlab-incoming+%{key}(a)torproject.org to: From: git(a)gitlab.torproject.org Reply-To: git+%{key}(a)gitlab.torproject.org If you are using the `From` headers in your email client filters, for example to send all GitLab email into a separate mailbox, you WILL need to make a change for that filter to work again. I know I had to make such a change, which was simply to replace `gitlab(a)torproject.org` by `git(a)gitlab.torproject.org` in my filter. The `Reply-To` change should not have a real impact. I suspected emails sent before the change might not deliver properly, but I tested this, and both the old emails and the new ones work correctly, so that change should be transparent to everyone. (The reason for that is that the previous `gitlab-incoming(a)torproject.org` address is *still* forwarding to `git(a)torproject.org` so that will work for the foreseeable future.) # Alternatives considered ## Reusing the prod email address The main reason I implemented this change is that I want to have a GitLab development server, as mentioned in the background. But more specifically, we don't want the prod and dev servers to share email addresses, because then people could easily get confused as to where a notification is coming from. Even worse, a notification from the dev server could yield a reply that would end up in the prod server. ## Adding a new top-level address So, clearly, we need two different email addresses. But why change the *current* email address instead of just adding a new one? That's trickier. One reason is that I didn't want to add a new alias on the top-level `torproject.org` domain. Furthermore, the old configuration (using `torproject.org`) is officially [discouraged upstream][] as it can lead to some security issues. [discouraged upstream]: https://docs.gitlab.com/ee/administration/incoming_email.html#security-conc… # Costs N/A, staff. # Approval This needs approval from TPA and tor-internal. # Deadline This will be considered approved tomorrow (2022-06-30) at 16:00 UTC unless there are any objections, in which case it will be rolled back for further discussion. The reason there is such a tight deadline is that I want to get the development server up and running for the Hackweek. It is proving less and less likely that the server will actually be *usable* *during* the Hackweek, but if we can get the server up as a result of the Hackweek, it will already be a good start. # Status This proposal is currently in the `proposed` state. # References Comments welcome by email or in issue [tpo/tpa/team#40820][]. [tpo/tpa/team#40820]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40820 -- Antoine Beaupré torproject.org system administration

1 0

What's happening in Shadow 2022-06
by Jim Newsome 28 Jun '22

28 Jun '22

Mirrored from https://github.com/shadow/shadow/discussions/2243 This is part of a series of periodic updates of development in Shadow. This work is sponsored by the NSF. NSF sponsorship: https://shadow.github.io/docs/guide/nsf_sponsorship.html Previous update: https://github.com/shadow/shadow/discussions/2007 We will be presenting a paper on Shadow's 2.0 architecture, "Co-opting Linux Processes for High-Performance Network Simulation", at the USENIX Annual Technical Conference. Paper: https://www.robgjansen.com/publications/phantom-atc2022.pdf USENIX ATC: https://www.usenix.org/conference/atc22 We've merged 123 non-dependabot pull requests and closed 38 issues since our previous update. Pull requests: https://github.com/shadow/shadow/pulls?q=is%3Apr+merged%3A2022-04-05..2022-… Issues: https://github.com/shadow/shadow/issues?q=closed%3A2022-04-05..2022-06-27+i… Release status ============== We have released Shadow 2.1. This release focused largely on more complete and accurate OS emulation, to increase the number of applications that can be run under Shadow. Shadow now supports newer versions of glibc, software that uses signals and "busy loops", and dynamically linked golang programs. It also has a new `--debug-hosts` feature to facilitate attaching debuggers like `gdb` to Shadow's managed processes. See the release notes for details. Shadow 2.1: https://github.com/shadow/shadow/releases/tag/v2.1.0 Release notes: https://github.com/shadow/shadow/discussions/2219 We've begun work on Shadow 2.2, which will largely be a push to refactor and migrate more of the core Shadow code to Rust, which is expected to ultimately increase velocity of Shadow development. Shadow 2.2 project: https://github.com/shadow/shadow/projects/6 Notable changes since last update ============================= Most of the changes since the last update are covered in the v2.1.0 release notes. We are now also keeping a running CHANGELOG of user-facing changes since the last release. Currently this is: * We have removed ptrace-mode, and the associated experimental options `use-o-n-waitpid-workaround` and `--interpose-method`. ptrace-mode was an alternative to Shadow's current interposition mechanism that uses `LD_PRELOAD` and `seccomp`. This change should be transparent to most users, since it hasn't been the default for several releases, and was only accessible via experimental options. See https://github.com/shadow/shadow/issues/1945 Release notes: https://github.com/shadow/shadow/discussions/2219 Changelog: https://github.com/shadow/shadow/blob/main/CHANGELOG Happy simulating! The Shadow team

1 0

Another late hackweek entry: docs hackathon!
by kez 27 Jun '22

27 Jun '22

Hi all! I also have a super last-minute hackweek proposal: a docs hackathon! There's two parts to this proposal: 1) Updating our web- and wiki-based documentation where it needs to be updated, adding to it where it's incomplete, and opening tickets for changes that should be made at some point (but that we maybe don't have time/energy for right now) 2) Finding a replacement for gitlab wikis. Gitlab wikis only allow contributions from repository developers (<https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/76>), and the restrictions of the wiki are starting to become a quality-of-life issue for some teams. Ideally we'll find a replacement that fixes our issues without introducing new ones :p Basic familiarity with gitlab and wiki software (as an admin or user) is useful. Being able to update lektor pages is also helpful, though not required! If you're interested in helping out, feel free to add yourself to the pad and stop by #hackweek-docshackathon-2022 on OFTC! Kez

1 0

Tor Browser Weekly Meeting cancelled this week (2022-06-27)
by Richard Pospesel 26 Jun '22

26 Jun '22

Hi Everyone, This week is HackWeek, so we will be skipping our weekly Tor Browser meeting and meet again July 5th at 1100 UTC in #tor-meeting on OFTC IRC. best, -Richard

1 0

Tor's Hackweek starting June 27th at 1600 UTC
by gaba 26 Jun '22

26 Jun '22

Hola people! This week we are holding Tor's hack week. We will have people coming together to hack on several projects [0] proposed in the last few weeks. If you have any new proposal please submit it asap [1] before Monday 1600 UTC. So far we have 10 projects [0]. Each project has a pad [0] where you can find more information about it, who is on the team, and where people are going to meet during the week. All these projects will be presented on Monday at 1600 UTC in a BBB room [2]. You can add yourself to the pad of the team you want to collaborate with and ask any questions during the presentation on Monday. To summarize the presentation will be: Monday, June 27th at 1600 UTC ROOM: https://tor.meet.coop/gab-dpb-9zt-7tq happy hacking! gaba 0. https://gitlab.torproject.org/tpo/community/hackweek/#proposals-submitted-r… 1. https://hackweek.onionize.space/hackweek/ 2. https://tor.meet.coop/gab-dpb-9zt-7tq -- pronouns she/her/they GPG Fingerprint EE3F DF5C AD91 643C 21BE 8370 180D B06C 59CA BD19

1 0

Anti-censorship team meeting notes, 2022-06-23
by meskio 23 Jun '22

23 Jun '22

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2022/tor-meeting.2022-06-23-15.58.html And our meeting pad: Anti-censorship work meeting pad -------------------------------- Next meeting: Thursday July 7 16:00 UTC Weekly meetings, every Thursday at 16:00 UTC, in #tor-meeting at OFTC (channel is logged while meetings are in progress) == Goal of this meeting == Weekly check-in about the status of anti-censorship work at Tor. Coordinate collaboration between people/teams on anti-censorship at Tor. == Links to Useful documents == * Our anti-censorship roadmap: * Roadmap: https://gitlab.torproject.org/groups/tpo/anti-censorship/-/boards * The anti-censorship team's wiki page: * https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/home * Past meeting notes can be found at: * https://lists.torproject.org/pipermail/tor-project/ * Tickets that need reviews: from sponsors we are working on: * All needs review tickets: https://gitlab.torproject.org/groups/tpo/anti-censorship/-/merge_requests?s… * Sponsor 28 * must-do tickets: https://gitlab.torproject.org/groups/tpo/-/milestones/10 * possible tickets: https://gitlab.torproject.org/groups/tpo/-/issues?scope=all&utf8=%E2%9C%93&… * Sponsor 96 * https://gitlab.torproject.org/groups/tpo/-/milestones/24 == Announcements == * Next week is hackweek, no ant-censorship meeting!!! == Discussion == * What is the status of adjusting snowflake (pion) DTLS signature to avoid blocking in Russia? (Based on offset of supported_groups extension.) * https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/iss… * https://github.com/pion/dtls/pull/474 * https://ntc.party/t/webrtc/2174/21 * https://gitlab.torproject.org/tpo/community/support/-/issues/40050 (generally) * shell will do some research on what makes sense as infra for testing snowflake connections * do we want a second broker for testing? * or multi-pool support? * snowflake spike on metrics * https://metrics.torproject.org/userstats-bridge-combined.html?start=2022-03… * being looked at the metrics side: https://gitlab.torproject.org/tpo/network-health/metrics/website/-/issues/4… == Actions == https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/issues/32 == Interesting links == == Reading group == * We will discuss "" on * * Questions to ask and goals to have: * What aspects of the paper are questionable? * Are there immediate actions we can take based on this work? * Are there long-term actions we can take based on this work? * Is there future work that we want to call out in hopes that others will pick it up? == Updates == Name: This week: - What you worked on this week. Next week: - What you are planning to work on next week. Help with: - Something you need help with. cecylia (cohosh): last updated 2022-06-23 Last week: - got tor to bootstrap fully with conjure PT in test environment - testenv: https://gitlab.torproject.org/cohosh/phantombox - conjure PT: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conj… - ran a quick tutorial on reproducible snowflake/tor-browser builds This week: - work with conjure developers to get the PT working with the production conjure station Needs help with: dcf: 2022-06-16 Last week: - snowflake CDN bookkeeping https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-co… - commented on dnstt pluggable transport client https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac… - commented on restarts for snowflake probetest https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Next week: - look at STATUS VERSION proposal https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/63 Help with: meskio: 2022-06-23 Last week: - gitlab implementation in gettor - metrics for gettor - test gettor-rdsys setup Next week: - deployment of rdsys-gettor Shelikhoo: 2022-06-23 Last Week: - [Merged & Deployed] Add Distributed Snowflake Server Support (snowflake!87) - [Merged] Distributed Snowflake Bridges (Javascript ver.) (snowflake-webext!29) - [Merged & Deployed] Implement metrics to measure snowflake churn (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…) (snowflake!95) - [Merge Request Awaiting] Add SOCKS5 forward proxy support to snowflake (snowflake!64) - [Discussion & Deployment] Migrating Controlling git repo to Tor Gitlab Instance (shelikhoo/LogCollectorAncillary#5) - [Research & Discussion] Discussion about the possibility of adding PT support to V2Ray to serve the role of HTTPT (https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/82) - [Investigate] China "Anti-Fraud" Webpage Redirection Censorship (censorship-analysis#40026): update the research based on updated ooni result - [Deployment] Snowflake Broker Next Week: - [Coding & Deployment] Proposal: Centralized Probe Result Collector (anti-censorship/team#54) - [Research & Coding] WebSocket + CDN Based Probe Control Connection Forwarder (shelikhoo/LogCollectorAncillary#3) - [Investigate] China "Anti-Fraud" Webpage Redirection Censorship (censorship-analysis#40026): update the research based on updated ooni result Itchy Onion: 2022-06-23 Last week: - ongoing debugging s28 issues 81 - taking over part of testing snowflake This week: - ongoing debugging s28 issues 81, fixing a leaking file descriptor issue - taking over part of testing snowflake -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

1 0

TPA-RFC-33: monitoring requirements (draft)
by Antoine Beaupré 23 Jun '22

23 Jun '22

Hi, (Yes, I send a lot of emails today, sorry. :) As part of the Debian bullseye upgrade, we're considering an upgrade of our Icinga server or a replacement with Prometheus. Considering some of you actually use one or the other, as service admins, I would be grateful if you could review the draft requirements I have written here, in TPA-RFC-33: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-33-monito… I also need to write a "persona" for service admins, so input on that would be welcome. Comments are welcome in the issue: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40755 ... or by replying to this email, or as edits to the wiki page. Thanks! -- Antoine Beaupré torproject.org system administration

1 0

TPA-RFC-20: bullseye upgrade schedule
by Antoine Beaupré 23 Jun '22

23 Jun '22

Note: this proposal is also visible in: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-20-bullse… Summary: bullseye upgrades will roll out starting the first weeks of April and May, and should complete before the end of August 2022. Let us know if your service requires special handling. # Background Debian 11 [bullseye][] was [released on August 14 2021][]). Tor started the upgrade to bullseye shortly after and hopes to complete the process before the [buster][] EOL, [one year after the stable release][], so normally around August 2022. In other words, we have until this summer to upgrade *all* of TPA's machine to the new release. New machines that were setup recently have already been installed in bullseye, as the installers were changed shortly after the release. A few machines were upgraded manually without any ill effects and we do not consider this upgrade to be risky or dangerous, in general. This work is part of the [%Debian 11 bullseye upgrade milestone][], itself part of the [OKR 2022 Q1/Q2 plan][]. # Proposal The proposal, broadly speaking, is to upgrade all servers in three batches. The first two are somewhat equally sized and spread over April and May, and the rest will happen at some time that will be announced later, individually, per server. ## Affected users All service admins are affected by this change. If you have shell access on any TPA server, you want to read this announcement. ## Upgrade schedule The upgrade is split in multiple batches: * low complexity (mostly TPA): April * moderate complexity (service admins): May * high complexity (hard stuff): to be announced separately * to be retired or rebuilt servers: not upgraded * already completed upgrades The free time between the first two will also allow us to cover for unplanned contingencies: upgrades that could drag on and other work that will inevitably need to be performed. The objective is to do the batches in collective "upgrade parties" that should be "fun" for the team (and work parties *have* generally been generally fun in the past). ### Low complexity, batch 1: April A first batch of servers will be upgraded in the first week of April. Those machines are considered to be somewhat trivial to upgrade as they are mostly managed by TPA or that we evaluate that the upgrade will have minimal impact on the service's users. ``` archive-01 build-x86-05 build-x86-06 chi-node-12 chi-node-13 chives ci-runner-01 ci-runner-arm64-02 dangerzone-01 hetzner-hel1-02 hetzner-hel1-03 hetzner-nbg1-01 hetzner-nbg1-02 loghost01 media-01 metrics-store-01 perdulce static-master-fsn submit-01 tb-build-01 tb-build-03 tb-tester-01 tbb-nightlies-master web-chi-03 web-cymru-01 web-fsn-01 web-fsn-02 ``` 27 machines. At a worst case 45 minutes per machine, that is 20 hours of work. At three people, this might be doable in a day. Feedback and coordination of this batch happens in issue [tpo/tpa/team#40690][]. ### Moderate complexity, batch 2: May The second batch of "moderate complexity servers" happens in the first week of May. The main difference with the first batch is that the second batch regroups services mostly managed by service admins, who are given a longer heads up before the upgrades are done. ``` bacula-director-01 bungei carinatum check-01 crm-ext-01 crm-int-01 fallax gettor-01 gitlab-02 henryi majus mandos-01 materculae meronense neriniflorum nevii onionbalance-01 onionbalance-02 onionoo-backend-01 onionoo-backend-02 onionoo-frontend-01 onionoo-frontend-02 polyanthum rude staticiforme subnotabile ``` 26 machines. If the worst case scenario holds, this is another day of work, at three people. Not mentioned here is the `gnt-fsn` Ganeti cluster upgrade, which is covered by ticket [tpo/tpa/team#40689][]. That alone could be a few day-person of work. Feedback and coordination of this batch happens in issue [tpo/tpa/team#40692][] ### High complexity, individually done Those machines are harder to upgrade, due to some major upgrades of their core components, and will require individual attention, if not major work to upgrade. ``` alberti eugeni hetzner-hel1-01 pauli ``` Each machine could take a week or two to upgrade, depending on the situation and severity. To detail each server: * `alberti`: `userdir-ldap` is, in general, risky and needs special attention, but should be moderately safe to upgrade, see ticket [tpo/tpa/team#40693][] * `eugeni`: messy server, with lots of moving parts (e.g. Schleuder, Mailman), Mailman 2 EOL, needs to decide whether to migrate to Mailman 3 or replace with Discourse (and self-host), see [tpo/tpa/team#40471][], followup in [tpo/tpa/team#40694][] * `hetzner-hel1-01`: Nagios AKA Icinga 1 is end-of-life and needs to be migrated to Icinga 2, which involves fixing our git hooks to generate Icinga 2 configuration (unlikely), or rebuilding a Icinga 2 server, or replacing with Prometheus (see [tpo/tpa/team#29864][]), followup in [tpo/tpa/team#40695][] * `pauli`: Puppet packages are severely out of date in Debian, and Puppet 5 is EOL (with Puppet 6 soon to be). doesn't necessarily block the upgrade, but we should deal with this problem sooner than later, see [tpo/tpa/team#33588][], followup in [tpo/tpa/team#40696][] All of those require individual decision and design, and specific announcements will be made for upgrades once a decision has been made for each service. ### To retire Those servers are possibly scheduled for removal and may not be upgraded to bullseye at all. If we miss the summer deadline, they might be upgraded as a last resort. ``` cupani gayi moly peninsulare vineale ``` Specifically: * cupani/vineale is covered by [tpo/tpa/team#40472][] * gayi is [TPA-RFC-11: SVN retirement][], [tpo/tpa/team#17202][] * moly/peninsulare is [tpo/tpa/team#29974][] ### To rebuild Those machines are planned to be rebuilt and should therefore not be upgraded either: ``` cdn-backend-sunet-01 colchicifolium corsicum nutans ``` Some of those machines are hosted at a Sunet and need to be migrated elsewhere, see [tpo/tpa/team#40684][] for details. `colchicifolium` will is planned to be rebuilt in the `gnt-chi` cluster, no ticket created yet. They will be rebuilt in new bullseye machines which should allow for a safer transition that shouldn't require specific coordination or planning. ### Completed upgrades Those machines have already been upgraded to (or installed as) Debian 11 bullseye: ``` btcpayserver-02 chi-node-01 chi-node-02 chi-node-03 chi-node-04 chi-node-05 chi-node-06 chi-node-07 chi-node-08 chi-node-09 chi-node-10 chi-node-11 chi-node-14 ci-runner-x86-05 palmeri relay-01 static-gitlab-shim tb-pkgstage-01 ``` ### Other related work There is other work related to the bullseye upgrade that is mentioned in the [%Debian 11 bullseye upgrade milestone][]. # Alternatives considered We have not set aside time to automate the upgrade procedure any further at this stage, as this is considered to be a too risky development project, and the current procedure is fast enough for now. We could also move to the cloud, Kubernetes, serverless, and Ethereum and pretend none of those things exist, but so far we stay in the real world of operating systems. Also note that this doesn't cover Docker container images upgrades. Each team is responsible for upgrading their image tags in GitLab CI appropriately and is *strongly* encouraged to keep a close eye on those in general. We may eventually consider enforcing stricter control over container images if this proves to be too chaotic to self-manage. # Costs It is estimates this will take one or two person-month to complete, full time. # Approvals required This proposal needs approval from TPA team members, but service admins can request additional delay if they are worried about their service being affected by the upgrade. Comments or feedback can be provided in issues linked above. # Deadline Upgrades will start in the first week of April 2022 (2022-04-04) unless an objection is raised. This proposal will be considered adopted by then unless an objection is raised within TPA. # Status This proposal is currently in the `proposed` state. # References * [TPA bullseye upgrade procedure][] * [%Debian 11 bullseye upgrade milestone][] [TPA bullseye upgrade procedure]: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/upgrades/bullseye/ [%Debian 11 bullseye upgrade milestone]: https://gitlab.torproject.org/groups/tpo/tpa/-/milestones/5 [bullseye]: https://wiki.debian.org/DebianBullseye [released on August 14 2021]: https://www.debian.org/News/2021/20210814 [buster]: howto/upgrades/buster [one year after the stable release]: https://www.debian.org/security/faq#lifespan [OKR 2022 Q1/Q2 plan]: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/roadmap/2022 [tpo/tpa/team#40690]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40690 [tpo/tpa/team#40692]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40692 [tpo/tpa/team#40693]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40693 [tpo/tpa/team#40471]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40471 [tpo/tpa/team#29864]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/29864 [tpo/tpa/team#33588]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/33588 [tpo/tpa/team#40684]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40684 [tpo/tpa/team#40694]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40694 [tpo/tpa/team#40695]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40695 [tpo/tpa/team#40696]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40696 [tpo/tpa/team#40472]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40472 [tpo/tpa/team#17202]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/17202 [TPA-RFC-11: SVN retirement]: policy/tpa-rfc-11-svn-retirement [tpo/tpa/team#29974]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/29974 [tpo/tpa/team#40689]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40689 -- Antoine Beaupré torproject.org system administration

1 4