mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.1.0 2022-11-30T20:10:16Z 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 2022-10-26T15:07:30Z eta tor@eta.st 2022-10-19T13:36:40Z urn:sha1:a118a639edfe2130931ca0003368e31834ce0669 The new `ipc` module inside `tor-ptmgr` implements the Pluggable Transport Specification version 1 (`pt-spec.txt`, https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/pt-spec.txt). This enables module users to spawn pluggable transport binaries inside a child process asynchronously, and receive structured information about how to connect to the transports provided by said binaries. Internally, this is structured as a pure set of serialisers and deserialisers for the protocol in the specification (in the form of environment variables, and the PT's stdout), a wrapper to run the PT binary and enable accessing its output asynchronously, and a user-facing wrapper that handles ensuring all the requested transports launched properly. The included `run-pt` example is an exceedingly minimal wrapper program that was useful in testing. More tests can and should be added in a further MR. closes arti#394; part of arti#69 2022-10-03T14:01:46Z Nick Mathewson nickm@torproject.org 2022-10-03T14:01:46Z urn:sha1:102e3c221dfadd6578cc6001f0566897fa9acaf8 (Since the APIs for the `Schedule::sleep*` functions changed, this is a breaking change in tor-rtcompat. Therefore, the Runtime trait in tor-rtcompat is now a different trait. Therefore, anything that uses the Runtime trait in its APIs has also broken.)