Arti issueshttps://gitlab.torproject.org/tpo/core/arti/-/issues2024-03-12T16:52:43Zhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1324Decide which decriptors to vote for, for each relay2024-03-12T16:52:43ZGabagaba@torproject.orgDecide which decriptors to vote for, for each relayArti: Directory authorities implementationhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1323Decide which relays to include in vote2024-03-12T16:52:29ZGabagaba@torproject.orgDecide which relays to include in voteArti: Directory authorities implementationhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1322Assign flags according to configuration and measurement2024-03-12T16:45:13ZGabagaba@torproject.orgAssign flags according to configuration and measurementArti: Directory authorities implementationhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1321Port the system for directory authorities to generate votes2024-03-12T16:54:42ZGabagaba@torproject.orgPort the system for directory authorities to generate votesDirectory authorities vote on a consensus view of the network once per hour and thus need a mechanism to generate these votes. This issue we will port the directory authority’s system to generate votes into Arti.Directory authorities vote on a consensus view of the network once per hour and thus need a mechanism to generate these votes. This issue we will port the directory authority’s system to generate votes into Arti.Arti: Directory authorities implementationhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1320Port the ability for directory authorities to manage authority keys2024-03-12T16:39:50ZGabagaba@torproject.orgPort the ability for directory authorities to manage authority keysEach directory authority has a “directory signing key.” Directory authorities use this key to provide a signed list of all the known relays to clients using the network. This means that unless an adversary can control a majority of the d...Each directory authority has a “directory signing key.” Directory authorities use this key to provide a signed list of all the known relays to clients using the network. This means that unless an adversary can control a majority of the directory authorities, they can't trick a client into using other Tor relays.
This Activity includes developing ways for directory authorities to generate and manage signing and identity keys, to store keys in an encrypted way, to consume authority signing keys and certificates, and to alert when keys and certificates are close to expiration.Arti: Directory authorities implementationhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1319Consume a "bad-relay" configuration2024-03-12T16:01:11ZGabagaba@torproject.orgConsume a "bad-relay" configurationArti: Directory authorities implementationhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1318Pin relay keys to prevent key-change attacks2024-03-12T16:03:13ZGabagaba@torproject.orgPin relay keys to prevent key-change attacksArti: Directory authorities implementationhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1317Track relay history to determine fast, stable, guard, hsdir flags2024-03-12T16:02:33ZGabagaba@torproject.orgTrack relay history to determine fast, stable, guard, hsdir flagsArti: Directory authorities implementationhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1316Probe relays for reliability2024-03-12T16:02:16ZGabagaba@torproject.orgProbe relays for reliabilityArti: Directory authorities implementationhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1315Manage list of router descriptors2024-03-12T16:01:36ZGabagaba@torproject.orgManage list of router descriptorsArti: Directory authorities implementationhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1314Receive incoming router descriptors2024-03-12T15:59:40ZGabagaba@torproject.orgReceive incoming router descriptorsArti: Directory authorities implementationhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1313Implement mechanisms for directory authorities to receive, manage, probe, tra...2024-03-12T16:03:45ZGabagaba@torproject.orgImplement mechanisms for directory authorities to receive, manage, probe, track, consume and configure different kind of information from all Tor relays.Port the ability for directory authorities to form a view of network status: In this issue, we will develop in Arti the mechanisms necessary for directory authorities to receive, manage, probe, track, consume, and configure different kin...Port the ability for directory authorities to form a view of network status: In this issue, we will develop in Arti the mechanisms necessary for directory authorities to receive, manage, probe, track, consume, and configure different kinds of information from all Tor relays in order to form the network status view that is distributed to clients. Directory authorities collect information like reliability, bandwidth measurements, and router descriptors. They additionally assign status flags to relays (see O1.8 for status flag implementation details)—all of this needs to be transitioned from C to Arti.Arti: Directory authorities implementationhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1312"intro_payload", "IntroduceHandshakePayload" terminology2024-03-05T18:56:08ZIan Jacksoniwj@torproject.org"intro_payload", "IntroduceHandshakePayload" terminologyIn the spec, this thing isn't given a proper name. It's just described as "ENCRYPTED". IMO the spec ought to be updated to use the word "payload". But torspec!255 will conflict with that, so maybe not right now. The terminology we ha...In the spec, this thing isn't given a proper name. It's just described as "ENCRYPTED". IMO the spec ought to be updated to use the word "payload". But torspec!255 will conflict with that, so maybe not right now. The terminology we have in Arti is "header" vs "payload" which is probably useful.
However, the type `IntroduceHandshakePayload` has the word `Handshake` in it which is redundant.
Also in Arti we have `IntroPayloadExt` and `IntroduceExt`. It's great that we have two types, but they should cross-reference to the names in the spec. But the spec doesn't give things names.
Proposals:
In arti, wait after !2026, then change `IntroduceHandshakePayload` to `IntroducePayload`.
In torspec, wait after torspec!255, then use "payload" for the plaintext of the ENCRYPTED part and consider using the word "header" for the outer part. Then, in arti, add the decided-on terminology to the docs, and also add a proper cross-reference.Ian Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/1310Release rune improvements2024-03-05T13:06:51Zgabi-250Release rune improvementsThe release rune shouldn't publish more than 1 crate per minute(?) to prevent failures like:
```
Caused by:
the remote server responded with an error (status 429 Too Many Requests): You have published too many updates to existing cra...The release rune shouldn't publish more than 1 crate per minute(?) to prevent failures like:
```
Caused by:
the remote server responded with an error (status 429 Too Many Requests): You have published too many updates to existing crates in a short period of time. Please try again after Mon, 04 Mar 2024 16:02:16 GMT or email help@crates.io to have your limit increased.
```gabi-250gabi-250https://gitlab.torproject.org/tpo/core/arti/-/issues/1309RPC: detect attempts to enable it when compiled out?2024-03-04T11:00:32ZIan Jacksoniwj@torproject.orgRPC: detect attempts to enable it when compiled out?When RPC is cargo-configured out, the `rpc` field in the configuration simply vanishes (after !2009). The effect will be an "unused config key" warning.
We should decide if this is the right behaviour. Another option would be to *reje...When RPC is cargo-configured out, the `rpc` field in the configuration simply vanishes (after !2009). The effect will be an "unused config key" warning.
We should decide if this is the right behaviour. Another option would be to *reject* such configs (eg as we do for bridges.)
My initial feeling is that a warning is the right balance of salience.Arti: RPC Supporthttps://gitlab.torproject.org/tpo/core/arti/-/issues/1308Want to forbid path::display2024-03-04T13:54:44ZIan Jacksoniwj@torproject.orgWant to forbid path::displayThis is a footgun. See for example the code before !2012.
We should clippy forbid it and if we actually need it we should have a `.display_lossy` wrapper somewhere.This is a footgun. See for example the code before !2012.
We should clippy forbid it and if we actually need it we should have a `.display_lossy` wrapper somewhere.https://gitlab.torproject.org/tpo/core/arti/-/issues/1306Rendezvous circuit errors in shadow sim2024-02-29T18:14:12Zgabi-250Rendezvous circuit errors in shadow simSee https://gitlab.torproject.org/tpo/core/arti/-/issues/1280#note_3000959
```
2000-01-04T10:25:56Z WARN tor_hsservice::helpers: Problem while accepting rendezvous request: error: Could not connect rendezvous circuit.: Could not establ...See https://gitlab.torproject.org/tpo/core/arti/-/issues/1280#note_3000959
```
2000-01-04T10:25:56Z WARN tor_hsservice::helpers: Problem while accepting rendezvous request: error: Could not connect rendezvous circuit.: Could not establish circuit to rendezvous point: Tried to Establish a circuit to a rendezvous point 2 times, but all attempts failed
Attempt 1: Circuit took too long to build
Attempt 2: Circuit took too long to build
2000-01-04T10:25:56Z DEBUG tor_circmgr::hspool: Unable to build preemptive circuit for onion services: error: Circuit took too long to build
2000-01-04T10:25:56Z DEBUG tor_circmgr::hspool: Unable to build preemptive circuit for onion services: error: Circuit took too long to build
2000-01-04T10:25:57Z DEBUG tor_circmgr::hspool: Unable to build preemptive circuit for onion services: error: Circuit took too long to build
2000-01-04T10:25:57Z WARN tor_circmgr::hspool: Too many preemptive onion service circuits failed; waiting a while.
2000-01-04T10:26:10Z DEBUG tor_proto::circuit::reactor: Circ 5.3915: Received DESTROY cell. Reason: Circuit was destroyed without client truncate [DESTROYED]
2000-01-04T10:26:10Z WARN tor_hsservice::helpers: Problem while accepting rendezvous request: error: Could not connect rendezvous circuit.: Could not establish circuit to rendezvous point: Tried to Establish a circuit to a rendezvous point 2 times, but all attempts failed
Attempt 1: Problem building a circuit, while extending to chosen HS hop: Circuit closed
Attempt 2: Circuit took too long to build
```https://gitlab.torproject.org/tpo/core/arti/-/issues/1305IPTs only established after 3h in shadow sim2024-02-29T18:14:53Zgabi-250IPTs only established after 3h in shadow simSee https://gitlab.torproject.org/tpo/core/arti/-/issues/1280#note_2998748See https://gitlab.torproject.org/tpo/core/arti/-/issues/1280#note_2998748https://gitlab.torproject.org/tpo/core/arti/-/issues/1303Tor Browser needs from Arti2024-02-28T19:05:30ZPier Angelo VendrameTor Browser needs from ArtiWe've been told on IRC that the best place to do requests for the RPC layer is here, so here we are :smile:.
# Lower level stuff
Tor Browser handles different kind of users.
I'd expect the majority of users to just use the process sta...We've been told on IRC that the best place to do requests for the RPC layer is here, so here we are :smile:.
# Lower level stuff
Tor Browser handles different kind of users.
I'd expect the majority of users to just use the process started by the browser.
(In this case, the browser needs to be able to configure the implementation).
But we have a notable exception: Tails.
In this case, we still connect to the control port, but only for stuff like the circuit display.
I'm not sure on how this will be handled.
An idea is that Tails might have only one Arti (Arti Server?) instance, and somehow the browser will be given some credentials to access a restricted set of commands.
For all the other cases, I think running Arti in the browser's parent/main process would work for us.
(Firefox is multi-processed, but we run the JS to interact with little-t-tor in the main process; I think an in-process Arti would also run in the parent process, but I'm not sure).
Firefox has already a bunch of async Rust and it offers facilities to spawn more async stuff (we saw something with ahf in Sweden, maybe it was [this](https://searchfox.org/mozilla-central/source/xpcom/rust/moz_task/src/lib.rs)).
But it isn't a big deal if eventually we'll have to start another process, we already do it for little-t-tor.
The most annoying part is how to connect to Arti's interface.
For the control port, we use a fixed port number (and some users are unhappy about this, because it prevents to have different Tor Browser instances running at the same time).
On Linux we support Unix-sockets, and we pass its path on the command line (but TCP control port is the default also on Linux).
In my opinion, the most important thing for us is to be able to use a single interface.
Eventually we'll consume everything in JS.
I guess an official JS implementation would use long-polling (with `fetch`?) or WebSocket.
`fetch` runs in privileged JS.
[WebSockets work more or less](https://bugzilla.mozilla.org/show_bug.cgi?id=784686), in an [not-very-elegant way](https://searchfox.org/mozilla-central/rev/9cd4ea81e27db6b767f1d9bbbcf47da238dd64fa/services/fxaccounts/FxAccountsPairingChannel.sys.mjs#27-30).
Otherwise, we have access to TCP sockets, but it's a Firefox-only API.
I don't know if we can easily adapt to a Node.js-like API.
I also guess an official JS implementation would target Node.js, be in npm and possibly have some other JS dependencies. We're not very used to pull in stuff from npm (esp. if it has dependencies), but we can work that out.
Otherwise Firefox has well-established mechanisms to pass stuff between JS and Rust that allows you to avoid FFI.
(Spawning an async task, and consuming its result seems to be easy enough. But in the worst case scenario, we could probably use Firefox's event broadcasting mechanisms).
Even passing the JSON strings (in the past you talked about a JSON-based format) without doing any parsing in the Rust side down to JS would probably work for us.
@ma1 knows Firefox internals much better than me and I'm sure he will have a lot of additional information and opinions :slight_smile:.
# Commands we use
Tor Browser's current interactions with the control port live in a couple of files: [`TorProvider.sys.mjs`](https://gitlab.torproject.org/tpo/applications/tor-browser/-/blob/tor-browser-115.8.0esr-13.5-1/toolkit/components/tor-launcher/TorProvider.sys.mjs) and [`TorControlPort.sys.mjs`](https://gitlab.torproject.org/tpo/applications/tor-browser/-/blob/tor-browser-115.8.0esr-13.5-1/toolkit/components/tor-launcher/TorControlPort.sys.mjs) (these links are from the current alpha version, but will be outdated in a few weeks, because we change branch every time there's a new Firefox release).
We've done our best to abstract from the control port, and write a few functions based on our needs from the browser point of view, but it's likely that some functionalities are still influenced by how the control port works.
So, we think that when we'll start integrating Arti, we might update our API, or adapt to it to make the integration easier.
At the moment, the calls we have are:
- a function to write settings
- network enabled/disabled: we use it to start/stop the bootstrap
- bridges: enabled/disabled and bridge lines
- proxy: address (socks4/socks5/https) + authentication (socks5/https)
- ports for fascist firewall
- a function to flush settings
- this might be a piece of legacy from when we wrote in torrc, but we don't need the underlying layer to save settings, we save them in Firefox preferences
- connect/stopBootstrap
- actually implemented with `SETCONF DisableNetwork`
- newnym
- IIRC, even though we use SOCKS isolation, we still do newnym for something related to onion services
- a function to get the configured bridges
- it seems not to be used directly, even though we still query tor about the bridges in its configuration when we create the data for the circuit display
- a function to get the configured pluggable transports
- it's used when initializing the domain fronting for censorship cirumvention. But we could do something else and skip this.
- a function to get the current bootstrap status
- this is likely something we will have to fix a little bit on our end, because we just relay all the infromation tor sends us to the upper layers (the connection page's state machine), but we don't check them (we look for anything that is in the form `key=value` and return a generic object with any key we find)
- a function to get the information about a node, given its id
- IP addresses (v4 and v6 if available; in case of PTs such as Snowflake, we return address from the bridge line rather then the actual IP)
- region code (for regular relays)
- bridge type (vanilla/PT)
- this might fail for C-tor, if the user specified a bridge line without a fingerprint :unamused:
- onion authentication
- add key (optionally, save it in some key storage!)
- remove key
- list known keys
- logs
- we listen to the various ERR/WARN/NOTICE, but a direct way of getting logs would be appreciated :slight_smile:
- a function to get the current bridge
- little-t-tor doesn't actually have this feature at the moment, so we look at every new circuit, and check the first node
- ownership stuff
- the browser takes the ownership of the tor daemon by default, but my preference would be for running it in-process
- we listen to some events
- circuit, stream: we proactively populate some data structures with all the streams and the circuits we see for the circuit display. We basically need to be able to associate the SOCKS credential to the circuits. In some cases (Tails with onion grater) we have some misses in our structures, and we also query the circuits with `GETINFO`. In general, we would like to have a more direct way of getting the data for the circuit display and for the current bridge.
- `status_client`: we use it to update the information in the bootstrap page. The handler shares most of its code with the function to query for the bootstrap status.
- notice/warn/err: we collect these events to show them to the user in `about:preferences`. Having a functions to get all the logs would also work for us for this purpose, but in addition to that, when we see a warn or err we show a "Show logs" button in the connection page.
/cc @richardArti: RPC Supporthttps://gitlab.torproject.org/tpo/core/arti/-/issues/1302maint/fixup-features should skip the examples directory2024-02-28T12:04:44Zgabi-250maint/fixup-features should skip the examples directory`cargo run -p fixup-features Cargo.toml` applies fixups to the examples and `maint` scripts too, which seems undesirable. For example:
```diff
diff --git a/examples/gsoc2023/dns-resolver/Cargo.toml b/examples/gsoc2023/dns-
resolver/Carg...`cargo run -p fixup-features Cargo.toml` applies fixups to the examples and `maint` scripts too, which seems undesirable. For example:
```diff
diff --git a/examples/gsoc2023/dns-resolver/Cargo.toml b/examples/gsoc2023/dns-
resolver/Cargo.toml
index 5b0291039..21ed4ec05 100644
--- a/examples/gsoc2023/dns-resolver/Cargo.toml
+++ b/examples/gsoc2023/dns-resolver/Cargo.toml
@@ -16,3 +16,6 @@ tokio = { version = "1.7", features = ["full"] }
# Useful to print debugging or log messages in async programs
tracing = "0.1"
tracing-subscriber = "0.3.17"
+
+[features]
+full = ["arti-client/full"]
```