| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the combination of a number of separate commits, many of which
were generated by seddery, and then rebased and squashed.
Cargo.toml
perl -i~ -pe 's{^derive-adhoc}{derive-deftly = "0.10"}' crates/*/Cargo.toml
(not regenerated during rebase)
update Cargo.lock
`cargo fetch` without --locked
(regenerated during rebase)
seddery
git-ls-files | grep '\.rs$' | xargs perl -i~ -pe 's{^use derive_adhoc}{use derive_deftly}'
git-ls-files | grep '\.rs$' | xargs perl -i~ -pe 's{\bdefine_derive_adhoc\b}{define_derive_deftly}g'
git-ls-files | grep '\.rs$' | xargs perl -i~ -pe 's{\bAdhoc\b}{Deftly}g if m{derive}'
git-ls-files | grep '\.rs$' | xargs perl -i~ -pe 's{\#\[derive_adhoc\b}{#[derive_deftly}g'
git-ls-files | grep '\.rs$' | xargs perl -i~ -pe 's{use derive_adhoc}{use derive_deftly}'
git-ls-files | grep '\.rs$' | xargs perl -i~ -pe 's{\bderive_adhoc\b}{derive_deftly_adhoc} if m{use.*deftly}'
git-ls-files | grep '\.rs$' | xargs perl -i~ -pe 's{\bderive_adhoc!}{derive_deftly_adhoc!}'
(not regenerated during rebase)
Manually add `#[derive_deftly_adhoc]` where needed.
seddery
git-ls-files | grep '\.rs$' | xargs perl -i~ -pe 's{\#\[adhoc\b}{#[deftly}g'
git-ls-files | grep '\.rs$' | xargs perl -i~ -pe 's{\bderive_adhoc_template}{derive_deftly_template}'
(not regenerated during rebase)
Manually fix up an import
Manually update some builder attrs
Manually fix up tor_rtmock::time_core
This was missed in my seddery, due to me rebasing the branch and not
redoing the seddery.
|
| | |
|
| |
|
|
| |
Closes #1283
|
| |
|
|
|
| |
Service nicknames are represented by `HsNickname`, so let's
rename `HsClientSpecifier` to `HsClientNickname`.
|
| |
|
|
|
|
|
|
| |
This also removes a TODO regarding adding a `Nickname` type for
representing `HsClientSpecifier` and `HsNickname` (we don't need it if
`Slug`s are non-empty).
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1931#note_2990227
|
| |
|
|
|
|
| |
`ArtiPathComponent`s are really just `Slugs`.
Part of #1193, #1092
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
This addresses a `TODO HSS` about deriving the `KeySpecifier`
implementation for client key specifiers.
Note that we no longer have a key specifier type for intro auth keys
(which are not supported anyway, see #1037).
|
| | |
|
| |
|
|
|
| |
The previous name was ambiguous, and confusable with KeyPathError
(of which it is, basically, a variant).
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
StaticSecret (fmt).
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
StaticSecret.
Previously, when retrieving `KS_hsc_desc_enc` keys (or any other x25519
keys) from the keystore, the keymgr would discard the public part of the
key (SSH private keys contain the public part of the key too). Instead
of discarding the public key and returning just the `StaticSecret`, the
keymgr now returns a `StaticKeypair`. This makes the x25519
`EncodableKey`/`ToEncodableKey` implementation consistent with the
ed25519 one (which retrieves key pairs rather than "unescorted"
secrets).
|
| |
|
|
| |
The secret keys are prefixed with `KS`, not `KP`.
|
| | |
|
| |
|
|
| |
`ArtiPathComponent` is a more generic version of `HsClientSpecifier`.
|
| |
|
|
|
|
| |
The HS `HsClientSpecifier` and `HsClientSecretKeySpecifier` are moved to
`tor-hsclient`. The HS service secret key specifier stubs are moved to
`tor-hsservice`.
|
| |
|
|
|
|
| |
It's not perfectly clear what this error type should be, so let's use
`ConfigBuildError` for now (it makes things easier in `arti-client`, as
we already have an `ErrorDetail` for it).
|
| |
|
|
|
|
|
|
| |
Fixes warning from
cargo -o doc --document-private-items --all-features --workspace
This was evidentlhy overlooked during recent replacement of unescorted
private keys in the code.
|
| |
|
|
|
|
| |
Fortunately, these are all in experimental code.
Closes #798
|
| |
|
|
| |
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| |
|
|
|
| |
It can contain no keys; state this more prominently, and explain what
it represents. Also fix a few typos etc.
|
| | |
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1034#note_2881575
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Provide a more cookied "secret keys for use to connecting to a
particular HS" type, with a builder.
This wants to use config stuff, so oughtn't to be in tor-*crypto.
The individual types remain there.
|
| | |
|
| | |
|
| |
|
