- tor-project - lists.torproject.org

Tomorrow we hangout!
by emma peel 19 May '22

19 May '22

Every 3rd Friday of the month the Tor L10n Team meets to translate together, share tricks, have fun while translating, meet fellow translators, and find out about the l10n priorities for the Tor Project. Tomorrow on the hangout we will talk about the coming updates of the Tor Browser, with new connection - bridges configuration. We will install a Tor alpha to see how the new connection works and what is a Bridge emoji. Come join us on the Localization Hangout, from Noon UTC, on the #tor-l10n channel in OFTC. (you can also use Element https://element.io/ to connect: #tor-l10n:matrix.org) At 13 UTC we make a call on Big Blue Button If you are not a translator yet, you still have time to become one before the hangout: https://community.torproject.org/localization/becoming-tor-translator/ What do we do in a hangout? Translate stuff Share translation tips and resources Complain about developers Talk about translation priorities Talk about our local contexts Practice bug reporting and git skills

1 0

Tails report for April 2022
by sajolida 17 May '22

17 May '22

Tails report for April 2022 <https://tails.boum.org/news/report_2022_04/> * Disoj, our new Project Manager, started working with us. It's the first time Tails has a dedicated Project Manager and we are all very excited about this change. Disoj will help us work better and faster to accomplish our mission <https://tails.boum.org/contribute/mission/>. * We got very busy preparing Tails 5.0 <https://tails.boum.org/news/version_5.0/index.en.html>. * We upgraded all our infrastructure to Debian 11 to ensures that all our public and internal servers will continue receiving security updates timely after August. * We organized 2 online trainings <https://tails.boum.org/news/ciclo_de_autodefensa_digital_mexico/index.en.ht…> for people in Mexico. You can download our slides <https://tails.boum.org/contribute/how/promote/material/slides/Ciclo_Autodef…> and the structure <https://tails.boum.org/contribute/how/promote/material/slides/Ciclo_Autodef…> of the training if you want to organize Tails workshops yourself. * Tails has been started more than 783 850 times this month. This makes 25 031 boots a day on average. -- sajolida Tails — https://tails.boum.org/ UX · Fundraising · Technical Writing

1 0

Community Team meeting notes - May 9 2022
by gus 16 May '22

16 May '22

