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-15T11:00:12Z Gabriela Moldovan gabi@torproject.org 2024-05-01T12:57:00Z urn:sha1:2828a5ab2e667bd3d8c8333fd26999a999d3a0d7 `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 2024-05-08T18:08:24Z Gabriela Moldovan gabi@torproject.org 2024-05-08T18:07:36Z urn:sha1:04d527bbd66545e6b0178951c4d041287cdb12bb This reverts commit 9ea35caeb1ed23fd029627d04819debc41d85c77. 2024-05-08T18:08:24Z Gabriela Moldovan gabi@torproject.org 2024-05-08T18:06:22Z urn:sha1:4401bfb74d0dde20fd8e3ce2fb5b4cb4d2182147 Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2131#note_3028014 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`.