Hi,
So TPA has adopted this proposal, internally, to make yet another set of
emergency changes to our mail system, to respond to critical issues
affecting delivery and sustainability of our infrastructure.
I encourage you to read the "Affected users" section and "Timeline"
below. In particular, we will be experimenting with "sender rewriting"
soon, which will involve mangling emails we forward around to try and
fix deliverability on those.
The schleuder mailing list will also move servers.
Maintenance windows for those changes will be communicated separately.
Thank you for your attention!
PS: and no, we didn't submit this for adoption to everyone, because it
was felt it was mostly technical changes that didn't warrant outside
approval, let me know if that doesn't make sense, of course.
--
Antoine Beaupré
torproject.org system administration
---
title: TPA-RFC-71: Emergency email deployments, phase B
costs: staff
approval: TPA
affected users: all torproject.org email users
deadline: 5 days, 2024-10-01
status: draft
discussion: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41778
---
Summary: deploy a new sender-rewriting mail forwarder ASAP, migrate
mailing lists off the legacy server to a new machine, migrate the
remaining Schleuder list to the Tails server, upgrade `eugeni`.
Table of contents:
- Background
- Proposal
- Actual changes
- Mailman 3 upgrade
- New sender-rewriting mail exchanger
- Schleuder migration
- Upgrade legacy mail server
- Goals
- Must have
- Nice to have
- Non-Goals
- Scope
- Affected users
- Personas
- Timeline
- Optimistic timeline
- Worst case scenario
- Alternatives considered
- References
- History
- Personas descriptions
- Ariel, the fundraiser
- Blipblop, the bot
- Gary, the support guy
- John, the contractor
- Mallory, the director
- Nancy, the fancy sysadmin
- Orpheus, the developer
# Background
In [#41773][], we had yet another report of issues with mail delivery,
particularly with email forwards, that are plaguing Gmail-backed
aliases like grants@ and travel@.
[#41773]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41773
This is becoming critical. It has been impeding people's capacity of
using their email at work for a while, but it's been more acute since
google's recent changes in email validation (see [#41399][]) as now
hosts that have adopted the SPF/DKIM rules are bouncing.
[#41399]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41399
On top of that, we're way behind on our buster upgrade schedule. We
still have to upgrade our primary mail server, `eugeni`. The plan for
that ([TPA-RFC-45][], [#41009][]) was to basically re-architecture
everything. That won't happen fast enough for the LTS retirement which
we have crossed two months ago (in July 2024) already.
[TPA-RFC-45]: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-45-mail-a…
[#41009]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41009
So, in essence, our main mail server is unsupported now, and we need
to fix this as soon as possible
Finally, we also have problems with certain servers (e.g. `state.gov`)
that seem to dislike our bespoke certificate authority (CA) which
makes *receiving* mails difficult for us.
# Proposal
So those are the main problems to fix:
- Email forwarding is broken
- Email reception is unreliable over TLS for some servers
- Mail server is out of date and hard to upgrade (mostly because of
Mailman)
## Actual changes
The proposed solution is:
- **Mailman 3 upgrade** ([#40471][])
- **New sender-rewriting mail exchanger** ([#40987][])
- **Schleuder migration**
- **Upgrade legacy mail server** ([#40694][])
[#40471]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40471
[#40987]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40987
[#40694]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40694
### Mailman 3 upgrade
Build a new mailing list server to host the upgraded Mailman 3
service. Move old lists over and convert them while retaining the old
archives available for posterity.
This includes lots of URL changes and user-visible disruption, little
can be done to work around that necessary change. We'll do our best to
come up with redirections and rewrite rules, but ultimately this is a
disruptive change.
This involves yet another authentication system being rolled out, as
Mailman 3 has its own user database, just like Mailman 2. At least
it's one user per site, instead of per list, so it's a slight
improvement.
This is issue [#40471][].
### New sender-rewriting mail exchanger
This step is carried over from [TPA-RFC-45][], mostly unchanged.
[Sender Rewriting Scheme]: https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme
[postsrsd]: https://github.com/roehling/postsrsd
[postforward]: https://github.com/zoni/postforward
Configure a new "mail exchanger" (MX) server with TLS certificates
signed by our normal public CA (Let's Encrypt). This replaces that
part of `eugeni`, will hopefully resolve issues with `state.gov` and
others ([#41073][], [#41287][], [#40202][], [#33413][]).
[#33413]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/33413
[#40202]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40202
[#41287]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41287
[#41073]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41073
This would handle forwarding mail to other services (e.g. mailing
lists) but also end-users.
To work around reputation problems with forwards ([#40632][],
[#41524][], [#41773][]), deploy a [Sender Rewriting Scheme][] (SRS)
with [postsrsd][] (packaged in Debian, but [not in the best shape][])
and [postforward][] (not packaged in Debian, but zero-dependency
Golang program).
It's possible deploying [ARC][] headers with [OpenARC][], Fastmail's
[authentication milter][] (which [apparently works better][]), or
[rspamd's arc module][] might be sufficient as well, to be tested.
[OpenARC]: https://tracker.debian.org/pkg/openarc
[not in the best shape]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017361
Having it on a separate mail exchanger will make it easier to swap in
and out of the infrastructure if problems would occur.
The mail exchangers should also sign outgoing mail with DKIM, and
*may* start doing better validation of incoming mail.
[authentication milter]: https://github.com/fastmail/authentication_milter
[apparently works better]: https://old.reddit.com/r/postfix/comments/17bbhd2/about_arc/k5iluvn/
[rspamd's arc module]: https://rspamd.com/doc/modules/arc.html
[#41524]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41524
[#40632]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40632
[ARC]: http://arc-spec.org/
### Schleuder migration
Migrate the remaining mailing list left (the Community Council) to the
Tails Shleuder server, retiring our Schleuder server entirely.
This requires configuring the Tails server to accept mail for
`(a)torproject.org`.
Note that this may require changing the addresses of the existing
Tails list to `(a)torproject.org` if Schleuder doesn't support virtual
hosting (which is likely).
### Upgrade legacy mail server
Once Mailman has been safely moved aside and is shown to be working
correctly, upgrade Eugeni using the normal procedures. This should be
a less disruptive upgrade, but is still risky because it's such an old
box with lots of legacy.
One key idea of this proposal is to keep the legacy mail server,
`eugeni`, in place. It will continue handling the "MTA" (Mail Transfer
Agent) work, which is to relay mail for other hosts, as a legacy
system.
The full eugeni replacement is seen as too complicated and unnecessary
at this stage. The legacy server will be isolated from the rewriting
forwarder so that outgoing mail is mostly unaffected by the forwarding
changes.
## Goals
This is not an exhaustive solution to all our email problems,
[TPA-RFC-45][] is that longer-term project.
### Must have
- Up to date, supported infrastructure.
- Functional legacy email forwarding.
### Nice to have
- Improve email forward deliverability to Gmail.
### Non-Goals
- **Clean email forwarding**: email forwards *may* be mangled and
rewritten to appear as coming from `(a)torproject.org` instead of the
original address. This will be figured out at the implementation
stage.
- **Mailbox storage**: out of scope, see [TPA-RFC-45][]. It is hoped,
however, that we *eventually* are able to provide such a service, as
the sender-rewriting stuff might be too disruptive in the long run.
- **Technical debt**: we keep the legacy mail server, `eugeni`.
- **Improved monitoring**: we won't have a better view in how well we
can deliver email.
- **High availability**: the new servers will not add additional
"single point of failures", but will not improve our availability
situation (issue [#40604][])
[#40604]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40604
## Scope
This proposal affects the all inbound and outbound email services
hosted under `torproject.org`. Services hosted under `torproject.net`
are *not* affected.
It also does *not* address directly phishing and scamming attacks
([#40596][]), but it is hoped the new mail exchanger will provide
a place where it is easier to make such improvements in the future.
[#40596]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40596
## Affected users
This affects all users which interact with `torproject.org` and its
subdomains over email. It particularly affects all "tor-internal"
users, users with LDAP accounts, or forwards under `(a)torproject.org`,
as their mails will get rewritten on the way out.
### Personas
Here we collect a few "personas" and try to see how the changes will
affect them, largely derived from [TPA-RFC-45][], but without the
alpha/beta/prod test groups.
For *all* users, a common impact is that emails will be rewritten by
the sender rewriting system. As mentioned above, the impact of this
still remains to be clarified, but at least the hidden `Return-Path`
header will be changed for bounces to go to our servers.
Actual personas are in the Reference section, see [Personas
descriptions][].
| Persona | Task | Impact |
|---------|-------------|--------------------------------------------------------------------------|
| Ariel | Fundraising | Improved incoming delivery |
| Blipbot | Bot | No change |
| Gary | Support | Improved incoming delivery, new moderator account on mailing list server |
| John | Contractor | Improved incoming delivery |
| Mallory | Director | Same as Ariel |
| Nancy | Sysadmin | No change in delivery, new moderator account on mailing list server |
| Orpheus | Developer | No change in delivery |
[Personas descriptions]: #personas-descriptions
## Timeline
### Optimistic timeline
- Late September (W39): issue raised again, proposal drafted (now)
- October:
- W40: proposal approved, installing new rewriting server
- W41: rewriting server deployment, new mailman 3 server
- W42: mailman 3 mailing list conversion tests, users required for testing
- W43: mailman 2 retirement, mailman 3 in production
- W44: Schleuder mailing list migration
- November:
- W45: `eugeni` upgrade
### Worst case scenario
- Late September (W39): issue raised again, proposal drafted (now)
- October:
- W40: proposal approved, installing new rewriting server
- W41-44: difficult rewriting server deployment
- November:
- W44-W48: difficult mailman 3 mailing list conversion and testing
- December:
- W49: Schleuder mailing list migration vetoed, Schleuder stays on
`eugeni`
- W50-W51: `eugeni` upgrade postponed to 2025
- January 2025:
- W3: `eugeni` upgrade
# Alternatives considered
We decided to not just run the sender-rewriting on the legacy mail
server because too many things are tangled up in that server. It is
just too risky.
We have also decided to not upgrade Mailman in place for the same
reason: it's seen as too risky as well, because we'd first need to
upgrade the Debian base system and if that fails, rolling back is too
hard.
# References
- [discussion issue][]
[discussion issue]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41778
## History
This is the the *fifth* proposal about our email services, here are
the previous ones:
* [TPA-RFC-15: Email services][] (rejected, replaced with TPA-RFC-31)
* [TPA-RFC-31: outsource email services][] (rejected, in favor of
TPA-RFC-44 and following)
* [TPA-RFC-44: Email emergency recovery, phase A][] (standard, and
mostly implemented except the sender-rewriting)
* [TPA-RFC-45: Mail architecture][] (still draft)
[TPA-RFC-15: Email services]: policy/tpa-rfc-15-email-services
[TPA-RFC-31: outsource email services]: policy/tpa-rfc-31-outsource-email
[TPA-RFC-44: Email emergency recovery, phase A]: policy/tpa-rfc-44-email-emergency-recovery
[TPA-RFC-45: Mail architecture]: policy/tpa-rfc-45-mail-architecture
## Personas descriptions
### Ariel, the fundraiser
Ariel does a lot of mailing. From talking to fundraisers through
their normal inbox to doing mass newsletters to thousands of people on
CiviCRM, they get a lot done and make sure we have bread on the table
at the end of the month. They're awesome and we want to make them
happy.
Email is absolutely mission critical for them. Sometimes email gets
lost and that's a major problem. They frequently tell partners their
personal Gmail account address to work around those problems. Sometimes
they send individual emails through CiviCRM because it doesn't work
through Gmail!
Their email forwards to Google Mail and they now have an LDAP account
to do email delivery.
### Blipblop, the bot
Blipblop is not a real human being, it's a program that receives
mails and acts on them. It can send you a list of bridges (bridgedb),
or a copy of the Tor program (gettor), when requested. It has a
brother bot called Nagios/Icinga who also sends unsolicited mail when
things fail.
There are also bots that sends email when commits get pushed to some
secret git repositories.
### Gary, the support guy
Gary is the ticket overlord. He eats tickets for breakfast, then
files 10 more before coffee. A hundred tickets is just a normal day at
the office. Tickets come in through email, RT, Discourse, Telegram,
Snapchat and soon, TikTok dances.
Email is absolutely mission critical, but some days he wishes there
could be slightly less of it. He deals with a lot of spam, and surely
something could be done about that.
His mail forwards to Riseup and he reads his mail over Thunderbird
and sometimes webmail. Some time after TPA-RFC_44, Gary managed to
finally get an OpenPGP key setup and TPA made him a LDAP account so he
can use the submission server. He has already abandoned the Riseup
webmail for TPO-related email, since it cannot relay mail through the
submission server.
### John, the contractor
John is a freelance contractor that's really into privacy. He runs his
own relays with some cools hacks on Amazon, automatically deployed
with Terraform. He typically run his own infra in the cloud, but
for email he just got tired of fighting and moved his stuff to
Microsoft's Office 365 and Outlook.
Email is important, but not absolutely mission critical. The
submission server doesn't currently work because Outlook doesn't allow
you to add just an SMTP server. John does have an LDAP account,
however.
### Mallory, the director
Mallory also does a lot of mailing. She's on about a dozen aliases
and mailing lists from accounting to HR and other unfathomable
things. She also deals with funders, job applicants, contractors,
volunteers, and staff.
Email is absolutely mission critical for her. She often fails to
contact funders and critical partners because `state.gov` blocks our
email -- or we block theirs! Sometimes, she gets told through LinkedIn
that a job application failed, because mail bounced at Gmail.
She has an LDAP account and it forwards to Gmail. She uses Apple Mail
to read their mail.
### Nancy, the fancy sysadmin
Nancy has all the elite skills in the world. She can configure a
Postfix server with her left hand while her right hand writes the
Puppet manifest for the Dovecot authentication backend. She browses
her mail through a UUCP over SSH tunnel using mutt. She runs her own
mail server in her basement since 1996.
Email is a pain in the back and she kind of hates it, but she still
believes entitled to run their own mail server.
Her email is, of course, hosted on her own mail server, and she has
an LDAP account. She has already reconfigured her Postfix server to
relay mail through the submission servers.
### Orpheus, the developer
Orpheus doesn't particular like or dislike email, but sometimes has
to use it to talk to people instead of compilers. They sometimes have
to talk to funders (`#grantlyfe`), external researchers, teammates or
other teams, and that often happens over email. Sometimes email is
used to get important things like ticket updates from GitLab or
security disclosures from third parties.
They have an LDAP account and it forwards to their self-hosted mail
server on a OVH virtual machine. They have already reconfigured their
mail server to relay mail over SSH through the jump host, to the
surprise of the TPA team.
Email is not mission critical, and it's kind of nice when it goes
down because they can get in the zone, but it should really be working
eventually.
--
Antoine Beaupré
torproject.org system administration
--
tpa-team mailing list
tpa-team(a)lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tpa-team
# Introduction
Dear tor-project@,
my work in February 2025 has been centered around two small but powerful
tools that I have authored during this time period.
# oniux
In the beginning of the month, I started the *oniux* project[1], which
utilizes `namespaces(7)` and onionmasq in order to securely isolate an
arbitrary application through Tor. It basically serves as a replacement
for torsocks but in a way that is less hacky and sounds more correct.
My work centered around studying the inner workings of Linux namespaces
and capabilities, writing an initial prototype and finally the real
implementation. I have also given a German-language presentation about
this at my local hackspace and can give you the slides on request.
Please read the projects README for further information about this,
including the inner workings on which I have spent a huge effort to
document those.
# TorVault
During the other half the month, I started the *TorVault* project[2],
which makes it possible to use the `OfflineMasterKey` feature for relays
in combination with a Yubikey.
It provides a guide on how to generate and import a long-term Ed25519
identity key onto a Yubikey (recommended) or on how to generate a
long-term Ed25519 identity key on the Yubikey itself.
The program itself then provides an interactive dialogue that prompts
the user for the relevant information (device name, expiration date,
paths, ...). In the end, the program generates and exports the relevant
keys and certificate(s) which are then ready to be deployed into the
relays `keys/` folder.
I have announced the project onto the tor-relays@ mailing list and I am
already using it in production for my own relay.
Right now, I have plans to port this tool into Rust in order to
eventually integrate it into Arti. Unfortunately, the Rust ecosystem is
– at the moment – not far enough to support this, because Curve25519
support in Yubikeys is a rather new feature not supported by the most
popular Rust Yubikey crate. This is also an area I am working on at the
moment.
Thank You,
Clara
---
[1]: https://gitlab.torproject.org/cve/oniux
[2]: https://gitlab.torproject.org/tpo/core/TorVault
Hello friends,
As Monday 17th is a US holiday, and I’ll be AFK on Tuesday, the UX Team meeting has been postponed until the following Monday instead.
Thanks,
D
1 Hey everyone!
1
2 Here are our meeting logs:
3
http://meetbot.debian.net/tor-meeting/2025/tor-meeting.2025-02-13-16.00.html
4
5 And our meeting pad:
6
7 Anti-censorship work meeting pad
8 --------------------------------
9 Anti-censorship
10 --------------------------------
11
12 Next meeting: Thursday,Feb 27 16:00 UTC
13 Facilitator: shelikhoo
14 ^^^(See Facilitator Queue at tail)
15
16 Weekly meetings, every Thursday at 16:00 UTC, in #tor-meeting at OFTC
17 (channel is logged while meetings are in progress)
18
19 This week's Facilitator: onyinyang
20
21 == Goal of this meeting ==
22
23 Weekly check-in about the status of anti-censorship work at Tor.
24 Coordinate collaboration between people/teams on anti-censorship at
the Tor Project and Tor community.
25
26
27 == Links to Useful documents ==
28 * Our anti-censorship roadmap:
29 *
Roadmap:https://gitlab.torproject.org/groups/tpo/anti-censorship/-/boards
30 * The anti-censorship team's wiki page:
31 *
https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/home
32 * Past meeting notes can be found at:
33 * https://lists.torproject.org/pipermail/tor-project/
34 * Tickets that need reviews: from projects, we are working on:
35 * All needs review tickets:
36 *
https://gitlab.torproject.org/groups/tpo/anti-censorship/-/merge_requests?s…
37 * Project 158 <-- meskio working on it
38 *
https://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues/?label_na…
39
40
41 == Announcements ==
42
43 * No meeting February 20th. There is FOCI at the same time
44 * https://foci.community/
45 * snowflake-graphs proxy CSV files (client-match.csv,
proxy-country.csv, proxy-nat-type.csv, proxy-type.csv) are available
again. (Working around a bad descriptor that had prevented updates since
2024-08.)
46 *
https://gitlab.torproject.org/dcf/snowflake-graphs/-/commit/089e0af01aa6383…
47
48 == Discussion ==
49
50 * moderation of mailing lists to prevent spam
51 *
https://lists.torproject.org/mailman3/hyperkitty/list/anti-censorship-team@…
52 * we agree to moderate new subscribers and remove the
moderation flag on first post if is not spam
53 * Whether to switch to debian fork of golang for CI
54 *
https://gitlab.torproject.org/tpo/tpa/team/-/issues/42014#note_3159983
55 * The problem is sporadic CI failures due to container
rate limits.
56 * The rate limit problem has been fixed, for the
anti-censorship team at least, by maintaining our own mirror of
container images:
57
https://gitlab.torproject.org/tpo/anti-censorship/duplicatedcontainerimages/
58 * tpo/tpa/team#42014 is a request to have the admin
team take on the responsibility of mirroring those container images.
59 * The admin team prefers that we use their existing
Debian images that contain golang, rather than take on a new set of
container mirrors.
60 * shelikhoo has a distaste for Debian-based images,
stemming from past experience with excessive patching and slow updates.
shelikhoo prefers either to build our own golang from source (possibly
on a Debian-based image), or else use a binary release of golang.
61 * Debian patches to golang:
https://sources.debian.org/patches/golang-1.19/1.19.13-1~bpo11%2B1/
62 * So the trilemma is: 1. extra maintenance for the
anti-censorship team (duplicatedcontainerimages), 2. extra maintenance
for the admin team, or 3. using the admin team–maintained images which
shelikhoo does not want to use.
63 * The resolution is #1: keep using our own mirror at
our own maintenance expense.
64 * TPA provides golang containers based on oldstable,
stable, testing and sid versions of golang
65 * golang version in debian might be different than the
official one
66 * we'll keep using our mirrors of containers
67 * Would we like to support WASM version of proxy?
68 *
https://gitlab.torproject.org/WofWca/snowflake/-/compare/main...wasm?from_p…
69 * we could replace the javascript logic of the webextension
with the WASM version of the standalone proxy. Removing the need to
duplicate functionallity in two languages
70 * When compiled to WASM, Pion acts as a wrapper around the
browser's own WebRTC API (i.e. Pion doesn't craft its own DTLS records
etc.). So it may be possible to keep browser protocol fingerprints the
way they are already.
71 *
https://github.com/pion/webrtc/blob/v4.0.9/examples/README.md#webassembly
"Pion WebRTC can be used when compiled to WebAssembly, also known as
WASM. In this case the library will act as a wrapper around the
JavaScript WebRTC API."
72
73 for Feb 27:
74 * Should we user test snowflake with covert-dtls? It is
difficult to force Snowflake client to become the DTLS client:
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
75 * "After some debugging, reading the pion webrtc source code,
and referencing RFC 5763 (DTLS-SRTP framework) I realized why hook was
never triggered. The Snowflake client will almost always become the
server in the DTLS handshake as sends the SDP Offer every time.
According to the RFC, only the offer can decide who becomes the client
or server."
76
77 == Actions ==
78
79 == Interesting links ==
80
81 *
https://opencollective.com/censorship-circumvention/projects/snowflake-dail…
82 *
https://opencollective.com/censorship-circumvention/projects/snowflake-dail…
83 * €3,917.57 snowflake-01 bandwidth expenses in 2024
84
85 == Reading group ==
86
87 * We will discuss "Identifying VPN Servers through
Graph-Represented Behaviors" on February 27
88 * https://dl.acm.org/doi/10.1145/3589334.3645552
89 * https://dl.acm.org/doi/pdf/10.1145/3589334.3645552
90 * https://github.com/chenxuStep/VPNChecker
91 * Questions to ask and goals to have:
92 * What aspects of the paper are questionable?
93 * Are there immediate actions we can take based on this
work?
94 * Are there long-term actions we can take based on this
work?
95 * Is there future work that we want to call out in
hopes that others will pick it up?
96
97 == Updates ==
98 Name:
99 This week:
100 - What you worked on this week.
101 Next week:
102 - What you are planning to work on next week.
103 Help with:
104 - Something you need help with.
105
106 cecylia (cohosh): 2025-02-13
107 Last week:
108 - supported conjure work
109 - reviewed snowflake!315
110 - helped debug and and give feedback on snowflake website
111 - updated our jasmine tests for snowflake-webext CI
(snowflake-webext#112)
112 - responded to emails on SQS rendezvous
113 - commented on onionperf + python3.13 issue (onionperf#40051)
114 - finally closed out the meek bridge handover issue (team#133)
115 - updated team#142 with recent proxy count graphs and closed it
116 - other random reviews and todos
117 This week:
118 - support conjure work
119 - debug SQS rendezvous 400 errors
120 - take a look at potential snowflake orbot bug
121 -
https://github.com/guardianproject/orbot-android/issues/1183
122 - maybe do some lox work
123
124 dcf: 2025-02-13
125 Last week:
126 - snowflake azure CDN bookkeeping
https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-co…
127 - decommissioned the snowflake-broker.azureedge.net CDN
profile
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
128 - decommissioned the old snowflake broker VPS instance
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
129 - verified documentation fix for snowflake-broker journalctl
command
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
130 Next week:
131 - open issue to have snowflake-client log whenever
KCPInErrors is nonzero
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
132 - parent:
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
133 - open issue to disable /debug endpoint on snowflake broker
134 Help with:
135
136 meskio: 2024-02-13
137 Last week:
138 - long discussions around rdsys in containers (rdsys#219)
139 - debug why webtunnel in lyrebird is not accepting https
proxy (lyrebird#40024)
140 - fix moat so it will distribute webtunnel bridges in russia
(rdsys#256)
141 - bring backward compatibility on the moat captcha API
(rdsys!480)
142 Next week:
143 - steps towards a rdsys in containers (rdsys#219)
144
145 Shelikhoo: 2024-02-13
146 Last Week:
147 - [Refine] Unreliable+unordered WebRTC data channel
transport for Snowflake rev2 (cont.)(
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
) improvements
148 - [Invesgate]Add support for using a proxy to connect to
the
PTs(https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/…
149 - Merge request reviews
150 Next Week/TODO:
151 - Merge request reviews
152 - [Refine] Unreliable+unordered WebRTC data channel
transport for Snowflake rev2 (cont.)(
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
) improvements
153 - [Deploy] Remove domain snowflake-broker.bamsoftware.com
from snowflake broker's ACME tool
154 - [Fix] Add support for using a proxy to connect to the
PTs(https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/…
155
156 onyinyang: 2025-02-13
157 Last week(s):
158 - continued work on ampcache registration method for conjure
159 - WIP MR: https://github.com/cohosh/conjure/pull/1
160 Next week:
161 - finish up ampcache registration method (sqs on hold for now)
162 - Begin work on either obfs4 transport or decoy registration
option
163 - FOCI
164 - add TTL cache to lox MR for duplicate responses:
165
https://gitlab.torproject.org/tpo/anti-censorship/lox/-/merge_requests/305
166 As time allows:
167 - Continue work on implementing issuer efficiency for
check-blockage and trust-promotion protocols
168 - Work on outstanding milestone issues:
169 - key rotation automation
170
171 Later:
172 pending decision on abandoning lox wasm in favour of some
kind of FFI?
https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43096):
173 - add pref to handle timing for pubkey checks in Tor browser
174 - add trusted invitation logic to tor browser integration:
175
https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42974
176 - improve metrics collection/think about how to show Lox is
working/valuable
177 - sketch out Lox blog post/usage notes for forum
178
179 (long term things were discussed at the meeting!):
180 - brainstorming grouping strategies for Lox buckets (of
bridges) and gathering context on how types of bridges are
distributed/use in practice
181 Question: What makes a bridge usable for a given user,
and how can we encode that to best ensure we're getting the most
appropriate resources to people?
182 1. Are there some obvious grouping strategies that
we can already consider?
183 e.g., by PT, by bandwidth (lower bandwidth
bridges sacrificed to open-invitation buckets?), by locale (to be
matched with a requesting user's geoip or something?)
184 2. Does it make sense to group 3 bridges/bucket, so
trusted users have access to 3 bridges (and untrusted users have access
to 1)? More? Less?
185
186 theodorsm: 2025-02-13
187 Last weeks:
188 - Debugging Tor Build with covert-dtls:
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
189 Next weeks:
190 - Update covert-dtls to handle new DTLS extensions in
recent browsers
191 - Write instructions on how to configure covert-dtls
with snowflake client
192 - Fix merge conflicts in MR
(https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…).
193 - Condensing thesis into paper (on hold)
194 Help with:
195 - Test stability of covert-dtls in snowflake
196
197
198
199 Facilitator Queue:
200 onyinyang shelikhoo meskio
201 1. First available staff in the Facilitator Queue will be the
facilitator for the meeting
202 2. After facilitating the meeting, the facilitator will be moved to
the tail of the queue
~
~
~
~
--
---
onyinyang
GPG Fingerprint 3CC3 F8CC E9D0 A92F A108 38EF 156A 6435 430C 2036
Hi everyone,
Next Monday is a US holiday, so we will cancel our weekly IRC meeting.
The next one will be Monday February 24 (2025-02-24) at 1600 UTC in
#tor-meeting.
best,
-morgan
Hi!
We had our monthly meeting today, and here are the minutes.
# Roll call: who's there and emergencies
anarcat, groente, lavamind, lelutin and zen
# Dashboard review
Normal per-user check-in:
- <https://gitlab.torproject.org/groups/tpo/-/boards?scope=all&utf8=%E2%9C%93&…>
- <https://gitlab.torproject.org/groups/tpo/-/boards?scope=all&utf8=%E2%9C%93&…>
- <https://gitlab.torproject.org/groups/tpo/-/boards?scope=all&utf8=%E2%9C%93&…>
- <https://gitlab.torproject.org/groups/tpo/-/boards?scope=all&utf8=%E2%9C%93&…>
- <https://gitlab.torproject.org/groups/tpo/-/boards?scope=all&utf8=%E2%9C%93&…>
General dashboards:
- <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>
# FYI: tpo/tpa/tails/sysadmin moved to tpo/tpa/tails-sysadmin
Just that.
# February capacity review
We reviewed the "everything everwhere all the time" capacity
spreadsheet and confirmed the various people's allocations for
February:
- anarcat: coordination, security policy, pgBackRest, MinIO backups
- groente: email wrap up, start work on a plan for merging
authentication services
- lavamind: Puppet packaging and deployments, rdsys
contenainerization, GitLab MinIO migration
- lelutin: Prometheus phase B, MinIO backups
- zen: Tails' Bitcoin retirement, LimeSurvey merge, Icinga retirement
plan, Puppet merge plan proposal
# g10k decision
we're going to go ahead with the original g10k control repo plan (no
git modules, no monorepo, yes Puppetfile, yes git/package hashes),
this will require replacing the current environments deployment hook
provided by the puppet module and investigating how to deploy the
environments with g10k directly.
# Next meeting
March 3rd, as per regular scheduling.
# Metrics of the month
* hosts in Puppet: 90, LDAP: 90, Prometheus exporters: 584
* number of Apache servers monitored: 33, hits per second: 609
* number of self-hosted nameservers: 6, mail servers: 90
* pending upgrades: 0, reboots: 84
* average load: 1.17, memory available: 3.26 TiB/5.11 TiB, running processes: 238
* disk free/total: 58.89 TiB/142.92 TiB
* bytes sent: 475.80 MB/s, received: 304.62 MB/s
* [GitLab tickets][]: 257 tickets including...
* open: 1
* icebox: 156
* needs information: 4
* backlog: 21
* next: 16
* doing: 6
* needs review: 11
* (closed: 3919)
[Gitlab tickets]: https://gitlab.torproject.org/tpo/tpa/team/-/boards
We do not have an upgrade prediction graph as there are no major upgrades in progress.
--
Antoine Beaupré
torproject.org system administration
Hi! Below is my January’25 (Period: 2025-01-01 - 2025-01-27) report!
I have become more familiar with the projects, documents and internal
policies of the Tor Project.
In January, I resolved about 27 tickets from Farsi-speaking users:
* On Telegram (@TorProjectSupportBot) - 25;
* On RT (frontdesk@tpo) - 2;
Reported Right-to-left lack of support issue on RT:
https://gitlab.torproject.org/tpo/community/support/-/issues/40174
This is the pad link for my report :
https://pad.riseup.net/p/Haidi-Report-January2025-keep
Thanks,
Haidi