Hi, Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2022/tor-meeting.2022-05-09-13.59.log… And our meeting pad: ## Tor Community Team meeting pad Next meeting: Monday, May 16, 2022 - 1400 UTC Weekly meetings, every Monday at 14: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 Community Team work at Tor. ## Links to Useful documents * Previous meetings: https://forum.torproject.net/tag/community-team * Monthly l10n hangout: * https://community.torproject.org/localization/hangouts/ * Known issues with Tor Browser: * https://tb-manual.torproject.org/known-issues/ and Tor Browser for Android: https://tb-manual.torproject.org/mobile-tor/#known-issues ## Announcement * New (Tor Browser) Alpha Tester Badges are now live on the forum! (https://forum.torproject.net/badges/ see under 'Testing') * s123 looks like the nirvana of translation, and we will have a lot of new locales ## Discussion * TB Alpha testing + release - Next steps: - work on the TB User Manual updates in a pad till the end of May - emmapeel will send the new strings for translation * Training page: - Next steps: - Raya will ping kez to see what's possible to implement with Lektor (re: filters) * Demhack.ru hackathon: https://gitlab.torproject.org/tpo/community/team/-/issues/61 ## Updates Joydeep: Last week: - S125 wrap up - Tor Browser Alpha testing and QA - user support work: forum, RT, cdr.link - monthly report - deployed a text module on cdr.link to collect feedback wrt TB Alpha (https://gitlab.torproject.org/tpo/community/support/-/issues/40079) This week: - 1:1 sync with Gus - Weekly sync with the UX team - adjusting discourse trust levels: https://gitlab.torproject.org/tpo/community/support/-/issues/40060 - TB Alpha testing contd. - Tasks related to collecting Tor Browser Alpha feedback from our support channels: 1. Create a pad to collect user feedback from RT and cdr.link and track down TB alpha bugs 2. Create a template on RT to tag tickets Help with: - Something you need help with. Gus: Last week: - Team 1:1s - Merged: https://community.torproject.org/training/partners/ - Worked on the Tor Meetup - East Africa - Reviewed the sysadmin workshop survey with gman999: https://nc.torproject.net/apps/forms/cDLPxryHJcP5kMeW - Worked with Rafael Bonifaz and Maria for the OONI + Tor workshop: https://gitlab.torproject.org/tpo/community/training/-/issues/47 - Contacted top exit operators running !0.4.7.7 and asked to upgrade - https://gitlab.torproject.org/tpo/community/relays/-/issues/46 - Announced the next relay operator meetup: https://gitlab.torproject.org/tpo/community/relays/-/issues/45 - Sponsor125 retrospective This week: - Alix Dunn facilitation course - Team 1:1s - S96 meeting - S9 meeting - Work on East africa meetup agenda with raya and isa - Submit the final demhack.ru project: https://gitlab.torproject.org/tpo/community/team/-/issues/61 - Network health work with GeKo Help with: - Reviewing Felix contribution - a relay docker image: https://gitlab.torproject.org/tpo/community/relays/-/issues/43 raya: Last week: - submitted s123 report - 1:1 with gus - s123 coordination: full list of services and languages - s123: handling some blockages - working on general presentation about onion services: https://gitlab.torproject.org/tpo/community/training/-/issues/44 - working on bread&net proposal: https://gitlab.torproject.org/tpo/community/outreach/-/issues/40011 This week: - submit bread&net proposal - first draft of presentation: https://gitlab.torproject.org/tpo/community/training/-/issues/44 Nina: Last week: - English-Russian translations for TB Alpha Testing: announcements, templates, etc. - TB Alpha testing - User support on RT and cdr.link - dealing with broken bot - wrap up with s125 - Monthly report This week: - Activities arount TB Alpha - 1:1 with Gus - User support rhatto: Last week: - S123 - Continue the Onionprobe testbed setup: https://gitlab.torproject.org/tpo/onion-services/onionprobe/-/merge_request… - S123 - Work on new deployments - 1:1 with Gus This week: - S123 - Continue the Onionprobe testbed setup: https://gitlab.torproject.org/tpo/onion-services/onionprobe/-/merge_request… - S123 - Work on new deployments - S123 - Onionmine: batch mode: https://gitlab.torproject.org/tpo/onion-services/onionmine/-/issues/7 - S123 - Continue to work on new deployments emmapeel: Last week: - s123 and s125 l10n work: onboarding, documentation, stats - debug onion landing page i18n - general l10n documentation - gitlab gardening This week: - publish website translations - stats in gitlab -- The Tor Project Community Team Lead

1 0

Job Opening: OONI Community Coordinator
by Maria Xynou 13 May '22

13 May '22

Hello, I'm excited to share that we're hiring! The OONI team (a non-profit fighting internet censorship) is looking for a dedicated *community coordinator* to help grow and support the OONI community around the world. *Information about the job description, qualification requirements, and how to apply* is available here: https://ooni.org/post/2022-job-opening-ooni-community-coordinator/ Born in 2012, OONI builds free software (OONI Probe) that enables anyone to detect and collect evidence of internet censorship. With more than 100k installs, OONI Probe is run in more than 160 countries every month. To increase transparency of internet censorship, we publish censorship measurements as open data in near real-time. This data supports research and advocacy efforts investigating and fighting internet censorship worldwide. By joining our team, you will support our partners and global community of human rights defenders to measure and fight internet censorship. Our community is at the heart of our work, and you will play an important role in helping to ensure that our tools meet the needs of our community. This is a *full-time 12-month contract position* (which may be extended), starting ASAP. This is a *fully remote position*. We encourage applications from anywhere in the world! The application deadline is *Sunday, 12th June 2022.* Please spread the word ( https://twitter.com/OpenObservatory/status/1525110440153559040) and help us find someone who can best serve the internet freedom community! Thank you, OONI team.

