tor-project

tor-project@lists.torproject.org

16 participants
2324 discussions

cohosh's monthly status report, September 2023
by Cecylia Bocovich 06 Oct '23

06 Oct '23

Hi! This is my status report for contract work done in September 2023. # Reputation-based bridge distribution - Worked on deploying the lox distributor for testing purposes - https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/167 - Discussed rdsys resource API - https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/merge_requests/15… - Dependency updates # Conjure - Wrote some next steps for Conjure work - https://gitlab.torproject.org/tpo/operations/proposals/-/issues/51 # Snowflake - Helped recover from problem with cdn.sstatic.net front domain - Investigated alternative domain fronts - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - Looked into OONI and Orbot handling of bridge linse - https://github.com/guardianproject/orbot/issues/983 - https://github.com/ooni/probe-cli/pull/1337 - Implemented a feature in snowflake to randomly select from a pool of front domains - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - Discussed a weird increase in snowflake client polls - https://lists.torproject.org/pipermail/anti-censorship-team/2023-September/… - Due to bridge outage: https://lists.torproject.org/pipermail/anti-censorship-team/2023-September/… - Followed up on reports of snowflake fingerprinting in Russia - Due to out-of-date OONI probe clients - https://github.com/ooni/probe/issues/2533 - Dependency updates

1 0

Nina’s Monthly Status Report: September 2023
by Nina 05 Oct '23

05 Oct '23

Hi! Below is my Setember’23 report! In September, I resolved 615 tickets: On Telegram (@TorProjectSupportBot) - 367 On RT (frontdesk@tpo) - 236 On WhatsApp (+447421000612) - 9 and on Signal (+17787431312) - 3. During that month I - 1. Helped Russian-speaking users to bypass censorship: shared bridges and assisted with using them and troubleshooting; 2. Collected user feedback; 3. Helped to solve Tor Browser issues like: - antivirussoftware blocking Tor Browser[1] - bug"Pluggable Transport process terminated with status code 0"[2], which is fixed in 0.4.8.x, but Tor Browser stable still use 0.4.7.x Tor version. The new attempts of the Russian government to block popular VPN protocols resulted in many users trying to use little-t-tor to proxytheir connection and circumvent censorship, so I helped themtoconfigure it. In September we also answeredmany tickets related to the domain frontingissue [3]. I also helped the Tor Localization team reviewing some Russian terms andtranslations for the Tor Browser and the Tor Project website. [1] https://forum.torproject.org/t/torbrowser-12-5-6-no-longer-flagged-by-windo… [2] https://gitlab.torproject.org/tpo/core/tor/-/issues/33669 [3] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42120

1 0

Rhatto's Monthly Status Report, September 2023
by rhatto 02 Oct '23

02 Oct '23

