mirrors/arti.git/crates/tor-hsclient/src, branch arti-v2.0.0mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v2.0.02026-01-27T18:05:36Zmaint/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.
chanmgr: Introduce a ChanMgrConfig struct2026-01-13T18:45:24ZDavid Gouletdgoulet@torproject.org2025-12-16T17:56:06Zurn:sha1:0eb2e1d5ef74e26114a85f4827991c5bea7b20b9
This struct is used to pass configuration parameters to the ChanMgr when
building it.
At the moment, it holds the ChannelConfig and RelayIdentities (feature
gated) which will be used in subsequent commits.
Note that relays do require RelayIdentities to build channels.
Signed-off-by: David Goulet <dgoulet@torproject.org>
chanmgr: Remove KeyMgr from constructor2026-01-13T18:45:24ZDavid Gouletdgoulet@torproject.org2025-12-16T16:21:14Zurn:sha1:604e40a32170682f0dc0f680f38ad2b4de9429d0
We'll rely on a RelayIdentities to pass in the right keys to the ChanMgr
instead of the entire KeyMgr.
Signed-off-by: David Goulet <dgoulet@torproject.org>
hsclient, hsservice: Remove no longer needed conversion functions2026-01-06T15:25:20ZGabriela Moldovangabi@torproject.org2026-01-06T11:47:35Zurn:sha1:a20fb9b96ab7512c23d75f56c23693c288faa5c1keymgr: Use d-d to generate CTorPath<->KeySpecifier conversions2026-01-06T15:25:20ZGabriela Moldovangabi@torproject.org2026-01-06T11:47:24Zurn:sha1:0221cb64c93d4b9767cb78346e6d2f9d505efba6keymgr: 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.
keymgr: Push error handling into the from_ctor_path() functions2026-01-06T15:25:19ZGabriela Moldovangabi@torproject.org2026-01-05T12:24:38Zurn:sha1:4b817a9450566d7b81b77ba6f4c7c16adffe6d5dkeymgr: Specify ctor conversion functions as module2026-01-06T15:25:19ZGabriela Moldovangabi@torproject.org2025-12-23T20:05:29Zurn:sha1:ab4418cb841f7634ffe9827dbf23737cdc068a91
This is similar to `#[serde(with = "...")]`, and feels a bit nicer than
having to specify two separate functions for the conversions (because
with two separate functions, you *can* technically only specify one of
them, which shouldn't be allowed).
keymgr: Extend KeySpecifier macro to support CTorPath conversions2026-01-06T15:25:19ZGabriela Moldovangabi@torproject.org2025-12-15T15:18:38Zurn:sha1:11684e062a84bc191843e4111755ea248e5b22af
This enables us to implement `KeyMgr::describe()`, which relies on the
ability to extract the key specifier of the key from its `KeyPath`.