1 0

Anti-censorship team meeting notes, 2022-5-12
by Shelikhoo 12 May '22

12 May '22

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2022/tor-meeting.2022-05-12-15.58.html <http://meetbot.debian.net/tor-meeting/2022/tor-meeting.2022-03-31-15.59.html> And our meeting pad: Anti-censorship work meeting pad -------------------------------- Next meeting: Thursday May 19th 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 == * == Discussion == * Snowflake doesn't work in Russia (connection failure by timeout) * there are some anomalies in OONI for RU, but they are not higher than some coutries like CA * most of snowflake users are comming from Russia, it works at least for some * stunreachability measurements show 3 (of 12) STUN servers inaccessible in Russia, 2 blocked by Russian ISPs, 1 possibly geoblocking of users in Russia * https://explorer.ooni.org/chart/mat?probe_cc=RU&test_name=stunreachability&… * flakey bridge-stats still show plenty of connections from Russia today * whoever added this discussion item is not here to supply more details * Moat gives blocklisted(ru) bridges in Russia (e.g. https://metrics.torproject.org/rs.html#details/1807BF9A521468998385F179DDBF…) * meskio will investigate it == Actions == * == Interesting links == * == Reading group == * We will discuss "Understanding the Impact of Encrypted DNS on Internet Censorship, ACM WWW 2021" on May 19th, 2022 * https://shhaos.github.io/papers/www21-DoE.pdf * 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. anadahz: 2022-01-27 Last week: - Increase timeout check cycles for default-bridge-felix-1 and default-bridge-felix-2 as they have been generating too many alerts: https://gitlab.torproject.org/tpo/anti-censorship/monit-configuration/-/mer… cecylia (cohosh): last updated 2022-05-12 Last week: - work on conjure PT - review of Distributed snowflake server support (snowflake!87) This week: - continue work on conjure PT - continue snowflake maintenance tasks Needs help with: dcf: 2022-05-12 Last week: - started to look at OONI stunreachability measurements from Russia Next week: - look at STATUS VERSION proposal https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/63 - set up access control on the snowflake-02 bridge https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - write up observations on OONI stunreachability measurements from Russia Help with: arlolra: 2022-04-07 Last week: - Merged the rest of snowflake !81 Next week: - Get to snowflake-webext #10 Evergreen: - Figure out where in pion/webrtc ALPN should be configured and used - Maybe add Chacha20Poly1305 to pion/dtls https://github.com/pion/dtls#planned-features https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Help with: - maxb: 2021-09-23 Last week: - Worked on https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… re: utls for broker negotiation - Had conversation with someone about upstream utls http round tripper https://github.com/refraction-networking/utls/pull/74 - Too busy with work :/ Next week: - _Really_ want to get a PR for utls round tripper meskio: 2022-05-12 Last week: - add location to circumvention settings (rdsys#108) - use a worker to write telegram metrics (rdsys!39) - deploy a test setup for dynamic bridges updates API (rdsys#98) - prepare demhack.ru hackathon challenge (team#61) - configure our mergerequest assignments bot so cohosh only gets snowflake ones (TriageOps!8) Next week: - rethink distributor retries to the rdsys backend (rdsys#99) - use systemd to run bridgedb (team#72) Shelikhoo: 2022-05-12 Last Week: - [Merge Request] Add Distributed Snowflake Server Support (snowflake!87) - [Merge Request Awaiting] Add SOCKS5 forward proxy support to snowflake (snowflake!64) - [Merge Request Review] Telegram distributor hands both new and old bridges to old accounts (snowflake!37) - [Research & Coding] WebSocket + CDN Based Probe Control Connection Forwarder (shelikhoo/LogCollectorAncillary#3) - [Coding & Deployment] Proposal: Centralized Probe Result Collector (anti-censorship/team#54) - [Discussion] Opening 8443 port on probetelemetry-01@ for V2Ray Websocket Connection Inbound (continue) Next Week: - [Coding] Distributed Snowflake Bridges (continue) - [Merge Request] Add Distributed Snowflake Server Support (snowflake!87) - [Coding & Deployment] Proposal: Centralized Probe Result Collector (anti-censorship/team#54) - [Research & Coding & Coding] WebSocket + CDN Based Probe Control Connection Forwarder (shelikhoo/LogCollectorAncillary#3) - [Research & Coding] Implement metrics to measure snowflake churn (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…) Itchy Onion: 2022-05-12 Last week: - prepared for Georgetown meeting (read code/docs about snowflake) This week: - audit PI meeting - working on the snowflake issues assigned to me - review MRs assigned to me HackerNCoder: 2021-12-16 This week: Last/done: Setup web mirror on tor.encryptionin.space Next: Get (new VPs with) new IP and setup new web mirror on new domain

