The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-03-27T21:47:32Zhttps://gitlab.torproject.org/tpo/onion-services/oniongroove/-/issues/1Oniongroove deployment research2024-03-27T21:47:32ZSilvio RhattoOniongroove deployment researchResearch on all relevant deployment technologies (DevOps) for Onion Services: build a first matrix of technologies, recipes and strategies, incorporating it into the specs (onion-support#40).Research on all relevant deployment technologies (DevOps) for Onion Services: build a first matrix of technologies, recipes and strategies, incorporating it into the specs (onion-support#40).Oniongroove 0.1.0Silvio RhattoSilvio Rhatto2024-05-16https://gitlab.torproject.org/tpo/onion-services/onionprobe/-/issues/64Exit codes should reflect reality2024-03-27T21:44:24ZgeorgExit codes should reflect realityIt seems, onionprobe exits with `0` aka success in any case, while it should probably exit with `> 0` if things go wrong:
```
~ onionprobe -e test.onion; echo $? ...It seems, onionprobe exits with `0` aka success in any case, while it should probably exit with `> 0` if things go wrong:
```
~ onionprobe -e test.onion; echo $?
2022-07-23 12:52:30,170 INFO: Starting Onionprobe version 1.0.0...
2022-07-23 12:52:30,170 INFO: Initializing Tor process...
2022-07-23 12:52:32,145 INFO: Onionprobe is initialized. Hit Ctrl-C to interrupt it.
2022-07-23 12:52:32,145 INFO: Processing test.onion...
2022-07-23 12:52:32,145 ERROR: Invalid onion service address set for test.onion: test.onion
2022-07-23 12:52:32,146 INFO: Error while receiving a control message (SocketClosed): received exception "read of closed file"
2022-07-23 12:52:32,146 INFO: Error while receiving a control message (SocketClosed): received exception "peek of closed file"
2022-07-23 12:52:32,146 INFO: Error while receiving a control message (SocketClosed): received exception "peek of closed file"
2022-07-23 12:52:32,146 INFO: Error while receiving a control message (SocketClosed): received exception "peek of closed file"
2022-07-23 12:52:32,146 INFO: Error while receiving a control message (SocketClosed): received exception "peek of closed file"
2022-07-23 12:52:32,146 INFO: Error while receiving a control message (SocketClosed): received exception "peek of closed file"
0
```Onionprobe 1.2.0Silvio RhattoSilvio Rhatto2024-05-16https://gitlab.torproject.org/tpo/tpa/team/-/issues/41217retire cupani2024-03-26T20:48:47Zanarcatretire cupaniOnce all lagacy Git repositories have been migrated to GitLab (#41215), retire cupani.Once all lagacy Git repositories have been migrated to GitLab (#41215), retire cupani.legacy Git infrastructure retirement (TPA-RFC-36)anarcatanarcat2024-04-24https://gitlab.torproject.org/tpo/core/arti/-/issues/463Client-side backend code for UDP support2023-06-01T20:14:20ZNick MathewsonClient-side backend code for UDP support@dgoulet is interested in writing a client-side backend code to allow programmatic access to the UDP-over-tor protocol as specified in [proposal 339](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/339-udp-over-tor.m...@dgoulet is interested in writing a client-side backend code to allow programmatic access to the UDP-over-tor protocol as specified in [proposal 339](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/339-udp-over-tor.md).
Here are, roughly, the steps you'd need:
* [x] We need to be able to send and receive the new messages. Add parsing and encoding support for the new relay message types in `tor-cell::relay::msg`.
* [ ] We need to be able to tell which exits support UDP. Add parsing support for the new exit policy types for microdescriptors in `tor-netdoc::doc::microdesc`.
* [ ] Here's the core: we need a type corresponding to a datagram stream, that can send and receive UDP messags. Add new `DatagramStream` type for UDP messages in `tor-proto`. They should re-use `tor_proto::stream::raw::{StreamReader,StreamWriter}` under the hood. Probably they should share code with `tor_proto::stream::data`; it would be good to avoid code duplication when possible.
* [ ] We'll need a way to create these streams! Make a new function like `begin_data_stream` on `tor_proto::ClientCirc` to begin a datagram stream.
* [ ] The circuit manager will need to know how to tell which exits it can use for UDP. Add a new variants or new fields in `tor_circmgr::usage::{TargetCircUsage,SupportedCircUsage}` to handle requesting a circuit whose exit needs to support UDP. Maybe the right way to do this is by adding a new boolean and a new set of constructors to `TargetPort`?
* [ ] We'll need a way to make these streams correctly from `arti_client`. That might take the form of a new `connect_udp` and `connect_udp_with_prefs` function pair, similar to the existing `connect` and `connect_with_prefs` in `TorClient`. We'll want to avoid code duplication with those functions.
General notes:
* At every point we should keep test coverage as high as we can!
* The new UDP functions in high-level crates should probably be `#[cfg(feature="experimental-api`)] for now.
* It's probably a good idea to do a separate MR for each stage listed above.
* If any of the existing code doesn't make sense, just ask! It's probably badly documented or badly explained, and we should fix that.Sponsor 101 - Tor VPN Client for AndroidDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/applications/vpn/-/issues/1Define a Threat Model2023-11-24T11:58:28ZMatthew FinkelDefine a Threat ModelAs a reference, [Tor Browser's design document](https://2019.www.torproject.org/projects/torbrowser/design/) describes which threats/attacks are considered in-scope. A VPN (or VPN-like service) has different strengths and weaknesses, the...As a reference, [Tor Browser's design document](https://2019.www.torproject.org/projects/torbrowser/design/) describes which threats/attacks are considered in-scope. A VPN (or VPN-like service) has different strengths and weaknesses, therefore we must define those and evaluate reasonable expectations.
Some initial questions:
- When are the VPN's protections applicable?
- What are reasonable expectaions when the service is disabled?
- What are reasonable expectations when the service is enabled?
- Which use cases can we reasonably support? (e.g., under which circumstances can we fail-closed: device is rebooted or app crashes?)
- What properties does an application's connection gain/have when routed through this service?Sponsor 101 - Tor VPN Client for Androidmicahmicah@torproject.orgmicahmicah@torproject.org2024-01-29https://gitlab.torproject.org/tpo/core/arti/-/issues/1292Add service config for enabling client authorization ("restricted mode")2024-03-05T14:43:22Zgabi-250Add service config for enabling client authorization ("restricted mode")* [ ] Choose a name for the `enabled` option, and decide what values it
should take (`BoolOrAuto` may not be the right type for it
* [ ] Implement the service configuration for configuring "restricted" mode
with static `authorize...* [ ] Choose a name for the `enabled` option, and decide what values it
should take (`BoolOrAuto` may not be the right type for it
* [ ] Implement the service configuration for configuring "restricted" mode
with static `authorized_clients`:
```toml
[onion_service."allium-cepa".restricted_mode]
# TODO: The naming and values of this field are provisional
enabled = auto | on | off
[onion_service."allium-cepa".restricted_mode.authorized_clients.static]
alice = "descriptor:x25519:PU63REQUH4PP464E2Y7AVQ35HBB5DXDH5XEUVUNP3KCPNOXZGIBA"
bob = "descriptor:x25519:B5ZQGTPERMMUDA6VC63LHJUF5IHPOKJMUK26LY2XKSF7VG52AESQ"
# Alternatively, you can specify a directory of authorized clients.
# Each authorized client is represented by an .auth file, as specified
# under CLIENT AUTHORIZATION in tor(1).
#
# [onion_service."allium-cepa".restricted_mode.authorized_clients]
# path = "/etc/allium/authorized_clients"
```Arti: Feature parity with the C implementationgabi-250gabi-250https://gitlab.torproject.org/tpo/core/arti/-/issues/1291Support encoding the public part of client auth keys in C Tor format2024-02-21T15:36:36Zgabi-250Support encoding the public part of client auth keys in C Tor formatArti: Feature parity with the C implementationgabi-250gabi-250https://gitlab.torproject.org/tpo/core/arti/-/issues/1284Clients should identify services by nickname, not hsid2024-02-21T15:36:38Zgabi-250Clients should identify services by nickname, not hsid * [ ] Add a client-side `ClientSideFooHsNickname` type. Pick a name for it
(it should be distinguishable from the service-side `HsNickname`), define
its charset and decide what limit to impose on its length
* [ ] Add a `Clie... * [ ] Add a client-side `ClientSideFooHsNickname` type. Pick a name for it
(it should be distinguishable from the service-side `HsNickname`), define
its charset and decide what limit to impose on its length
* [ ] Add a `ClientSideFooHsNickname` to the client key specifiers, and make
clients error if there is more than one nickname for any given HsIdArti: Feature parity with the C implementationgabi-250gabi-250https://gitlab.torproject.org/tpo/core/arti/-/issues/1281Implement the arti hsc prepare-stealth-mode-key subcommand2024-02-21T15:36:37Zgabi-250Implement the arti hsc prepare-stealth-mode-key subcommandSee the proposal in https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1987#note_2996998
* [ ] Pick a name for the subcommand (`prepare-restricted-mode-key`? `prepare-shielded-mode-key`?)
* [ ] Implement the subcommand:
``...See the proposal in https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1987#note_2996998
* [ ] Pick a name for the subcommand (`prepare-restricted-mode-key`? `prepare-shielded-mode-key`?)
* [ ] Implement the subcommand:
```
arti hsc prepare-stealth-mode-key
--hs[-]nick[name] ... # no default, option has shorter convenience aliases
[ --config arti.toml ] # default is default arti.toml
[ --keystore ... ] # default is `default`; no client nicknames yet
[ --output FOO.auth ] # default is <hs-nickname>.auth, use `-` for stdout
[ --overwrite ] # overwrites any existing output file; default is to refuse
[ --generate=no|yes|if-needed ] # if-needed is the default; otherwise, can error
```
This depends on #1283, #1284 and #1291Arti: Feature parity with the C implementationgabi-250gabi-250https://gitlab.torproject.org/tpo/core/arti/-/issues/1091Make sure that guard selection algorithm handles restriction-based behavior c...2023-11-15T19:00:05ZNick MathewsonMake sure that guard selection algorithm handles restriction-based behavior correctlyWe want to avoid a recurrence of tor#40876 here; to do so, we need to make sure that our guard selection algorithm obeys restrictions in the particular way described in torspec!182, possibly as amended by torspec!184. (We should wait un...We want to avoid a recurrence of tor#40876 here; to do so, we need to make sure that our guard selection algorithm obeys restrictions in the particular way described in torspec!182, possibly as amended by torspec!184. (We should wait until the dust settles on those MRs a bit, of course.)Arti: Feature parity with the C implementationhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1086Stream timeout error kind/message is confusing2023-11-15T19:00:22ZoparaStream timeout error kind/message is confusing### Summary
If a stream times out, the error message seems to imply it's an `ExitTimeout`, but the `kind()` is not `ExitTimeout`.
### What is the expected behavior?
```rust
// arti_client 0.10.2
use arti_client::config::TorClientConfi...### Summary
If a stream times out, the error message seems to imply it's an `ExitTimeout`, but the `kind()` is not `ExitTimeout`.
### What is the expected behavior?
```rust
// arti_client 0.10.2
use arti_client::config::TorClientConfigBuilder;
use arti_client::HasKind;
use arti_client::TorClient;
#[tokio::main]
async fn main() -> arti_client::Result<()> {
let mut builder = TorClientConfigBuilder::default();
builder
.stream_timeouts()
.connect_timeout(std::time::Duration::from_micros(10));
let tor_client = TorClient::create_bootstrapped(builder.build().unwrap()).await?;
let connection = tor_client.connect(("example.com", 80)).await;
if let Err(e) = connection {
println!("Error: {e} - {e:?}");
println!("Error kind(): {}", e.kind());
println!(
"Is ExitTimeout? {}",
matches!(e.kind(), arti_client::ErrorKind::ExitTimeout)
);
}
Ok(())
}
```
Output:
```
Error: tor: operation timed out at exit: Timed out while waiting for answer from exit - Error { detail: ExitTimeout }
Error kind(): operation timed out at exit
Is ExitTimeout? false
```
The error messages all seem to indicate that it's an `ExitTimeout`, but the actual kind is `RemoteNetworkTimeout`. What makes it more confusing is that `ExitTimeout` is an actual kind. So if you see the above error message and then try to match on the error with something like `Err(e) if e.kind() == ExitTimeout`, it will compile but you won't actually catch the error properly.Arti: Feature parity with the C implementationhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1073Use buffered readers around our socks connections2023-11-13T14:53:04ZNick MathewsonUse buffered readers around our socks connectionsWhile working on #786, @beth noticed that we do some tiny reads in our SOCKS implementation, and we should probably add a buffered reader to make those not result in tiny syscalls.
This isn't a huge issue; we can do it whenever. The cod...While working on #786, @beth noticed that we do some tiny reads in our SOCKS implementation, and we should probably add a buffered reader to make those not result in tiny syscalls.
This isn't a huge issue; we can do it whenever. The code to change is in `arti::socks` and `chanmgr::transport::proxied`.Arti: Feature parity with the C implementationhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1040tor-guardmgr wakes arti up every second!2023-11-15T19:00:53ZNick Mathewsontor-guardmgr wakes arti up every second!See https://gitlab.torproject.org/tpo/core/arti/-/issues/1040#note_2950549
I think this is rather poor. People have spent a lot of effort abolishing high-frequency periodic wakeups, because they waste energy (battery). And apparently,...See https://gitlab.torproject.org/tpo/core/arti/-/issues/1040#note_2950549
I think this is rather poor. People have spent a lot of effort abolishing high-frequency periodic wakeups, because they waste energy (battery). And apparently, the work done is sufficiently extensive to make a test unreasonably slow.
(The test `tor_hsclient::state::test::expiry` is using a "giant leap" clock update because otherwise it has to similate every one of these wakeups.
Perhaps `tor_hsservice::timeout_track` could help.
### Old description
cc @gabi-250
Not a huge issue, but state::test::expiry now takes longer to run than any other test in Arti. Perhaps worth fixing if it's easy to do so?
(Found because I use `cargo-nextest`, which runs everything in parallel and displays the times.)Arti: Feature parity with the C implementationIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/1026Could not connect to guard2023-11-13T14:55:35ZLowLandMink543Could not connect to guard### Summary
When build arti from source following direction from README.md, arti builds successfully and compiles but is unable to connect to any
### Steps to reproduce:
1. Clone the Arti branch with hash a05d64d7f1424f140c49a5897f05...### Summary
When build arti from source following direction from README.md, arti builds successfully and compiles but is unable to connect to any
### Steps to reproduce:
1. Clone the Arti branch with hash a05d64d7f1424f140c49a5897f05b26a1eef7c2d, better known as release 1.1.8
2. Build arti create as a release bundle
2. Open a command prompt or PowerShell window
3. Navigate to the release binary
4. Run the binary with the command `arti.exe proxy`
### What is the current bug behavior?
Arti fails to connect to guard nodes
### What is the expected behavior?
Arti will connect to a guard node and then establish the rest of a 3 hop circuit without any significant errors
### Environment
- Cargo Version: 1.69.0
- RustC Version: 1.69.0
- Operating System: Windows 11 Home 22H2 22621.2215
- Install Method: Building from source
### Relevant logs and/or screenshots:
[Arti Trace Log](/uploads/4eeebc7554be0c35cd8cd3f1caa8453f/arti-trace.log)
[Arti Info Log](/uploads/7930d013a1587ff03295937c6e1a63ef/arti-info.log)
### Possible fixes:
Unknown at this timeArti: Feature parity with the C implementationhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1001Connection problems where Arti 'sticks' to a faulty circuit2023-11-15T19:01:19ZetaConnection problems where Arti 'sticks' to a faulty circuitI'm writing this from a train using arti & onionmasq-linux (!) -- and earlier in the journey, I noticed some probably erroneous behaviour:
- I had connected to an `.onion` service successfully, and then my connection changed (due to me ...I'm writing this from a train using arti & onionmasq-linux (!) -- and earlier in the journey, I noticed some probably erroneous behaviour:
- I had connected to an `.onion` service successfully, and then my connection changed (due to me switching wifi networks).
- This presumably meant the old circuit was no longer usable. However, Arti continued to try and use it anyway for new connections to that service (understandable enough).
- The first attempt to do so failed, with "timed out waiting for exit" given as error reason.
- However, subsequent attempts tried to use it also failed, with the same error message -- I could no longer connect, despite having (now) working internet connection more generally.
- Restarting Arti got things to work again.
It would be nice if we had some sort of mechanism to detect 'stuck' circuits and retry by building different circuits, since this behaviour is quite annoying! I wonder whether it's specific to onion services, since I haven't noticed this in any other usecase.Arti: Feature parity with the C implementationhttps://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/925Non-fatal failures to bootstrap don't provide embedding code with any details2023-11-07T12:11:00ZetaNon-fatal failures to bootstrap don't provide embedding code with any detailsAnother weird bootstrapping failure in the wild on Android/onionmasq, this time after uncleanly shutting down an emulator and bringing it back up again:
```
06-26 16:49:11.361 2896 3087 I onionmasq: tor_dirmgr::bootstrap: 2: Looking f...Another weird bootstrapping failure in the wild on Android/onionmasq, this time after uncleanly shutting down an emulator and bringing it back up again:
```
06-26 16:49:11.361 2896 3087 I onionmasq: tor_dirmgr::bootstrap: 2: Looking for a consensus.
06-26 16:49:11.592 2896 3090 I onionmasq: tor_proto::circuit::streammap: Actually got an end cell on a half-closed stream!
06-26 16:49:13.810 2896 3087 I onionmasq: tor_dirmgr::bootstrap: 3: Looking for a consensus.
06-26 16:49:13.871 2896 3090 W onionmasq: tor_dirmgr::bootstrap: Unable to advance downloading staten_attempts=3state=Looking for a consensus.
06-26 16:49:13.873 2896 3090 W onionmasq: tor_dirmgr: Unable to download a usable directory: error: Unable to finish bootstrapping a directory. We will restart in 1s.
06-26 16:49:14.877 2896 3088 I onionmasq: tor_dirmgr::bootstrap: 1: Looking for a consensus.
06-26 16:49:15.112 2896 3088 D onionmasq: onionmasq_mobile::scaffolding: AndroidScaffolding::protect() for fd 110
06-26 16:49:15.898 2896 3088 I onionmasq: tor_dirmgr::bootstrap: 2: Looking for a consensus.
06-26 16:49:18.133 2896 3089 I onionmasq: tor_dirmgr::bootstrap: 3: Looking for a consensus.
06-26 16:49:18.206 2896 3087 W onionmasq: tor_dirmgr::bootstrap: Unable to advance downloading staten_attempts=3state=Looking for a consensus.
06-26 16:49:18.208 2896 3087 W onionmasq: tor_dirmgr: Unable to download a usable directory: error: Unable to finish bootstrapping a directory. We will restart in 1.686s.
06-26 16:49:19.903 2896 3088 I onionmasq: tor_dirmgr::bootstrap: 1: Looking for a consensus.
06-26 16:49:20.952 2896 3089 I onionmasq: tor_dirmgr::bootstrap: 2: Looking for a consensus.
06-26 16:49:23.163 2896 3089 I onionmasq: tor_dirmgr::bootstrap: 3: Looking for a consensus.
06-26 16:49:23.318 2896 3088 W onionmasq: tor_dirmgr::bootstrap: Unable to advance downloading staten_attempts=3state=Looking for a consensus.
06-26 16:49:23.320 2896 3088 W onionmasq: tor_dirmgr: Unable to download a usable directory: error: Unable to finish bootstrapping a directory. We will restart in 4.452s.
06-26 16:49:27.784 2896 3090 I onionmasq: tor_dirmgr::bootstrap: 1: Looking for a consensus.
06-26 16:49:28.870 2896 3090 I onionmasq: tor_dirmgr::bootstrap: 2: Looking for a consensus.
06-26 16:49:30.992 2896 3088 I onionmasq: tor_dirmgr::bootstrap: 3: Looking for a consensus.
06-26 16:49:31.031 2896 3089 W onionmasq: tor_dirmgr::bootstrap: Unable to advance downloading staten_attempts=3state=Looking for a consensus.
06-26 16:49:31.031 2896 3089 W onionmasq: tor_dirmgr: Unable to download a usable directory: error: Unable to finish bootstrapping a directory. We will restart in 9.12s.
06-26 16:49:40.171 2896 3088 I onionmasq: tor_dirmgr::bootstrap: 1: Looking for a consensus.
06-26 16:49:41.212 2896 3090 I onionmasq: tor_dirmgr::bootstrap: 2: Looking for a consensus.
06-26 16:49:43.037 2896 3090 I onionmasq: tor_dirmgr::bootstrap: 3: Looking for a consensus.
06-26 16:49:43.070 2896 3090 W onionmasq: tor_dirmgr::bootstrap: Unable to advance downloading staten_attempts=3state=Looking for a consensus.
06-26 16:49:43.071 2896 3090 W onionmasq: tor_dirmgr: Unable to download a usable directory: error: Unable to finish bootstrapping a directory. We will restart in 23.464s.
06-26 16:50:06.541 2896 3087 I onionmasq: tor_dirmgr::bootstrap: 1: Looking for a consensus.
06-26 16:50:07.578 2896 3089 I onionmasq: tor_dirmgr::bootstrap: 2: Looking for a consensus.
06-26 16:50:10.096 2896 3088 I onionmasq: tor_dirmgr::bootstrap: 3: Looking for a consensus.
06-26 16:50:10.142 2896 3088 W onionmasq: tor_dirmgr::bootstrap: Unable to advance downloading staten_attempts=3state=Looking for a consensus.
06-26 16:50:10.143 2896 3088 W onionmasq: tor_dirmgr: Unable to download a usable directory: error: Unable to finish bootstrapping a directory. We will restart in 50.084s.
```
The principal complaint here is, as the error seems to have been nonfatal, there's no way for the calling code (onionmasq) to know what it is; the bootstrapping code simply loops forever without ever actually returning an error. In this case, it was evidently due to the state directory being corrupted after the unclean shutdown somehow, since clearing the cache instantly fixed it (which would be a bug in its own right, if I had any actual details of the problem).
Would it be possible to provide some mechanism to allow embedding code to have more control or insight into the bootstrap retry process? This is really quite a problem in the Tor VPN use case, since this failure just manifests itself to the user as an indefinite failure to make progress (it does at least set the 'stuck' flag, but we really would prefer the actual error object).
(Yes, I know I can configure it to give up after n attempts, etc -- but then the only error received is an overly generic `CantAdvanceState`).Arti: Feature parity with the C implementationhttps://gitlab.torproject.org/tpo/core/arti/-/issues/898Checking preemptive circuit predictions every 10s2023-11-15T19:07:31ZIan Jacksoniwj@torproject.orgChecking preemptive circuit predictions every 10sI left an idle arti running and when I came back to that terminal I saw a window full of messages like this:
```
2023-06-16T14:38:12.660708Z DEBUG tor_circmgr: Checking preemptive circuit predictions.
2023-06-16T14:38:22.662960Z DEBUG to...I left an idle arti running and when I came back to that terminal I saw a window full of messages like this:
```
2023-06-16T14:38:12.660708Z DEBUG tor_circmgr: Checking preemptive circuit predictions.
2023-06-16T14:38:22.662960Z DEBUG tor_circmgr: Checking preemptive circuit predictions.
2023-06-16T14:38:32.664714Z DEBUG tor_circmgr: Checking preemptive circuit predictions.
```
This is not just noisy (although the noise is indeed poor and if that was the only problem I would suggest to downgrade that to trace). It also means arti is waking up every 10s to do housekeeping, even when there's nothing going on.
This is not desirable. Any polling ought to be considerably less frequent, to conserve energy.Arti: Feature parity with the C implementationhttps://gitlab.torproject.org/tpo/core/arti/-/issues/878broken pt config can create a broken state, preventing from bootstaping after...2023-11-14T16:43:41Ztrinity-1686abroken pt config can create a broken state, preventing from bootstaping after fixing the issueWhen trying to connect to a broken bridge (in this case, PT kind not registered), arti store something in its state directory, which causes it to not try to run PTs on subsequent restarts.
How to reproduce:
- run the snowflake example (...When trying to connect to a broken bridge (in this case, PT kind not registered), arti store something in its state directory, which causes it to not try to run PTs on subsequent restarts.
How to reproduce:
- run the snowflake example (not yet merged, in !1216), it works
- comment one bridge line, break the other, for instance change the PT kind from `snowflake` to `snowflak`
- run the example, it fails as expected
- restore the file
- run the example, it fails again. Interestingly, no line from `tor_ptmgr` ever get logged.
<details><summary>shell logs</summary>
```sh
trinity@zenby ~/d/t/c/a/c/arti-client (pt-snowflake) [SIGINT]> cargo run --example snowflake --features pt-client
Finished dev [unoptimized + debuginfo] target(s) in 0.23s
Running `/home/trinity/dev/tor/core/arti/target/debug/examples/snowflake`
connecting to Tor...
2023-06-07T21:22:31.966319Z INFO tor_dirmgr: Marked consensus usable.
2023-06-07T21:22:31.971166Z INFO tor_dirmgr: Loaded a good directory from cache.
connecting to example.com...
2023-06-07T21:22:32.263816Z INFO tor_ptmgr: Got a request for transport snowflake, which is not currently running. Launching it.
2023-06-07T21:22:32.264050Z INFO tor_ptmgr::ipc: Launching pluggable transport at /sbin/snowflake-pt-client for [PtTransportName("snowflake")]
2023-06-07T21:22:32.268040Z INFO tor_ptmgr::ipc: Transport 'snowflake' uses method PtClientMethod { kind: V5, endpoint: 127.0.0.1:36513 }
2023-06-07T21:22:32.268074Z INFO tor_ptmgr::ipc: PT binary initialisation done
2023-06-07T21:22:32.268150Z INFO tor_ptmgr: Successfully launched PT for snowflake at PtClientMethod { kind: V5, endpoint: 127.0.0.1:36513 }.
2023-06-07T21:22:32.416115Z INFO tor_ptmgr::ipc: [pt snowflake-pt-client] offer created
2023-06-07T21:22:32.993817Z INFO tor_ptmgr::ipc: [pt snowflake-pt-client] broker rendezvous peer received
2023-06-07T21:22:33.192347Z INFO tor_dirmgr: Marked consensus usable.
2023-06-07T21:22:33.196673Z INFO tor_dirmgr: Directory is complete. attempt=1
2023-06-07T21:22:33.345261Z INFO tor_ptmgr::ipc: [pt snowflake-pt-client] connected
2023-06-07T21:22:34.774159Z INFO tor_guardmgr::guard: We have found that guard [192.x.x.x:80 via snowflake 1z…] is usable.
sending request...
reading response...
HTTP/1.1 200 OK
<redacted for conciseness>
trinity@zenby ~/d/t/c/a/c/arti-client (pt-snowflake)> vim examples/snowflake.rs # comment one bridge, change to pt kind to `snowflak` on the other
trinity@zenby ~/d/t/c/a/c/arti-client (pt-snowflake)> cargo run --example snowflake --features pt-client
Compiling arti-client v0.9.1 (/home/trinity/dev/tor/core/arti/crates/arti-client)
warning: unused variable: `bridge_1`
--> crates/arti-client/examples/snowflake.rs:30:9
|
30 | let bridge_1: BridgeConfigBuilder = BRIDGE1_LINE.parse()?;
| ^^^^^^^^ help: if this is intentional, prefix it with an underscore: `_bridge_1`
|
= note: `#[warn(unused_variables)]` on by default
warning: `arti-client` (example "snowflake") generated 1 warning
Finished dev [unoptimized + debuginfo] target(s) in 1.68s
Running `/home/trinity/dev/tor/core/arti/target/debug/examples/snowflake`
connecting to Tor...
2023-06-07T21:22:44.695698Z INFO tor_dirmgr: Marked consensus usable.
2023-06-07T21:22:44.696135Z WARN tor_circmgr: Problem launching a timeout testing circuit: error: Unable to select a guard relay: No usable guards. Rejected 2/2 as down, then 0/0 as pending, then 0/0 as unsuitable to purpose, then 0/0 with filter.
2023-06-07T21:22:44.700623Z INFO tor_dirmgr: Loaded a good directory from cache.
connecting to example.com...
2023-06-07T21:22:45.927859Z INFO tor_dirmgr: Marked consensus usable.
2023-06-07T21:22:45.932017Z INFO tor_dirmgr: Directory is complete. attempt=1
^C⏎
trinity@zenby ~/d/t/c/a/c/arti-client (pt-snowflake)> vim examples/snowflake.rs # restore the file
trinity@zenby ~/d/t/c/a/c/arti-client (pt-snowflake) [SIGINT]> cargo run --example snowflake --features pt-client
Compiling arti-client v0.9.1 (/home/trinity/dev/tor/core/arti/crates/arti-client)
Finished dev [unoptimized + debuginfo] target(s) in 2.77s
Running `/home/trinity/dev/tor/core/arti/target/debug/examples/snowflake`
connecting to Tor...
2023-06-07T21:23:03.295584Z INFO tor_dirmgr: Marked consensus usable.
2023-06-07T21:23:03.297077Z WARN tor_circmgr: Problem launching a timeout testing circuit: error: Unable to select a guard relay: No usable guards. Rejected 2/2 as down, then 0/0 as pending, then 0/0 as unsuitable to purpose, then 0/0 with filter.
2023-06-07T21:23:03.300749Z INFO tor_dirmgr: Loaded a good directory from cache.
connecting to example.com...
2023-06-07T21:23:04.516865Z INFO tor_dirmgr: Marked consensus usable.
2023-06-07T21:23:04.521279Z INFO tor_dirmgr: Directory is complete. attempt=1
^C⏎
trinity@zenby ~/d/t/c/a/c/arti-client (pt-snowflake) [SIGINT]>
```
</details>
loosely related to #177Arti: 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 Mathewson