mirrors/arti.git/crates/tor-keymgr/src/lib.rs, branch arti-v2.4.0mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v2.4.02026-05-18T15:07:50Zkeymgr: 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`.
keymgr: Add a new trait for cert specifier patterns2026-03-12T14:56:35ZGabriela Moldovangabi@torproject.org2026-02-18T18:21:32Zurn:sha1:852c7b5da0dbcc2e889a1cd42dc799fe7e7fbb21
These are significantly different from `KeySpecifierPattern`s, so it's
best to have a separate trait.
keymgr: Add more tests for cert ArtiPath construction (fmt)2026-03-05T11:53:19ZGabriela Moldovangabi@torproject.org2026-02-26T16:44:59Zurn:sha1:ec8946dab939d614269f28a3b0c63243ec474737keymgr: Support having multiple denotator groups within an ArtiPath2026-03-05T11:53:19ZGabriela Moldovangabi@torproject.org2026-02-26T16:06:02Zurn:sha1:412c0f70bd3c2724cb57c871233e89ae3a93e0c4
This will enable us to parse certificate paths that consist of the
`ArtiPath` of the subject key, followed by the denotator group of the
certificate.
Allow clippy::collapsible_if to trigger2026-02-16T15:22:24ZGabriela Moldovangabi@torproject.org2026-02-09T11:49:02Zurn:sha1:ade1d59e8e44c93b6ee447b72a2948a9652ec44e
`clippy::collapsible_if` started triggering after bumping the MSRV to
1.88.
Since this triggers from a lot of places, and since there even are a
couple of instances where we explicitly allow `clippy::collapsible_ifs`,
I've opened #2342 for deciding what to do about it.
maint/add_warning: Run script to add new warning2026-01-27T18:05:36ZGabriela Moldovangabi@torproject.org2026-01-27T18:05:36Zurn:sha1:a98faf72eb06b47700faeeac5a8a0dd0fc29b584
This adds the lint to all our crates.
keymgr: Add a CTorKeySpecifier trait (fmt)2026-01-06T15:25:20ZGabriela Moldovangabi@torproject.org2026-01-06T10:54:03Zurn:sha1:9414042270b1f61ab2e704bac98fd0a60098ef61keymgr: Add a CTorKeySpecifier trait2026-01-06T15:25:20ZGabriela Moldovangabi@torproject.org2026-01-06T10:53:23Zurn:sha1:f39c10d445e0c5b4bdfbc92f09abc8a55f24e16ekeymgr: Make CTorPath more like the client/service specifiers (fmt)2026-01-06T15:25:20ZGabriela Moldovangabi@torproject.org2026-01-06T10:45:17Zurn:sha1:cf0267f8e4b6182448963949cfeebe35f949eb0fkeymgr: Make CTorPath more like the client/service specifiers2026-01-06T15:25:20ZGabriela Moldovangabi@torproject.org2026-01-06T10:43:41Zurn:sha1:71178a54dc8c3c3ed75b14ecbca3197feb22accc
This will make it easier to see the correspondence between CTorPaths
and the HS client/service key specifiers.
Initially, I was hoping this would make it easier to write a d-d macro
that automatically derives a `CTorPath` variant (e.g.
`HsClientDescEncKeypair`) from the KeySpecifier type name
(`HsClientDescEncKeypairSpecifier`), but alas, I don't think d-d can
"chop off" name suffixes ("Specifier", in this case).
`from_ctor_path()`/`ctor_path()` implementations for converting
`CTorPath`s to and from key specifiers.