| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
| |
This brings in the changes from #936.
|
| |
|
|
|
|
|
|
| |
According to the `ErrorKind` lumping guidelines, `KeystoreFsPermissions`
should be lumped with `FsPermissions`: they represent the same type
of error, and their "location" is the same ("Host").
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1315#note_2916455
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
This function isn't actually needed (it's not the responsibility of
`KeyType` to encode keys).
This commit also rewrites `ArtiNativeKeystore::insert` to use the new
`as_ssh_keypair_data` function instead of `to_ssh_format`.
|
| |
|
|
|
|
|
|
|
|
|
| |
The `EncodableKey::to_bytes` function didn't make much sense, because
not all keys have a canonical byte representation.
This commit replaces `EncodableKey::to_bytes` with
`EncodableKey::as_ssh_keypair_data`. In the future, `EncodableKey` will
grow functions for encoding keys in other storage formats too.
Closes #965
|
| | |
|
| |\
| |
| |
| |
| | |
Vesion bumps for 1.1.7.
See merge request tpo/core/arti!1458
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
These crates are at version 0.x.y, so we don't need to distinguish
new-feature changes from other changes:
```
tor-basic-utils
fs-mistrust
tor-error
tor-geoip
tor-checkable
tor-linkspec
tor-netdoc
tor-netdir
tor-persist
tor-ptmgr
tor-hsservice
```
This crate has a breaking change, but only when the semver-breaking
feature `experimental-api` is enabled:
```
tor-config
```
This crate is at version 1.x.y, but has no new public APIs, and
therefore does not need a minor version bump:
```
arti
```
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
These crates had first-order breaking changes:
```
retry-error
tor-keymgr
tor-proto
tor-hsclient
tor-rtmock
```
Additionally, these broke because they re-exposed RetryError:
```
tor-circmgr
```
Additionally, these broke because they may re-expose something from
tor-proto:
```
arti-client
tor-chanmgr
tor-dirclient
tor-dirmgr
tor-guardmgr
```
Additionally, these broke for other fiddly reasons:
`tor-ptmgr` implements traits from tor-chanmgr, which has a breaking
change above.
`arti-hyper` exposes types from arti-client in its API.
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This will enable us to test the parts of `ArtiNativeKeystore::insert`
that _are_ implemented (such as the part where it creates the missing
directories).
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
Keymgr api updates minor fixes
See merge request gabi-250/arti!1
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Trying to use a keystore that doesn't exist is `bad_api_usage!`.
|
| | |
| |
| |
| |
| |
| | |
This also removes the corresponding
`KeyMgrError::UnsupportedKeystoreSelector` error, because it's not
needed anymore.
|
| | |
| |
| |
| | |
keys from." (fmt)
|
| |/
|
|
|
|
|
|
|
| |
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.
|