Hi all :) This is my monthly status report for September 2023 with the main relevant activities I have done during the period. ## 0. Research ### Certificates The work for bringing TLS certificates for Onion Services was focused in the ACME for Onions proposal (https://acmeforonions.org). There were a series of relevant updates both on IETF ACME and on the CA/B Forum's Validation working groups: * https://lists.cabforum.org/pipermail/validation/2023-September/001927.html * https://magicalcodewit.ch/cabf-2023-09-07-slides/ * https://mailarchive.ietf.org/arch/msg/acme/LMYC_Ou41E_9RuaVSYPr7SIhCCc/ * https://github.com/AS207960/acme-onion/issues/2 I focused in: * Helping to figure ways that CAA and .onion descriptors could be handled by ACME client and servers. I'm still compiling the list of options for an ACME server to parse and validate an Onion Service descriptor. * Doing a documentation update about CAA checking: https://tpo.pages.torproject.net/onion-services/onionplan/appendixes/acme/#… https://gitlab.torproject.org/tpo/onion-services/onionplan/-/commit/0234173… ## Tor Browser Quality Assurance for Onion Services (TBB .onion QA) I have completed the first three quarters of Tor Browser QA testing (since 2023.Q1). ### Testbed * Since this QA process started, it's methodology and tooling was bootstrapped and improved. * Some basic tests were defined to happen at every Tor Browser release (when applicable). * Additional, specific tests were also defined to check for specific and potential issues. * The "Faulty Onions" project was prototyped, and is intended to provide test Onion Services with different errors to check how Tor Browser and other applications handles them. More details to be expected soon. * A few alternatives for test automation were researched, to consider whether some of the regular tests can be automated. * Public documentation remains yet to be done. ### Versions tested Eleven Tor Browsers versions were formally tested: * 12.5.1 * 12.5.2 * 12.5.3 * 12.5.4 * 12.5.5 * 12.5.6 * 13.0a1 * 13.0a2 * 13.0a3 * 13.0a4 * 13.0a5 ## 1. Development ### Onionprobe * Onionprobe 1.1.2 was released: https://gitlab.torproject.org/tpo/onion-services/onionprobe/-/blob/main/Cha… ## 2. Support ### Documentation Hackweek As a preparation for the upcoming [Hackweek][], I have submitted four project proposals: * Onion MkDocs tryout: https://gitlab.torproject.org/tpo/community/hackweek/-/issues/13 * Onion TeX Slim enhancements: https://gitlab.torproject.org/tpo/community/hackweek/-/issues/14 * Onion Reveal coding and documenting: https://gitlab.torproject.org/tpo/community/hackweek/-/issues/15 * Etherpad management: https://gitlab.torproject.org/tpo/community/hackweek/-/issues/16 I'm planning to work in just one of these projects, depending in which one is more popular or gets more attention. I'm also looking for people that wants to form a team, or even adopt one of these proposals. Please leave a comment, subscribe yourself or add your user name into the ticket description if you're interested :) [Hackeek][]: https://lists.torproject.org/pipermail/tor-project/2023-August/003675.html ### Maintenance * I also did the ongoing sponsored work with deployment, maintenance and monitoring of Onion Services. ## 3. Organization Time spent (from the total available for Tor-related work): | Category | Percentage |---------------|------------ | Research | 57 | Development | 1 | Support | 9 | Organization | 33 |---------------|------------ | Total | 100 -- Silvio Rhatto pronouns he/him

1 0

minutes from the sysadmin meeting
by Antoine Beaupré 02 Oct '23

02 Oct '23