1 0

Documentation about meetings at Tor
by Gaba 12 May '22

12 May '22

Hi! I updated the documentation on how we run meetings in https://gitlab.torproject.org/tpo/team/-/wikis/Meetings Please read it and if you have any comment send them to me via MR or private message or this list. I'm also interested to know your opinion on how we are running meetings: - What works? - What can be improved? - What do you need to feel more comfortable participating in meetings? Any access needs that we did not consider yet? cheers, gaba -- pronouns she/her/they GPG Fingerprint EE3F DF5C AD91 643C 21BE 8370 180D B06C 59CA BD19

1 0

Job Announcement - Software Developer
by Erin Wyatt 12 May '22

12 May '22

Hello, everyone! We are looking for two new Software Developers (same job, two positions): https://www.torproject.org/about/jobs/software-engineer-applications-team-2/ <https://www.torproject.org/about/jobs/software-engineer-applications-team-2/> Please refer anyone you think might be interested and help us spread the word. Thank you! Erin Wyatt Director of People Operations (she/her) ewyatt(a)torproject.org <mailto:ewyatt@torproject.org> PGP: 35E7 2A9F 6655 45F9 2CB6 6624 BA0C 9400 F80F 91CE https://www.torproject.org <https://www.torproject.org/> http://2gzyxa5ihm7nsggfxnu52rck2vv4rvmdlkiu3zzui5du4xyclen53wid.onion/ <http://2gzyxa5ihm7nsggfxnu52rck2vv4rvmdlkiu3zzui5du4xyclen53wid.onion/> ------------------------------------ >8 # Internet Freedom Nonprofit Seeks Software Engineer for Applications Team 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 a Software Engineer 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-Inf…) 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 40 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.t… <https://gitweb.torproject.org/community/policies.git/tree/code_of_conduct.t…> • The Tor Project Social Contract: https://gitweb.torproject.org/community/policies.git/tree/social_contract.t… <https://gitweb.torproject.org/community/policies.git/tree/social_contract.t…> • The Tor Project Statement of Values: https://gitweb.torproject.org/community/policies.git/tree/statement_of_valu… <https://gitweb.torproject.org/community/policies.git/tree/statement_of_valu…> 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.

1 0

minutes from the TPA meeting
by Antoine Beaupré 10 May '22

10 May '22

