mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.2.6 2024-07-30T14:20:24Z 2024-07-30T14:20:24Z Gabriela Moldovan gabi@torproject.org 2024-07-30T14:14:47Z urn:sha1:761d33b6ef9413bc05b4d48104f597f69ebc9305 2024-07-17T15:55:13Z Gabriela Moldovan gabi@torproject.org 2024-07-17T15:13:46Z urn:sha1:a48804f9a0770ab54a117a35c6ffdf4df9387950 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 2024-07-17T15:05:43Z Gabriela Moldovan gabi@torproject.org 2024-07-17T15:05:43Z urn:sha1:415e6e86e73ca1bf6c847d0bd488a091f9a18f3d 2024-07-17T15:05:10Z Gabriela Moldovan gabi@torproject.org 2024-07-17T15:05:10Z urn:sha1:e259e166c51e4e633eb52d45fe62bb53c3e2403f 2024-07-17T15:01:02Z Gabriela Moldovan gabi@torproject.org 2024-07-17T15:01:02Z urn:sha1:87145fb76f09391a452ddbb0c8d0f897109ca9e3 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 2024-07-10T10:50:44Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-07-09T13:47:01Z urn:sha1:e0f844d704e20f5d0ab6f4db32760889012cd870 2024-05-07T18:43:35Z Gabriela Moldovan gabi@torproject.org 2024-05-07T18:40:34Z urn:sha1:dfb63f8eb8453ae417d2381859cfe7bd213651e5 This helps prevent external users from creating `SshKeyData` out of unsupported types of `ssh_key::public::KeyData` and `ssh_key::private::KeypairData`. 2024-05-07T13:31:45Z Gabriela Moldovan gabi@torproject.org 2024-05-07T11:46:52Z urn:sha1:83119a81eb2ffd67d0608df6b1b2fabbf54401b7 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`. 2024-05-07T11:20:33Z Gabriela Moldovan gabi@torproject.org 2024-05-02T16:53:40Z urn:sha1:766fe621e467442370fcabfad7d897390dc790a6 I think it makes more sense for parse_ssh_format_erased to be a function of the key than of `KeyType`. 2024-05-07T09:51:13Z Gabriela Moldovan gabi@torproject.org 2024-05-02T12:57:45Z urn:sha1:a05b126adfb8acd65d9be4a26b5d6afa4dc518f5 This doesn't need to be public anymore now that the test keys are exported from `test_utils`. Addresses https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2076#note_3016577