<feed xmlns='http://www.w3.org/2005/Atom'>
<title>mirrors/arti.git/crates/tor-circmgr/src/lib.rs, branch arti-v1.1.5</title>
<subtitle>mirror of https://gitlab.torproject.org/tpo/core/arti
</subtitle>
<id>http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.1.5</id>
<link rel='self' href='http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.1.5'/>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/'/>
<updated>2023-05-16T13:02:09Z</updated>
<entry>
<title>Refactor ClientCirc APIs to use Arc&lt;ClientCirc&gt;.</title>
<updated>2023-05-16T13:02:09Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2023-05-16T13:02:09Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=ee390c423e7df0b678d77a8685f45dc526581910'/>
<id>urn:sha1:ee390c423e7df0b678d77a8685f45dc526581910</id>
<content type='text'>
Now ClientCirc is no longer `Clone`, and the things that need it
to be `Clone` instead return and use an Arc&lt;ClientCirc&gt;
We're doing this so that ClientCirc can participate in the RPC
system, and so that its semantics are more obvious.

Closes #846.

Thanks to the type system, this was a much simpler refactoring than
I had feared it would be.
</content>
</entry>
<entry>
<title>Add some missing imports</title>
<updated>2023-03-28T14:49:45Z</updated>
<author>
<name>Ian Jackson</name>
<email>ijackson@chiark.greenend.org.uk</email>
</author>
<published>2023-03-28T13:16:17Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=00e522a91ac1ecd59f48dc97a64319d748f2c482'/>
<id>urn:sha1:00e522a91ac1ecd59f48dc97a64319d748f2c482</id>
<content type='text'>
Now
  nailing-cargo +stable clippy -p tor-hsclient --all-features --all-targets
actually works.

squash! Add some missing imports
</content>
</entry>
<entry>
<title>circmgr: Declare builder() unconditionally.</title>
<updated>2023-03-22T16:35:41Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2023-03-16T17:06:18Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=35967ca38d52fb138dd41837df5db8dd93ec1087'/>
<id>urn:sha1:35967ca38d52fb138dd41837df5db8dd93ec1087</id>
<content type='text'>
(Still, only expose it when experimental-api is enabled.)
</content>
</entry>
<entry>
<title>circmgr: Begin an HS circuit pool structure</title>
<updated>2023-03-22T15:52:17Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2023-03-15T17:58:20Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=adafae8b3f118061789dd7cc37dcc3f072fdb913'/>
<id>urn:sha1:adafae8b3f118061789dd7cc37dcc3f072fdb913</id>
<content type='text'>
This is now enough to launch circuits on demand.  It still needs to
pre-build the first three hops, and to retry on failure.
</content>
</entry>
<entry>
<title>circmgr: Add a usage for building the beginning of an hs circ</title>
<updated>2023-03-22T15:52:17Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2023-03-15T14:41:07Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=dce4da55ae20d4867d5caf79adc6402fe03559bd'/>
<id>urn:sha1:dce4da55ae20d4867d5caf79adc6402fe03559bd</id>
<content type='text'>
This only builds the first 3 hops. It can be extended to a fourth
hop later -- or not, depending on the circuit kind.
</content>
</entry>
<entry>
<title>circmgr: Functions to launch an unmanaged circuit.</title>
<updated>2023-03-22T15:52:11Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2023-03-15T13:56:34Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=ec8c7eec4effc2b64e3aa616663387ef03a62eae'/>
<id>urn:sha1:ec8c7eec4effc2b64e3aa616663387ef03a62eae</id>
<content type='text'>
We'll use this to implement the circuits used by onion circuits.
</content>
</entry>
<entry>
<title>hsclient: Abolish knowledge of HS circuits in circmgr</title>
<updated>2023-03-01T18:12:29Z</updated>
<author>
<name>Ian Jackson</name>
<email>ijackson@chiark.greenend.org.uk</email>
</author>
<published>2023-03-01T16:46:15Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=bf2c0d6ff8e10f222624e6c854a4effb05aca337'/>
<id>urn:sha1:bf2c0d6ff8e10f222624e6c854a4effb05aca337</id>
<content type='text'>
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.
</content>
</entry>
<entry>
<title>tor-circmgr: Provide testing feature and TestConfig</title>
<updated>2023-03-01T16:20:16Z</updated>
<author>
<name>Ian Jackson</name>
<email>ijackson@chiark.greenend.org.uk</email>
</author>
<published>2023-02-23T17:24:43Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=feab6faa9e21d29c53ea144634af3ebedd9e196e'/>
<id>urn:sha1:feab6faa9e21d29c53ea144634af3ebedd9e196e</id>
<content type='text'>
Like the similar thing in tor-guardmgr.
</content>
</entry>
<entry>
<title>HS API: Remove HS client keys from circmgr API</title>
<updated>2023-03-01T16:18:09Z</updated>
<author>
<name>Ian Jackson</name>
<email>ijackson@chiark.greenend.org.uk</email>
</author>
<published>2023-02-22T15:37:00Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=a45acb3905b330ea573be94a3979f1dda8551be0'/>
<id>urn:sha1:a45acb3905b330ea573be94a3979f1dda8551be0</id>
<content type='text'>
*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.)
</content>
</entry>
<entry>
<title>HS planning: Discuss whether to remove all HS code from circmgr</title>
<updated>2023-03-01T16:18:09Z</updated>
<author>
<name>Ian Jackson</name>
<email>ijackson@chiark.greenend.org.uk</email>
</author>
<published>2023-02-22T15:33:57Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=feeb38c750a82066e100ba232eba0b0861374bf9'/>
<id>urn:sha1:feeb38c750a82066e100ba232eba0b0861374bf9</id>
<content type='text'>
</content>
</entry>
</feed>
