mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.3.2 2025-01-06T23:09:41Z 2025-01-06T23:09:41Z Steven Engler opara@torproject.org 2025-01-06T23:02:49Z urn:sha1:252a3a803b2db65792db5bd51dee8950d8557e0d Denies 'mod.rs' files for consistency. https://rust-lang.github.io/rust-clippy/master/index.html#mod_module_files 2024-12-03T14:27:26Z Nick Mathewson nickm@torproject.org 2024-12-03T14:15:50Z urn:sha1:64cc3f2ed3eea0b7c5cc89ae07cbdadfdc1646fb In 1.83, this warning triggers on many of our crates. We're thinking of fixing them all, but for now, we're going to disable the warning. This is part of #1765. 2024-10-31T14:34:51Z Gabriela Moldovan gabi@torproject.org 2024-10-30T18:23:10Z urn:sha1:7a0a41e2eed85065fcb614325f6fab838aa397e3 As per our discussion in https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2577#note_3099356 2024-10-31T14:34:51Z Gabriela Moldovan gabi@torproject.org 2024-10-23T11:01:05Z urn:sha1:04caca755d5294f83a571ccebeaa9b55fe13c7a7 2024-10-31T14:34:51Z Gabriela Moldovan gabi@torproject.org 2024-10-23T11:00:33Z urn:sha1:8357c7c6fe01fd4c59e353a39ff59642bff0c19a This will enable us to store more than one `K_relaysign_ed` in the keystore. Closes #1692 2024-10-31T14:34:01Z Gabriela Moldovan gabi@torproject.org 2024-10-23T10:27:32Z urn:sha1:f8e5b7452cd97c58bed91707cf42f29b3b9754de We'll eventually need this specifier (for example, if the `KS_relayid_ed` private key stored offline, the public part of the keypair will be stored in the online keystore, and will be retrievable using the new `RelayIdentityPublicKeySpecifier` specifier). 2024-10-31T14:29:30Z Gabriela Moldovan gabi@torproject.org 2024-10-23T10:23:11Z urn:sha1:3d0037dcc67aa7e3d34f18d5c8c7c40ac87b5718 2024-10-31T14:29:30Z Gabriela Moldovan gabi@torproject.org 2024-10-23T10:20:46Z urn:sha1:a4f2ccf9446c25af346274122512ae457b52693a According to its docs, `RelayIdentityKeySpecifier` was meant to be the key specifier for the relay identity keypair, so its role prefix should be `KS_`. This also renames `RelayIdentityKeySpecifier` to `RelayIdentityKeypairSpecifier` for clarity (we're about to add another specifier here, for the public relay identity key). 2024-10-14T17:50:48Z Gabriela Moldovan gabi@torproject.org 2024-10-14T17:50:48Z urn:sha1:b2d726951d1e73f2360710681ce19f5151644a0d The `RelaySigningKeySpecifier` is currently defined as: ```rust #[non_exhaustive] #[derive(Deftly, PartialEq, Debug, Constructor)] #[derive_deftly(KeySpecifier)] #[deftly(prefix = "relay")] #[deftly(role = "KP_relaysign_ed")] #[deftly(summary = "Relay medium-term signing keypair")] /// The key sepcifier of the relay medium-term signing key (RelaySigningKeypair) pub struct RelaySigningKeySpecifier; ``` This means there can only be a single `relaysign_ed` key with an `ArtiPath` of the form `relay/KP_relaysign_ed`. This is a problem, because relays storing their identity key offline will want to generate a number of `relaysign_ed` keys ahead of time, so we need the keystores to be able to contain multiple such keys. We will need their `ArtiPath` to encode a variable component (for example, a timestamp). We also need to teach `KeyMgr` to retrieve such keys (`KeyMgr::get` should return the first key that has a valid and timely certificate). This will involve extending the `KeySpecifier` trait with a function for obtaining the `KeySpecifier` of the certificate of the key, if there is one. For now, let's comment it out and rethink its `ArtiPath` as part of #1692. 2024-09-18T19:27:33Z Steven Engler opara@torproject.org 2024-09-18T19:21:45Z urn:sha1:6a9b0ee6f5e02b794174b9766d3eb21c73562ee7 This re-exports the types/traits needed by the `define_ed25519_keypair` macro so that the macro caller doesn't need to import a bunch of extra packages in its Cargo.toml that it doesn't use, and so that the caller doesn't need a `use prelude::*` before invoking the macro. This makes the macro nicer to use for the caller, and should prevent the macro from causing "cannot find ... in this scope" errors.