| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
keys from."
This reverts commit 38a6c74c7894dc96b16c9039cacc2a4023977b05.
This also updates some tests to make them compile with the reverted
version of the code.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As with `KeyMgr::insert`, only `KeystoreSelector::Id` and
`KeystoreSelector::Default` are supported.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
We'll need this to implement `Keystore::insert`.
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This refactoring will make more sense later, when we give
`KeyMgr::get` an extra parameter that specifies which keystore to
retrieve the key from.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The concept of a "key bundle" would introduce a lot of complexity while
providing little to no gain.
Some context:
```
Originally, "key bundles" were meant to be the answer to the question
"which keystore should insert place keys in?":
https://gitlab.torproject.org/tpo/core/arti/-/blob/36606a66ddca9abd1595d13c9397bc812bf24cb5/crates/tor-keymgr/src/mgr.rs#L60-69
However, I'm not so sure anymore that "key bundles" are the answer. I
don't think there is any way we can "guess" where a key should go. When
inserting/generating a new key, we should either:
always write to the same, primary key store, OR require the user to be
explicit about which key store the new key should go in (by assigning an
ID to each key store and expecting the user to provide it when
inserting/generating new keys)
I prefer the latter option, because it provides more flexibility, which
we're going to need when implementing the key management CLI (which I
think should allow users to generate keys anywhere they want, e.g. arti
keymgr generate <key type> --keystore hsm ...)
```
For more details, see the discussion on #903.
Closes #903
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The caller uses `KeystoreSelector` to specify which keystore to insert
the new key into (only `KeystoreSelector::Id` and
`KeystoreSelector::Default` are supported for `insert`).
The ability to insert keys in a particular keystore will come in handy
when we implement the key management CLI (the CLI will have an option
for specifying the keystore to access/modify).
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This error will be returned by `KeyMgr` if the caller tries to access a
keystore that does not exist, or if the requested `KeystoreSelector`
cannot be applied.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This will be used by `KeyMgr::insert` after we add an additional
argument to `insert` for specifying the keystore it should be using.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This will enable the `KeyMgr` to look up `Keystore`s by ID (which is
a requirement for disambiguating the semantics of `insert`, which
currently tries to "guess" which keystore it should be using).
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
This makes the code slightly less verbose.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
enabled.
Hiding the underlying value of `enabled` enables us to give it a
different `auto` value depending on whether the `keymgr` feature is
enabled or not (it defaults to `true` if `keymgr` is enabled, and
`false` otherwise).
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The `experimental-api` was only meant to apply to the use of the
unstable `ArtiNativeKeystoreConfig` in the Arti config.
`experimental-api` was _not_ supposed to be used for enabling/disabling
the keystore (that's what the `enabled` flag is for).
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
If the Arti keystore is disabled, we have nothing to initialize the
`KeyMgr` with, so we might as well make it optional.
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Add getters to a couple of config builders
See merge request tpo/core/arti!1425
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
It's a bit of a wart that tor-ptmgr calls these "protocols" and
tor-guardmgr calls these "transport names".
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
BridgeConfigBuilder is Serialize so this isn't making any new API
promises. Ideally we'd have getters like this everywhere.
|
| |\ \ \ \ \ \
| |_|_|_|_|/
|/| | | | |
| | | | | |
| | | | | | |
tor-geoip: Fix a doc warning
See merge request tpo/core/arti!1430
|
| |/ / / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
cargo doc --locked --document-private-items --workspace --all-features
warning: unclosed HTML tag `CountryCode`
--> crates/tor-geoip/src/lib.rs:90:54
|
90 | /// We store these as NonZeroU8 so that an Option<CountryCode> only has to
| ^^^^^^^^^^^^^
|
= note: `#[warn(rustdoc::invalid_html_tags)]` on by default
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
tor-linkspec: impl AsRef<str> for PtTransportName
See merge request tpo/core/arti!1426
|
| | |/ / / / |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Update pwd-grp to 0.1.1 to fix MacOS build etc.
See merge request tpo/core/arti!1427
|
| | |/ / / /
| | | | |
| | | | |
| | | | | |
This also gets rid of a duplicate copy of derive-adhoc.
|
| |\ \ \ \ \
| |_|/ / /
|/| | | |
| | | | |
| | | | | |
Bump requirement to rlimit 0.10.1
See merge request tpo/core/arti!1423
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
There was a bug in 0.10.0 that broke MacOS.
Part of #963.
|
| |\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | | |
geoip: Enable the niche optimization for CountryCode.
See merge request tpo/core/arti!1384
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Since we're going to be using `Option<CountryCode>` all over, let's
save the extra byte.
Sadly this required std::mem::transmute(), which is unsafe, so maybe
we should think twice.
|
| |\ \ \ \ \
| |_|_|_|/
|/| | | |
| | | | |
| | | | | |
Fix a pair of rustdoc links in chanmgr.
See merge request tpo/core/arti!1419
|
| |/ / / / |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
geoip: Allow ASNs as zeros when creating NetDefn
Closes #961
See merge request tpo/core/arti!1417
|
| | | | | |
| | | | |
| | | | |
| | | | | |
to be able to debug it, for instance.
|
| | | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | | |
so that GeoipDb can be created from files including ASNs generated with
tor/scripts/maint/geoip/geoip-db-tool.
Closes #961
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | | |
Print sources for errors in RetryError
Closes #958
See merge request tpo/core/arti!1416
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This would be a break in higher-layer crates which incorproate this
error but:
1. That's just arti-client which hides it behind the detailed errors
cargo feature
2. I'm hoping cargo-semver-checks would spot it, anyway.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The effect is that everywhere a RetryError is used, the error sources
for the contained errors will be Display'd.
In tor-hsclient we no longer need to explicitly wrap things up in
tor_error::Report.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
We're going to require that a RetryError contains things that are
AsRef<dyn Error> and ParseIntError isn't so we need a newtype.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This code came from tor-error. So now tor-error depends on
retry-error.
|
| |/ / /
| | |
| | |
| | | |
We're about to want this.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Update Cargo.lock for d-a versions
See merge request tpo/core/arti!1414
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
!1410 and !1412 had a semantic conflict *in the Cargo lockfile*!
!1410 added a new indirect dependency on derive-adhoc, which is used
in pwd-grp. pwd-grp is still declaring a dependency on d-a 0.6.1.
(This ought to be updated there in due course, but isn't a bug.)
!1412 updated our direct dependency on derive-adhoc to require 0.7.x.
In fact, the breaking change 0.6.x to 0.7.x is minor and we could have
written a more relaxed dependency.But cargo's syntax for that is very
clumsy - here is an example from derive-adhoc iteself:
itertools = ">=0.10.1, <0.12"
Fix this for now in our tree with a `cargo update`, to unbreak main.
|