mirrors/arti.git/crates/arti/src/subcommands/keys.rs, branch mainmirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=main2026-07-13T18:40:57Zarti: subcommands: keys: Fix clippy::for-kv-map2026-07-13T18:40:57Zhjrgrn3874-hjrgrn@gitlab.torproject.org2026-07-13T18:40:57Zurn:sha1:31576659b822a1c65cb279826e4db9432d37739dmultiple crates: Fix clippy warnings2026-07-10T14:50:50Zhjrgrn3874-hjrgrn@gitlab.torproject.org2026-07-10T14:12:44Zurn:sha1:c1a50610f1fd134b16792ba32b30eb03a7e6b666arti: subcommands: keys: Fix compact output2026-06-22T09:36:34Zhjrgrn3874-hjrgrn@gitlab.torproject.org2026-06-22T09:36:34Zurn:sha1:31b4c0f0b82e69e061467fde06119db91527ed51arti: Sort the arti keys list output2026-06-17T21:29:29ZGabriela Moldovangabi@torproject.org2026-06-17T17:30:36Zurn:sha1:c7c9a231aba6cbdc4944c3db2289c5744de83a5e
This will make the output deterministic and enable us to write some
`trycmd` tests in the form of markdown output snippets.
arti: Don't mention entry validity in the help message2026-06-17T16:18:26ZGabriela Moldovangabi@torproject.org2026-06-17T15:41:35Zurn:sha1:ba7f583ec704e153033aa36fa2be99789995235b
This actually applies to unrecognized entries too, and besides, most
users aren't going to think in terms of "valid" vs "invalid" entries, so
it's best to omit this qualifier.
arti: subcommands: keys: Rework output of keys list2026-06-17T16:17:59Zhjrgrn3874-hjrgrn@gitlab.torproject.org2026-06-17T16:17:59Zurn:sha1:e98b4a466fd6db9afd691ee3e9a74d3b4f5f90c9client: Factor out the "running a client" code into an inner typestate2026-05-26T16:57:05ZNick Mathewsonnickm@torproject.org2026-05-20T15:47:40Zurn:sha1:eba1ad0e0ed1dfc4b793ac5646d147aeabe8bc6d
We'll use this to distinguish "not running" from "running",
in order to make it easier to be sure that non-bootstrapping clients
will definitely not try to connect to the network.
keymgr: Remove RawKeystoreEntry2026-05-18T15:07:50ZGabriela Moldovangabi@torproject.org2026-05-18T13:24:46Zurn:sha1:2cfba1e031f5721cda583d95c03223e517c11612
I think this adds unnecessary indirection, and it's a bit confusing to
have two separate keystore entry types (we have `KeystoreEntry` too).
This type exists just to server as a wrapper over the `RawEntryId` of an
unrecognized keystore entry, and the `KeystoreId` of the keystore it was
found in.
This commit folds `RawKeystoreEntry` into `UnrecognizedEntry`, which was
previously a thin wrapper over `RawKeystoreEntry`.
Make all TorClient constructors wrap the TorClient in an Arc.2026-05-13T20:44:51ZNick Mathewsonnickm@torproject.org2026-05-13T13:33:59Zurn:sha1:3cb880f30a37d8757534b9832fccbf00482508a8
This is part of rationalizing the structure of TorClient so we can
refactor startup logic, and so that RPC code can reason about object
identity. See #2469.
keymgr: Move Unrecognized errors out of KeyPathError2026-01-06T15:25:19ZGabriela Moldovangabi@torproject.org2026-01-05T11:07:23Zurn:sha1:0f2b9e7914580e2b0c58936c22f80996781df014
Out of all the variants in `KeyPathError`, `Unrecognized` is the odd one
out, because unlike the others, which are mainly just lower level
parsing errors, `Unrecognized` is a higher level error constructed in
`KeyMgr::describe()`.
`KeyMgr::describe()` now returns an `Option`, because
* the failure to describe a user provided `KeyPath` may or may not be
an error
* previously, `describe()` would only ever return `Ok` or
`Err(KeyPathError::Unrecognized)`, which essentially a binary
result. Also, `describe()` would never return any of the other
`KeyPathError` kinds, which further suggests `Unrecognized`
doesn't belong there
The `Unrecognized` variant still exists, but is now part of
`KeystoreCorruptionError`, (returned from
`KeyMgr::validate_entry_integrity()`).