mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.4.0 2022-05-23T10:28:05Z 2022-05-23T10:28:05Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-05-20T15:49:30Z urn:sha1:2fc6c8a194fa668e5bdb9d94d25e29c5e1666a21 2022-05-23T10:28:05Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-05-18T15:02:52Z urn:sha1:793782acc80c05e2d2e125c65721c7a0b967d113 This is a general-purpose implementation of the ad-hoc approach currently taken in (eg) crates/tor-proto/src/channel/reactor.rs, with an API intended to defned against the more obvious mistakes. This allows us to separate the two concerns: the channel reactor can focus on handling channel cells and control messages and is over 2.5x shorter. The complexity of the manual sink implementation, and the machinery needed to avoid having to suspend while holding an item, are dealt with separately. That separate implemenation now has proper documentation. (Tests are in the nest commit to avoid this one being even more unwieldy.) We use `extend` to define this as an extension trait. A competitor is `ext` but in my personal projects I have found `extend` slightly better. 2022-05-11T17:52:12Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-05-11T14:30:28Z urn:sha1:0cc94d449ed5853838221a882f66c7838a36ee3f The type of ret.map_err(codec_err_to_chan)? is (). ISTM that writing `let () = ` makes it clear that there is nothing there, but the lint forbids this. This lint is warn by default and trips here for me on current nightly. It seems wrong to me. We should be able to make it clear to the reader that there is nothing here - note how this differs from the lines below where Ready contains msg. A let () binding is a good way to do that. I think the lint allow ought to be added everywhere, but that doesn't seem easy right now - see this issue about maint/add_warning: https://gitlab.torproject.org/tpo/core/arti/-/issues/469 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-04-11T16:34:16Z Nick Mathewson nickm@torproject.org 2022-04-11T16:31:05Z urn:sha1:4efe45ce6e14672625dea392b93da9cf43c72ec1 2022-04-07T14:15:28Z Nick Mathewson nickm@torproject.org 2022-04-07T14:01:19Z urn:sha1:9160b55c57e9b2d68b82059139a2be0dd7954b8a Fortunately, we don't need a separate type here: authenticated clock skew can only come attached to a `tor_proto::Error`. We also remove skew from `tor_proto::Error::HandshakeCertsExpired`, since it would now be redundant. 2022-04-07T14:07:35Z Nick Mathewson nickm@torproject.org 2022-04-06T19:29:24Z urn:sha1:7656ab09319aacbc8ef0e89e34a7dd5ce0ba1d85 of a channel. At first I wanted to have this information not be a part of channels at all, but it is a fairly tiny amount of data, and the alternatives are pretty crufty. 2022-03-23T12:49:36Z Nick Mathewson nickm@torproject.org 2022-03-23T12:49:36Z urn:sha1:791394cd2b455646c5e8938e7592d73b28c7977b tor-proto: add the ability to learn clock skew from NETINFO cells See merge request tpo/core/arti!410 2022-03-23T12:24:36Z Nick Mathewson nickm@torproject.org 2022-03-14T18:33:11Z urn:sha1:0b2cf533ee5771fdb16255652837af69c316642e We now check the handshake certificates unconditionally, and only report them as _expired_ as a last resort. (Rationale: if somebody is presenting the wrong identity from a year ago, it is more interesting that they are presenting the wrong ID than it is that they are doing so with an expired cert. We also now report a different error if the certificate is expired, but its expiration is within the range of reported clock skew. (Rationale: it's helpful to distinguish this case, so that we can blame the failure on possible clock skew rather than definitely attributing it to a misbehaving relay.) Part of #405. 2022-03-23T12:24:36Z Nick Mathewson nickm@torproject.org 2022-03-14T15:51:06Z urn:sha1:3885a2c05b64e6d071adfabdf5eb957fab001a5d NETINFO cells, which are sent in every handshake, may contain timestamps. This patch adds an accessor for the timestamp in the Netinfo messages, and teaches the tor-proto code how to compute the minimum clock skew in the code. The computation isn't terribly precise, but it doesn't need to be: Tor should work fine if your clock is accurate to within a few hours. This patch also notes a Y2038 problem in the protocol: see torspec#80. Part of #405.