mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=tor-dirmgr-v0.5.1 2022-07-08T17:26:18Z 2022-07-08T17:26:18Z eta tor@eta.st 2022-06-23T13:51:01Z urn:sha1:af64a0a984cb357c0b60cea650ca90d8d1c6240d This implements a higher-level API for the ntor v3 handshake, in line with that exposed by the ntor handshake. It does not, however, use the existing `ClientHandshake` trait, due to fundamental differences in the handshakes (namely, that the v3 handshake can include some additional extra extension data). Currently, the higher-level API assumes circuit extension, and copies the (undocumented!) magic verification string from c-tor that indicates this usage. A rudimentary set of functions for serializing and deserializing extensions to be sent with the handshake is also included, implementing the protocol in proposal 332 § A.2. Currently, it only implements the congestion control extensions specified in proposal 324 § 10.3. part of arti#88 2022-07-06T13:57:45Z eta tor@eta.st 2022-07-05T10:57:10Z urn:sha1:c2e2da5dc35b2e0aa4cc17865ec4d14c725558c7 - arti#448 and arti!607 highlight an issue with upgrading `rsa`: namely, the `x25519-dalek` version previously used has a hard dependency on `zeroize` 1.3, which creates a dependency conflict. - However, `x25519-dalek` version `2.0.0-pre.1` relaxes this dependency. Reviewing the changelogs, it doesn't look like that version is substantially different from the current one at all, so it should be safe to use despite the "prerelease" tag. - The new `x25519-dalek` version also bumps `rand_core`, which means we don't have to use the RNG compat wrapper in `tor-llcrypto` as much. closes arti#448 2022-06-23T19:42:45Z Nick Mathewson nickm@torproject.org 2022-06-23T19:42:45Z urn:sha1:38004a4f4dd3aa99b81b6585039e81dc77c17f32 Some of these were for decoding particular objects (we now say what kind of objects), and some were unrelated tor_cert errors that for some reason we had shoved into a tor_bytes::Error. There is now a separate tor_cert::CertError type, independent from tor_cert's use of `tor_bytes::Error` for parsing errors. 2022-06-23T18:35:26Z Nick Mathewson nickm@torproject.org 2022-06-23T18:35:26Z urn:sha1:92fd9fb0dec25ddd45a4428603db99bad8d72661 This avoids adding additional information for now; that will come on the next commits. 2022-06-02T18:56:42Z Nick Mathewson nickm@torproject.org 2022-06-02T17:31:43Z urn:sha1:967ea67b7dfc158f29cf449eb09bac89acdee46b This only affects uses of thread_rng(), and affects them all more or less indiscriminately. One test does not work with ARTI_TEST_PRNG=deterministic; the next commit will fix it. 2022-04-26T16:16:22Z Nick Mathewson nickm@torproject.org 2022-04-25T19:39:26Z urn:sha1:aaab6f38122261f7527e9a04b24972d09b775689 Now that we require Rust 1.56, we can upgrade to AES 0.8. This forces us to have some slight API changes. We require cipher 0.4.1, not cipher 0.4.0, since 0.4.0 has compatibility issues with Rust 1.56. 2022-04-25T17:06:26Z Nick Mathewson nickm@torproject.org 2022-04-25T16:40:33Z urn:sha1:2f6bc6bdc431fa36de70a167eea777dcf3f60bf2 Remove all `use` statements for `TryFrom` and `TryInto`. These are now redundant in Rust 2021. 2022-02-23T15:39:08Z Nick Mathewson nickm@torproject.org 2022-02-23T15:07:49Z urn:sha1:d42b932ed93c5f4d4204d933e4ea798c21c4d02d (We'll have a BadChanHandshake soon.) 2022-02-22T21:00:25Z Nick Mathewson nickm@torproject.org 2022-02-22T21:00:25Z urn:sha1:a2e2663e90df6a10d5f4d4b28d7070f26f04cf24 There was only one use of this, and it was in as-yet-unused relay-only code. Removing this type required refactoring the relay onion handshake code to use its own error type, which is probably clever anyway. 2022-02-15T14:57:03Z Nick Mathewson nickm@torproject.org 2022-02-15T14:57:03Z urn:sha1:6b611d6deae2e003ea81f459cd5e005c37ab50ce