mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.3.0 2024-10-08T13:23:17Z 2024-10-08T13:23:17Z Gabriela Moldovan gabi@torproject.org 2024-09-25T18:23:26Z urn:sha1:05066b0ebfc769cb54018d9633646ace70456ee3 This is only used for representing portions of `ArtiPath`s, so let's rename it accordingly. 2024-10-08T13:23:17Z Gabriela Moldovan gabi@torproject.org 2024-09-25T18:20:08Z urn:sha1:b2170d7d8a680255e389a3600444b50bd9d3a363 `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). 2024-10-08T13:23:17Z Gabriela Moldovan gabi@torproject.org 2024-09-20T15:39:43Z urn:sha1:971304d31bdb38fd9e6133941d2e021d4bb7dd6d 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. 2024-10-08T13:23:16Z Gabriela Moldovan gabi@torproject.org 2024-09-26T14:39:42Z urn:sha1:68376b22557e15404539f8dec40f9f11bf520f1f 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` 2024-09-30T16:20:11Z Nick Mathewson nickm@torproject.org 2024-09-30T16:20:11Z urn:sha1:68e9400e9c14863b8b20b3c6ab6a532bc83530a5 2024-09-23T17:58:55Z Gabriela Moldovan gabi@torproject.org 2024-09-23T14:23:13Z urn:sha1:b3cf77ed943e97428d2d6c3ef1f352ee9b273617 I am adding `is_enabled()` back because I plan to un-deprecate the `enabled` setting. 2024-09-23T13:17:49Z Gabriela Moldovan gabi@torproject.org 2024-09-20T10:20:33Z urn:sha1:80095da1aa47978cdba26c2b3d254a99c075cf53 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. 2024-09-20T23:13:14Z Morgan morgan@torproject.org 2024-09-07T04:37:09Z urn:sha1:641de54341202c5797d3f9b2d2fa1c82a04d2519 2024-09-20T23:13:14Z Morgan morgan@torproject.org 2024-09-15T18:25:53Z urn:sha1:5e4e7b69b8cd2791763559cb0563dc60c8a66ce2 2024-08-01T17:43:45Z Nick Mathewson nickm@torproject.org 2024-08-01T17:43:45Z urn:sha1:b63f942f8f729f31d153886ef513955c159f7aac