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-28T21:48:35Z Nick Mathewson nickm@torproject.org 2024-07-28T21:34:18Z urn:sha1:1b6394cec9653937b404b93ed510e90b2eff9ae7 This warning complains when we say `where T: SomeTrait + ?Sized` when `SomeTrait` is inherently Sized. 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-07-08T17:39:22Z Gabriela Moldovan gabi@torproject.org 2024-07-08T17:39:22Z urn:sha1:ebc07845752d71f9e76c6118b2ea09cfaeea13f2 2024-07-08T17:19:34Z Gabriela Moldovan gabi@torproject.org 2024-07-08T17:19:34Z urn:sha1:48b239cb3be2373141bb8fdf67be9e9468685eef 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. 2024-07-08T17:13:05Z Gabriela Moldovan gabi@torproject.org 2024-07-08T17:13:05Z urn:sha1:58a2271b82ba7bf60bd9308f87c63f73cf46dece 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.