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-24T14:13:58Z Ian Jackson iwj@torproject.org 2022-06-24T14:13:58Z urn:sha1:4831f9d38c8b3599184ca5f93a9929f784c8026b Fix clippy nightly again See merge request tpo/core/arti!603 2022-06-24T13:23:38Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-06-24T12:24:00Z urn:sha1:23c352b96bf07c981bb396fa34ce83e512ada0b2 Found these by disabling the nightly dbg macro special case. Now, we have a mechanism for globally adding suppressions to tests, we can use that instead. 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:59:52Z Nick Mathewson nickm@torproject.org 2022-06-23T18:59:52Z urn:sha1:35b7b8a47ad96f5eee032fab7900b3b29bf2fa73 Failing to encode is fundamentally different from failing to decode. We now treat those separately, and describe _what_ we failed to encode or decode. 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-23T18:15:42Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-06-23T18:15:29Z urn:sha1:589c6e52bb49ccfe6c0ad9d18d6b994978e46c6c Update all lint blocks 2022-06-21T19:34:27Z eta tor@eta.st 2022-06-21T19:34:27Z urn:sha1:4e3537746f4aa5d4df4abd5cb2be1385a4baa64b Do not include error source() in display() format. See merge request tpo/core/arti!598 2022-06-21T18:19:28Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-06-17T13:17:07Z urn:sha1:a2614729a4d87e163a21a0569917e0097acf311c Consequential ordering changes.