mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.6.0 2022-07-11T15:18:51Z 2022-07-11T15:18:51Z Nick Mathewson nickm@torproject.org 2022-07-11T15:04:27Z urn:sha1:fbb6484025ac024642afbeef6734d88e35210673 This change was a bit annoying, since most of this code _can't_ fail, and so the only reasonable response is to wrap the input in an internal error... except for one case where we're actually encoding a caller-provided message, so we _do_ want to wrap the EncodeError from tor_bytes. 2022-07-11T15:18:51Z Nick Mathewson nickm@torproject.org 2022-07-08T16:06:05Z urn:sha1:5a61a6d73aa2ddf4dd99c8af9c6082bb8c56d158 There were only a few of these. Removing it required porting everything to use `write_and_consume` instead, and handling its (potential) errors. 2022-07-11T15:18:51Z Nick Mathewson nickm@torproject.org 2022-07-08T15:20:50Z urn:sha1:7938f65c66020d6d7f143307f3336f340f398c63 This comprises four renames: ``` write_onto -> write_onto_infallible write_into -> write_into_infallible write -> write_infallible writer_and_consume -> write_and_consume_infallible. ``` The rest of this branch will be concerned with replacing these `_infallible` methods with ones that return a `Result`. This is part of #513. 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.