mirrors/arti.git/crates/tor-chanmgr/src/builder.rs, branch arti-v0.2.0mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.2.02022-03-23T12:24:36Ztor-proto: add a backend to detect reported clock skew.2022-03-23T12:24:36ZNick Mathewsonnickm@torproject.org2022-03-14T15:51:06Zurn: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.
Implement a basic form of RFC 8305 ("happy eyeballs") for channels2022-03-07T14:56:51Zetator@eta.st2022-03-04T15:58:21Zurn:sha1:c98d9dc5fec3da18b4d7098078c273a3a1558e45
This makes Arti usable in IPv6-only environments (arti#92) by letting us
attempt multiple connections to a given relay using all of its
addresses instead of just using the first (probably IPv4) one, using the
strategy from RFC 8305 ยง 5.
This isn't a complete implementation of Happy Eyeballs; ideally, we'd
sort the address list before doing concurrent connections. However, it
works (and has been tested inside an IPv6-only container inside eta's
network :p)
tor-chanmgr: use Bug types.2022-02-16T16:55:47ZNick Mathewsonnickm@torproject.org2022-02-15T19:19:03Zurn:sha1:caa70fde35b6a973ae2b29bf4760c5e019c14911Merge branch 'error-improvements' into 'main'2022-02-08T14:42:30Zetator@eta.st2022-02-08T14:42:30Zurn:sha1:109515ecfe587a65f0920e074cdd593d3810cd97
Hopefully uncontroversial improvements to new Error code
See merge request tpo/core/arti!291Expire channels that have been unused for too long2022-02-05T03:52:51ZYuan Lyulyuyuan92@gmail.com2022-02-04T04:36:01Zurn:sha1:f6f732a47818f789db76ad692d0025de1051072fMake SpawnError wrappers contain a 'spawning' string2022-02-04T21:06:11ZNick Mathewsonnickm@torproject.org2022-02-04T20:39:12Zurn:sha1:070e52653d9a49fe561e9ce119881f696baa325e
(By our convention, these errors should say what we were trying to
spawn when the error occurred.)
channel errors: Include what we were doing2022-02-04T15:03:19ZIan Jacksonijackson@chiark.greenend.org.uk2022-02-04T15:03:01Zurn:sha1:6c2f9dac16f3c550b2286fad3b8dce97cb7ba8e0tor-chanmgr: Handle IO errora in the new style2022-02-04T14:42:37ZIan Jacksonijackson@chiark.greenend.org.uk2022-01-26T15:44:12Zurn:sha1:2a471ffd1a1d70ed585067d2e1dc1bf94b8f3103
Two ? in the tests become expects, which will do. That avoids having
to construct a proper error with context here.
tor-chanmgr: Add bootstrap/status reporting.2022-01-18T18:06:08ZNick Mathewsonnickm@torproject.org2022-01-17T22:11:18Zurn:sha1:c162e57e29a3bfd1f0e793b25d8c986a96a0a474
The information is pretty basic here: we use "have we been able to
connect/TLS-handshake/Tor-handshake" as a proxy for "are we on the
internet? Are we on a reasonably unfiltered part of the internet?"
Eventually we'll want to make the information gathered and exported
more detailed: I've noted a few places in the code. For now,
however, this is about as good as C Tor does today, and it should be
a good starting point.
This uses a slightly different design from tor-dirmgr. Instead of
exporting an entire state structure via `postage::watch`, it exports
only the parts of that structure which the user is supposed to
read. I think that's more reasonable in this case because most of
the possible internal transitions in the tor-chanmgr state don't
cause a change in the exposed status.
chanmgr: get rid of Arc around Channel2022-01-13T13:12:29ZIan Jacksoniwj@torproject.org2022-01-13T13:12:29Zurn:sha1:9b723cba53852ecd3505c0cabc42ca3b5d31ad34