| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
This commit is intentionally misindented to make reviewing the diff a
bit easier.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In a certificate's `ArtiPath`, the `ArtiPath` of the subject key is now
separated from the certificate denotators by `@`. This will enable us to
derive the subject key `ArtiPath` from the `ArtiPath` of its
certificate.
In practice, this change is a no-op for the relay implementation,
because none of our certificates have certificate denotators. For
instance, the `ArtiPath` of the for the `KP_relaysign_ed` certificate
(`KP_relaysign_ed` signed with `KS_relayid_ed`) is of the form
`relay/relaysign_ed+<valid_until>` (the only denotators here are the
denotators of the subject key).
It's important to note that the certifying key is not encoded in the
`ArtiPath` of the certificate. The implication is that if we'll ever
need to have multiple certs for the same subject key, signed with
different with different certifying keys, those certificates will be
distinguished by their certificate denotator group. So if we ever need a
second certificate for `KP_relaysign_ed`, certified with something other
than `KP_relaysign_ed`, it will need to be of the form
`relay/relaysign_ed+<valid_until>@<CERT_DENOS>`, where `<CERT_DENOS>`
is a list of `+`-separated certificate denotators.
Closes #2377
|
| | |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
This introduces the concept of a "denotator group", and new syntax for
separating denotator groups within an ArtiPath.
The implementation will follow in a separate commit.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
`KeyCertificateSpecifiers` have an `ArtiPath`, so it's only natural to
retrieve it via this new `KeySpecifier` implementation.
This replaces the old, ad-hoc `ArtiPath` building from the `KeyMgr`
implementation: IMO, the `KeyMgr` impl is the wrong place to build these
`ArtiPath`s (ideally they should remain opaque to the `KeyMgr`).
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Resolves a clippy warning.
|
| | | |
|
| | |
| |
| |
| | |
Resolves a clippy warning.
|
| | | |
|
| | |
| |
| |
| | |
As suggested by clippy
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This doesn't really need to be macro-generated, because these impls only
differ in the `KeystoreId`.
The code is intentionally misindented to make reviewing the diff a bit
easier. A future commit will reformat it all.
|
| | | |
|
| |/
|
|
|
| |
I am about to remove this macro altogether and simplify the keystore
impls, so I am preemptively moving this into a separate function.
|
| |
|
|
|
|
|
|
|
| |
Done using:
```
for crate in $(./maint/list_crates | rg '^(tor|arti-)'); do
cargo set-version -p $crate 0.40.0
done
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The non-{arti-,tor-} crates are:
```
./maint/list-crates | rg -v '^(tor|arti)'
oneshot-fused-workaround
slotmap-careful
test-temp-dir
fslock-guard
hashx
equix
caret
fs-mistrust
safelog
retry-error
futures-copy
```
Because this release bumps the MSRV, I am bumping the minor version of all of
them.
MINOR="
oneshot-fused-workaround
slotmap-careful
test-temp-dir
fslock-guard
hashx
equix
caret
fs-mistrust
safelog
retry-error
futures-copy
"
for crate in $MINOR; do
cargo set-version --bump minor -p $crate;
done
```
|
| |
|
|
|
| |
As with previous modules, I've left some thing less conformant
with our "standard" APIs in order to keep backward compat (for now).
|
| |
|
|
| |
Closes #2360
|
| |
|
|
|
|
|
|
|
| |
`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.
|
| |
|
|
|
|
|
| |
As agreed at our last team meeting.
See
https://gitlab.torproject.org/tpo/core/arti/#minimum-supported-rust-version
|
| |
|
|
|
|
|
|
|
|
| |
Done via:
```
for crate in $(./maint/list-crates | rg '^(tor|arti-)'); do
cargo set-version -p $crate 0.39.0
done
```
|
| |\
| |
| |
| |
| | |
fix(minver): Update paste dependency to be minver compatible
See merge request tpo/core/arti!3610
|
| | | |
|
| |/
|
|
| |
This adds the lint to all our crates.
|
| |
|
|
|
| |
Fix the conflict in tor-netdoc/semver.md by hand, including the new
entries already landed since v1.9.0.
|
| |
|
|
|
|
|
|
|
| |
Done using the following:
```bash
for crate in $(./maint/list_crates | rg '^(tor|arti-)'); do
cargo set-version -p $crate 0.38.0
done
```
|
| |
|
|
| |
Fixes a clippy warning.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
