mirrors/arti.git/crates/tor-circmgr/src/lib.rs, branch arti-v1.1.4mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.1.42023-03-28T14:49:45ZAdd some missing imports2023-03-28T14:49:45ZIan Jacksonijackson@chiark.greenend.org.uk2023-03-28T13:16:17Zurn:sha1:00e522a91ac1ecd59f48dc97a64319d748f2c482
Now
nailing-cargo +stable clippy -p tor-hsclient --all-features --all-targets
actually works.
squash! Add some missing imports
circmgr: Declare builder() unconditionally.2023-03-22T16:35:41ZNick Mathewsonnickm@torproject.org2023-03-16T17:06:18Zurn:sha1:35967ca38d52fb138dd41837df5db8dd93ec1087
(Still, only expose it when experimental-api is enabled.)
circmgr: Begin an HS circuit pool structure2023-03-22T15:52:17ZNick Mathewsonnickm@torproject.org2023-03-15T17:58:20Zurn:sha1:adafae8b3f118061789dd7cc37dcc3f072fdb913
This is now enough to launch circuits on demand. It still needs to
pre-build the first three hops, and to retry on failure.
circmgr: Add a usage for building the beginning of an hs circ2023-03-22T15:52:17ZNick Mathewsonnickm@torproject.org2023-03-15T14:41:07Zurn:sha1:dce4da55ae20d4867d5caf79adc6402fe03559bd
This only builds the first 3 hops. It can be extended to a fourth
hop later -- or not, depending on the circuit kind.
circmgr: Functions to launch an unmanaged circuit.2023-03-22T15:52:11ZNick Mathewsonnickm@torproject.org2023-03-15T13:56:34Zurn:sha1:ec8c7eec4effc2b64e3aa616663387ef03a62eae
We'll use this to implement the circuits used by onion circuits.
hsclient: Abolish knowledge of HS circuits in circmgr2023-03-01T18:12:29ZIan Jacksonijackson@chiark.greenend.org.uk2023-03-01T16:46:15Zurn:sha1:bf2c0d6ff8e10f222624e6c854a4effb05aca337
Abolish CircMgr::get_or_launch_onion_client and everything to support
it. We have decided that `.onion` diversion ccan't/shouldn't occur in
tor-circmgr. Probably, it should occur much higher up - arti-client
maybe - since it will sometimes need ambient authority (KS_hsc_*).
Now all knowledge of HS connections is in tor-hsclient. This
gets rid of a layering inversion and the trait needed for tor-circmgr
to do the upcall to tor-hsclient.
tor-circmgr: Provide testing feature and TestConfig2023-03-01T16:20:16ZIan Jacksonijackson@chiark.greenend.org.uk2023-02-23T17:24:43Zurn:sha1:feab6faa9e21d29c53ea144634af3ebedd9e196e
Like the similar thing in tor-guardmgr.
HS API: Remove HS client keys from circmgr API2023-03-01T16:18:09ZIan Jacksonijackson@chiark.greenend.org.uk2023-02-22T15:37:00Zurn:sha1:a45acb3905b330ea573be94a3979f1dda8551be0
*If* we're going to retain any HS knowledge in circmgr, it definitely
doesn't need to know about per-operation client secrets.
(Maybe there might be ambient secrets, used for .onion diversion, but
they don't need to be in this API.)
HS planning: Discuss whether to remove all HS code from circmgr2023-03-01T16:18:09ZIan Jacksonijackson@chiark.greenend.org.uk2023-02-22T15:33:57Zurn:sha1:feeb38c750a82066e100ba232eba0b0861374bf9HS planning: Intend for HS connector to do all lifecycle mgmt2023-03-01T16:17:47ZIan Jacksonijackson@chiark.greenend.org.uk2023-02-22T15:25:34Zurn:sha1:06e6e118867bf60d3fc0fe4d4501cbd844eb48f3
Otherwise there has to be a state entry in the circmgr *and* a state
entry in the hs connector, for every HS. This division of
responsibilit will be confusing.
The HS code will then be more completely just a layer on top of circmgr.