It's that time of the month again! We met, and here are our minutes. TL;DR: we'll upgrade to Mailman 3, not self-hosted Discourse, Icinga vs Prometheus still up in the air, request templates coming. # Roll call: who's there and emergencies materculae is doing OOM errors: see [tpo/tpa/team#40750][]. anarcat is looking into it, no other emergencies [tpo/tpa/team#40750]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40750 present: anarcat, gaba, kez, lavamind # product deployment workflow question Gaba created an issue to provide feedback from the community team in [tpo/tpa/team#40746][]: > Something that came up from one of the project's retrospective this > month is about having a space in TPI for testing new tools. We need > space where we can **quickly** test things if needed. It could be a > policy of getting the service/tool/testing automatically destroyed > after a specific amount of time. [tpo/tpa/team#40746]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40746 Prior art: out of the [Brussels meeting][], came many tasks about server lifecycle, see in particular [tpo/tpa/team#29398][] (a template for requesting resources) and [tpo/tpa/team#29379][] (automatically shutdown). [Brussels meeting]: https://gitlab.torproject.org/legacy/trac/-/wikis/org/meetings/2019Brussels… [tpo/tpa/team#29398]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/29398 [tpo/tpa/team#29379]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/29379 We acknowledge that it was hard to communicate with TPA during the cdr.link testing. The [cdr.link issue][] actually took 9 days to complete between open and close. But once requirements were clarified and we agreed on deployment, it took less than 24 hours to actually setup the machine. [cdr.link issue]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40578 In general, our turnaround time for new VMs is currently one business day. That's actually part of our OKRs for this quarter, but so far it's typically how long it takes to provision a VM. It can take longer, especially when we are requested odd services we do not understand or that overlap with existing services. We're looking at at setting up templates to improve communication when setting up new resources, inspired from the [service cookbooks][] idea. The idea behind this mechanism is that the template helps answering common question we have when people ask for services, but it's also a good way to identify friction points. For example, if we get a *lot* of requests for VMs and those take a long time, then we can focus on automating that service. At first the template serves as an input for a manual operation, but eventually it could be a way to automate the creation and destruction of resources as well. Issue [tpo/tpa/team#29398][] was put back in the backlog to start working on this. One of the problems is that, to have issue templates, we need a Git repository in the project and, right now, the tpo/tpa/team project deliberately doesn't have one so that it "looks" like a wiki. But maybe we can just bite that bullet and move the wiki-replica in there. [service cookbooks]: https://lethain.com/service-cookbooks/ vs wiki # bullseye upgrade: phase 3 A quick update on the phase 2 progress ([tpo/tpa/team#40692][]): slower than phase 1, because those servers are more complicated. We had to had to deprecate python 2 (see [TPA-RFC-27][]), so far network health and TPA affected. Both were able to quickly port their scripts to Python 3 so far. Also had difficulties with the PostgreSQL upgrade (see above materculae issue). [TPA-RFC-27]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/33949 [tpo/tpa/team#40692]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40692 Let's talk about the difficult problems left in [TPA-RFC-20][]: bullseye upgrades. [TPA-RFC-20]: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-20-bullse… Extract from the RFC, discuss each individually: > * `alberti`: `userdir-ldap` is, in general, risky and needs special > attention, but should be moderately safe to upgrade, see ticket > [tpo/tpa/team#40693][] Tricky server, to be very careful around, but no controversy around it. > * `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][], Schleuder discussion in > [tpo/tpa/team#40564][] [tpo/tpa/team#40564]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40564 One of the ideas behind the Discourse setup was that we would eventually mirror many lists to Discourse. If we want to use Discourse, we need to start adding a Discourse category for *each* mailing list. The [Mailman 3 upgrade procedure][], that said, is not that complicated: each list is migrated by hand, but the migration is pretty transparent for users. But if we switch to Discourse, it would be a major change: people would need to register, all archive links would break, etc. [Mailman 3 upgrade procedure]: https://docs.mailman3.org/en/latest/migration.html We don't hear a lot of enthusiasm around migrating from Mailman to Discourse at this point. We will therefore upgrade from Mailman 2 to Mailman 3, instead of migrating everything to Discourse. As an aside, anarcat would rather avoid self-hosting Discourse unless it allows us to replace another service, as Discourse is a complex piece of software that would take a lot of work to maintain (just like Mailman 3). There are currently no plans to self-host discourse inside TPA. There was at least one vote for removing schleuder. It seems people are having both problems using and managing it, but it's possible that finding new maintainers for the service could help. > * `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][] Lavamind made a new puppet agent 7 package that should eventually land in Debian experimental. He will look into the Puppet server and Puppet DB packages with the Clojure team this weekend, has a good feeling that we should be able to use Puppet 7 in Debian bookworm. We need to decide what to do with the current server WRT bullseye. Options: 1. use upstream puppet 7 packages in bullseye, for bookworm move back to Debian packages 2. use our in-house Puppet 7 packages before upgrading to bookworm 3. stick with Puppet 5 for bullseye, upgrade the server to bookworm and puppet server 7 when we need to (say after the summer), follow puppet agent to 7 as we jump in the bookworm freeze Lavamind will see if it's possible to use Puppet agent 7 in bullseye, which would make it possible to upgrade only the server to bookworm and keep the fleet upgraded to bookworm progressively (option 3, above, favorite for now). > * `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][] Anarcat proposed to not upgrade Icinga and instead replace it with Prometheus and Alert Manager. We had a debate here: on the one hand, lavamind believes that Alert manager doesn't have all the bells and whistles that Icinga 2 provides. Icinga2 has alert history, a nice and intuitive dashboard where you ack alerts and see everything, while alert manager is just a dispatcher and doesn't actually come with a UI. Anarcat, however, feels that upgrading to Icinga2 will be a lot of work. We'll need to hook up all the services in Puppet. This is already all done in Prometheus: the node exporter is deployed on all machines, and there are service specific exporters deployed for many services: apache, bind, postgresql (partially) are all monitored. Plus, service admins have widely adopted the second Prometheus server and are actually already using for alerting. We have a service duplication here, so we need to make a decision on which service we are going to retire: either Alert Manager or Icinga2. The discussion is to be continued. > [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#40471]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40471 > [tpo/tpa/team#40693]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40693 > [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 Other major upgrade tasks remaining, informative, to be done progressively in may: * upgrades, batch 2: tpo/tpa/team#40692 (probably done by this point?) * gnt-fsn upgrade: tpo/tpa/team#40689 (involves an upgrade to backports, then bullseye) * sunet site move: tpo/tpa/team#40684 (involves rebuilding 3 machines) # Dashboard review Skipped for lack of time. * https://gitlab.torproject.org/tpo/tpa/team/-/boards/117 * https://gitlab.torproject.org/groups/tpo/web/-/boards * https://gitlab.torproject.org/groups/tpo/tpa/-/boards # Holidays planning Skipped for lack of time, followup by email. # Other discussions We need to review the dashboards at the next checkin, possibly discuss the Icinga vs Prometheus proposal again. # Next meeting Next meeting should be on Monday June 6th. # Metrics of the month * hosts in Puppet: 93, LDAP: 93, Prometheus exporters: 154 * number of Apache servers monitored: 27, hits per second: 295 * number of self-hosted nameservers: 6, mail servers: 8 * pending upgrades: 0, reboots: 0 * average load: 0.64, memory available: 4.67 TiB/5.83 TiB, running processes: 718 * disk free/total: 34.14 TiB/88.48 TiB * bytes sent: 400.82 MB/s, received: 266.83 MB/s * planned bullseye upgrades completion date: 2022-12-05 * [GitLab tickets][]: 178 tickets including... * open: 0 * icebox: 153 * backlog: 10 * next: 4 * doing: 6 * needs information: 2 * needs review: 3 * (closed: 2732) [Gitlab tickets]: https://gitlab.torproject.org/tpo/tpa/team/-/boards Upgrade prediction graph lives at https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/upgrades/bullseye/ Now also available as the main Grafana dashboard. Head to <https://grafana.torproject.org/>, change the time period to 30 days, and wait a while for results to render. # Number of the month 4 issues. We have somehow managed to bring the number of tickets in the icebox from 157 to 153, that's a 4 issues gain! It's the first time since we're tracking those numbers that we managed to get that number to go down *at all*, so this is really motivating. We also closed a whopping 53 tickets since the last report, not quite a record, but certainly on the high range. Also: we managed to bring back the estimated bullseye upgrades completion date back *two years*, into a more reasonable date. This year, even! We still hope to complete most upgrades by this summer, so hopefully that number will keep going down as we continue the upgrades. Another fun fact: we now have more Debian bullseye (54) than buster (39) machines. -- Antoine Beaupré torproject.org system administration

