The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-04-19T11:34:54Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41510The "Restore Defaults" doesn't restore the Security Level preferences2023-04-19T11:34:54ZPier Angelo VendrameThe "Restore Defaults" doesn't restore the Security Level preferencesWhile reviewing !464, I've noticed that the "Restore Defaults" link in about:preferences#privacy doesn't do anything (see also https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests/464#note_2860237).
Initially, I t...While reviewing !464, I've noticed that the "Restore Defaults" link in about:preferences#privacy doesn't do anything (see also https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests/464#note_2860237).
Initially, I thought adding an `is="text-link"` was enough, because some telemetry nonsense looks for that attribute, which we're missing and we get an exception that is visible in the console.
However, adding it doesn't seem to be enough, and we might need some additional investigation.
As a workaround, the button in the panel works, so we might release 12.0 with this problem, and add it to known bugs.
/cc @richard @duncanhttps://gitlab.torproject.org/tpo/core/arti/-/issues/692Client side of onion "introduce" and "rendezvous" handshakes2023-06-13T15:33:16ZNick MathewsonClient side of onion "introduce" and "rendezvous" handshakesThese protocols are described in sections 3.2 and 4 of `rend-spec-v3.txt`. They start with the client having only a descriptor for a targeted onion service. Then:
1. The client constructs a rendezvous circuit and tells the last hop (...These protocols are described in sections 3.2 and 4 of `rend-spec-v3.txt`. They start with the client having only a descriptor for a targeted onion service. Then:
1. The client constructs a rendezvous circuit and tells the last hop (the "rendezvous point") to `ESTABLISH_RENDEZVOUS`. It waits for a `RENDEZVOUS_ESTABLISHED`.
2. The client constructs an introduction circuit to one of the introduction points listed in the descriptor, and tells it `INTRODUCE1`. It waits for a `INTRODUCE_ACK`.
3. The client waits for a `RENDEZVOUS2` message on the rendezvous circuit, and uses it to compute cryptography for a final "virtual" hop on the rendezvous circuit. This circuit is now connected to the onion service.
These handshakes have a fair amount of cryptography going on; in this ticket, we're going to try to implement all of that cryptography. It might make sense to implement the service side of the cryptography at the same time, so we have something to test it against. The message types are implemented in #690.Arti: Onion service supporthttps://gitlab.torproject.org/tpo/core/arti/-/issues/688CircMgr: Support for anonymous circuit to target non-exit relay.2023-04-25T15:37:12ZNick MathewsonCircMgr: Support for anonymous circuit to target non-exit relay.For onion services, we will frequently need to build an anonymous circuit to a target non-exit relay. We use these circuits for anonymized directory connections, introduction circuits, and rendezvous circuits.
This will likely involve a...For onion services, we will frequently need to build an anonymous circuit to a target non-exit relay. We use these circuits for anonymized directory connections, introduction circuits, and rendezvous circuits.
This will likely involve a new usage in CircMgr. (Unlike other usages, these circuits cannot generally be shared for anything else.)Arti: Onion service supporthttps://gitlab.torproject.org/tpo/core/arti/-/issues/685Encryption/decryption and signature checking for onion descriptors2023-04-25T15:32:35ZNick MathewsonEncryption/decryption and signature checking for onion descriptorsAs a follow-on or related issue to #683, we will neeed to encrypt/decrypt the inner part of an onion service descriptor using the correct keys, and validate signatures throughout.
See `rend-spec-v3.txt` section 2.5.As a follow-on or related issue to #683, we will neeed to encrypt/decrypt the inner part of an onion service descriptor using the correct keys, and validate signatures throughout.
See `rend-spec-v3.txt` section 2.5.Arti: Onion service supporthttps://gitlab.torproject.org/tpo/core/arti/-/issues/683Encode and decode onion service descriptors2023-04-25T15:20:28ZNick MathewsonEncode and decode onion service descriptorsOnion service descriptors use the same metaformat as other Tor network documents, and should probably be encoded/decoded behind an optional feature in `tor-netdoc`. The format is documented in `rend-spec-v3.txt` sections 2.4 and 2.5.
W...Onion service descriptors use the same metaformat as other Tor network documents, and should probably be encoded/decoded behind an optional feature in `tor-netdoc`. The format is documented in `rend-spec-v3.txt` sections 2.4 and 2.5.
We should separate encryption/decryption concerns from parsing/encoding concerns: this will probably mean a two-stage process for encoding/decoding.
To get example desriptors for testing, we can run a chutney network that uses onion services, with instrumentation in the C tor to cause it to dump the descriptors it generates.
Subtasks (may not be an exhaustive list):
* [x] #743 netdoc metaformat encoder
* [x] #744 hs descriptor decoder
* [x] #745 hs descriptor encoderArti: Onion service supporthttps://gitlab.torproject.org/tpo/network-health/team/-/issues/277Come up with a set of labels we might want to use for annotating relays2023-10-03T09:32:07ZGeorg KoppenCome up with a set of labels we might want to use for annotating relaysWhile we might want to have some free text field to save relay annotations we definitely want to have some labels, too, which will help us with picking/sorting annotated relays. In this ticket we should come up with the set of labels we ...While we might want to have some free text field to save relay annotations we definitely want to have some labels, too, which will help us with picking/sorting annotated relays. In this ticket we should come up with the set of labels we want to start with.
/cc @gus @armaHiroHirohttps://gitlab.torproject.org/tpo/network-health/team/-/issues/276Write a small UI in Python for displaying and sorting relay annotations2023-06-14T16:53:07ZGeorg KoppenWrite a small UI in Python for displaying and sorting relay annotationsWe could think about re-using parts of the [`python-website`](https://gitlab.torproject.org/tpo/network-health/metrics/python-website) project maybe.We could think about re-using parts of the [`python-website`](https://gitlab.torproject.org/tpo/network-health/metrics/python-website) project maybe.https://gitlab.torproject.org/tpo/tpa/team/-/issues/40979document our fastly/CDN setup2022-11-30T19:55:45Zanarcatdocument our fastly/CDN setupso we have a CDN we use here, and it's not really documented. we have fairly good docs on the ~"static-component" system, but nothing on ~Fastly. we didn't even have a tag for it until #40978 was filed (and i made it).
so we should docu...so we have a CDN we use here, and it's not really documented. we have fairly good docs on the ~"static-component" system, but nothing on ~Fastly. we didn't even have a tag for it until #40978 was filed (and i made it).
so we should document:
* [ ] what we use fastly for
* [ ] how it's configured (e.g. `cdn-config-fastly.git`, `./tor-puppet/modules/roles/files/puppetmaster/update-fastly-ips`, static-component yaml file, probably more)
* [ ] what talks to it and why not everything is on there
* [ ] what our limits are
* [ ] contact information
* [ ] password management
basically make a full service audit.anarcatanarcathttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/112Reported as offline in metrics, some bridges are online and running2024-02-29T15:22:53ZGusReported as offline in metrics, some bridges are online and runningSince last week, some bridge operators are reporting that their bridge is 'offline' in Metrics, but they are online and running.
I can confirm that this is happening. One of my bridges is marked as [offline](https://metrics.torproject....Since last week, some bridge operators are reporting that their bridge is 'offline' in Metrics, but they are online and running.
I can confirm that this is happening. One of my bridges is marked as [offline](https://metrics.torproject.org/rs.html#details/25A5B3BB5449EC5A0D4AE4DB657899C02C186EBE), but on the tor logs I see:
>Nov 28 12:02:57.000 [notice] Heartbeat: Since last heartbeat message, I have seen 200 unique clients.
Other messages on the logs:
```
Nov 20 12:23:29.000 [notice] Guard bauruine ($5B83DC983406651A0B4F6AE1940793CDD6A6F92E) is failing more circuits than usual. Most likely this means the Tor network is overloaded. Success counts are 198/283. Use counts are 63/63. 227 circuits completed, 0 were unusable, 30 collapsed, and 5 timed out. For reference, your timeout cutoff is 324 seconds.
Nov 20 23:04:10.000 [notice] Our directory information is no longer up-to-date enough to build circuits: We're missing descriptors for 1/3 of our primary entry guards (total microdescriptors: 5983/6034). That's ok. We will try to fetch missing descriptors soon.
Nov 21 03:24:31.000 [notice] Guard rixtyminutes ($01AE2DE314276C82FCCC3603A1C2F3238E6544C9) is failing more circuits than usual. Most likely this means the Tor network is overloaded. Success counts are 109/156. Use counts are 37/37. 132 circuits completed, 0 were unusable, 23 collapsed, and 5 timed out. For reference, your timeout cutoff is 324 seconds.
```
Reddit: https://www.reddit.com/r/TOR/comments/z2o7ro/bridge_metrics_showing_offline/meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41482Bridge cards should inform users when a bridge isn't working2024-01-29T19:06:20ZGusBridge cards should inform users when a bridge isn't workingWhen a user requests a bridge using one of the bridge distributors (moat, telegram, connection assist), some of them may be blocked in their region. Users can see which bridge is failing on their Tor logs. Is it possible to display that ...When a user requests a bridge using one of the bridge distributors (moat, telegram, connection assist), some of them may be blocked in their region. Users can see which bridge is failing on their Tor logs. Is it possible to display that information on the bridge card so they don't need to check the logs?https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41479Verify browser.startup.homepage_override.buildID and update mechanisms2023-10-09T17:00:12ZPier Angelo VendrameVerify browser.startup.homepage_override.buildID and update mechanismsWe have a mechanism to make `about:tor` open an update page, with a few preferences involved.
We should review it.
Also, we write `browser.startup.homepage_override.buildID`, and so we could possibly remove it from the profile.We have a mechanism to make `about:tor` open an update page, with a few preferences involved.
We should review it.
Also, we write `browser.startup.homepage_override.buildID`, and so we could possibly remove it from the profile.https://gitlab.torproject.org/tpo/community/training/-/issues/79Introduction to Onion Services in Arabic2023-07-19T11:33:24ZrayaIntroduction to Onion Services in Arabic## To-Do:
- [ ] Complete translation of slides
- [ ] Upload to community portal
## Steps to upload to community portal
- [ ] add slides in PDF and ODP formats here: https://gitlab.torproject.org/tpo/web/community/-/tree/main/assets/stat...## To-Do:
- [ ] Complete translation of slides
- [ ] Upload to community portal
## Steps to upload to community portal
- [ ] add slides in PDF and ODP formats here: https://gitlab.torproject.org/tpo/web/community/-/tree/main/assets/static/files, simply as `file-name.odp` and `file-name.pdf`
- [ ] add slides in PDF and ODP formats here: https://gitlab.torproject.org/tpo/community/training, inside folder: `year/topic/file-name.odp` and `year/topic/file-name.pdf`
- [ ] add preview image of slides here (size H:700, W:400): https://gitlab.torproject.org/tpo/web/community/-/tree/main/assets/static/images/training, this image will be displayed here: http://community.torproject.org/training/resources, simply add as `file-name.png`
- [ ] edit the `training-resources.json` file and add training properties: https://gitlab.torproject.org/tpo/web/community/-/blob/main/databags/training-resources.json
- [ ] edit the `community-training-materials.json` file and add training properties:
https://gitlab.torproject.org/tpo/web/community/-/blob/main/databags/community-training-materials.json
### Working document
- https://docs.google.com/presentation/d/1Mlyzjfvcr5qI4hZlNMzF87iKBADX7EmVVFqn5rJfNqY/editrayarayahttps://gitlab.torproject.org/tpo/core/tor/-/issues/40718Allow setting DirPortFrontPage with DirCache 02023-09-05T12:53:08ZcypherpunksAllow setting DirPortFrontPage with DirCache 0relay meetup follow up:
Currently it is not possible to set `DirCache 0` on a relay that has set `DirPort`.
```
DirPort configured but DirCache disabled. DirPort requires DirCache.
```relay meetup follow up:
Currently it is not possible to set `DirCache 0` on a relay that has set `DirPort`.
```
DirPort configured but DirCache disabled. DirPort requires DirCache.
```https://gitlab.torproject.org/tpo/community/outreach/-/issues/40017Tor activities at FOSDEM 20232023-09-30T01:30:48ZGusTor activities at FOSDEM 2023Happening on Brussels / 4 & 5 February 2023
https://fosdem.org/2023/Happening on Brussels / 4 & 5 February 2023
https://fosdem.org/2023/https://gitlab.torproject.org/tpo/core/tor/-/issues/40717Additional metricsport stats for various stages of onionservice handshake2023-12-07T14:41:35ZMike PerryAdditional metricsport stats for various stages of onionservice handshakeIf we export additional onion service metrics such as time measurements on the HSDIR, INTRO, and REND stages of circuit setup for both client and service side, and the number of timeouts/failures there, it would help to uncover the root ...If we export additional onion service metrics such as time measurements on the HSDIR, INTRO, and REND stages of circuit setup for both client and service side, and the number of timeouts/failures there, it would help to uncover the root cause of issues like https://gitlab.torproject.org/tpo/core/tor/-/issues/40570 and related reliability and connectivity issues with onion services.
We can also export congestion control info from https://gitlab.torproject.org/tpo/core/tor/-/issues/40708 to the onionservice metrics set, too, which can help us with tuning congestion control for onion services.
We can then hook up the onionperf onion service instances to our grafana dashboard, and gather more detailed stats that way, as a supplement to the metrics that get graphed on the metrics website.https://gitlab.torproject.org/tpo/community/outreach/-/issues/40016Tor Project proposals for Mozfest 20232023-01-16T01:15:42ZGusTor Project proposals for Mozfest 2023I'm opening this ticket to coordinate the community team proposals for Mozfest.
Event: 8 to 20 June 2023, Amsterdam
CFP: The deadline to submit your proposal for MozFest 2023 is December 16th 2022. https://www.mozillafestival.org/en/pro...I'm opening this ticket to coordinate the community team proposals for Mozfest.
Event: 8 to 20 June 2023, Amsterdam
CFP: The deadline to submit your proposal for MozFest 2023 is December 16th 2022. https://www.mozillafestival.org/en/proposals/2022-12-15https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/133consider security levels for runners2023-06-28T18:44:11Zanarcatconsider security levels for runnersWikimedia foundation have an interesting approach to GitLab runner security:
https://wikitech.wikimedia.org/wiki/GitLab/Gitlab_Runner/Security_Evaluation
Basically, they have three levels:
* nothing: you bring your own runners, that ...Wikimedia foundation have an interesting approach to GitLab runner security:
https://wikitech.wikimedia.org/wiki/GitLab/Gitlab_Runner/Security_Evaluation
Basically, they have three levels:
* nothing: you bring your own runners, that would be the equivalent of everyone *not* under the `tpo/` namespace for us
* members-only: access to shared runners
* special projects: allow-list of select projects which are the only ones with access to hardened runners, and *only* on the protected branch
There's all sorts of hardening on those runners, which include:
* image restrictions: an allow-list of images that are allowed to be used for jobs
* non-root gitlab-runner
* (planned) rootless docker (see #129 for our effort at podman, which could do this as well)https://gitlab.torproject.org/tpo/core/tor/-/issues/40716Impelement conflux for onion services2022-11-28T14:01:05ZMike PerryImpelement conflux for onion servicesConflux is traffic splitting, and will result in increased throughput and reduced latency for onion services after a connection has been established, by routing traffic over multiple paths, or via the lowest latency path to a service.
T...Conflux is traffic splitting, and will result in increased throughput and reduced latency for onion services after a connection has been established, by routing traffic over multiple paths, or via the lowest latency path to a service.
This ticket is for the onion service pieces of conflux (https://gitlab.torproject.org/tpo/core/tor/-/issues/40593).
We will not be implementing the onion services pieces of conflux as part of that ticket. It can be done later, if any onion service sponsors care about latency or throughput.
The pieces for onion services are:
- **Negotiation**
- [ ] Protover Advertisement for Onions (24h)
- [ ] Rend circuit linking (40h)
This is specified in https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/329-traffic-splitting.txt, but we probably want to allow onion services to configure their scheduler by manually choosing either BLEST, or LowRTT, since different kinds of onion services may want to optimize for either throughput or latency.
There may be some additional work wrt making sure linked edge conns work properly, if they are handled differently for the onion service case.
Also, some shadow validation and performance testing will be needed. Maybe 40h or so of dev time (though much longer wall-clock time).https://gitlab.torproject.org/tpo/team/-/issues/109Include allocation task into the process of setting up roadmaps for the teams...2023-02-01T23:58:23ZGabagaba@torproject.orgInclude allocation task into the process of setting up roadmaps for the teams every quarter.https://gitlab.torproject.org/tpo/core/arti/-/issues/641AbstractSpec SupportedCircUsage restrict_mut vs supports2023-01-24T17:28:58ZIan Jacksoniwj@torproject.orgAbstractSpec SupportedCircUsage restrict_mut vs supportsIn `impl crate::mgr::AbstractSpec for SupportedCircUsage`, `supports` and `restrict_mut` contain extremely similar code.
1. This should be unified.
2. Note that `supports` checks `Exit.ports` but `restrict_mut` does not modify `ports`:...In `impl crate::mgr::AbstractSpec for SupportedCircUsage`, `supports` and `restrict_mut` contain extremely similar code.
1. This should be unified.
2. Note that `supports` checks `Exit.ports` but `restrict_mut` does not modify `ports`:
```
16:07 <+Diziet> nickm: I see that supports does something wioth
TargetCircUsage::Exit.ports and restrict_mut doesn't. Is that
correct ?
16:26 <+nickm> Diziet: yeah, arguably restrict_mut should do that check too.
16:27 <+nickm> (Diziet: I say "arguably" because the "requirements" section on
restrict_mut says that it shouldn't be called in that case.)
```
I'm not sure that's right but we are too busy now to look into this properly. (CC @nickm)Ian Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.org