mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.1.0 2022-11-18T15:12:05Z 2022-11-18T15:12:05Z Nick Mathewson nickm@torproject.org 2022-11-18T15:12:05Z urn:sha1:d51162e55b19036528b4fafc1d4b15c8d9d23a04 It looks like, despite a few false starts, they've got this warning right; there weren't any false positives. 2022-09-10T12:39:47Z trinity-1686a trinity@deuxfleurs.fr 2022-09-10T12:39:47Z urn:sha1:8e7a904260dfe344eed70a9eef109695544347c1 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