Hi!
Here are your monthly TPA minutes, enjoy!
# Roll call: who's there and emergencies
anarcat, kez, lavamind, gaba are present. colchicifolium backups are
broken, and we're looking into it, but that's not really an emergency,
as it is definitely not new. see [issue 40650][].
[issue 40650]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40650
# TPA-RFC-15: email services
We discussed the [TPA-RFC-15][] proposal.
[TPA-RFC-15]: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-15-
The lack of IMAP services is going to be a problem for some personas
and should probably be considered part of the propsoal.
For approval, we should first send to tor-internal for comments, then
a talk at all hands in april, then isa/sue for financial approval.
# Dashboard review
We went through the 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
We moved a bunch of stuff to the icebox (particularly in the
gitlab-lobby and anon_ticket projects), and also made sure to assign
every ~Next ticket to someone in the web team. Generally, we only
looked at tickets associated with a Milestone in the web dashboard
because it's otherwise too crowded.
# Upcoming work parties
We're going to have those work parties coming up:
* ganeti gnt-chi: on Tuesday, finish setting up the gnt-chi cluster,
to train people with out of band access and ipsec
* bullseye upgrades: in a week or two, to upgrade a significant chunk
of the fleet to bullseye, see [ticket 40662][] where we'll make a
plan and send announcements
[ticket 40662]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40662
# Holidays
anarcat is planning some off time during the first weeks of august, do
let him know if you plan to take some time off this summer.
# future of media.tpo
We discussed the future of media.tpo ([tpo/web/team#30][]), since it
mentions rsync and could be a place to store things like assets for
the blog and other sites.
anarcat said we shouldn't use it as a CDN because it's really just an
archive, and only a single server. if we need a place like that, we
should find some other place. we should probably stop announcing the
rsync service instead of fixing it, I doubt anyone is using that.
[tpo/web/team#30]: https://gitlab.torproject.org/tpo/web/team/-/issues/30#note_2785843>
# Other discussions
We briefly talked about colchicifolium, but that will be reviewed at
the next checkin.
# Next meeting
April 4th.
# Metrics of the month
* hosts in Puppet: 87, LDAP: 87, Prometheus exporters: 143
* number of Apache servers monitored: 25, hits per second: 301
* number of self-hosted nameservers: 6, mail servers: 8
* pending upgrades: 22, reboots: 1
* average load: 0.92, memory available: 4.11 TiB/5.13 TiB, running processes: 646
* disk free/total: 31.96 TiB/84.70 TiB
* bytes sent: 331.59 MB/s, received: 201.29 MB/s
* planned bullseye upgrades completion date: 2024-12-01
* [GitLab tickets][]: 177 tickets including...
* open: 0
* icebox: 151
* backlog: 9
* next: 9
* doing: 5
* needs information: 3
* (closed: 2643)
[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.
--
Antoine Beaupré
torproject.org system administration
Hi,
As part of the procmail retirement I announce on March 1st, the email
notification hook used by the old Gitolite server to notify users of new
patches started breaking in odd and unpredictable ways:
https://gitlab.torproject.org/tpo/tpa/team/-/issues/40653https://gitlab.torproject.org/tpo/tpa/team/-/issues/40659
I have tried to fix this by deploying `reformail` as a `formail`
replacement, but that ultimately failed as well. In the end, I deployed
a newer mailing hook called "git-multimail":
https://github.com/git-multimail/git-multimail
After a brief test period inside TPA, all repositories have been
switched over to the new hook today. You might notice a different email
template. It's also possible you receive more email than before.
If there's any significant problem with the new hook, do let us know in
the usual place:
https://gitlab.torproject.org/tpo/tpa/team/-/wikis/support
There is no clear list of changes since the last hook, because the hook
we were using was an in-house version with no corresponding upstream
version. That said, it was fairly similar to the defunct
`post-receive-email` hook, and there *is* a list of differences between
git-multimail and that, which you can read here:
https://github.com/git-multimail/git-multimail/blob/master/git-multimail/RE…
That's about it, thank you for your attention and have a nice day,
a.
--
Antoine Beaupré
torproject.org system administration
Hey everyone!
Here are our meeting logs:
http://meetbot.debian.net/tor-meeting/2022/tor-meeting.2022-03-10-15.59.html
And our meeting pad:
Anti-censorship work meeting pad
--------------------------------
Next meeting: Thursday March 17th 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 checkin 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 30
* https://gitlab.torproject.org/groups/tpo/-/milestones/4
* https://gitlab.torproject.org/groups/tpo/-/milestones/7
* https://gitlab.torproject.org/groups/tpo/-/milestones/5
* https://gitlab.torproject.org/groups/tpo/-/milestones/6
* 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&…
== Announcements ==
== Discussion ==
* (from March 11th) Reach an agreement on distributed Snowflake (Broker)|(Server) design. Shel: are you going to be workign on https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ? What else we need to move forward on it? -- from gaba
* The client telling the broker what bridge it wants to use: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
* missing pieces:
* broker having a list of known bridge fingerprints
* proxies telling the broker what bridges they know about in their poll messages
* might be a good next step
* arlo is happy to pick this up, if it's helpful +1
* broker matching clients with proxies, considering not only NAT compatibility but bridge fingerprint
* proxies will need to both (1) know how to interpret the broker's instructions as to what websocket server to connect to, and (2) know how to forward the client's requested bridge fingerprint to the websocket server.
* a proxy that does not signal such support to the broker can be matched only with clients that either: do not specify a bridge fingerprint, or specify the current default 2B280B23E1107BB62ABFC40DDCC8824814F80A72
* proxies forwarding bridge fingerprint to snowflake-server intheir websocket connection
* snowflake-server having its own internal mapping of bridge fingerprint -> ExtORPort address
* needs a configuration file or something, can no longer come from TOR_PT_EXTENDED_SERVER_PORT environment variable since there may be more than one
* Next steps:
* who is doing what?
* snowflake proxy auto-update?
* webextensions have their usual update mechanism
* docker auto-update if enabled
* deb package updates
* people compiling and running their own go-proxy, no updates or notifications of updates
* the web badge does a page refresh (i think)
== Actions ==
== Interesting links ==
* https://bsd.network/@matthieu/107900307121945165
* running snowflake proxy on OpenBSD
== Reading group ==
* We will discuss "Throttling Twitter: an emerging censorship technique in Russia" on 17 March
* https://dl.acm.org/doi/pdf/10.1145/3487552.3487858
* https://censorbib.nymity.ch/#Xue2021a
* 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-03-10
Last week:
- worked on setting up a dev environment for conjure
- https://github.com/refraction-networking/conjure/wiki/Environment-Setup
- some reviews
This week:
- continued work on conjure PT
- continue to monitor snowflake broker stats
- review rdsys!15
Needs help with:
dcf: 2022-03-10
Last week:
- worked on aquiring resources for better hosting for the snowflake bridge
- posted summary of snowflake amp cache https://github.com/net4people/bbs/issues/109
- posted observations on multi-instance metrics graphs https://gitlab.torproject.org/tpo/network-health/metrics/onionoo/-/issues/4…
- posted summary of last week's discussion about multiple snowflake bridges https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
- posted notes about IGD port forwarding https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
Next week:
- review arlo's bridge fingerprint forwarding change https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
Help with:
agix: 2021-02-10
Last week:
- Continued work on gettor-twitter
Next week:
- Hopefully finish the task
Help with:
-
arlolra: 2022-03-10
Last week:
- Pass bridge fingerprint in SOCKS param to the broker
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
Next week:
- Revise !81
- Start on the next piece of the multiple bridge design
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-featureshttps://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-03-10
Last week:
- use bridge-distribution-request in rdsys (rdsys#93)
- use rdsys bridges in circumvention settings (bridgedb#40045)
- send the right assingments.log to the metrics
Next week:
- add some untilisting mechanism to circumvention settings (rdsys#79)
Shelikhoo: 2022-03-10
Last Week:
- [Merge Request Awaiting] Add SOCKS5 forward proxy support to snowflake (snowflake!64)
- [Merge Request Awaiting] uTLS for broker negotiation(Updated)
- [Coding & Deployment] Proposal: Centralized Probe Result Collector (anti-censorship/team#54)
- [Deployment] Vantage Point in Vinnica, Ukraine
- [Discussion] Centralized Probe Log Collection Ascension Request
- [Discussion] Hosting Centralized Probe Log Collection Server on TPA managed VPS
Next Week:
- [Coding] Add SOCKS5 forward proxy support to snowflake (snowflake!64) - built-in DNS
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
hanneloresx: 2021-3-4
Last week:
- Submitted MR for bridgestrap issue #14
Next week:
- Finish bridgestrap #14
- Find new issue to work on
Help with:
-
--
meskio | https://meskio.net/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
My contact info: https://meskio.net/crypto.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Nos vamos a Croatan.
Hello everyone!
This is my monthly report for the month of February. Last month we saw a
uptick in the number of requests for unlisted obfs4 bridges. This
resulting in a lot of troubleshooting with the users ranging from bridge
lines not being parsed by Tor because of line breaks to issues with Tor
not bootstrapping because of firewalls and VPNs. With increased usage of
Snowflake, I also helped a lot of users with questions about setting up
a proxy, using Snowflake and other general questions about Snowflake.
With the latest tor release [1], I received a few queries as to how to
verify the signature. We now have the new instructions documented on the
Support Portal [2].
There were three Tor Browser releases last month, namely, 11.0.5
(Android only), 11.0.6, 11.5.a4. We are still receiving a number of
queries from users using macOS < 10.12 for which Tor Browser 11.0.x is
not compatible [3]. And a few users raised the issue [4] about 11.0.6
Windows bundles signed with an old certificate which was reported to and
fixed by the Applications Team.
We maintain a set of templates on our Request Tracker to improve our
workflow and easily respond to recurring queries. I reviewed and updated
all of the articles that we maintain. This exercise is very important
and I intend to do this every quarter at the very least.
That pretty much sums up the highlights from last month and following
are some quick stats and highlights from our official support channels.
# Frontdesk
Timeline : 01 Feb - 28 Feb 2022
Tickets:
new: 38
open: 21
resolved: 852
Breakdown of number of RT tickets received with respect to operating
system:
(Note: This includes tickets where the user mentioned the operating
system or it was evident from the issue they were running into and/or
enclosed screenshots.)
Windows - 6
macOS - 11
GNU/Linux - 1
Android- 4
Breakdown of most frequent tickets (at least 3 RT tickets):
1. 613 RT Tickets - How to use Tor Bridges in Russia. [5]
2. 38 RT Tickets - Private Bridge requests. This is not related to the
.ru censorship but requests from Tor users in China, Iran, etc. [6]
3. 6 RT Tickets - Tor Browser 11 incompatible with older versions of
macOS. [3]
4. 4 RT Tickets- How to verify little-t-tor signature? [2]
5. 3 RT Tickets - Youtube inaccessible over Tor.
# Tor Forum
Most popular topics (in terms of no. of views) in February:
1. "File signature could not be verified 11.0.6_en-US.exe [32-bit]". [7]
2. (Onion) Sites do not work after transfer to another server. Details:
0xF2 - dating [date] error. [8]
3. "Torrc, unit files, confusion" (conflict between the recursive
function of %include and the AppArmor profile) [9]
4. "Login button (on Udemy.com) does not work". [10]
5. "High-speed relays on Windows - not great, not terrible". [11]
Thanks,
-- Joydeep
[1]: https://forum.torproject.net/t/release-0-4-5-12-and-0-4-6-10/2024
[2]: https://support.torproject.org/little-t-tor/verify-little-t-tor/
[3]: https://forum.torproject.net/t/version-of-tor-browser-compatible-with-macos…
[4]: https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/4…
[5]: https://forum.torproject.net/t/tor-blocked-in-russia-how-to-circumvent-cens…
[6]: https://support.torproject.org/censorship/connecting-from-china/
[7]: https://forum.torproject.net/t/file-signature-could-not-be-verified-11-0-6-…
[8]: https://forum.torproject.net/t/sites-do-not-work-after-transfer-to-another-…
[9]: https://forum.torproject.net/t/torrc-unit-files-confusion/2217
[10]: https://forum.torproject.net/t/login-button-does-not-work/2224/12
[11]: https://forum.torproject.net/t/high-speed-relays-on-windows-not-great-not-t…
Hi all :)
This is my monthly status report for February 2022.
Main activities during the period:
0. Onboarding:
It was my first month at Tor and I did a bunch of onboarding & research
tasks that are summarized here:
https://gitlab.torproject.org/tpo/community/team/-/issues/57
2. Sponsor 123:
Bootstrapping tasks, including kickoff and discovery meetings.
3. Started the Oniongroove repository as a follow up from the Onion SRE
notes sent previously:
https://gitlab.torproject.org/rhatto/oniongroove/https://lists.torproject.org/pipermail/tor-project/2022-February/003288.html
Draft specs are currently available at the feature/specs branch,
under heavy development and soon to be rebased/merged into the main branch.
When that happens, they will probably be ready for review/comments/suggestions.
Please let me know if you have references and recommendations about
Onion Services setup, deployment and best practices :)
4. Security policy:
Assigned myself into drafting a security policy (currently in the backlog):
https://gitlab.torproject.org/tpo/team/-/issues/41
I'm looking for examples and references on the topic :)
--
Silvio Rhatto
pronouns he/him
Hello everyone!
This is my monthly status report for February, 2022.
In February, I focused on testing support approaches via cdr.link on
Telegram. Starting the Telegram support at the end of January 2022, we
used the articles from the RT to create template answers in cdr.link. As
I have immersed myself in the specifics of the work via messenger, I
realized that this type of support needs another approach, and shorter
templates would work better. Thus, I rewrote these templates based on
platform and commons issues and added a new one on how to download Tor
Browser, as Russian users often ask about it.
I also added a new template article to deal with requests about onion
services. I also added a similar article to RT, in Russian.
For a month, I have collected experiences of support via cdr.link
channel. The summary can be seen here:
https://gitlab.torproject.org/tpo/community/support/-/issues/40059
This month, since censorship became harder, we started to get more
requests on troubleshooting, as users want to be sure that Tor Browser
works.
Overall, I solved around 1670 tickets in February:
Telegram (Cdr.link) - 953
RT (frontdesk) - 717
Translation
I made some Russian to English and English to Russian translations for
social media:
https://twitter.com/torproject/status/1497241683100061704https://twitter.com/torproject/status/1493332229346365447
Thanks,
Nina
Hi folks,
I've been stretched too thin lately, and am risking further burnout
by trying to continue doing too many things. So in an effort to keep
myself more sustainable, I'm scaling back and focusing on a smaller set
of activities.
My original hope was to spend some real time thinking about
reputation-based ("Salmon"-like) bridge distribution strategies,
first because it is a good self-contained topic and second because we
have funding for it and nobody is scheduled to work on it. But funder
relationship tasks keep coming up, so my best remaining plan is to
try to balance the "funder presentation" interrupts with the "get some
uninterrupted time to think about Salmon" goal.
I've written my priorities, framed loosely as OKRs but I admit it's more
like a roadmap, on a new wiki page:
https://gitlab.torproject.org/tpo/team/-/wikis/arma
with the goal that it will be easier for other people to follow along
with what I'm up to.
For this round I am also using this list of priorities as a way to
constrain my scope: I plan to drop things that aren't on this list. That
is, I'm moving from "best effort, try to do all the things but actually
do too many of them poorly" to "by default, do not do things that aren't
on this list."
My immediate next steps are to make gitlab tickets for the upcoming tasks,
so my gitlab board will better reflect reality. I am going to spend the
rest of this week continuing to do too many things, and this weekend I
will switch gears to start the new plan. So if there is something you
still need from me, it's best to remind me about it this week.
Thank you for your understanding as I attempt this new experiment with
trying to get back to being productive while also staying sane. :)
--Roger
Hey everyone!
Here are our meeting logs:
http://meetbot.debian.net/tor-meeting/2022/tor-meeting.2022-03-03-15.59.html
And our meeting pad:
Anti-censorship work meeting pad
--------------------------------
Next meeting: Thursday March 10th 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 checkin 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 30
https://gitlab.torproject.org/groups/tpo/-/milestones/4https://gitlab.torproject.org/groups/tpo/-/milestones/7https://gitlab.torproject.org/groups/tpo/-/milestones/5https://gitlab.torproject.org/groups/tpo/-/milestones/6
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&…
== Announcements ==
Centralized Probe Result Collector on trial deployment
Russia, Turkey, Beijing probetests are integrated
BridgeDB is now using rdsys
== Discussion ==
obfs4 fail to connect issue
https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40804
we are coordinating with builtin bridges to update, many has already updated
there is now a docker image with the new version
the obfs4proxy 0.0.13 package will land in debian backports soon
snowflake load and bottlenecks
do we need more proxies?
next steps for bridge capacity
probetest is at is capacity
could standalone proxies (which can make direct TCP connections) bypass snowflake-server and connect directly to the tor ExtORPort
no, snowflake-server holds the turbo tunnel state
we want to move into a design where there are multiple snowflake-servers and multiple bridges
idea: partition snowflake-servers and bridges into non-overlapping "pools"
i.e., snowflake-server A forwards to a set of bridges, snowflake-server B forwards to *its* set of bridges, and they share no bridges in common
(which is a generalization of the current case, where there is 1 snowflake-server and 1 bridge)
(there could be distinct brokers for different pools, but that is orthogonal)
partitioning the set of bridges has this effect: when a broker/proxy wants to connect a client's traffic to a snowflake-server, for a specific bridge there is *one and only one* snowflake-server that is associated with that bridge
therefore multiple connections in the same session, which use the same bridge, will also use the same snowflake-server, and therefore not lose turbo tunnel state
it can work like this:
the client torrc specifies the desired bridge fingerprint in its bridge line as a SOCKS param (redundantly with the fingerprint that is already there as part of the syntax)
e.g. `Bridge snowflake 1111222233334444aaaabbbbccccdddd 192.0.2.3:1 url=https://snowflake.torproject.net/front=front.example.com ice=... fingerprint=1111222233334444aaaabbbbccccdddd`
the client sends the desired bridge fingerprint along with its offer to the broker
the broker has a mapping of bridge fingerprints to snowflake-server WebSocket URLs. when the broker matches the client with a proxy, the broker informs the proxy of the WebSocket URL to connect to (i.e., which snowflake-server to connect to). it will always be the same snowflake-server URL for the same bridge fingerprint, because the mapping is consistent.
the proxy connects to the WebSocket URL provided by the broker, and it includes the bridge fingerprint in the URL query string when it makes the connection (the same way the client IP address is communicated: e.g. `?client_ip=1.2.3.4:5678&fingerprint=1111222233334444aaaabbbbccccdddd`)
the snowflake-server has its own mapping of bridge fingerprint to ExtORPort addresses. if it's an existing turbo tunnel session, it just resumes the ExtORPort TCP it already has. if it's a new session, it connects to the ExtORPort address corresponding to the bridge fingerprint.
such a design alleviates the state-sharing concerns with multiple snowflake-servers. as long as a client uses a consistent bridge fingerprint during a session (which it will), it will get mapped to the same snowflake-server.
arlolra is planning to write a patch for including the bridge fingerprint as a bridge line SOCKS param, and passing it to the broker, which is a necessary step for any of this
then there can be multiple snowflake bridge lines in torrc, each with different bridge fingerprints. load balancing will come from the tor client's local random selection.
there is a "thundering herd" concern with the way tor currently uses multiple bridge lines. tor will attempt to connect to all of them at once, and keep using only one of them. This means N broker transactions and N STUN exchanges, and possibly N-1 proxies held idle.
maybe it's not such a big problem, if N is not too large
an alternative would be a modification to tor where it shuffles its bridge list, and tries only one at a time
another alternative is to write the torrc file dynamically: choose a random bridge line, then write torrc containing only that one randomly selected bridge line
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
need to consider backward compatibility: a client that doesn't communicate its desired fingerprint gets mapped to the existing
== Actions ==
== Interesting links ==
https://archive.org/details/ptim2021 Pluggable Transports Implementers Meeting 2021 videos
== Reading group ==
We will discuss "Throttling Twitter: an emerging censorship technique in Russia" on 10 March
https://dl.acm.org/doi/pdf/10.1145/3487552.3487858https://censorbib.nymity.ch/#Xue2021a
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-03-03
Last week:
- updated version of snowflake in Tor Browser to include logged events
- https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/4…
- started work on conjure PT for Tor (conjure#1)
- https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conj…
- reviewed and merged some small snowflake MRs
- snowflake!79
- snowflake!80
- checked out shadow fixes for go programs
- https://github.com/shadow/shadow/issues/1549
- helped monitor snowflake broker stats
- https://lists.torproject.org/pipermail/anti-censorship-team/2022-February/0…
- commented on adding more snowflake bridges (snowflake#28651)
This week:
- continued work on conjure PT
- continue to monitor snowflake broker stats
Needs help with:
dcf: 2022-03-03
Last week:
- posted summary of snowflake bridge outage on 2022-02-18 https://lists.torproject.org/pipermail/anti-censorship-team/2022-February/0…
- tried porting extor-static-cookie to rust https://lists.torproject.org/pipermail/anti-censorship-team/2022-February/0…
- tried the bridgedb+rdsys setup https://lists.torproject.org/pipermail/anti-censorship-team/2022-February/0…
- inquired with OTF about funding for the snowflake bridge
- posted about hardware limitations at the snowflake bridge https://lists.torproject.org/pipermail/tor-project/2022-March/003301.html
- posted notes on using STATUS for PT version reporting https://gitlab.torproject.org/tpo/core/tor/-/issues/11101#note_2781418
- commented on space changes for STATUS VERSION https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/63
Next week:
Help with:
agix: 2021-02-10
Last week:
- Continued work on gettor-twitter
Next week:
- Hopefully finish the task
Help with:
-
arlolra: 2022-03-03
Last week:
-
Next week:
- Figure out where in pion/webrtc ALPN should be configured and used
- Maybe add Chacha20Poly1305 to pion/dtls
https://github.com/pion/dtls#planned-featureshttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
- Pass bridge fingerprint in SOCKS param to the broker
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-03-03
Last week:
- deploy rdsys + bridgedb in production (rdsys#12)
- update docker obfs4-bridge image with the new obfs4proxy (docker-obfs4-bridge#12)
- coordinate with TPA to clean up the old email setup in BridgeDB
- coordinate with metrics so the new assignments file
- work on an update of the pt-spec to include the version on the STATUS message
Next week:
- use rdsys bridges in circumvention settings (bridgedb#40045)
Shelikhoo: 2022-03-03
Last Week:
- [Merge Request Awaiting] Add SOCKS5 forward proxy support to snowflake (snowflake!64)
- [Merge Request Awaiting] uTLS for broker negotiation
- [Discussion] Proposal: Support for Dynamic IP obfs4 bridges with unattended proxy information update (aka "Subscription")
- [Coding & Deployment] Proposal: Centralized Probe Result Collector (anti-censorship/team#54)
Next Week:
- [Coding & Deployment] Proposal: Centralized Probe Result Collector (anti-censorship/team#54)
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
hanneloresx: 2021-3-4
Last week:
- Submitted MR for bridgestrap issue #14
Next week:
- Finish bridgestrap #14
- Find new issue to work on
Help with:
-
--
meskio | https://meskio.net/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
My contact info: https://meskio.net/crypto.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Nos vamos a Croatan.
Hi,
The venerable "procmail" package will progressively be removed from all
torproject.org servers over the next 6 hours.
Details on the why and the how are explained in this ticket:
https://gitlab.torproject.org/tpo/tpa/team/-/issues/40639
... but the short version is that procmail hasn't been maintained for
more than 20 years and has known security issues.
If you currently use any of the following commands in any script or
program, you will need to migrate to an alternative:
* procmail
* mailstats
* lockfile
* formail
For procmail and mailstats, the alternative is generally to switch to a
Sieve-compatible local delivery agent (LDA). I have deployed this on
rude (rt.torproject.org) successfully. The other host using it was
polyanthum, which has been cleaned up as well (tpo/tpa/team#40635). I am
not aware of any other deployment of procmail, and I searched far and
wide (for .procmailrc files, specifically).
As for the other alternatives, instead of lockfile(1), use
flock(1). Instead of formail(1) you can use reformail(1), from the
courier `maildrop` package.
If I missed anything, do let me know.
Apologies for the rushed deployment. Typically, we would do this sort of
change with an advanced notice and a formal proposal, but considering
the severity of the security issue, I figured it was better to act
quickly, at the cost of breaking things, rather than allow what is
essentially a backdoor into our systems.
A.
--
Antoine Beaupré
torproject.org system administration