summaryrefslogtreecommitdiff
path: root/crates/tor-keymgr
Commit message (Collapse)AuthorAgeFilesLines
* Bump all the unstable tor- and arti- crates to 0.22.0.Gabriela Moldovan2024-09-031-8/+8
| | | | | | | | | | Done using: ``` for crate in $(./maint/list_crates | rg '^(tor|arti-)'); do cargo set-version -p $crate 0.22.0 done ```
* 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
* Don't need to tell docs.rs to enable `docsrs` cfgKunal Mehta2024-08-021-1/+0
| | | | | It now does it automatically, see <https://docs.rs/about/builds#detecting-docsrs>.
* Remove semver.md files post-release.Nick Mathewson2024-08-011-1/+0
|
* Bump versions for tor- and arti- crates to 0.21.0Nick Mathewson2024-08-011-8/+8
| | | | | | | | | | This is the result of: ``` for crate in $( ./maint/list_crates |grep '^\(tor\|arti-\)' ); do cargo set-version -p $crate 0.21.0 done ```
* 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
|
* Merge branch 'fix-time-period-parsing-bug' into 'main'gabi-2502024-07-081-5/+7
|\ | | | | | | | | tor-keymgr: Use collect_tuple in TimePeriod::from_slug. See merge request tpo/core/arti!2248
| * 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.
* | Update to derive-deftly 0.14Ian Jackson2024-07-081-1/+1
|/ | | | | This removes the deprecated syntaxes. Updating now will prevent us re-introducing the old syntaxes, which we updated in arti!2209.
* Update versions of 0.x tor-* and arti-* cratesIan Jackson2024-06-271-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | nailing-cargo -uE set-version -p arti-client 0.20.0 nailing-cargo -uE set-version -p arti-relay 0.20.0 nailing-cargo -uE set-version -p arti-rpcserver 0.20.0 nailing-cargo -uE set-version -p tor-async-utils 0.20.0 nailing-cargo -uE set-version -p tor-basic-utils 0.20.0 nailing-cargo -uE set-version -p tor-bytes 0.20.0 nailing-cargo -uE set-version -p tor-cell 0.20.0 nailing-cargo -uE set-version -p tor-cert 0.20.0 nailing-cargo -uE set-version -p tor-chanmgr 0.20.0 nailing-cargo -uE set-version -p tor-checkable 0.20.0 nailing-cargo -uE set-version -p tor-circmgr 0.20.0 nailing-cargo -uE set-version -p tor-config 0.20.0 nailing-cargo -uE set-version -p tor-consdiff 0.20.0 nailing-cargo -uE set-version -p tor-dirclient 0.20.0 nailing-cargo -uE set-version -p tor-dirmgr 0.20.0 nailing-cargo -uE set-version -p tor-error 0.20.0 nailing-cargo -uE set-version -p tor-geoip 0.20.0 nailing-cargo -uE set-version -p tor-guardmgr 0.20.0 nailing-cargo -uE set-version -p tor-hsclient 0.20.0 nailing-cargo -uE set-version -p tor-hscrypto 0.20.0 nailing-cargo -uE set-version -p tor-hsrproxy 0.20.0 nailing-cargo -uE set-version -p tor-hsservice 0.20.0 nailing-cargo -uE set-version -p tor-keymgr 0.20.0 nailing-cargo -uE set-version -p tor-linkspec 0.20.0 nailing-cargo -uE set-version -p tor-llcrypto 0.20.0 nailing-cargo -uE set-version -p tor-log-ratelim 0.20.0 nailing-cargo -uE set-version -p tor-memquota 0.20.0 nailing-cargo -uE set-version -p tor-netdir 0.20.0 nailing-cargo -uE set-version -p tor-netdoc 0.20.0 nailing-cargo -uE set-version -p tor-persist 0.20.0 nailing-cargo -uE set-version -p tor-proto 0.20.0 nailing-cargo -uE set-version -p tor-protover 0.20.0 nailing-cargo -uE set-version -p tor-ptmgr 0.20.0 nailing-cargo -uE set-version -p tor-relay-selection 0.20.0 nailing-cargo -uE set-version -p tor-rpcbase 0.20.0 nailing-cargo -uE set-version -p tor-rtcompat 0.20.0 nailing-cargo -uE set-version -p tor-rtmock 0.20.0 nailing-cargo -uE set-version -p tor-socksproto 0.20.0 nailing-cargo -uE set-version -p tor-units 0.20.0 Each of which runs a rune like cargo set-version --offline -p tor-units 0.20.0
* Update to itertools 0.13.0Ian Jackson2024-06-251-1/+1
| | | | | | | No code changes needed. Precisely nailing-cargo -Eu upgrade --incompatible -p itertools
* Update to derive-deftly 0.13.0Ian Jackson2024-06-251-1/+1
| | | | | | | No code changes needed. Precisely nailing-cargo -Eu upgrade --incompatible -p derive-deftly
* 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-174-3/+4
| | | | | | * Bump in Cargo.toml * Deal with `${Xmeta as ...}` incompatible change, by always specifying an `as`, and changing `as tokens`.
* Bump all the unstable tor- and arti- crates to 0.19.Gabriela Moldovan2024-06-051-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The unstable crates are: - tor-error - tor-config - tor-units - tor-geoip - tor-rtcompat - tor-rtmock - tor-log-ratelim - tor-rpcbase - tor-memquota - tor-llcrypto - tor-protover - tor-bytes - tor-hscrypto - tor-socksproto - tor-checkable - tor-cert - tor-linkspec - tor-cell - tor-proto - tor-netdoc - tor-consdiff - tor-netdir - tor-relay-selection - tor-persist - tor-chanmgr - tor-ptmgr - tor-guardmgr - tor-circmgr - tor-dirclient - tor-dirmgr - tor-keymgr - tor-hsclient - tor-hsservice - tor-hsrproxy - arti-client - arti-rpcserver - arti-hyper - tor-basic-utils - tor-async-utils Done using ``` for p in "${unstable[@]}"; do cargo set-version -p $p 0.19; done ``` where `unstable` contains the list above
* tor-keymgr: Regenerate the keys.Gabriela Moldovan2024-05-1612-48/+48
| | | | | The keys generated in this commit are reproducible using the `maint/keygen-openssh-test/generate` script.
* tor-keymgr: Regenerate the test keys.Gabriela Moldovan2024-05-1512-51/+53
| | | | | | | This commit contains a new set of `tor-keymgr/testdata` keys, generated using ./maint/keygen-openssh-test/generate.sh`. Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2121#note_3025369
* tor-keymgr: Move keygen script to maint.Gabriela Moldovan2024-05-156-306/+0
|
* tor-keymgr: Make keygen crate part of the workspace.Gabriela Moldovan2024-05-152-2475/+0
|
* tor-keymgr: Add script for generating test key files.Gabriela Moldovan2024-05-158-0/+2787
| | | | | | | | | | | `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
| * Revert "tor-keymgr: Fix now-failing test."Gabriela Moldovan2024-05-081-0/+16
| | | | | | | | This reverts commit 9ea35caeb1ed23fd029627d04819debc41d85c77.
| * tor-keymgr: Validate the KeyType when inserting into the ephemeral keystore.Gabriela Moldovan2024-05-081-0/+20
| | | | | | | | Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2131#note_3028014
| * tor-keymgr: Add function for extracting the KeyType of an ssh key.Gabriela Moldovan2024-05-082-0/+50
| |
| * tor-keymgr: Fix newly failing tests (fmt).Gabriela Moldovan2024-05-081-33/+62
| |
| * tor-keymgr: Fix newly failing tests.Gabriela Moldovan2024-05-082-59/+109
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This updates the keymgr tests to be slightly more robust. These tests attach some metadata to each key, such as the "nickname" of the key (which only exists for testing purposes), whether the key was auto-generated, and the keystore ID of the keystore from which the key was retrieved. Previously, the metadata was encoded in the key "material" itself (the test "keys" were actually just `String`s with a hacky `EncodableKey` implementation that abused the "encrypted" variant of `KeypairData`). This was only possible because we had access to the key internals (through `SshKeyData::Public`/`SshKeyData::Private`), but since the internals are inaccessible now, the tests need to be updated.
| * tor-keymgr: Make SshKeyData an opaque type.Gabriela Moldovan2024-05-073-87/+75
| | | | | | | | | | | | This helps prevent external users from creating `SshKeyData` out of unsupported types of `ssh_key::public::KeyData` and `ssh_key::private::KeypairData`.
| * tor-keymgr: Do not make SshKeyData infallibly convertible from ↵Gabriela Moldovan2024-05-072-11/+49
| | | | | | | | KeyData/KeypairData.
| * tor-keymgr: Seal the EncodableKey trait.Gabriela Moldovan2024-05-072-1/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As explained in the docs, this trait should not be implementable outside of the `tor-keymgr` crate. The `SshKeyData::into_erased` and `UnparsedOpensshKey::parse_ssh_format_erased` impls assume the types implementing `EncodableKey` form a statically known closed set. If we later decide to make the supported key types an open set, we should make this trait implementable outside of `tor-keymgr` too. External types wanting to create custom "key types" for use in the keymgr should use the non-sealed `ToEncodableKey` trait, which specifies the `EncodableKey` type to use. This trait is mainly used to create `SshKeyData` IMO, we should make `SshKeyData` opaque, since it's not meant to be constructed through other means (`SshKeyData` is currently a public enum, so its variants and the `ssh_key` types they wrap are public). A future commit will make it opaque.
| * tor-keymgr: Update ephemeral keystore docs.Gabriela Moldovan2024-05-071-2/+2
| |
| * tor-keymgr: Dedupe all the convert functions.Gabriela Moldovan2024-05-073-143/+17
| |
| * tor-keymgr: Make an ArtiNativeKeystore-specific function private.Gabriela Moldovan2024-05-071-20/+16
| | | | | | | | | | | | | | The `ssh_algorithm()` function was only meant for use in the ArtiNativeKeystore, for extracting the `KeyType` given the `SshAlgorithm` of a key read from disk, so it really shouldn't be crate-public.
| * tor-keymgr: Move arti-specific ssh code to arti module.Gabriela Moldovan2024-05-078-70/+75
| | | | | | | | | | | | | | | | | | Some of the types and impls from `key_type/ssh.rs` (such as `UnparsedOpenSshKey`) have nothing to do with `KeyType`, and are only used by the `ArtiNativeKeystore`, so I'm moving them to the `arti` keystore module. The shared ssh-related stuff now lives in the top-level `ssh.rs`.
| * tor-keymgr: Test that the ephemeral store returns the correct type.Gabriela Moldovan2024-05-071-2/+6
| |
| * tor-keymgr: Fix now-failing test.Gabriela Moldovan2024-05-071-16/+0
| | | | | | | | | | | | Inserting a key that has the wrong key type no longer fails, because we now store the `KeyData` as-is, without attempting to parse it as a specific kind of SSH key.