Note: this proposal is also visible in:
https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-20-bullse…
Summary: bullseye upgrades will roll out starting the first weeks of
April and May, and should complete before the end of August 2022. Let
us know if your service requires special handling.
# Background
Debian 11 [bullseye][] was [released on August 14 2021][]). Tor
started the upgrade to bullseye shortly after and hopes to complete
the process before the [buster][] EOL, [one year after the stable
release][], so normally around August 2022.
In other words, we have until this summer to upgrade *all* of TPA's
machine to the new release.
New machines that were setup recently have already been installed in
bullseye, as the installers were changed shortly after the release. A
few machines were upgraded manually without any ill effects and we do
not consider this upgrade to be risky or dangerous, in general.
This work is part of the [%Debian 11 bullseye upgrade milestone][],
itself part of the [OKR 2022 Q1/Q2 plan][].
# Proposal
The proposal, broadly speaking, is to upgrade all servers in three
batches. The first two are somewhat equally sized and spread over
April and May, and the rest will happen at some time that will be
announced later, individually, per server.
## Affected users
All service admins are affected by this change. If you have shell
access on any TPA server, you want to read this announcement.
## Upgrade schedule
The upgrade is split in multiple batches:
* low complexity (mostly TPA): April
* moderate complexity (service admins): May
* high complexity (hard stuff): to be announced separately
* to be retired or rebuilt servers: not upgraded
* already completed upgrades
The free time between the first two will also allow us to cover for
unplanned contingencies: upgrades that could drag on and other work
that will inevitably need to be performed.
The objective is to do the batches in collective "upgrade parties"
that should be "fun" for the team (and work parties *have* generally
been generally fun in the past).
### Low complexity, batch 1: April
A first batch of servers will be upgraded in the first week of April.
Those machines are considered to be somewhat trivial to upgrade as
they are mostly managed by TPA or that we evaluate that the upgrade
will have minimal impact on the service's users.
```
archive-01
build-x86-05
build-x86-06
chi-node-12
chi-node-13
chives
ci-runner-01
ci-runner-arm64-02
dangerzone-01
hetzner-hel1-02
hetzner-hel1-03
hetzner-nbg1-01
hetzner-nbg1-02
loghost01
media-01
metrics-store-01
perdulce
static-master-fsn
submit-01
tb-build-01
tb-build-03
tb-tester-01
tbb-nightlies-master
web-chi-03
web-cymru-01
web-fsn-01
web-fsn-02
```
27 machines. At a worst case 45 minutes per machine, that is 20 hours
of work. At three people, this might be doable in a day.
Feedback and coordination of this batch happens in issue
[tpo/tpa/team#40690][].
### Moderate complexity, batch 2: May
The second batch of "moderate complexity servers" happens in the first
week of May. The main difference with the first batch is that the second
batch regroups services mostly managed by service admins, who are given
a longer heads up before the upgrades are done.
```
bacula-director-01
bungei
carinatum
check-01
crm-ext-01
crm-int-01
fallax
gettor-01
gitlab-02
henryi
majus
mandos-01
materculae
meronense
neriniflorum
nevii
onionbalance-01
onionbalance-02
onionoo-backend-01
onionoo-backend-02
onionoo-frontend-01
onionoo-frontend-02
polyanthum
rude
staticiforme
subnotabile
```
26 machines. If the worst case scenario holds, this is another day of
work, at three people.
Not mentioned here is the `gnt-fsn` Ganeti cluster upgrade, which is
covered by ticket [tpo/tpa/team#40689][]. That alone could be a few
day-person of work.
Feedback and coordination of this batch happens in issue [tpo/tpa/team#40692][]
### High complexity, individually done
Those machines are harder to upgrade, due to some major upgrades of
their core components, and will require individual attention, if not
major work to upgrade.
```
alberti
eugeni
hetzner-hel1-01
pauli
```
Each machine could take a week or two to upgrade, depending on the
situation and severity. To detail each server:
* `alberti`: `userdir-ldap` is, in general, risky and needs special
attention, but should be moderately safe to upgrade, see ticket
[tpo/tpa/team#40693][]
* `eugeni`: messy server, with lots of moving parts (e.g. Schleuder,
Mailman), Mailman 2 EOL, needs to decide whether to migrate to
Mailman 3 or replace with Discourse (and self-host), see
[tpo/tpa/team#40471][], followup in [tpo/tpa/team#40694][]
* `hetzner-hel1-01`: Nagios AKA Icinga 1 is end-of-life and needs to
be migrated to Icinga 2, which involves fixing our git hooks to
generate Icinga 2 configuration (unlikely), or rebuilding a Icinga
2 server, or replacing with Prometheus (see
[tpo/tpa/team#29864][]), followup in [tpo/tpa/team#40695][]
* `pauli`: Puppet packages are severely out of date in Debian, and
Puppet 5 is EOL (with Puppet 6 soon to be). doesn't necessarily
block the upgrade, but we should deal with this problem sooner than
later, see [tpo/tpa/team#33588][], followup in [tpo/tpa/team#40696][]
All of those require individual decision and design, and specific
announcements will be made for upgrades once a decision has been made
for each service.
### To retire
Those servers are possibly scheduled for removal and may not be
upgraded to bullseye at all. If we miss the summer deadline, they
might be upgraded as a last resort.
```
cupani
gayi
moly
peninsulare
vineale
```
Specifically:
* cupani/vineale is covered by [tpo/tpa/team#40472][]
* gayi is [TPA-RFC-11: SVN retirement][], [tpo/tpa/team#17202][]
* moly/peninsulare is [tpo/tpa/team#29974][]
### To rebuild
Those machines are planned to be rebuilt and should therefore not be
upgraded either:
```
cdn-backend-sunet-01
colchicifolium
corsicum
nutans
```
Some of those machines are hosted at a Sunet and need to be migrated
elsewhere, see [tpo/tpa/team#40684][] for details. `colchicifolium` will
is planned to be rebuilt in the `gnt-chi` cluster, no ticket created
yet.
They will be rebuilt in new bullseye machines which should allow for a
safer transition that shouldn't require specific coordination or
planning.
### Completed upgrades
Those machines have already been upgraded to (or installed as) Debian
11 bullseye:
```
btcpayserver-02
chi-node-01
chi-node-02
chi-node-03
chi-node-04
chi-node-05
chi-node-06
chi-node-07
chi-node-08
chi-node-09
chi-node-10
chi-node-11
chi-node-14
ci-runner-x86-05
palmeri
relay-01
static-gitlab-shim
tb-pkgstage-01
```
### Other related work
There is other work related to the bullseye upgrade that is mentioned
in the [%Debian 11 bullseye upgrade milestone][].
# Alternatives considered
We have not set aside time to automate the upgrade procedure any
further at this stage, as this is considered to be a too risky
development project, and the current procedure is fast enough for
now.
We could also move to the cloud, Kubernetes, serverless, and Ethereum
and pretend none of those things exist, but so far we stay in the real
world of operating systems.
Also note that this doesn't cover Docker container images
upgrades. Each team is responsible for upgrading their image tags in
GitLab CI appropriately and is *strongly* encouraged to keep a close
eye on those in general. We may eventually consider enforcing stricter
control over container images if this proves to be too chaotic to
self-manage.
# Costs
It is estimates this will take one or two person-month to complete, full
time.
# Approvals required
This proposal needs approval from TPA team members, but service admins
can request additional delay if they are worried about their service
being affected by the upgrade.
Comments or feedback can be provided in issues linked above.
# Deadline
Upgrades will start in the first week of April 2022 (2022-04-04)
unless an objection is raised.
This proposal will be considered adopted by then unless an objection
is raised within TPA.
# Status
This proposal is currently in the `proposed` state.
# References
* [TPA bullseye upgrade procedure][]
* [%Debian 11 bullseye upgrade milestone][]
[TPA bullseye upgrade procedure]: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/upgrades/bullseye/
[%Debian 11 bullseye upgrade milestone]: https://gitlab.torproject.org/groups/tpo/tpa/-/milestones/5
[bullseye]: https://wiki.debian.org/DebianBullseye
[released on August 14 2021]: https://www.debian.org/News/2021/20210814
[buster]: howto/upgrades/buster
[one year after the stable release]: https://www.debian.org/security/faq#lifespan
[OKR 2022 Q1/Q2 plan]: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/roadmap/2022
[tpo/tpa/team#40690]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40690
[tpo/tpa/team#40692]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40692
[tpo/tpa/team#40693]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40693
[tpo/tpa/team#40471]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40471
[tpo/tpa/team#29864]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/29864
[tpo/tpa/team#33588]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/33588
[tpo/tpa/team#40684]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40684
[tpo/tpa/team#40694]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40694
[tpo/tpa/team#40695]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40695
[tpo/tpa/team#40696]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40696
[tpo/tpa/team#40472]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40472
[tpo/tpa/team#17202]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/17202
[TPA-RFC-11: SVN retirement]: policy/tpa-rfc-11-svn-retirement
[tpo/tpa/team#29974]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/29974
[tpo/tpa/team#40689]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40689
--
Antoine Beaupré
torproject.org system administration
Hey everyone!
Here are our meeting logs:
http://meetbot.debian.net/tor-meeting/2022/tor-meeting.2022-04-28-15.58.html
And our meeting pad:
Anti-censorship work meeting pad
--------------------------------
Next meeting: Thursday May 5th 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 ==
* polyanthum & gettor-01 will be upgraded next week, the servers
where bridgedb,rdsys,gettor and other anti-censorship infra is hosted
== Discussion ==
* Distributed Snowflake Server Support
* Any feedbacks?
*
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
* No blocker issue discovered.
* will first deploy the new broker, and give time for proxies
to update
* removed smallerRichard builtin server
*
https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/44
* RKS hackathon
* (Discussion Skipped)
== Actions ==
*
== Interesting links ==
*
https://www.codastory.com/authoritarian-tech/kazakhstan-shut-down-its-inter…
* https://eprint.iacr.org/2020/114
== Reading group ==
* We will discuss "Blocking of HTTP/3 (QUIC) in Russia" on
Apr/28th/2022
* https://dl.acm.org/doi/abs/10.1145/3487552.3487836
* https://github.com/net4people/bbs/issues/108
* 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-04-14
Last week:
- moved tor-specific snowflake code out of client library
(snowflake#40124)
- merge request: snowflake!85
- bump version of webrtc dependency (snowflake#40127)
- merge request: snowflake!86
- commented on snowflake web workflow (snowflake#40125)
- opened issue to bump version of snowflake and webrtc in tor
browser (tor-browser-build#40474)
- work on conjure test environment setup
This week:
- continue work on conjure PT
- continue snowflake maintenance tasks
Needs help with:
dcf: 2022-04-28
Last week:
- made graphs of the snowflake bridge since the server move 2
weeks ago
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
Next week:
- look at STATUS VERSION proposal
https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/63
- set up access control on the snowflake-02 bridge
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
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-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-04-28
Last week:
- use bridgestrap results to select what bridges to
distribute (rdsys#96)
- give rdsys a free software license (rdsys#107)
- removed smallerRichard builtin bridge (team#44)
- brainstorm on dnstt (trac#40001)
Next week:
- deploy telegram in rdsys (rdsys#101)
- advance on the onionsproutsbot deployment
Shelikhoo: 2022-04-28
Last Week:
- [Merge Request Awaiting] Add SOCKS5 forward proxy support to
snowflake (snowflake!64)
- [Coding & Deployment] Proposal: Centralized Probe Result
Collector (anti-censorship/team#54)
- [Discussion] Centralized Probe Log Collection Ascension Request
- [Discussion] Hosting Centralized Probe Log Collection
Server on TPA managed VPS
- [Discussion] Proposal: Support for Dynamic IP obfs4 bridges
with unattended proxy information update(aka "Subscription")
- [Coding] Distributed Snowflake Bridges - Broker
- [Coding] Distributed Snowflake Bridges Testing Environment
- Dockerlized
- [Deployment] Distributed Snowflake Bridges Testing Broker
Next Week:
- [Coding] Distributed Snowflake Bridges (continue)
- [Research] Implement metrics to measure snowflake
churn(https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transport…
- [Research] Blocking of Snowflake in Turkmenistan, 2021-10-24
Itchy Onion: 2022-04-28
Last week:
- debugged a RACE 2.1.0 issue
- had a meeting with Georgetown folks (a recurring meeting to
go over each other's channel code)
This week:
- go over snowflake code (in preparation for the next
Georgetown meeting and also help with rebase snowflake rebasing)
- go over RACECAR docs
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
Hi!
For visibility in the broader community, I'm sending the priorities we
have for 2022 and specific projects and tasks we are working on for this
quarter. There are links where you can read more about the work that
different teams at Tor are doing.
If you want to read about long term strategic goals for the Tor project
organization, you can go to this wiki page:
https://gitlab.torproject.org/tpo/team#organization
# The Tor Project Priorities 2022
The Tor network
Make the Tor network faster for users
Get Arti to production level
Improve bad relay tooling
Support researchers for network experiments
Improve monitoring and alerting for metrics services.
Maintain a healthy relay operators community
Increase adoption of onion services
Trainings and User Research in the global south
Connect with censored users to improve censorship circumvention
Research on Tor Browser new features and VPN concept
Collaborate with other organizations in the Tor ecosystem
New Tor's "VPN" client
Design safety criteria
Define MVP for client
Build the network engine for VPN solution
Evaluate orbot and leap components and architecture
Start working on UI
Tor Browser
Implement feedback from users
Improve automatic censorship detection during bootstrap
Enable HTTPS-only mode
Browser is under control (releases on schedule, automated tests
pass)
Censorship Circumvention
Implement new pluggable transport: Conjure & HTTPT
Scale Snowflake
Deploy improved bridge distribution system
Monitor bridge health
Censorship analysis and response to it
Infrastructure
User support tools gets improved
User support
Documentation keep up to date
Improve mail services
Rebuild donate page
Make it easier for translators to contribute
# Tor's TEAMS PRIORITIES FOR Q2
----------------------------------
## Applications
(Led by Richard. Board
https://gitlab.torproject.org/groups/tpo/applications/-/boards?label_name[]…)
Implement Tor Browser UX changes that UX team is prioritizing from
user research and feedback.
Improve automatic censorship detection during bootstrapping in Tor
Browser (desktop and Android).
Evaluate orbot and leap for components and architecture.
Design VPN safety criteria.
HTTPS everywhere replacement.
Go/Rust/Java dependency resolution: how to resolve dependencies
ahead of time.
Browser: Browser is under control
Android Tor Browser releases are on schedule
Android/Linux Tor Browser Automated tests are passing
Survey the Browser ecosystem
Integration: Begin understanding application integration/embedding
Begin helping Network Team create easy-to-use Arti API
Document required components for Android app integration
## Community
(Led by Gus. Board
https://gitlab.torproject.org/groups/tpo/community/-/boards?label_name[]=Q2
and
https://gitlab.torproject.org/groups/tpo/onion-services/-/boards?label_name…)
- assist network health team to maintain a healthy relay operators community
- assist anti-censorship team on connecting with censored users to
improve censorship circumvention
- improve user support tools and documentation
- lead trainings with communities in latinoamerica and east africa
- look for spikes in tor usage and document process and resources
available for it.
## Network Health
(Led by Geko. Board
https://gitlab.torproject.org/groups/tpo/network-health/-/boards?label_name…)
- s61 O2.1: Reduce the number of slow and extremely slow sessions for
our users by developing and deploying load balancing improvements.
- s61 O4.2: Find and fix performance-impacting issues and bugs
discovered from monitoring and scanning.
- Run bad-relay detection scripts
- Bad-relay tooling improvements .
- Fix any sbws critical issues that may come up
- Support for researchers for network experiments
- Consider tickets from other teams
- Support OTF fellow on Relay Operators Community Health Research
- Relay operator meetups.
- Keep moderating and answering the tor-relays mailing list
- Handle EOL relays
- Support mentee from GSoC
- Improve monitoring and alerting for metrics services.
- Deploy a data store for metrics servicesn plan
- Refactor sbws2
- Surprise 'anomaly analysis' on the network as needed
- Think about metrics for the VPN client and their possible privacy
issues/risks
- Network anomaly detection: use current monitoring infrastructure to
get some of the anomalies we can catch with it.
# Network
(Led by Alex. Board
https://gitlab.torproject.org/groups/tpo/core/-/boards?label_name[]=Q2)
- S30 2.3.3 - Improve ability for bridgedb/authority to test bridges
that only expose a pluggable transport.
- S30 2.4.5 - Increase stability and resilience of bridge authority and
bridgeDB by exploring and implementing decentralization of those services.
- S61 O1.1: Optimize user-facing performance by tuning parameters of
previously deployed Tor network improvements.
- S61 O2: sbws with congestion control (Tor support to pin exits/Sos
Rends, or just wait).
- S61 O3.2: Implement promising performance improvements from evaluation
in O3.1.
- S61 O4.1: Improve and implement network health monitoring and scanning.
- S96 O3.5: Integrate Tor+Snowflake/obfs4 capabilities into mobile
applications.
- S96 O3.5.1 OnionShare, iOS.
- S96 O3.5.2: OnionShare, Android.
- S96 O3.5.3: Save (Share-Archive-Verify-Encrypt) by OpenArchive .
- S101 O3.2: Enhance Tor to act as a VPN service, rather than an opt-in
proxy as it does today.
- S119 Arti 1.0.0 - Try to reach "production quality".
# Anti-censorship
(Lead by Meskio. Board
https://gitlab.torproject.org/groups/tpo/anti-censorship/-/boards?label_nam…)
- S30 O2.3.1 - Develop new and/or improve existing bridge selection and
distribution strategies based on data collected about successful,
effective methods per evaluation during O1.1. Conjure/Tapdance
implementation
- S96 O1.1.1 Prepare the Snowflake system for a surge in operators and
users.
- S96 O1.2: Increase the number of Snowflake bridges.
- S96 O1.3: Implement bridges with pluggable transport HTTPT support.
- S96 O1.4: Increase the number of active obfs4 and HTTPT bridges.
- S96 O2.2: Deploy improved bridge distribution systems.
- S96 Start Salmon based design
- S96 O2.3: React and steer our response to censorship.
- S96 O4.3: Modify GetTor so that it can distribute Tor Browser via
messaging apps
- S28 RACE project
- S2125 Automatize bridge rotation for telegram. Continue translations
of anti-censorship material into russian.
# UX
(Led by Duncan. Board
https://gitlab.torproject.org/groups/tpo/-/boards?label_name[]=UX%20Team)
Roadmap in
https://www.figma.com/file/n4ETd0cUkcfj3KyclJQnt3/UX-Team-Planning?node-id=…
# TPA
(Led by Anarcat. Board
https://gitlab.torproject.org/groups/tpo/tpa/-/boards )
Roadmap in https://gitlab.torproject.org/tpo/tpa/team/-/wikis/roadmap/2022
# WEB
It is a collaboration between TPA and Community teams. Board
https://gitlab.torproject.org/groups/tpo/web/-/boards
cheers,
gaba (Tor's project manager)
Greetings,
Network team will be releasing on Wednesday (April 27th, 2022) the first
stable release of the 0.4.7.x series.
Very little has changed from the previous release candidate so this should be
a smooth transition into the stable. We'll of course keep a close eye on it
due to its drastic new feature: congestion control
Upcoming versions:
- 0.4.7.7
@network-team: It is _now_ a good time to start reviewing changes/ files:
https://gitlab.torproject.org/tpo/core/tor/-/tree/main/changes
Last, we've asked the dirauth to recommend this version few minutes ago. Keep
an eye out for the release announcement and a blog post about this new stable
version.
Cheers!
David
--
g0mNrchagnDtRyN1ttVfag8Txoz/EKIKjotiMPGc7ug=
Hey everyone!
Here are our meeting logs:
http://meetbot.debian.net/tor-meeting/2022/tor-meeting.2022-04-21-15.59.html
And our meeting pad:
Anti-censorship work meeting pad
--------------------------------
Next meeting: Thursday April 21th 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 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 ==
* Do we have graphs about telegram bridge usage
* irl has some script to generate them
* current telegram bridges are not pressent in metrics.tpo as 'distributor telegram', as they are manually feeded. This will change when we start using rdsys for it.
* Is the reading group reading supposed to be "Web censorship measurements of HTTP/3 over QUIC" https://dl.acm.org/doi/abs/10.1145/3487552.3487836 ?
* or the threads https://github.com/net4people/bbs/issues/108https://ntc.party/t/http-3-quic/1823 ?
* one of the authors of the paper, Kathrin Elmenhorst, has posted some more recent measurements of HTTP/3 blocking in Russia specifically https://github.com/kelmenhorst/quic-censorship/issues/4
* we'll read the paper, the threads are for more context
* Snowflake Multi-Server Broker Testing (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…)
* (this is where the client tells the broker&proxy what bridge it wants to use, by putting fingerprint=1234ABCD... on its Bridge line)
* testing is wellcome...
* there are instructions for testing it in the issue
* Report of CDN Block in Turkmenistan(https://gitlab.torproject.org/tpo/anti-censorship/censorship-a…
* cloudflare is being blocked in Turkmenistan
* in Russia they are blocking 2 IPs of cloudflare too, but might be an error of overblocking targeting a single site https://ntc.party/t/cloudflare-cdn/2245/24
* shell will talk with fastly and cloudflare to see what they know, and we'll look into setting up a vantage point in TM
* meskio, if you could give rdsys a free software license, i will breathe easier at night: https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/107
* meskio will add 3-BSD in the comming days
* dnstt, next steps
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac…
* the major blocker now is to have support for PT commands over the SOCKS connection
* will require forking the code into tpo
== Actions ==
*
== Interesting links ==
* https://pluggabletransports.info/blog/pt-meetup-apr2022/
== Reading group ==
* We will discuss "Blocking of HTTP/3 (QUIC) in Russia" on Apr/28th/2022
* https://dl.acm.org/doi/abs/10.1145/3487552.3487836
* https://github.com/net4people/bbs/issues/108
* 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-04-14
Last week:
- moved tor-specific snowflake code out of client library (snowflake#40124)
- merge request: snowflake!85
- bump version of webrtc dependency (snowflake#40127)
- merge request: snowflake!86
- commented on snowflake web workflow (snowflake#40125)
- opened issue to bump version of snowflake and webrtc in tor browser (tor-browser-build#40474)
- work on conjure test environment setup
This week:
- continued work on conjure PT
- continue snowflake maintenance tasks
Needs help with:
dcf: 2022-04-21
Last week:
- investigated how Tor Metrics estimates the number of users and asked questions about it https://lists.torproject.org/pipermail/tor-dev/2022-April/014724.htmlhttps://gitlab.torproject.org/tpo/network-health/metrics/website/-/issues/4…
- made a graph of Tor users in Russia across all transports https://gitlab.torproject.org/tpo/community/support/-/issues/40050#note_279…
- wrote feedback on the Def Con submission draft
- installed a second snowflake bridge https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
Next week:
- look at STATUS VERSION proposal https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/63
Help with:
agix: 2021-02-10
Last week:
- Continued work on gettor-twitter
Next week:
- Hopefully finish the task
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-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-04-21
Last week:
- deploy rdsys 0.2 with many fixes
- update monit configuration to the new snowflake bridge (monit-configuration!2)
- merge moat documentation into rdsys (rdsys!34)
- catch up after a week off
Next week:
- use bridgestrap results to select what bridges to distribute (rdsys#96)
- give rdsys a free software license (rdsys#107)
Shelikhoo: 2022-04-21
Last Week:
- [Merge Request Awaiting] Add SOCKS5 forward proxy support to snowflake (snowflake!64)
- [Coding & Deployment] Proposal: Centralized Probe Result Collector (anti-censorship/team#54)
- [Discussion] Centralized Probe Log Collection Ascension Request
- [Discussion] Hosting Centralized Probe Log Collection Server on TPA managed VPS
- [Discussion] Proposal: Support for Dynamic IP obfs4 bridges with unattended proxy information update(aka "Subscription")
- [Discussion+Coding] Support Automatic Bridge Info update(shelikhoo/LogCollectorAncillary#1)
- [Discussion+Coding] Remove Inactive Bridge from Test Result(shelikhoo/LogCollectorAncillary#2)
- [Coding] Distributed Snowflake Bridges - Broker
- [Coding] Distributed Snowflake Bridges Testing Environment - Dockerlized
- [Deployment] Distributed Snowflake Bridges Testing Broker
Next Week:
- [Coding] Distributed Snowflake Bridges (continue)
- [Research] Blocking of Snowflake in Turkmenistan, 2021-10-24
Itchy Onion: 2022-04-14
Last week:
- worked on rebasing RACECAR snowflake but didn't finish (3 day week)
- read RACECAR doc
This week:
- debugged a RACE 2.1.0 issue
- read snowflake code -- there is going to be a recurring 1:1 meeting between me and Eliana from Georgetown to go over each other's channel code
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.