The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-06-15T10:31:28Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40809Bring padding machines into sync with Tobias's latest changes2023-06-15T10:31:28ZMike PerryBring padding machines into sync with Tobias's latest changesTobias has added some changes to the padding machines in his latest research: in particular, the padding machine can respond to queue length/congestion signals. I believe there are now also probabilistic transitions (ie https://gitlab.to...Tobias has added some changes to the padding machines in his latest research: in particular, the padding machine can respond to queue length/congestion signals. I believe there are now also probabilistic transitions (ie https://gitlab.torproject.org/tpo/core/tor/-/issues/31636 or https://gitlab.torproject.org/tpo/core/tor/-/issues/31787).
I need to read his latest paper, sync with him, and discuss these things. This will generate new tickets.Mike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/arti/-/issues/884Clarify intended time for which a NetDir should be held; make sure code is be...2023-06-12T17:21:29ZNick MathewsonClarify intended time for which a NetDir should be held; make sure code is behaving sensibly.See discussion at https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1228?commit_id=cd133bdc0930d5f120ed95b019ec1388df435b0d#note_2910285 .
Basically, we should _at least_ document that when you get an `Arc<NetDir>` from an ...See discussion at https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1228?commit_id=cd133bdc0930d5f120ed95b019ec1388df435b0d#note_2910285 .
Basically, we should _at least_ document that when you get an `Arc<NetDir>` from an `NetDirProvider`, you shouldn't hold on to it longer than you need to. (The reason being: said `Arc` is pointing to a `Mutex<Arc<NetDir>>` that can get updated with `Arc::get_mut()`, which can clone the `NetDir` if somebody has a reference to it.)
Additionally, we should look through our code and explain why we are holding `NetDir`s for the "right" amount of time, and use this to inform best practices. (For example, this is part of the reason why, when constructing a circuit path, we construct the _entire_ path all at once. It is also part of the reason why `OwnedCircTarget` exists.)
Possibly, we should turn Relay into a type that holds Arc<> rather than a reference. Doing this would alleviate some of our pain, but not all.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41835Review default search engine options2024-03-07T13:46:03ZdonutsReview default search engine optionsMullvad Browser took a start-from-scratch approach and removed all default search options besides DuckDuckGo. While we probably don't want to do the same, I think Tor Browser's search options could still use some housekeeping – e.g.
- S...Mullvad Browser took a start-from-scratch approach and removed all default search options besides DuckDuckGo. While we probably don't want to do the same, I think Tor Browser's search options could still use some housekeeping – e.g.
- Some of the favicons are out of date, inconsistent (e.g. in the case of DuckDuckGo and its corresponding onion site) and pretty crunchy.
- I'm not sure whether "DuckDuckGoOnion" and "BlockchairOnion" are consistent with our naming conventions.
- In some ways, "default" feels like a recommendation. Do we really want to recommend Google, Youtube and Yahoo?
- Does StartPage receive enough usage to warrant being included as a default option?
- The menu could be combined with the onionize switch proposed for about:tor in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41333
Were we to remove a few options we could come up with a user migration plan that adds the currently selected search provider as a custom option.
- [default-search-options](/uploads/200d67018885264361455d2cbca8c040/default-search-options.png)richardrichardhttps://gitlab.torproject.org/tpo/core/arti/-/issues/915Actually check kind() on HsIdParseError, and bubble it upwards for SOCKS error.2023-11-13T13:29:34ZNick MathewsonActually check kind() on HsIdParseError, and bubble it upwards for SOCKS error.From discussion on !1279, @diziet says
> nothing actually calls `.kind()` on an `HsIdParseError`. Instead, there is a tangled mess in `tor-client`. `address.rs` is required (by its surroundings) to produce a `TorAddrError`; that is done...From discussion on !1279, @diziet says
> nothing actually calls `.kind()` on an `HsIdParseError`. Instead, there is a tangled mess in `tor-client`. `address.rs` is required (by its surroundings) to produce a `TorAddrError`; that is done in `err.rs` with a `From` impl which discards the `HsIdParseError`. Then `TorAddrError` doesn't implement `ErrorKind`. Instead, it is just stuffed into an `ErrorDetail::Address` which results in `EK::InvalidStreamTarget`.
>
> I guess this wants a ticket. Certainly it's a can of worms we don't want to block this MR with.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41859Font used for IPs in circuit display is illegible2023-10-10T16:03:27ZcypherpunksFont used for IPs in circuit display is illegibleThe font for IPs in the 'Tor Circuit' display is illegible and to small.
The old one ,TBB >12.5, was good!
Can i change it with a parameter, about:config; without changing the browser fingerprint? Display:1080p desktop monitor, OS=Window...The font for IPs in the 'Tor Circuit' display is illegible and to small.
The old one ,TBB >12.5, was good!
Can i change it with a parameter, about:config; without changing the browser fingerprint? Display:1080p desktop monitor, OS=Windows.
p.s.: I havn't had no difficulty finding the circuit display.henryhenryhttps://gitlab.torproject.org/tpo/core/arti/-/issues/927Allow ChanMgr to expire a specific channel immediately2023-06-27T14:04:55ZSaksham MittalAllow ChanMgr to expire a specific channel immediatelyFrom discussion on IRC, @nickm expressed desire for such a function:
`expire_channels() expires all channels that have been unused for too long; I am thinking instead about the possibility that the user wants a way to say "expire this on...From discussion on IRC, @nickm expressed desire for such a function:
`expire_channels() expires all channels that have been unused for too long; I am thinking instead about the possibility that the user wants a way to say "expire this one channel right now."`Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/network-health/margot/-/issues/8Come up with a plan for our efforts of finding similar relays2024-02-19T17:21:32ZGeorg KoppenCome up with a plan for our efforts of finding similar relaysWe want at some point figure out what similar relays to a relay X or a group of relays XYZ means. We should look at the literature and proposals that showed up in the past to create a plan and follow-up tickets.
https://lists.torproject...We want at some point figure out what similar relays to a relay X or a group of relays XYZ means. We should look at the literature and proposals that showed up in the past to create a plan and follow-up tickets.
https://lists.torproject.org/pipermail/network-health/2021-April/000672.html and phw's work around sybil hunting are good starting points here.jugajugahttps://gitlab.torproject.org/tpo/network-health/team/-/issues/58Move to margot as a helper-scripts replacement2024-01-09T09:14:29ZGeorg KoppenMove to margot as a helper-scripts replacementWe should move away from maintaining our `helper-scripts` and use `margot` instead.We should move away from maintaining our `helper-scripts` and use `margot` instead.jugajugahttps://gitlab.torproject.org/tpo/network-health/margot/-/issues/32Find out why a relay in previous consensuses is not found2024-01-09T09:17:11ZjugaFind out why a relay in previous consensuses is not foundTalking with @gk by IRC we had the case of a relay not being found by margot by nickname that instead appeared in metrics.tpo (does it has 2h delay) and consensus-health.tpo.
It might be the case that the relay just went offline or chan...Talking with @gk by IRC we had the case of a relay not being found by margot by nickname that instead appeared in metrics.tpo (does it has 2h delay) and consensus-health.tpo.
It might be the case that the relay just went offline or changed name and margot couldn't find it cause looking at a more recent live consensus.
I couldn't find the relay either in the local arti storage.jugajugahttps://gitlab.torproject.org/tpo/core/arti/-/issues/946Somehow prevent or discourage people from creating a huge number of independe...2023-11-15T18:58:26ZNick MathewsonSomehow prevent or discourage people from creating a huge number of independent TorClientsThere's an antipattern in our API: it's possible and easy to create a huge number of separate `TorClient` instances that do not share internal state, which all try to bootstrap independently. This needlessly wastes resources.
It's poss...There's an antipattern in our API: it's possible and easy to create a huge number of separate `TorClient` instances that do not share internal state, which all try to bootstrap independently. This needlessly wastes resources.
It's possible that the confusion here is exacerbated by the fact that we would _prefer_ people to create a large number of `TorClient` instances that **do** share internal state, by creating one instance and `Clone`ing it.
Possible solutions include:
* Removing our "shared state" code (see #611), or making it off-by-default.
* Adding more documentation to discourage people from doing this.
* Somehow making it harder to do in the same process in the API.
* Creating a runtime warning if people do this.Arti: RPC Supporthttps://gitlab.torproject.org/tpo/core/arti/-/issues/947Can we speed up our (blocking) CI pipelines at all?2023-07-04T19:03:17ZNick MathewsonCan we speed up our (blocking) CI pipelines at all?Currently a successful pipeline takes around 23 to 50 minutes to complete. That's not so great in terms of interactive development.
Can any of our slower tests be made faster, or safely made "nightly only" or "main only" or something, ...Currently a successful pipeline takes around 23 to 50 minutes to complete. That's not so great in terms of interactive development.
Can any of our slower tests be made faster, or safely made "nightly only" or "main only" or something, so that we can get our MRs checked and merged faster?https://gitlab.torproject.org/tpo/network-health/team/-/issues/311Gather baseline metrics for bandwidth lying detection2024-01-24T11:52:23ZGeorg KoppenGather baseline metrics for bandwidth lying detectionIn order to estimate how we are able to reduce bandwidth lying through the course of our Sponsor 112 project we need to get a baseline or the status quo first. This ticket is tracking that work.In order to estimate how we are able to reduce bandwidth lying through the course of our Sponsor 112 project we need to get a baseline or the status quo first. This ticket is tracking that work.jugajugahttps://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues/40067Deprecation warnings in onionperf2024-01-16T14:25:26ZHiroDeprecation warnings in onionperfOnionperf needs a rewrite of how we are handling some of the data for analysis and visualization, some of the python libraries used have changed and we should check that things keep running before our code gets deprecated.Onionperf needs a rewrite of how we are handling some of the data for analysis and visualization, some of the python libraries used have changed and we should check that things keep running before our code gets deprecated.https://gitlab.torproject.org/tpo/network-health/metrics/onionperf-ansible/-/issues/2Add iptables-nft rules to ansible2024-01-16T14:01:52ZHiroAdd iptables-nft rules to ansibleThere is a part of setting up an onionperf client that we still do manually and this implies adding a redirect between port 443 and 8080 so that tgen can do its measurements. I think we should add this to the recipes.There is a part of setting up an onionperf client that we still do manually and this implies adding a redirect between port 443 and 8080 so that tgen can do its measurements. I think we should add this to the recipes.HiroHirohttps://gitlab.torproject.org/tpo/core/tor/-/issues/40822[warn] Possible replay detected! An INTRODUCE2 cell with the same ENCRYPTED s...2023-08-28T12:28:35ZTimeIsGold[warn] Possible replay detected! An INTRODUCE2 cell with the same ENCRYPTED section was seen 0 seconds ago. Dropping cell.I am running HS using Tor 0.4.7.13 Running on Windows Server and i am using Obfs4 Bridges for my nodes.
i got this messages every day and i don't know what is the problem
`[warn] Possible replay detected! An INTRODUCE2 cell with the sam...I am running HS using Tor 0.4.7.13 Running on Windows Server and i am using Obfs4 Bridges for my nodes.
i got this messages every day and i don't know what is the problem
`[warn] Possible replay detected! An INTRODUCE2 cell with the same ENCRYPTED section was seen 0 seconds ago. Dropping cell.`
`[notice] Your network connection speed appears to have changed. Resetting timeout to 60000ms after 18 timeouts and 1000 buildtimes.`https://gitlab.torproject.org/tpo/core/arti/-/issues/955keymgr: Keystores should be able to store certificates2024-01-09T17:25:23Zgabi-250keymgr: Keystores should be able to store certificates`Keystore`s should be able to store certificates too, not just keys. When we add support for certs we should also rename the `Keystore` trait to `SecretStore` or something`Keystore`s should be able to store certificates too, not just keys. When we add support for certs we should also rename the `Keystore` trait to `SecretStore` or somethingArti: Onion service supportgabi-250gabi-250https://gitlab.torproject.org/tpo/core/rust-pwd-grp/-/issues/1Should Id be split into uid and gid?2023-08-28T12:29:06ZNick MathewsonShould Id be split into uid and gid?It seems like an antipattern to use the same type for two different namespaces; let's split Id into separate uid and gid types?
Edited to add: Actually, maybe it should just an opaque type too, and not an alias for u32?It seems like an antipattern to use the same type for two different namespaces; let's split Id into separate uid and gid types?
Edited to add: Actually, maybe it should just an opaque type too, and not an alias for u32?https://gitlab.torproject.org/tpo/core/arti/-/issues/956Correct behavior when bridge-line addrs differ from bridge descriptor addrs?2023-11-15T19:07:52ZNick MathewsonCorrect behavior when bridge-line addrs differ from bridge descriptor addrs?Our current rule is that we consider a bridge to have every address listed on its bridge line, and every address listed in its descriptor. Is that correct? If so, we should document why.
cc @dgoulet @mikeperry
Found while looking a...Our current rule is that we consider a bridge to have every address listed on its bridge line, and every address listed in its descriptor. Is that correct? If so, we should document why.
cc @dgoulet @mikeperry
Found while looking at !1408 and !1409Arti: Feature parity with the C implementationNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/arti/-/issues/799Bootstrap event sender doesn't always report readiness correctly2023-11-13T15:40:07ZetaBootstrap event sender doesn't always report readiness correctlyIt's unclear whether this is working as intended or not, but it appears that loading a bootstrapped directory successfully from cache won't go and update the bootstrap status reported through `BootstrapEvents` as hitting 100%. The most I...It's unclear whether this is working as intended or not, but it appears that loading a bootstrapped directory successfully from cache won't go and update the bootstrap status reported through `BootstrapEvents` as hitting 100%. The most I managed to get it to was
```
2023-03-28T15:26:53.339788Z DEBUG arti_client::status: 45%: connecting successfully; directory is fetching authority certificates (8/8)
```
Since it never sets `ready_for_traffic` either, consumers depending on the bootstrap event sender might mistakenly think that bootstrap is still ongoing.
You can work around this in client code by calling `TorClient::bootstrap` manually and reporting completion when that function returns, but it'd be nice to have the event sender fixed;
- it seems weird that `TorClient::bootstrap` can return without `ready_for_traffic` also being set;
- and it seems weird that you will only see the 100% bootstrap event state when downloading a fresh directory.
(arti 1.1.2 installed via Cargo on Linux, but the problem also happens embedded on Android)Arti: Feature parity with the C implementationNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/network-health/onbasca/-/issues/135Refactor code from onbrisca to onbasca2024-01-24T11:55:05ZjugaRefactor code from onbrisca to onbascajugajuga