mirrors/arti.git/crates/tor-hsclient, branch arti-v1.9.0mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.9.02026-01-12T12:44:12Zcargo: Bump all non arti/tor crates2026-01-12T12:44:12ZClara Englercve@cve.cx2026-01-12T12:40:27Zurn:sha1:7e5ed9f4b87e0dcdf6f2f4a8eaa77bbfda5f1b2a
This only includes retry-error which had a few functional additions in
December, thereby rasing the minor version as new features were added to
the public API.
Done using the following:
* Find all non arti, non tor crates.
* `ls -1 crates/ | grep -v "^tor-\|^arti"`
* Exclude the ones without changes.
* `maint/changed_crates -v "arti-v$LAST_VERSION" 2>&1 >/dev/null | grep -i "no change"`
* Look into each with changes.
* In this case only retry-error.
* Bump the minor because it had non-trivial changes.
cargo: Update `arti-*` and `tor-*` to `0.38.0`2026-01-12T12:32:35ZClara Englercve@cve.cx2026-01-12T12:32:35Zurn:sha1:230b0201ea730a633e55c2781611a52c5ec73c28
Done using the following:
```bash
for crate in $(./maint/list_crates | rg '^(tor|arti-)'); do
cargo set-version -p $crate 0.38.0
done
```
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`.
fix: use wallclock timestamps in all push_timed calls2025-12-17T14:48:04ZNihal4218-nihalxkumar@gitlab.torproject.org2025-12-13T14:12:08Zurn:sha1:2e790f071fb070f042d9b6a82caa055eb9d7f783