mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.1.1 2023-02-01T15:36:29Z 2023-02-01T15:36:29Z Nick Mathewson nickm@torproject.org 2023-02-01T15:36:29Z urn:sha1:7c1b6a5a81e382be6210c7e2b0aae9695ad0bef4 These crates had API or behavior changes that may affect downstream crates. Fortunately, they're all version 0.x, and don't need minor bumps for this. 2023-02-01T15:23:58Z Nick Mathewson nickm@torproject.org 2023-02-01T15:23:58Z urn:sha1:66f594a4b6fac81137886be90a7bda3687923d48 These changes influence behavior, but not effect compatibility. (If I messed up, and any crate except for `arti` has non-breaking API changes, that's still fine, since they are all version 0.x.) 2022-11-30T20:10:16Z Nick Mathewson nickm@torproject.org 2022-11-30T20:10:16Z urn:sha1:38bef96b99dbf17922dc601d4250abc0368b519f We made this job easy this time around: by incrementing our MSRV, we have forced ourselves to do at least a minor bump everywhere. 2022-11-30T00:30:50Z Nick Mathewson nickm@torproject.org 2022-11-30T00:30:50Z urn:sha1:9765fdc2e6443aece135f2287136d1347094c3f2 2022-11-28T22:29:32Z Nick Mathewson nickm@torproject.org 2022-11-28T20:24:40Z urn:sha1:820657b6bc042d2d93f50946969120cead04e829 This makes a `pt_state` directory inside .local/share/arti (or the local equivalent), right next to our existing `state` dir. Ideally we would use a separate directory for each PT, but we have a very fuzzy "what is a specific PT" notion. Closes #667 2022-11-28T22:29:23Z Nick Mathewson nickm@torproject.org 2022-11-28T18:34:48Z urn:sha1:6bde90ce01e341eb995005f26305e177c0b906ef Per convention, have a `full` feature. Also, downgrade the 'TODO pt-client' entries in README::limitations, since they are not blockers for 1.1.0. 2022-11-28T22:29:23Z Nick Mathewson nickm@torproject.org 2022-11-28T18:16:58Z urn:sha1:8d0ac9bdc852802fb034d2b72cde79094f673222 These are implementation details and we don't want to mark them as stable. To do this, I needed to apply some additional options to the example code's configuration in Cargo.toml. 2022-11-28T18:52:21Z eta tor@eta.st 2022-11-22T16:24:15Z urn:sha1:3b41c78d6fc5eceac3b45ea9ef1540b72f9b4004 This commit implements `PtMgr`, a pluggable transport manager responsible for keeping track of spawned PTs and spawning them to satisfy client requests on demand. It does this in two parts: the `PtMgr` type exported to the rest of the code, and the background `PtReactor` that actually does the spawning; this design ensures that only one attempt to spawn a PT is active at a time, and will prove useful later for implementing e.g. timeouts. A few changes were necessary to the rest of the code in order to make this all work out. Namely: - `TransportRegistry`'s API didn't make any sense for two reasons: - It wasn't feasible for implementors to implement `ChannelFactory`, since that'd require constructing a `ChanBuilder` (which requires a bootstrap reporting event sender). - Treating the PT manager as a registry is over-general; it's only necessary for it to spawn pluggable transports, so saddling it with other concerns didn't make any sense. - (It's possible to get extensibility for arbitrary user customization by just letting the user swap in a new `ChannelFactory`, anyway.) - Therefore, the `PtMgr` implements the new `AbstractPtMgr` trait, which is far more narrowly focused; this only exists to solve a dependency loop, and is documented as such. - This provides a `TransportHelper` instead of a `ChannelFactory`. 2022-11-16T11:39:25Z eta tor@eta.st 2022-11-03T14:36:31Z urn:sha1:1c9f6fb179bc88b77079026f249eb3e1678617ca This brings the draft configuration mechanisms in tor-ptmgr in line with the config in other crates, using builders. It also plumbs the config type through into the main `arti-client` config, and adds some example lines to `arti-example-config.toml`. 2022-11-10T15:57:33Z Nick Mathewson nickm@torproject.org 2022-11-07T19:18:02Z urn:sha1:936920b26e43447a010e249a9b5a5b9f69ca0da1