mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.0.4 2022-01-31T16:05:34Z 2022-01-31T16:05:34Z Nick Mathewson nickm@torproject.org 2022-01-31T16:05:34Z urn:sha1:329bde58ddc572cc6db198da279f180a1ac6895d tor-netdir needs to bump because tor-netdoc bumped, even though there were no other changes in tor-netdir. Whoops. tor-guardmgr needs to bump because it already published, with the older tor-netdir. 2022-01-31T15:30:52Z Nick Mathewson nickm@torproject.org 2022-01-31T15:30:52Z urn:sha1:01d99373089f8131d1df9758fce45ffaa3fbf659 2022-01-28T13:38:54Z Nick Mathewson nickm@torproject.org 2022-01-28T13:38:54Z urn:sha1:2f51add62f715b07fa420042081fd4ede47724c7 2022-01-26T19:31:49Z Nick Mathewson nickm@torproject.org 2022-01-26T19:31:49Z urn:sha1:9c043a648a1a05ae0f2fcb30990f7a8eda831e63 2022-01-25T18:16:39Z Nick Mathewson nickm@torproject.org 2022-01-24T20:12:49Z urn:sha1:d1d121aac6c6dd5bd0b31ef6e01614da36071221 This change uses the async-native-tls crate for everything, and deletes some duplicated code. 2022-01-25T18:16:39Z Nick Mathewson nickm@torproject.org 2022-01-21T14:28:11Z urn:sha1:8def5a0d89603c8f1cfd91109bb439f1881d968f This is based on @janimo's approach in !74, but diverges in a few important ways. 1. It assumes that something like !251 will merge, so that we can have separate implementations for native_tls and rustls compiled at the same time. 2. It assumes that we can implement this for the futures::io traits only with no real penalty. 3. It uses the `x509-signature` crate to work around the pickiness of the `webpki` crate. If webpki eventually solves their [bug 219](https://github.com/briansmith/webpki/issues/219), we can remove a lot of that workaround. Closes #86. 2022-01-19T20:47:26Z Nick Mathewson nickm@torproject.org 2022-01-19T19:12:08Z urn:sha1:17920e43f84fd6c4c3f9abe77c7b477d6c17602c This will make it easier to implement them using some other TLS provider as well, without having to duplicate all of our code. 2022-01-19T13:40:36Z Nick Mathewson nickm@torproject.org 2022-01-19T13:40:36Z urn:sha1:db2ca6ebc4721eecfc8273f152b479da646db91c 2022-01-18T18:06:08Z Nick Mathewson nickm@torproject.org 2022-01-17T22:11:18Z urn: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. 2022-01-18T18:06:08Z Nick Mathewson nickm@torproject.org 2022-01-13T18:55:34Z urn:sha1:f34faec7d96fdb87aa84744950ac37264b215965 The interface is similar to the one exposed by `arti-client`: it internally uses postage::watch to give a series of events showing when a bootstrap status is changing. Thanks to the existing state/driver separation in the DirMgr design we don't need much new logic: each download state needs to expose (internally) how far along it is in its download, which the bootstrap code passes to the DirMgr if it has changed. I believe that in the long run, we'll probably want to expose more (or different) information here, and we'll want to process it differently. With that in mind, I've made the API for `DirBootstrapStatus` deliberately narrow, so that we can change its of its internal later on without breaking code that depends on it. (The information exposed by this commit is not yet summarized in `arti-client`.) Part of #96.