Ahoy! Well it's just been way too long since we've done this, but we've done it! Here's our short sysadmin minutes from today's meeting. # Roll call: who's there and emergencies onionoo-backend running out of disk space ([tpo/tpa/team#41343][]) [tpo/tpa/team#41343]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41343 # Dashboard cleanup 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&… 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 Nextcloud roadmap / spreadsheet. Overall, it seems we are as you would expect when returning from a rather chaotic vacation. Backlog is large, but things seem to be under control. We added SVN back on the roadmap after one too many tickets asking for setup. # Metrics of the month * hosts in Puppet: 89, LDAP: 89, Prometheus exporters: 166 * number of Apache servers monitored: 37, hits per second: 626 * number of self-hosted nameservers: 6, mail servers: 10 * pending upgrades: 1, reboots: 0 * average load: 0.69, memory available: 3.58 TiB/4.98 TiB, running processes: 424 * disk free/total: 53.19 TiB/126.72 TiB * bytes sent: 403.47 MB/s, received: 269.04 MB/s * planned bullseye upgrades completion date: 2024-08-02 * [GitLab tickets][]: 196 tickets including... * open: 0 * icebox: 163 * needs information: 5 * backlog: 13 * next: 9 * doing: 4 * needs review: 2 * (closed: 3301) [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/bookworm/ Now also available as the main Grafana dashboard. Head to <https://grafana.torproject.org/>, change the time period to 30 days, and wait a while for results to render. # Number of the month: 42 34 machines were upgraded from bullseye to bookworm in the two first days of last week! We calculated this was an average of 20 minutes per host to upgrade. The trick, of course, is that things often break *after* the upgrade, and that "fixing" time is not counted here. That said, last estimate for this was one hour per machine, and we're doing a whole fleet upgrade every 2-3 years, which means about ten hours of work saved per year. But the number of the month is, of course, 42, as we now have an equal number of bookworm and bullseye machine, after the upgrade. And that number is, naturally, [42][]. See also https://xkcd.com/1205/ which, interestingly, we fall out of scope of. [42]: https://en.wikipedia.org/wiki/42 -- Antoine Beaupré torproject.org system administration

1 0

PieroV's Monthly Status Report, September 2023
by Pier Angelo Vendrame 02 Oct '23

02 Oct '23

Hi everyone! Here is my status report for September 2023. This month, I continued working on the refactoring of the Tor integration in Tor Browser and finally merged the merge requested with the biggest changes [0]. During the month, I also fixed some bugs it caused and improved the compatibility with the external Tor daemons. Then, I worked on some audits for the 102 to 115 transition. In particular, I reviewed our profiles [1]. Some other tasks included swapping a few branding assets, such as the About dialog wordmark and the Windows installer icons. I also fixed the reproducibility bug with generated headers on Windows [2] and upstreamed the patch to Firefox. During September, we had two emergency releases. I helped with the stable channel: I prepared and built both 12.5.4 and 12.5.6. For 13.0a4, I only rebased it on top of Firefox 115.2.1. Finally, I worked on enabling system-wide installs for Mullvad Browser. However, it's a work in progress as it requires some non-trivial changes to the updater. Best, Pier [0] https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests… [1] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41496 [2] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41995

1 0

shadow update 2023-09-27
by Jim Newsome 29 Sep '23

29 Sep '23

Mirrored from <https://github.com/shadow/shadow/discussions/3187>: This is part of a series of periodic updates of development in Shadow. This work is sponsored by the [NSF](https://shadow.github.io/docs/guide/nsf_sponsorship.html). Previous update: [2023-06](https://github.com/shadow/shadow/discussions/3061). We've merged [74 non-dependabot pull requests](https://github.com/shadow/shadow/pulls?q=is%3Apr+merged%3A2023-06… and closed [8 issues](https://github.com/shadow/shadow/issues?q=closed%3A2023-06-30..2023… since our previous update. # Latest improvements ## Spawning processes Shadow now supports running programs that spawn additional processes. Technically, this means it now supports `fork`, `vfork`, `execve`, and other related syscalls. Some uses for this: * The primary way for `tor` to work with [pluggable transports](https://blog.torproject.org/tor-heart-bridges-and-pluggable-tra… is for the `tor` process to dynamically spawn the pluggable transport process. This is currently the *only* way that pluggable transports are supported in `arti`. This now works in `shadow`. * Orchestration of multiple processes on a single host in `shadow` can now be done using e.g. `sh` or `python` scripts, instead of having to specify every process directly in `shadow`'s configuration file. * `shadow` can now run other software that spawns worker or helper processes. Another exciting application for this in `shadow` *development* is that we can now more easily run third party test suites, which typically spawn multiple test processes. For example, running `tor`'s own self-tests helps validate that `shadow` is correctly emulating the platform functionality that `tor` uses; currently [more than 99% of the tests pass](https://github.com/shadow/shadow/issues/3168)! ## New TCP stack Shadow's experimental new TCP stack is merged, and can be enabled with the experimental command-line flag `--use-new-tcp`. This new implementation is in Rust instead of C, and is developed to be very testable (e.g. in its own crate decoupled from the rest of Shadow, and with pluggable system dependencies). While some functionality is still being finished, we expect it will be much easier to maintain and to validate its correctness than the previous C implementation. Improved support for pcap file output also makes it easier to review Shadow's simulated network traffic. ## Shim stability We've occasionally run into problems due to `shadow`'s preloaded shim calling into `libc`. This is unsafe because some initialization can run before `libc` itself is fully initialized, and much of the code runs in a seccomp signal handler, running afoul of [async-signal-safety](https://man7.org/linux/man-pages/man7/signal-safety.7.…. Luckily, Rust has a rich ecosystem of code that doesn't depend on libc (`no_std` code). We've made substantial progress in migrating the shim's C code to `no_std` Rust code. ## Socket API improvements Our UDP socket implementation has been migrated from C to Rust, and along the way we've made many improvements to the socket API for UDP, TCP, and Unix sockets. We've added support for the following: * `sendmsg`, `recvmsg`, and `shutdown` syscall support for UDP sockets * `MSG_TRUNC` support for UDP and Unix sockets * `MSG_PEEK` support for UDP sockets * `SO_DOMAIN`, `SO_PROTOCOL`, and `SO_ACCEPTCONN` socket options for TCP and UDP sockets * `SIOCGSTAMP` ioctl support for TCP and UDP sockets We've also made various fixes and improvements to existing socket functionality so that Shadow more accurately follows the behaviour of Linux. ## C to Rust migration We continue to progress our migration from C to Rust. In addition to Rust progress in the shim and in the new TCP stack, other notable migrations since the last update include the shared memory allocator, epoll and timerfd descriptors and syscalls, UDP sockets, and several time-related syscalls. Our current status is 74% Rust code and 21.4% C code (much of this being C tests) according to Github statistics. # Release status We expect to release Shadow 3.1.0 some time in the next few weeks. # Project status - NSF grant is wrapping up The last three years of development on Shadow have been sponsored by an [NSF](https://shadow.github.io/docs/guide/nsf_sponsorship.html) grant. That grant ends at the end of this month (September 2023). This isn't the end of development on Shadow — Rob Jansen (@robgjansen) at the U.S. Naval Research Laboratory continues to head the project. Over the course of this project, The Tor Project has incorporated Shadow into its own research and testing workflows, and is likely to continue contributing as well. We look forward to continue improving and maintaining Shadow, but at a slower pace of development since we no longer expect contributions from programmers singularly dedicated to Shadow development. Jim Newsome (@sporksmith) is continuing to be a Tor Project employee but shifting focus to other Tor projects; Steven Engler (@stevenengler) is open to opportunities. Happy simulating! The Shadow team

1 0

Anti-censorship team meeting notes, 2023-09-28
by onyinyang 28 Sep '23

28 Sep '23

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2023/tor-meeting.2023-09-28-15.57.html And our meeting pad: Anti-censorship work meeting pad -------------------------------- ------------------------------------------------------------------------------------ THIS IS A PUBLIC PAD ------------------------------------------------------------------------------------ Anti-censorship -------------------------------- Next meeting: Thursday, Oct 05 16:00 UTC Facilitator: meskio Weekly meetings, every Thursday at 16:00 UTC, in #tor-meeting at OFTC (channel is logged while meetings are in progress) This week's Facilitator: onyinyang == 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 the Tor Project and Tor community. == 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 96 <-- meskio, shell, onyinyang, cohosh * https://gitlab.torproject.org/groups/tpo/-/milestones/24 * Sponsor 150 <-- meskio working on it * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues/?label_na… == Announcements == == Discussion == - Update on snowflake domain fronting issues: - problem with cdn.sstatic.net affected more than just snowflake, also moat, conjure (no deployment change required) - fixed in new tor browser update but some users relying on snowflake/moat bridges will be unable to update - relying on a the same new front may be detrimental to improve connection issues for some users, perhaps a pool of randomly selected domains would improve the situation: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… == Actions == == Interesting links == == Reading group == * We will discuss "" on * * Questions to ask and goals to have: * What aspects of the paper are questionable? * Are there immediate actions we can take based on this work? * Are there long-term actions we can take based on this work? * Is there future work that we want to call out in hopes that others will pick it up? == Updates == Name: This week: - What you worked on this week. Next week: - What you are planning to work on next week. Help with: - Something you need help with. cecylia (cohosh): 2023-09-28 Last week: - rdsys merge request !157 - wrote a feature for snowflake that allows multiple domain fronts - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - wrote a forum post for the domain fronting issue with moat - https://forum.torproject.org/t/temporary-fix-for-moat-and-connection-assist… - looked into orbot use of circumvention settings api - https://github.com/guardianproject/orbot/issues/983 This week: - finish deploying lox distributor - follow up on conjure reliability issues - visualize and write up some snowflake shadow simulation results Needs help with: dcf: 2023-09-21 Last week: - snowflake CDN bookkeeping https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-co… - noticed a problem with the fastly domain front and coordinated with cohosh to analyze it https://lists.torproject.org/pipermail/anti-censorship-team/2023-September/… Next week: - revise encapsulation.ReadData redesign to return an error in the case of a short buffer https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - open issue to have snowflake-client log whenever KCPInErrors is nonzero https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - parent: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - open issue to disable /debug endpoint on snowflake broker Before EOY 2023: - move snowflake-02 to new VM Help with: meskio: 2023-09-21 Last week: - make fake descriptors for rdsys (rdsys#171) - document rdsys development process (rdsys#131) - use the right content-type in moat (rdsys#175) - add token authentication to onbasca requests (rdsys#174) Next week: - add a DB for bridges to rdsys (rdsys#56) Shelikhoo: 2023-09-28 Last Week: - [Merge Request Awaiting] Add SOCKS5 forward proxy support to snowflake (snowflake!64) (stalled) - Write Tor Spec for Armored URL - Remove Go 1.20 CI for Snowflake: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - Consolidated Snowflake Update dependencies:https://gitlab.torproject.org/tpo/anti-censorship/pluggable-tr… - Merge request reviews Next Week/TODO: - Write Tor Spec for Armored URL(continue) - Merge request reviews onyinyang: 2023-09-28 Last week(s): - Still need to merge the updated dependencies and make MR to upstream ZK lib: - found bug in the zkp crate and will push a change to this to the upstream branch - reach out to dalek-cryptography maintainers to give them a heads up and get a sense of the plan for zkp lib - we may end up maintaining the zkp lib - Finished changes to rdsys API at the /resources endpoint to meet the needs of Lox - Working on required changes to lox-distributor This week: - Hopefully,finish up with the dependencies issue - Finish up changes to Lox distributor - continue with metrics (long term things were discussed at the meeting!): https://pad.riseup.net/p/tor-ac-community-azaleas-room-keep - brainstorming grouping strategies for Lox buckets (of bridges) and gathering context on how types of bridges are distributed/use in practice 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? 1. Are there some obvious grouping strategies that we can already consider? 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?) 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? -- --- onyinyang GPG Fingerprint 3CC3 F8CC E9D0 A92F A108 38EF 156A 6435 430C 2036

1 0

Anti-censorship team meeting notes, 2023-09-21
by Shelikhoo 21 Sep '23

21 Sep '23

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2023/tor-meeting.2023-09-21-15.57.html And our meeting pad: Anti-censorship work meeting pad -------------------------------- ------------------------------------------------------------------------------------ THIS IS A PUBLIC PAD ------------------------------------------------------------------------------------ Anti-censorship -------------------------------- Next meeting: Thursday, Sep 28 16:00 UTC Facilitator: onyinyang Weekly meetings, every Thursday at 16:00 UTC, in #tor-meeting at OFTC (channel is logged while meetings are in progress) This week's Facilitator: Shelikhoo == 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 the Tor Project and Tor community. == 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 96 <-- meskio, shell, onyinyang, cohosh * https://gitlab.torproject.org/groups/tpo/-/milestones/24 * Sponsor 150 <-- meskio working on it * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues/?label_na… == Announcements == == Discussion == * deprecation of CAPTCHA moat * https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/173 * captchas seem to be easy for censors to solve, and hard for some users to solve * prefer the circumvention settings API instead, it's not great but it seems to work better (distributes different subsets of bridges each day, you cannot enumerate them all in one day) * meskio has been ontifying downstream users about the planned deprecation * ggus: since we are planning to turn this off, before we do, could we experiment with different/harder captchas and see if bridges continue being blocked. (The hypothesis being that the captcha API is the primary way that they discover bridges.) * A proposal to phase out captchas in bridgedb from 2021: https://lists.torproject.org/pipermail/tor-dev/2021-July/014602.html * Replies suggested doing an experiment with captcha removal for 50% of bridges, that way they don't all get burned if it doesn't work * https://lists.torproject.org/pipermail/tor-dev/2021-July/014603.html * https://lists.torproject.org/pipermail/tor-dev/2021-July/014604.html * agreement on removing the in-house captcha * meskio will create an issue to explore captcha experiments * https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/176 * snowflake domain front resolving to a mix of fastly and cloudflare since 2023-09-20 * https://lists.torproject.org/pipermail/anti-censorship-team/2023-September/… * https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42120 * options for remediation: * change the domain front to one that still always resolves to fastly * not a lot of good options, also we don't have good knowledge of which are already censored https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * locally pin the IP address of the front domain we are using now * or resolve a different (fastly) name, but keep using the same front that we use now * creates an inconsistency between DNS and TLS * we can change the front domain for circumvention settings users, which does not require waiting for a TB/orbot/etc. release * change the domain to foursquare.com * guardian project / orbot? meskio says orbot is already using circumvention settings. But circumvention settings might be ignored for built-in bridges. * dcf will make a forum post and contact guardian project * community team will try to get testing of fourquare.com in the next week * meskio will make the change in Tor Browser and circumvention settings * Remove Go 1.20 support? kcp library seems to crash compiler: * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * # github.com/xtaci/kcp-go/v5 * /go/pkg/mod/github.com/xtaci/kcp-go/v5@v5.6.3/timedsched.go:19:6: internal compiler error: panic: interface conversion: interface is nil, not ir.Node * Please file a bug report including a short program that triggers the error. * https://go.dev/issue/new * note: module requires Go 1.21 * https://github.com/xtaci/kcp-go/blob/v5.6.3/timedsched.go#L19 * Go compiler issue: https://github.com/golang/go/issues/61074 * Has to do with new compiler builtin "clear" in go1.21 https://tip.golang.org/doc/go1.21#language * ...which kcp-go started using 10 days ago https://github.com/xtaci/kcp-go/commit/691fc2febef3dd927dca7815b207fb4dad19… * shelikhoo will go ahead and remove go1.20 support == Actions == == Interesting links == * https://www.bamsoftware.com/papers/fep-flaws/#sec:obfs4 * writeup of Elligator distinguishers that have affected obfs4proxy == Reading group == * We will discuss "" on * * Questions to ask and goals to have: * What aspects of the paper are questionable? * Are there immediate actions we can take based on this work? * Are there long-term actions we can take based on this work? * Is there future work that we want to call out in hopes that others will pick it up? == Updates == Name: This week: - What you worked on this week. Next week: - What you are planning to work on next week. Help with: - Something you need help with. cecylia (cohosh): 2023-09-21 Last week: - dealt with dependency updates for snowflake and lox - discussed rdsys resource endpoints - opened an issue to create a lox user on rdsys-frontend-01 - https://gitlab.torproject.org/tpo/tpa/team/-/issues/41330 - wrote some next steps for conjure work - https://gitlab.torproject.org/tpo/operations/proposals/-/issues/51 This week: - finish deploying lox distributor - follow up on conjure reliability issues - visualize and write up some snowflake shadow simulation results Needs help with: dcf: 2023-09-21 Last week: - snowflake CDN bookkeeping https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-co… - noticed a problem with the fastly domain front and coordinated with cohosh to analyze it https://lists.torproject.org/pipermail/anti-censorship-team/2023-September/… Next week: - revise encapsulation.ReadData redesign to return an error in the case of a short buffer https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - open issue to have snowflake-client log whenever KCPInErrors is nonzero https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - parent: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - open issue to disable /debug endpoint on snowflake broker Before EOY 2023: - move snowflake-02 to new VM Help with: meskio: 2023-09-21 Last week: - make fake descriptors for rdsys (rdsys#171) - document rdsys development process (rdsys#131) - use the right content-type in moat (rdsys#175) - add token authentication to onbasca requests (rdsys#174) Next week: - add a DB for bridges to rdsys (rdsys#56) Shelikhoo: 2023-09-21 Last Week: - [Merge Request Awaiting] Add SOCKS5 forward proxy support to snowflake (snowflake!64) (stalled) - Add Remote Network Address Mapping in HTTP Upgrade Transport (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webt…) (Done pass the client IP to tor for country usage stadistics, https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webt…) - Release new version of snowflake(https://gitlab.torproject.org/tpo/anti-censorship/pluggable-trans… - Update CI targets to test Android from Golang 1.21 (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…) - Merge request reviews Next Week/TODO: - Write Tor Spec for Armored URL - Merge request reviews onyinyang: 2023-09-21 Last week(s): - Continued updating dependencies, including: - found issues with zkp library and am working on determining how to best handle those going forward, fixes are required to keep other dalek-cryptography libraries up to date: https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/merge_requests/51 - additionally, there is a bug in the zkp crate that is noted in the blockage migration protocol so we might try to fix it: https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/blob/main/crates… - Attempted changes to rdsys API at the /resources endpoint to meet the needs of Lox - Started on adding metrics This week: - Hopefully sort out the dependencies issue - Finish up changes to the API - continue with metrics (long term things were discussed at the meeting!): https://pad.riseup.net/p/tor-ac-community-azaleas-room-keep - brainstorming grouping strategies for Lox buckets (of bridges) and gathering context on how types of bridges are distributed/use in practice 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? 1. Are there some obvious grouping strategies that we can already consider? 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?) 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?

1 0

Job Opportunity - Project Manager
by Erin Wyatt 18 Sep '23

18 Sep '23

Hi everyone! We have a new job opening for a Project Manager! https://www.torproject.org/about/jobs/project-manager/ <https://www.torproject.org/about/jobs/project-manager/> If you are or know someone who would be a good fit and wants to join our team, please apply/share. Have a great week and thanks for helping us spread the word! :) Cheers, Erin Wyatt Director of People Operations (she/her) ewyatt(a)torproject.org <mailto:ewyatt@torproject.org> PGP: 35E7 2A9F 6655 45F9 2CB6 6624 BA0C 9400 F80F 91CE https://www.torproject.org <https://www.torproject.org/> http://2gzyxa5ihm7nsggfxnu52rck2vv4rvmdlkiu3zzui5du4xyclen53wid.onion/ <http://2gzyxa5ihm7nsggfxnu52rck2vv4rvmdlkiu3zzui5du4xyclen53wid.onion/>

1 0

Anti-censorship team meeting notes, 2023-09-14
by onyinyang 14 Sep '23

14 Sep '23

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2023/tor-meeting.2023-09-14-15.58.html And our meeting pad: Anti-censorship -------------------------------- Next meeting: Thursday, Sep 21 16:00 UTC Facilitator: Shelikhoo Weekly meetings, every Thursday at 16:00 UTC, in #tor-meeting at OFTC (channel is logged while meetings are in progress) This week's Facilitator: onyinyang == 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 the Tor Project and Tor community. == 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 96 <-- meskio, shell, onyinyang, cohosh * https://gitlab.torproject.org/groups/tpo/-/milestones/24 * Sponsor 139 <-- hackerncoder, irl, joydeep, meskio, emmapeel working on it * https://pad.riseup.net/p/sponsor139-meeting-pad == Announcements == == Discussion == == Actions == == Interesting links == * == Reading group == * We will discuss "" on * * Questions to ask and goals to have: * What aspects of the paper are questionable? * Are there immediate actions we can take based on this work? * Are there long-term actions we can take based on this work? * Is there future work that we want to call out in hopes that others will pick it up? == Updates == Name: This week: - What you worked on this week. Next week: - What you are planning to work on next week. Help with: - Something you need help with. cecylia (cohosh): 2023-09-14 Last week: - posted shadow + PT guide on the forum - https://forum.torproject.org/t/experimenting-with-tor-pluggable-transports-… - followed up on a report that snowflake is being blocked in russia - https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/iss… - https://ntc.party/t/ooni-shows-blocking-on-snowflake-in-select-isps-in-russ… - opened issue with OONI for adding probe-engine version filter to MAT - https://github.com/ooni/probe/issues/2533 - filed an upstream issue with conjure on not relying on the replace directive - https://github.com/refraction-networking/conjure/issues/226 - updated gotapdance library version in Conjure PT to fix a stall issue - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conj… - worked on deploying lox distributor - https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/167 This week: - finish deploying lox distributor - map out next steps for conjure work - followup on conjure reliability issues - visualize and write up some snowflake shadow simulation results Needs help with: dcf: 2023-09-13 Last week: - snowflake CDN bookkeeping https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-co… Next week: - revise encapsulation.ReadData redesign to return an error in the case of a short buffer https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - open issue to have snowflake-client log whenever KCPInErrors is nonzero https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - parent: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - open issue to disable /debug endpoint on snowflake broker Help with: meskio: 2023-09-07 Last week: - vacation :) - coordinate with TPA to get a VM for a rdsys staging server - review lyrebird merge requests Next week: - deploy the rdsys staging server Shelikhoo: 2023-09-07 Last Week: - [Merge Request Awaiting] Add SOCKS5 forward proxy support to snowflake (snowflake!64) (stalled) - logcollector alert system - Add Remote Network Address Mapping in HTTP Upgrade Transport (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webt…) - Merge request reviews Next Week/TODO: - Add Remote Network Address Mapping in HTTP Upgrade Transport (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webt…) (Continue) - Release new version of snowflake - Merge request reviews onyinyang: 2023-09-14 Last week(s): - Continued updating dependencies, including: - aes-gcm: https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/merge_requests/35 - base64: https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/merge_requests/36 - found issues with zkp library and am working on determining how to best handle those going forward, fixes are required to keep other dalek-cryptography libraries up to date: https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/merge_requests/51 - Started on adding metrics This week: - Update rdsys API at the /resources endpoint to meet the needs of Lox - Continue with adding metrics (long term things were discussed at the meeting!): https://pad.riseup.net/p/tor-ac-community-azaleas-room-keep - brainstorming grouping strategies for Lox buckets (of bridges) and gathering context on how types of bridges are distributed/use in practice 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? 1. Are there some obvious grouping strategies that we can already consider? 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?) 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? -- --- onyinyang GPG Fingerprint 3CC3 F8CC E9D0 A92F A108 38EF 156A 6435 430C 2036

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

tor-project