aboutsummaryrefslogtreecommitdiff
path: root/crates/tor-keymgr/src
Commit message (Collapse)AuthorAgeFilesLines
...
* tor-keymgr: Implement KeyPath::matches for CTorPaths.Gabriela Moldovan2024-10-082-14/+37
| | | | | | | `KeyPath::matches` now returns a boolean (because we can't return a matching "range" for `CTorPaths`, because unlike ArtiPaths, they're not represented as `String`s, and do not have variable parts that need to be captured).
* tor-keymgr: Reimagine CTorPath as an enum.Gabriela Moldovan2024-10-083-14/+80
| | | | | | | | | | | | | | | | | | | | | | C Tor's client restricted discovery keys don't have the service hsid encoded in the filename (the hsid of the service each key is associated with is encoded in contents of the key file). This means that given a key specifier like `HsClientDescEncKeypairSpecifier` (which is a wrapper over an HsId), we can't actually compute the relative path of the key in its `KeySpecifier::ctor_path()` implementation. To do so we would need to access the keystore to figure out which path contains the requested HsId, which we can't (and shouldn't!) do from within the `KeySpecifier` impl. This suggests the String newtype (representing a relative path) we previously had is not a good abstraction for `CTorPath`s. Moreover, `CTorPath` are static (they don't have dynamic components like `ArtiPath`), so it makes more sense to model `CTorPath` as an enum. The new `CTorPath::ClientHsDescEncKey(HsId)` variant will be used to instruct the C Tor client keystore to find the file that contains the specified `HsId`, while the `Service` variant will be used for hidden service keys.
* tor-keymgr: Add configuration for C Tor service keystores.Gabriela Moldovan2024-10-081-3/+201
|
* tor-keymgr: Return an error if the keystore IDs are not unique.Gabriela Moldovan2024-10-081-0/+8
| | | | | | | | The `KeyMgrBuilder` now returns an error if the configured keystores don't have pairwise unique IDs. This is needed because some keymgr operations take a `KeystoreSelector` specifying the ID of the keystore the operation should be performed on, and assume that the keystore ID uniquely identifies a single keystore.
* tor-keymgr: Move config/arti.rs to config.rsGabriela Moldovan2024-10-082-116/+113
| | | | | | | | The config will soon contain secondary C Tor keystore configuration too, so the `arti` namespacing is about to stop making sense. I recommend reviewing this commit using `git diff --color-moved=zebra --ignore-space-change`
* tor-hsservice: Move HsNickname to tor-persist.Gabriela Moldovan2024-10-081-0/+3
| | | | | | | We are about to need this in `tor-keymgr`, where we're about to add a config for C Tor service keystores (the C Tor keystore config will have an associated `HsNickname` that specifies which of the arti hidden services it's supposed to be used with).
* tor-keymgr: Linkify the ArtiKeystoreKind docs.Gabriela Moldovan2024-10-031-2/+2
|
* Upgrade to derive_more version 1.0.0Nick Mathewson2024-09-251-3/+5
| | | | | | The `derive_more` crate broke backward compatibility with this version, so this change involved quite a few manual fixups. With luck, they'll keep compatibility for some while in the future.
* tor-keymgr: Rename keystore.type to keystore.kind.Gabriela Moldovan2024-09-231-2/+2
| | | | | In !2394 we settled on `kind`. This updates the error messages to reference the new field name.
* tor-keymgr: Move keystore config under keystore.primary.Gabriela Moldovan2024-09-231-3/+16
| | | | | The keystore settings only configure the *primary* keystore, so they should be under `keystore.primary`.
* arti: Reinstate the keystore.enabled option.Gabriela Moldovan2024-09-231-51/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a follow-up from !2394 I want to keep the `keystore.enabled` option, because I'm planning on extending `ArtiKeystoreConfig` to support configuring secondary keystores too (currently, the only supported setting is `keystore.kind`, which configures the primary keystore). `keystore.enabled` will disable keystore use altogether (i.e. both primary and secondary). Currently, we only support configuring the "primary" (previously known as "default") keystore, which can be either "native" (the on-disk Arti keystore), or "ephemeral" (an in-memory keystore). To implement #858, we will need to support configuring additional keystores too, so we will need to move to a config of the form ```toml [storage.keystore] # Whether the keystore is enabled. #enabled = "auto" # Configure the primary keystore. [storage.keystore.primary] # The type of primary keystore to use kind = "auto" | "native" | "ephemeral" # Optionally configure C Tor keystores for arti to use. # # Note: The keystores listed here are read-only (keys are only # ever written to the primary keystore, configured in # `storage.keystore.primary`). [[storage.keystore.ctor]] # If the `kind` is `service`, this should be set to the `HiddenServiceDirectory` # of your hidden service. Arti will read `HiddenServiceDirectory/hostname` # and `HiddenServiceDirectory/private_key`. (Note: if your service is running # in restricted discovery mode, you must set the # `[[onion_services."<the nickname of your svc>".restricted_discovery.key_dirs]]` # to `HiddenServiceDirectory/client_keys` # # If the `kind` is `client`, this should be set to `ClientOnionAuthDir` of # your client. If Arti is configured to run as a client (i.e. if it runs in SOCKS # proxy mode), it will read the client restricted discovery keys from this path. path = "/foo/bar" # The type of keystore `path` should be interpreted as kind = "client" | "service" ``` This moves the current keystore settings to `storage.keystore.primary` in preparation for that change.
* tor-keymgr: Add back ArtiKeystoreConfig::is_enabled().Gabriela Moldovan2024-09-231-0/+7
| | | | | I am adding `is_enabled()` back because I plan to un-deprecate the `enabled` setting.
* tor-keymgr: Rename the primary keystore for clarity.Gabriela Moldovan2024-09-233-26/+26
| | | | | | | | | | Previously, arti's primary keystore was referred to as its "default" keystore. However, "default" is inaccurate here: there is no way to meaningfully override this "default" (the "default" store acts as the main keystore). Throughout the codebase, we query all keystores for keys (including the secondary ones), but only ever write to the default/primary keystore. This is OK for now, because it enables us to have one mutable keystore, and multiple secondary, read-only stores.
* tor-keymgr: added dummy implementation of ArtiEphemeralKeyStoreMorgan2024-09-201-0/+14
|
* tor-keymgr: added support for specifying keystore kind to ArtiKeystoreConfigMorgan2024-09-201-16/+80
|
* tor-keymgr: renamed ArtiNativeKeystoreConfig to ArtiKeystoreConfigMorgan2024-09-201-5/+5
|
* tor-keymgr: Set KeySpecifier deftly exported struct non_exhaustiveDavid Goulet2024-09-181-0/+1
| | | | Signed-off-by: David Goulet <[email protected]>
* tor-keymgr: put ephemeral keystore behind experimental featureSteven Engler2024-09-172-1/+9
| | | | Feature is named "ephemeral-keystore".
* tor-keymgr: add disk-related docs to `ArtiEphemeralKeystore`Steven Engler2024-09-171-0/+6
|
* tor-keymgr: add an overwrite flag to KeyMgr::insert()Morgan2024-09-101-8/+47
|
* rename get_keypair_specifier() to keypair_specifier()Adam Joseph F0B74D717CDE8412A3E0D4D5F29AC8080DA8E1E02024-09-094-8/+8
| | | | https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2393#note_3073480
* tor_keymgr: teach the KeyStore how to satisfy public key requests using a ↵Adam Joseph F0B74D717CDE8412A3E0D4D5F29AC8080DA8E1E02024-09-091-1/+9
| | | | | | | | | | | | | | | keypair Now that: - KeySpecifier::get_keypair_specifier() can be used to convert the KeySpecifier for a public key into the KeySpecifier for its secret key - ToEncodableKey<Key=PublicKey> has a "type level pointer" to ToEncodableKey<Key=KeyPair> We can use these two features together to automatically satisfy any request to get a public key using the corresponding secret key (if available).
* tor_key_forge::traits::ToEncodableKey: add KeyPair associated typeAdam Joseph F0B74D717CDE8412A3E0D4D5F29AC8080DA8E1E02024-09-091-0/+2
| | | | | | | | | | This comment adds a second associated type `KeyPair` to ToEncodableKey. For a `ToEncodableKey` which represents a (secret) KeyPair, this type is Self. For a `ToEncodableKey` which represents a public key, this is the `ToEncodableKey` whose `Key` is the pair of which this is the public part. This is essentially a "type level pointer" from the ToEncodableKey for a public key to the ToEncodableKey for its secret key.
* tor_keymgr: add get_keypair_specifier() to KeySpecifier, and derive itAdam Joseph F0B74D717CDE8412A3E0D4D5F29AC8080DA8E1E02024-09-094-0/+32
| | | | | | | This commit adds a new method `get_keypair_specifier()` to `KeySpecifier`. This method is used to indicate when one KeySpecifier (e.g. `KP_hs_id`) is the public part of another keypair (e.g. `KS_hs_id`). It will return the containing keypair in this case, and `None` otherwise.
* tor_hsservice: add `impl From<&FooPublicKeySpecifier> for ↵Adam Joseph F0B74D717CDE8412A3E0D4D5F29AC8080DA8E1E02024-09-091-0/+6
| | | | | | | | | | | | | FooKeypairSpecifier` instances This adds the following trivial `From` instances: - tor_hsservice: impl From<&HsIdPublicKeySpecifier> for HsIdKeypairSpecifier - tor_hsservice: impl From<&BlindIdPublicKeySpecifier> for BlindIdKeypairSpecifier - tor_hscrypto::pk: impl From<HsBlindIdKeypair> for HsBlindIdKey - tor_llcrypto::pk::ed25519: impl From<ExpandedKeypair> for PublicKey - tor_keymgr::mgr: impl From<TestKey> for TestPublicKey - tor::hscrypto::pk: impl From<HsIdKeypair> for HsIdKey
* Rename tor-keys crate to tor-key-forgeDavid Goulet2024-09-049-15/+15
| | | | Signed-off-by: David Goulet <[email protected]>
* tor-keymgr: Use tor-keys crate and remove dead codeDavid Goulet2024-09-0411-841/+50
| | | | | | | | | | | Everything copied in the previous commits to tor-keys is now removed and tor-keys crate is used accross the code. Minor changes to tor-keys to accomodate this change. Part of #1137 Signed-off-by: David Goulet <[email protected]>
* tor-keys: Automatically implement keymgr traitDavid Goulet2024-09-042-33/+5
| | | | | | | | | | | | | | | | | The derive ed25519 keypair macro now implements the keymgr trait so the key wrapper can now be used with a keystore without needing to specify it in the tor-keymgr crate. For this to work, a slight change to the KeygenRng trait was needed as in to expect the CryptoRngCore trait which is what ed25519-dalek requires. And also, the removal of the Sealed trait since now it is accepted to implement these traits outside tor-keymgr. Fixes #1137 Signed-off-by: David Goulet <[email protected]>
* Fix typosDimitris Apostolou2024-09-032-4/+4
|
* tor-keymgr: Remove unnecessary io::Error handling.Gabriela Moldovan2024-08-081-6/+0
| | | | | | `fs-mistrust` always maps `io::ErrorKind::NotFound` to `fs_mistrust::Error::NotFound`, so these `io::ErrorKind::NotFound` branches were unreachable.
* tor-keymgr: Use CheckedDir::metadata() instead of PathBuf::try_exists().Gabriela Moldovan2024-08-082-12/+48
| | | | | We now use `CheckedDir::metadata()` to check if the path exists and is of the correct type.
* tor-keymgr: Use the new relative path wrapper (fmt).Gabriela Moldovan2024-08-081-9/+15
|
* tor-keymgr: Use the new relative path wrapper.Gabriela Moldovan2024-08-082-43/+24
|
* tor-keymgr: Add new rel_path module with helpers for handling relative paths.Gabriela Moldovan2024-08-082-0/+77
|
* tor-keymgr: Add private RelKeyPath type for relative paths.Gabriela Moldovan2024-08-081-10/+22
| | | | | | | | This makes `rel_path` return a `RelKeyPath` instead of a `PathBuf` to prevent the accidental misuse of relative key paths (like the one from #1492). Closes #1494
* tor-keymgr: Use Path::try_exists() instead of Path::exists().Gabriela Moldovan2024-07-301-3/+10
|
* Fix new "clippy::needless-maybe-sized" warning on nightlyNick Mathewson2024-07-281-1/+1
| | | | | This warning complains when we say `where T: SomeTrait + ?Sized` when `SomeTrait` is inherently Sized.
* tor-keymgr: Fix ArtiNativeKeystore::contains() bug.Gabriela Moldovan2024-07-171-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a bug in `ArtiNativeKeystore`'s `Keystore::contains()` implementation: previously, it called Path::exists() on the relative path (built by concatenating the key specifier and the extension), so unless your current directory happened to be the root of the keystore, `contains()` would always return `false`. `KeyMgr::generate` uses `Keystore::contains()` under the hood, so it was affected by this bug too: if called `overwrite = false`, it would misbehave and overwrite any existing keys. Internally, we call `KeyMgr::generate` in a couple of places: * `tor-hsservice/src/lib.rs`, to generate the `hsid` if it doesn't already exist. This callsite is not affected by the bug, because `KeyMgr::generate` is only called if `KeyMgr::get` returns `None` * `tor-hsservice/src/ipt_mgr.rs`, to generate `KS_hss_ntor` and `KS_hs_ipt_sid` keys for intro point establishment. This callsite is also not affected (because it too calls `get()` before attempting to `generate()`) The bug affects any downstream users that use `KeyMgr::generate` with a key manager backed by `ArtiNativeKeystore`. ------ `KeyMgr::get_or_generate` is not affected, even though it calls `Keymgr::generate` (it performs a separate extra check before calling `generate()`). (Both suffer from a known TOCTOU race, but that's a separate matter.) As an aside, I'd like to somehow unify `KeyMgr::get_or_generate` and `KeyMgr::get` (I've had some attempts in the past but ended up abandoning them because the result was more unergonomic than the existing APIs). Part of #1492
* tor-keymgr: Rename function to clarify it returns a relative path (fmt).Gabriela Moldovan2024-07-171-1/+2
|
* tor-keymgr: Rename function to clarify it returns a relative path.Gabriela Moldovan2024-07-171-15/+15
|
* tor-keymgr: Add test for ArtiNativeKeystore::contains.Gabriela Moldovan2024-07-171-0/+2
| | | | | | | | | | This new assertion fails, because the implementation of `ArtiNativeKeystore::contains()` is buggy: it calls Path::exists() on the relative path built by concatenating the key specifier and the extension (so unless your current directory happens to be the root of the keystore, contains() is always going to return false). Part of #1492
* tor-keymgr: Correct message for mistrust errorIan Jackson2024-07-102-4/+4
|
* tor-keymgr: Use collect_tuple in TimePeriod::from_slug (fmt).Gabriela Moldovan2024-07-081-1/+2
|
* tor-keymgr: Use collect_tuple in TimePeriod::from_slug.Gabriela Moldovan2024-07-081-5/+5
| | | | | | The previous approach was buggy: collecting the parts of the time period into an `ArrayVec` of length 3 would panic if the number of parts was greater than 3.
* tor-keymgr: Test that parsing a TimePeriod with too many parts doesn't panic.Gabriela Moldovan2024-07-081-0/+1
| | | | | | | | This test currently fails because we have a bug in `TimePeriod`'s `from_slug()` implementation. `TimePeriod::from_slug()` splits the slug by `_`, and attempts to collect the parts into an `ArrayVec` of length 3. This is wrong, because the `collect()` will panic if there are more than 3 parts.
* Change deftly syntax to post 0.12.1 versionIan Jackson2024-06-173-3/+3
| | | | | | | | | | | * Change `pub` to `export` * Change the `=` in define to `:` * Change `pub_template_semver_check` to `template_export_semver_check` Right now, 0.12.1 supports both syntaxes. I have verified this branch also compiles with https://gitlab.torproject.org/Diziet/rust-derive-deftly/-/merge_requests/402 ee171ffaf56d7dcb7d75584054921153fe19b222
* Update to derive-deftly 0.12.1Ian Jackson2024-06-172-2/+2
| | | | | | * Bump in Cargo.toml * Deal with `${Xmeta as ...}` incompatible change, by always specifying an `as`, and changing `as tokens`.
* tor-keymgr: Add script for generating test key files.Gabriela Moldovan2024-05-151-0/+6
| | | | | | | | | | | `tor-keymgr/testdata` contains a bunch of OpenSSH keys used for testing. I meant to share the script I generated them with, but somehow never got around to it. Note: the OpenSSH keys generated by this script are going to look slightly different than the ones that are checked into the repo. This is because some of those original key files were generated ad-hoc (I manually modified them a while ago, but I forgot exactly how
* tor-keymgr: Fix nightly warnings.Gabriela Moldovan2024-05-091-6/+6
| | | | This is a follow-up from !2131
* Merge branch 'keymgr-ephemeral-refactor' into 'main'gabi-2502024-05-0911-616/+830
|\ | | | | | | | | | | | | tor-keymgr: Refactor code shared between ArtiNativeKeystore and ArtiEphemeralKeystore Closes #1362 and #1367 See merge request tpo/core/arti!2131
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 07:10:07 +0000