The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-01-16T13:50:05Zhttps://gitlab.torproject.org/tpo/network-health/metrics/tagtor/-/issues/25Add filtering options for relays one is interested in2024-01-16T13:50:05ZGeorg KoppenAdd filtering options for relays one is interested inFor bad-relay work or general tagging help it would be nice if we could filter relays, eg. wrt AS, uptime, first_seen dates etc.For bad-relay work or general tagging help it would be nice if we could filter relays, eg. wrt AS, uptime, first_seen dates etc.TagTor is completed for its scope in Sponsor 112https://gitlab.torproject.org/tpo/network-health/metrics/tagtor/-/issues/23Sort entries by consensus weight by default2024-01-16T13:50:05ZGeorg KoppenSort entries by consensus weight by defaultGiven that it would help with the tagging workflow @arma described (see: #19), we should sort the entries according to consensus weight by default.Given that it would help with the tagging workflow @arma described (see: #19), we should sort the entries according to consensus weight by default.TagTor is completed for its scope in Sponsor 112HiroHirohttps://gitlab.torproject.org/tpo/network-health/metrics/tagtor/-/issues/22Group TagTor entries by family where possible2024-01-16T13:50:05ZGeorg KoppenGroup TagTor entries by family where possibleAs said in #20 for tagging purposes the particular relays are not too important, we want to have the relays grouped so they match to operators, which we could have met, talked to etc. So, instead of a per relay view we want to have a per...As said in #20 for tagging purposes the particular relays are not too important, we want to have the relays grouped so they match to operators, which we could have met, talked to etc. So, instead of a per relay view we want to have a per family one if possible. (If there are only single relays or bridges per operator then, of course, those are single relay/bridge entries only and that's fine, too)TagTor is completed for its scope in Sponsor 112HiroHirohttps://gitlab.torproject.org/tpo/network-health/metrics/tagtor/-/issues/21Add total bw and per relay bw and consensus weight to the routers display2024-03-28T11:15:30ZGeorg KoppenAdd total bw and per relay bw and consensus weight to the routers displayWe want to know how much weight relays have and their advertised bandwidth. Those could be additional columns. Additionally, I think it's worth having the advertised bw visible for all the relays under a particular filter, which could be...We want to know how much weight relays have and their advertised bandwidth. Those could be additional columns. Additionally, I think it's worth having the advertised bw visible for all the relays under a particular filter, which could be displayed below the router/bridges table.TagTor is completed for its scope in Sponsor 112HiroHirohttps://gitlab.torproject.org/tpo/network-health/metrics/tagtor/-/issues/19Interactive guided tagging user flow2024-01-16T13:50:05ZRoger DingledineInteractive guided tagging user flowIt looks like the initial tagtor flow is designed around a "user realizes they want to tag a specific relay, goes to tagtor, finds the relay, tags it" flow.
To answer overall-network analysis questions, we need another flow which aims a...It looks like the initial tagtor flow is designed around a "user realizes they want to tag a specific relay, goes to tagtor, finds the relay, tags it" flow.
To answer overall-network analysis questions, we need another flow which aims at more comprehensive tagging.
I described one approach to that flow in my July 2020 tor-relays@ post (https://lists.torproject.org/pipermail/tor-relays/2020-July/018669.html):
"the next step is to figure out the workflow for annotating relays. I
had originally imagined some sort of web-based UI where it leads me
through constructing and maintaining a list of fingerprints that I have
annotated as 'known' and a list annotated as 'unknown', and it shows
me how my lists have been doing over time, and presents me with new
not-yet-annotated relays.
[...]
One of the central functions in those scripts would be to sort the
annotated relays by network impact (some function of consensus weight,
bandwidth carried, time in network, etc), so it's easy to identify the
not-yet-annotated ones that will mean the biggest shifts. Maybe this
ordered list is something we can teach onionoo to output, and then all the
local scripts need to do is go through each relay in the onionoo list,
look them up in the local annotations list to see if they're already
annotated, and present the user with the unannotated ones."
That is, the flow I am imagining is to have tagtor *sort* the relay families by importance to the network, and then present to me the top n families that I haven't yet tagged as roger-known or roger-unknown. Then I can do a bit of work at a time, put it down, come back later, and at any moment I can be answering the highest impact questions about the network.
Then there are some secondary metrics that would be good to hear, which should pop out of the sorting, such as "what fraction of the network have I tagged in some way", "what fraction is roger-known", "what fraction is roger-unknown".
The sorting function can start really simple, like "sum of consensus weights of members of family" but we can imagine fancier ones later, like putting higher priority on big relay groups that *other people* haven't tagged yet either.TagTor is completed for its scope in Sponsor 112HiroHirohttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40755TPA-RFC-33: monitoring system upgrade or replacement2024-03-19T20:17:23ZanarcatTPA-RFC-33: monitoring system upgrade or replacementin #29864, we've gone pretty deep in comparisons between prometheus and icinga and how the first could replace the latter.
but now we're stuck at "i like this one better than the other" because we don't have a clear set of requirements....in #29864, we've gone pretty deep in comparisons between prometheus and icinga and how the first could replace the latter.
but now we're stuck at "i like this one better than the other" because we don't have a clear set of requirements.
the task here is to write a set of requirements for the new alerting system and, ultimately, make a proposal for the replacement of the deprecated Icinga 1 deployment we have now.
* [ ] establish requirements
* [ ] approve requirements
* if replacing icinga:
* [ ] review #29864 for ideas and tasks
* [ ] decide whether we keep the prometheus1/2 distinction
* [ ] deploy alert manager on prometheus1
* [ ] reimplement the Nagios alerting commands (optional?)
* [ ] send Nagios alerts through the alertmanager (optional?)
* [ ] rewrite (non-NRPE) commands (9) as Prometheus alerts
* [ ] scrape the NRPE metrics from Prometheus (optional)
* [ ] create a dashboard and/or alerts for the NRPE metrics (optional)
* [ ] review the NRPE commands (300+) to see which one to rewrite as Prometheus alerts
* [ ] turn off the Icinga server
* [ ] remove all traces of NRPE on all nodes
* if keeping icinga
* [ ] review work from @weasel done on DSA's Puppet/Icinga integration
* [ ] deploy that module or another inciga module inside puppet
* [ ] rewrite all the checks from the `nagios-master.cfg` file into puppet (300+)
* [ ] rebuild a new Icinga 2 server
* [ ] retire the old Icinga 1 serverold service retirement 2023anarcatanarcathttps://gitlab.torproject.org/tpo/tpa/team/-/issues/32273archive private information from SVN2022-12-06T19:50:49Zanarcatarchive private information from SVNa common problem in the internal and corp SVN repository shutdown is "what do we do with all that stuff now". for example, the internal repository is shutdown now (#15949) but there is still information there that is valuable. or not. we...a common problem in the internal and corp SVN repository shutdown is "what do we do with all that stuff now". for example, the internal repository is shutdown now (#15949) but there is still information there that is valuable. or not. we're not sure. we think so, but maybe some of it should be destroyed.
so we need to answer the following questions:
1. which data should be kept and destroyed from the repositories?
2. where should it be kept?
so far, I went under the assertion that the answers were:
1. keep everything
2. in nextcloud
but it seems this might not be exactly right.old service retirement 2023https://gitlab.torproject.org/tpo/tpa/team/-/issues/32025Stop using corpsvn and disable it as a service2022-12-06T19:50:54ZRoger DingledineStop using corpsvn and disable it as a serviceIn legacy/trac#17202 we're going to decommission the server that runs our various svn services.
We have a plan for the public svn.tpo service: legacy/trac#15948
and we are making a plan for svninternal: legacy/trac#15949
That leaves c...In legacy/trac#17202 we're going to decommission the server that runs our various svn services.
We have a plan for the public svn.tpo service: legacy/trac#15948
and we are making a plan for svninternal: legacy/trac#15949
That leaves corpsvn, which I think is the most actively used still -- for example our accounting folks use it. This ticket is about making and finishing the plan for shutting down the corpsvn service.old service retirement 2023https://gitlab.torproject.org/tpo/tpa/team/-/issues/17202Shut down SVN and decomission the host (gayi)2022-12-06T19:51:28ZNick MathewsonShut down SVN and decomission the host (gayi)It is now 2015. Let us not have an SVN server running in 2016.
-- And is now 2020 and we are finally trying to shutdown this. Modifying this ticket to add the plan suggested by arma (with a few modifications by me).
(1) Freeze corps...It is now 2015. Let us not have an SVN server running in 2016.
-- And is now 2020 and we are finally trying to shutdown this. Modifying this ticket to add the plan suggested by arma (with a few modifications by me).
(1) Freeze corpsvn (i.e. make it read-only), and make a full checkout
of it somewhere, and have that accessible.
(2) Use Nextcloud for any other file people may need to save. *Not* move all the old files there, or at least not by default.
(3) Put together a strike team to look at the frozen corpsvn checkout,
plus the frozen internalsvn checkout. Build a list of categories (HR,
finance, grantwriting, grant manager, etc), and sort the files into
these categories, discarding as many files as possible. Figure out
where else people are storing these files currently (granthub? google
docs? their hard drive?). Make a comprehensive plan for how files of each category should be stored, and who should have read or write access per category. For example, there's no reason that HR documents should go into the same database, or even the same storage service, as grant proposals. Process started in https://bugs.torproject.org/32273
Update, 2021: there's a "forest" of tickets surrounding this, as the "tree" was lost in the Trac migration, i'll try to reconstruct related tickets:
* SVN/host shutdown (this ticket)
* [ ] #32273 - archive private information from SVN: determine what moves to where (presumably: "everything, to nextcloud")
* [x] #15949 - shutdown SVN internal (done, but the repository is still on gayi, and not archived anywhere else)
* [ ] #32025 - stop using corpsvn and disable it (still open, blocked mostly on @sue iirc)
* [x] #33537 - audit SVN accesses (led to the [access control document](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/svn/#access-control) and a private audit email with one minor remaining task, `Message-ID: 871rq02rvt.fsf@curie.anarc.at`, can probably be just closed)
* [x] #15948 - public SVN retirement (done, moved to the static site mirror system (#32031) and archive.org)
* [x] #31686 - textile retirement (done)
* [ ] #40260 - actual proposal (next step, blocker)
It seems the next step here is to write a policy proposal to make sure we're all on the same page ("let's move to Nextcloud") and schedule a call with Sue to make sure it works in her workflow.old service retirement 2023anarcatanarcathttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40260TPA-RFC-11: SVN retirement2024-02-20T16:08:17ZanarcatTPA-RFC-11: SVN retirementDraft a proposal to retire SVN altogether. This was somewhat agreed on in #17202, and there are discussions on how exactly to do this in #32273 (how to archive it) and #32025 (how stop corpsvn specifically, the remaining live repo), but ...Draft a proposal to retire SVN altogether. This was somewhat agreed on in #17202, and there are discussions on how exactly to do this in #32273 (how to archive it) and #32025 (how stop corpsvn specifically, the remaining live repo), but this was all done before we came up with the TPA-RFC process.
Now that we have that process, it seems logical to go through with it explicitly so that all stakeholders can express their concerns about the change. I specifically plan on having a live call with sue about this, since she's the most impacted by this.
I create this ticket to track that proposal because #17202 has been sitting in the icebox forever and it's kind of hard to "grab" because it feels so big. Having "write a proposal" first seems more accessible.
draft proposal is in https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-11-svn-retirement
Next steps:
- [x] @susan draft requirements for the sensitive file storage service
- [x] @anarcat research whether we can restrict external sharing in Nextcloud
- [x] @anarcat schedule a meeting in late june to revise the aboveold service retirement 2023anarcatanarcat2024-01-19https://gitlab.torproject.org/tpo/applications/vpn/-/issues/136Design the user interface for v6 of the VPN pre-alpha2024-03-27T17:31:07ZdonutsDesign the user interface for v6 of the VPN pre-alphaSee the linked issues below for specific changes and new features, each of which should include its own estimate.See the linked issues below for specific changes and new features, each of which should include its own estimate.VPN pre-alpha 06donutsdonutshttps://gitlab.torproject.org/tpo/applications/vpn/-/issues/133Flip the connection / circuit display per app2024-03-06T15:32:43Zmicahmicah@torproject.orgFlip the connection / circuit display per appAs it is now, if you get information for an app, you will see the connections and then if you click on a connection, you see the circuit. We discussed in our meeting today that it would make more sense to first show the circuit and then ...As it is now, if you get information for an app, you will see the connections and then if you click on a connection, you see the circuit. We discussed in our meeting today that it would make more sense to first show the circuit and then if you were to click on the circuit, you would then see the connections.
This seemed to be a purely UI change, and not something that needs to be done in onionmasq itself.VPN pre-alpha 06cybertacybertahttps://gitlab.torproject.org/tpo/applications/vpn/-/issues/119Review strings used on "Bridges" page for length and consistency2024-03-26T22:58:47ZkwadronautReview strings used on "Bridges" page for length and consistencyThe wording is pretty long:
> **Enter bridge address**
>
> Add a bridge provided by a trusted organization or someone you know
![image](/uploads/6eed6b060be49262539f5064c635907b/image.png)
Maybe we can get something shorter, suggestio...The wording is pretty long:
> **Enter bridge address**
>
> Add a bridge provided by a trusted organization or someone you know
![image](/uploads/6eed6b060be49262539f5064c635907b/image.png)
Maybe we can get something shorter, suggestions:
- Add a bridge from a trusted organization or person
- Add a trusted bridge
- Enter a bridge from a trusted sourceVPN pre-alpha 06donutsdonutshttps://gitlab.torproject.org/tpo/core/onionmasq/-/issues/73Deal with failures to bootstrap more gracefully / introduce a timeout2024-03-27T17:31:10ZetaDeal with failures to bootstrap more gracefully / introduce a timeout@kwadronaut raises the example of seeing 'connecting' forever when trying to use snowflake (or another unsupported PT). We should definitely fail faster in this sort of case, given we'll be getting failures to build circuits etc. (in fac...@kwadronaut raises the example of seeing 'connecting' forever when trying to use snowflake (or another unsupported PT). We should definitely fail faster in this sort of case, given we'll be getting failures to build circuits etc. (in fact this is an arti bug), and we should probably have some form of overall timeout.VPN pre-alpha 06Micah Elizabeth ScottMicah Elizabeth Scotthttps://gitlab.torproject.org/tpo/core/onionmasq/-/issues/70Add support for Snowflake2024-03-27T17:31:16ZetaAdd support for SnowflakeThe current PT support only does obfs4. We probably want snowflake too.The current PT support only does obfs4. We probably want snowflake too.VPN pre-alpha 06Micah Elizabeth ScottMicah Elizabeth Scott2024-03-07https://gitlab.torproject.org/tpo/core/onionmasq/-/issues/66implement Connectivity Handler2024-03-27T17:31:21Zcybertaimplement Connectivity HandlerAndroid offers the possibility to receive events on network connectivity changes. In order to improve onionmasq's handling of missing or flaky underlying network connectivity, we should make use if Androids ConnectivityManagerCompat to d...Android offers the possibility to receive events on network connectivity changes. In order to improve onionmasq's handling of missing or flaky underlying network connectivity, we should make use if Androids ConnectivityManagerCompat to determine if the phone has any working internet connection. Additionally we should pass that information via the JNI to the rust part of Onionmasq.VPN pre-alpha 06Micah Elizabeth ScottMicah Elizabeth Scotthttps://gitlab.torproject.org/tpo/core/onionmasq/-/issues/41Figure out how to handle complex DNS queries2024-03-27T17:27:57ZetaFigure out how to handle complex DNS queriesThis was raised in the meeting as part of the VPN app's proposal: what if e.g. an XMPP app wants to make an SRV query? Currently this would just fail, and the Tor network doesn't actually support this kind of DNS query.
Should we perhap...This was raised in the meeting as part of the VPN app's proposal: what if e.g. an XMPP app wants to make an SRV query? Currently this would just fail, and the Tor network doesn't actually support this kind of DNS query.
Should we perhaps use some random DoH / DoT server to forward only those types of query which we can't do?VPN pre-alpha 06https://gitlab.torproject.org/tpo/applications/vpn/-/issues/48Provide links to support channels and offline documentation2024-03-22T01:07:25Zmicahmicah@torproject.orgProvide links to support channels and offline documentationWhen users have issues with TorVPN that they cannot resolve on their own, they should easily find a help meny with documentation and links to support channels so they can resolve their issues.
~~The help documentation should be availabl...When users have issues with TorVPN that they cannot resolve on their own, they should easily find a help meny with documentation and links to support channels so they can resolve their issues.
~~The help documentation should be available offline, so its possible to debug issues without needing to connect to the Internet in the clear to access it.~~
(The offline documentation portion of this issue will be moved to the cost extension)VPN pre-alpha 06cybertacybertahttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41511upgrade crm-ext-01 to php 8 or retire2024-02-20T20:04:45Zanarcatupgrade crm-ext-01 to php 8 or retirein https://gitlab.torproject.org/tpo/tpa/team/-/issues/41252#note_2990644, @kez tested crm-ext-01 after I upgraded it and found the donate site completely broken by the PHP 8.2 upgrade. apparently, `implode` completely changed signature ...in https://gitlab.torproject.org/tpo/tpa/team/-/issues/41252#note_2990644, @kez tested crm-ext-01 after I upgraded it and found the donate site completely broken by the PHP 8.2 upgrade. apparently, `implode` completely changed signature in PHP and the old signature was dropped in PHP 8, which breaks a *lot* of things.
exactly how much is unclear, @kez estimated just the work to estimate that work to be a few hours of work.
for now i rolled back to the php 7.4 package from bullseye, and added it to the sources.list file (although puppet might have killed the .list file already). we need to figure out a plan to go forward, either port the code, or retire the box, which is the ultimate goal once donate-neo goes to production.Redesign donate.torproject.orghttps://gitlab.torproject.org/tpo/community/team/-/issues/96Call for testers - TBA Alpha Connect Assist2024-03-05T19:13:47ZGusCall for testers - TBA Alpha Connect AssistApplications Team is implementing "connect assist" on TBA and it would be nice to collect users feedback. We should create a Call for Testers on the Forum.
Connect Assist is available on 13.5a3 alpha.
```
## Connect assist comes to And...Applications Team is implementing "connect assist" on TBA and it would be nice to collect users feedback. We should create a Call for Testers on the Forum.
Connect Assist is available on 13.5a3 alpha.
```
## Connect assist comes to Android
This alpha is the first release with Desktop's censorship circumvention feature (connect assist) available on Android! You can try it out for yourself by navigating to the `Settings > Tor Network` and selecting `Enable beta connection features`.
**NOTE**: This feature is very much in development and is still quiet brittle and liable to breakage. Do *not* toggle this option if you value your current Tor Browser for Android Alpha configuration. If this option gets the app into an unusable state, you can get back to the legacy bootstrapping system by clearing the app's storage and cache via the Android system settings. Of course, doing so will also delete any existing configuration options so please do not enable this option if this would be a problem for you.
When this feature ships in 13.5 in late spring/early summer 2024, Android users connecting from censored networks should have the exact same bootstrapping functionality Desktop users currently have. If they are unable to connect to the Tor Network, Tor Browser will query the anti-censorship backend to determine which pluggable transports and bridges they need to use based upon their locale and the current censorship landscape. The browser will then attempt to bootstrap once more with the new settings applied. Our hope is that this will take a lot of the guesswork out of connecting to the Tor Network for our mobile users, and ensure unfettered network access during censorship events.
For now we expect this new bootstrapping UX to be buggy, but we wanted to get it into the hands of users as early as possible so we can iterate and find and fix bugs as early as possible.
```Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & TibetGusGus2024-03-01