mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.0.0 2022-08-04T14:54:21Z 2022-08-04T14:54:21Z Nick Mathewson nickm@torproject.org 2022-08-04T14:54:21Z urn:sha1:e3cc533853defba11ce40369f31f3e0bef790e21 Revise our handling of the zeroize trait Closes #254 See merge request tpo/core/arti!655 2022-08-01T19:41:22Z Nick Mathewson nickm@torproject.org 2022-08-01T19:14:42Z urn:sha1:37e6c95fdc01319fc8afb34229e7b097851da33d Everything that is a secret encryption key, or an input that is used to produce a secret encryption key, has to get zeroized. And that's all! Closes #254. 2022-08-01T19:41:22Z Nick Mathewson nickm@torproject.org 2022-08-01T18:53:34Z urn:sha1:eedd63d5e9a4e055260b476177ee14972584a1bb This does not yet make sure that `SecretBuf` is used where it _should_ be, but at least it ensures that most uses of `SecretBytes` will indeed act as intended, and make sure that whatever they contain is zeroized. It requires some corresponding changes to method calls for correctness and type conformance. 2022-07-26T14:09:28Z eta tor@eta.st 2022-07-26T14:06:35Z urn:sha1:f02d732b7f1490d38c2e78ce54a4f22a79b50de8 In order to mitigate syntax highlighting issues and a rust-analyzer bug (https://github.com/rust-analyzer/rust-analyzer/issues/10178), rename files that are included with the `include!` macro to have a `.rs` extension. Make sure the included files are outside `src/`, in order to not confuse humans and automated editing tools that might mistake them for valid Rust modules. fixes arti#381 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.