1 0

No UX team meeting today, May 10th
by nah＠riseup.net 10 May '22

10 May '22

Hello everyone, Most of the team is not available today, so we are going to cancel this meeting. See you all next week! Nah User Researcher The Tor Project

1 0

TPA-RFC-27: Python 2 end of life
by Antoine Beaupré 09 May '22

09 May '22

Summary: Python 2 is officially unsupported by TPA. Major breakage to unfixed code is expected after the Debian bullseye upgrade completes (May-July 2022), and definite breakage will occur when Python 2 support is completely dropped in Debian bookworm (some time in 2023). # Background [Python 2.7.18][] was released on April 20th 2020. It was the last Python 2 release that will ever happen, and Python 2 is now unsupported, end of life, [dead][]. [Python 2.7.18]: https://www.python.org/downloads/release/python-2718/ [dead]: https://www.enricozini.org/blog/2020/python/python-2-is-dead/ ## Status of Python 2 in Debian It was originally thought that the Debian 11 "bullseye" [release][] (on August 14th 2021) would not support Python 2 at all, but it was actually released with *some* Python 2 support. [release]: https://www.debian.org/News/2021/20210814 However, an analysis from anarcat about the [Python 2 modules shipped in bullseye][] shows that a large number of Python 2 modules were actually removed from Debian 11. Out of the 2699 "python 2" packages in Debian buster (packages starting with `python2?-`, excluding `-doc` and `-dbg`), 2616 were removed. Therefore, only 90 such packages remain in Debian bullseye, a 97% reduction. [Python 2 modules shipped in bullseye]: https://people.debian.org/~anarcat/python2-in-debian/ As a consequence, odds are that your Python 2 code will just stop working after the bullseye upgrade, if it uses one of the [modules missing from bullseye][]. Which, really, means if it uses anything outside the standard library that is not vendored with your code (e.g. in a "virtualenv"), because the odds of that module being one of the few 90 modules are pretty low. [modules missing from bullseye]: https://people.debian.org/~anarcat/python2-in-debian/python2-removed-bullse… The next Debian stable release (12, code name "bookworm") doesn't yet have a clear plan to remove Python 2, but it's likely to shrink the list of Python 2 modules even further. It is currently down to 79 packages. Bookworm also does not currently ship the magic [python-is-python2][] package, which ensures the existence of `/usr/bin/python`. This means any script with such a header will start breaking in Debian bookworm: #!/usr/bin/python [python-is-python2]: https://packages.debian.org/bullseye/python-is-python2 # Status of Python 2 in TPA We currently are in the middle of a the [Debian 11 bullseye upgrade][], so we have both Debian 10 and Debian 11 machines, which means we have actually Python 2.7.16 and 3.7.3 (buster) and Python 2.7.18 and 3.9.2 (bullseye) currently deployed. In any case, we have two "reasonable" versions of Python 2 (2.7+) and Python 3 (3.5+) available everywhere, it should be fairly easy to target Python 3 for ports, without having to concern ourselves with Python 2 support any longer. [Debian 11 bullseye upgrade]: https://gitlab.torproject.org/groups/tpo/tpa/-/milestones/5 We do not currently knowingly deploy any Python 2 module in the above list, although it's possible some packages are manually installed on some host. The TPA code base still has a lot of Python 2 code, particularly on the LDAP server, but there's a lot of Python 2 code floating around the infrastructure. We haven't performed an audit of the code and are fixing issues as they come up as part of the Python 2 upgrade procedure. Other services have not been examined. So far, most services actually run under Python 3, or have been found to be already ported and just needing a redeployment (see [tpo/network-health/metrics/exit-scanner#40004][] for an example). [tpo/network-health/metrics/exit-scanner#40004]: https://gitlab.torproject.org/tpo/network-health/metrics/exit-scanner/-/iss… # Proposal After the Debian 11 "bullseye" upgrade, TPA will *not* support Python 2 modules that were removed from Debian. Any program using such a module will need to be ported to Python 3, as the packages shipping those modules will be removed as part of the upgrade procedure. The `/usr/bin/python` binary will remain, for now, as the 2.7.18 executable. After the Debian 12 "bookworm" upgrade, Python 2 will be completely removed from servers. Any program using Python 2 will likely stop working completely as the `/usr/bin/python` command will be removed. The `/usr/bin/python` command *may* eventually be replaced by the Python 3 interpreter, but that will not be before the bookworm upgrade procedure begins, and only if the lack of a `python` binary is too problematic for users. ## Timeline Debian 11 bullseye upgrades should complete by July 1st 2022, but most upgrades should complete by the second week of May 2022, that is next week, starting on May 9th 2022 and continuing during the week. A grace period *may* be given to certain projects that cannot immediately port their code to Python 3, by keeping Python 2 modules from Debian buster installed, even after the bullseye upgrade. Those modules will *definitely* be removed by July 1st 2022, however. Debian 12 bookworm upgrades are currently scheduled to begin some time in 2023 and should be completed before July 2024. An actual schedule will be proposed in a future announcement. When this change will be deployed, Python 2 will be gone from TPA servers. ## Affected users This affects any service admin who deploys Python code on TPA infrastructure. # Alternatives considered We have considered just ignoring this problem, and in fact that was the approach with the [original Debian 11 bullseye upgrade proposal][]. Although it didn't state it explicitly, it didn't have any plan for the Python 2 upgrade. And indeed, the issue about the [Python end of life][] was postponed to the [Debian 12 bookworm upgrade milestone][], because it was believed Python 2 would just keep working in Debian 11. Unfortunately, the [second batch of upgrades][] showed the situation was much more severe than we expected, and required a more radical approach. [second batch of upgrades]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40692 [Python end of life]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/33949 [original Debian 11 bullseye upgrade proposal]: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-20-bullse… Another alternative to porting your code to Python 3 is actually to use the PyPy interpreter, which still supports Python 2 (and is actually still struggling with its Python 3 port). However, we strongly discourage this approach, and `pypy` is not currently installed on any TPA server. GitLab CI users may be able to ignore this issue by using containers that do ship Python 2. Note that we *may*, in the future, implement controls on the container images deployed from GitLab CI to avoid using old, unsupported software in this way, exactly for this kind of situation. But for now there are no such controls. We strongly discourage the use of outdated software, including containers, inside your tool chain, in general. # Costs Staff. There is no estimate on the volume of Python 2 code left to upgrade. A study of this should probably be performed at some point, but so far we have assumed this wasn't a problem, so we are dealing with this on a case-by-case basis. # Approval TPA. # Deadline This proposal will welcome comments until Tuesday May 10th, at which point it will be considered adopted and the Debian bullseye upgrades will resume. We acknowledge this is an extremely short deadline (~5 days), but we have actually planned those Debian bullseye upgrade for a while, and somehow expected there wouldn't be much Python 2 code lying around. We hope that the exception for Python 2 modules (until July 1st) will be sufficient mitigation for us to continue with the bullseye upgrades in a timely manner. # Status This proposal is currently in the `proposed` state. # References * [Discussions about this proposal][], comments welcome here! * [Debian 11 bullseye upgrade milestone][] * [Debian 12 bookworm upgrade milestone][] [Discussions about this proposal]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/33949 [Debian 11 bullseye upgrade milestone]: https://gitlab.torproject.org/groups/tpo/tpa/-/milestones/5 [Debian 12 bookworm upgrade milestone]: https://gitlab.torproject.org/groups/tpo/tpa/-/milestones/6 -- Antoine Beaupré torproject.org system administration

1 1