vincenzopalazzo
/
arti
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
arti/crates/tor-ptmgr/Cargo.toml

45 lines
1.5 KiB
TOML
Raw Normal View History

Add the skeleton of a tor-ptmgr crate When complete, this crate will handle launching and using pluggable transports on demand.
2022-09-23 14:47:30 +01:00
[package]
name = "tor-ptmgr"
Bump minor version of tor-rtcompat and most of its dependents (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.)
2022-10-03 15:01:46 +01:00
version = "0.1.0"
Add the skeleton of a tor-ptmgr crate When complete, this crate will handle launching and using pluggable transports on demand.
2022-09-23 14:47:30 +01:00
authors = ["The Tor Project, Inc.", "Nick Mathewson <nickm@torproject.org>"]
edition = "2021"
bump rust-version to 1.60 in every crate.
2022-11-07 19:18:02 +00:00
rust-version = "1.60"
Add the skeleton of a tor-ptmgr crate When complete, this crate will handle launching and using pluggable transports on demand.
2022-09-23 14:47:30 +01:00
license = "MIT OR Apache-2.0"
homepage = "https://gitlab.torproject.org/tpo/core/arti/-/wikis/home"
description = "Manage a set of pluggable transports to circumvent censorship"
keywords = ["tor", "arti", "censorship"]
categories = ["network-programming", "cryptography"]
repository = "https://gitlab.torproject.org/tpo/core/arti.git/"
[features]
default = ["tor-channel-factory"]
tor-channel-factory = []
[dependencies]
async-trait = "0.1.2"
tor-ptmgr/ipc: First cut of pluggable transport spawning 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-19 14:36:40 +01:00
derive_builder = { version = "0.11.2", package = "derive_builder_fork_arti" }
Add the skeleton of a tor-ptmgr crate When complete, this crate will handle launching and using pluggable transports on demand.
2022-09-23 14:47:30 +01:00
futures = "0.3.14"
tor-ptmgr: make configuration use builders, plumb into arti-client 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-03 14:36:31 +00:00
serde = { version = "1.0.103", features = ["derive"] }
Draft: Pluggable transport manager 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-22 16:24:15 +00:00
tempfile = "3.3"
tor-ptmgr/ipc: First cut of pluggable transport spawning 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-19 14:36:40 +01:00
thiserror = "1"
Draft: Pluggable transport manager 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-22 16:24:15 +00:00
tor-chanmgr = { version = "0.7.0", path = "../tor-chanmgr", features = ["pt-client"] }
Add the skeleton of a tor-ptmgr crate When complete, this crate will handle launching and using pluggable transports on demand.
2022-09-23 14:47:30 +01:00
tor-config = { version = "0.6.0", path = "../tor-config" }
tor-ptmgr/ipc: First cut of pluggable transport spawning 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-19 14:36:40 +01:00
tor-error = { version = "0.3.2", path = "../tor-error" }
tor-linkspec = { version = "0.5.1", path = "../tor-linkspec", features = ["pt-client"] }
Bump minor version of tor-rtcompat and most of its dependents (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.)
2022-10-03 15:01:46 +01:00
tor-rtcompat = { version = "0.7.0", path = "../tor-rtcompat" }
tor-ptmgr/ipc: First cut of pluggable transport spawning 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-19 14:36:40 +01:00
tor-socksproto = { version = "0.5.1", path = "../tor-socksproto" }
tracing = "0.1.18"
Add the skeleton of a tor-ptmgr crate When complete, this crate will handle launching and using pluggable transports on demand.
2022-09-23 14:47:30 +01:00
[dev-dependencies]
tor-ptmgr/ipc: First cut of pluggable transport spawning 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-19 14:36:40 +01:00
anyhow = "1.0.23"
tokio = { version = "1.7", features = [
"rt",
"rt-multi-thread",
"io-util",
"net",
"time",
"macros",
] }
tor-rtcompat = { path = "../tor-rtcompat", version = "0.7.0", features = ["tokio", "native-tls"] }
tracing-subscriber = "0.3.0"