4841b50c9f
I found these versions empirically, by using the following process:
First, I used `cargo tree --depth 1 --kind all` to get a list of
every immediate dependency we had.
Then, I used `cargo upgrade --workspace package@version` to change
each dependency to the earliest version with which (in theory) the
current version is semver-compatible. IOW, if the current version
was 3.2.3, I picked "3". If the current version was 0.12.8, I
picked "0.12".
Then, I used `cargo +nightly upgrade -Z minimal-versions` to
downgrade Cargo.lock to the minimal listed version for each
dependency. (I had to override a few packages; see .gitlab-ci.yml
for details).
Finally, I repeatedly increased the version of each of our
dependencies until our code compiled and the tests passed. Here's
what I found that we need:
anyhow >= 1.0.5: Earlier versions break our hyper example.
async-broadcast >= 0.3.2: Earlier versions fail our tests.
async-compression 0.3.5: Earlier versions handled futures and tokio
differently.
async-trait >= 0.1.2: Earlier versions are too buggy to compile our
code.
clap 2.33.0: For Arg::default_value_os().
coarsetime >= 0.1.20: exposed as_ticks() function.
curve25519-dalek >= 3.2: For is_identity().
generic-array 0.14.3: Earlier versions don't implement
From<&[T; 32]>
httparse >= 1.2: Earlier versions didn't implement Error.
itertools at 0.10.1: For at_most_once.
rusqlite >= 0.26.3: for backward compatibility with older rustc.
serde 1.0.103: Older versions break our code.
serde_json >= 1.0.50: Since we need its Value type to implement Eq.
shellexpand >= 2.1: To avoid a broken dirs crate version.
tokio >= 1.4: For Handle::block_on().
tracing >= 0.1.18: Previously, tracing_core and tracing had separate
LevelFilter types.
typenum >= 1.12: Compatibility with rust-crypto crates
x25519-dalek >= 1.2.0: For was_contributory().
Closes #275.
|
||
|---|---|---|
| .. | ||
| fuzz | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
README.md
tor-socksproto
Implements SOCKS in the flavors provided by Tor.
Overview
SOCKS is an old and somewhat janky protocol for telling a TCP proxy where to connect. Versions 4, 4a, and 5 are sometimes encountered in the wild.
The tor-socksproto crate tries to hide the actual details of the
protocol, and expose a stateful handshake type that eventually
provides a [SocksRequest] or an error. It is part of
Arti, a project to
implement Tor in Rust.
At present, it is only used to provide a
SOCKS proxy over the Tor network, but eventually it may be used
to implement support for connecting to the Tor network over a
SOCKS proxy.
This crate may be a good choice for you if you need a SOCKS implementation that "behaves like Tor", but otherwise it is probably better to use some other SOCKS crate.
For more information about SOCKS:
- SOCKS5 (which is preferred) is specified in RFC 1928, and see also RFC 1929 for Username/Password authentication in SOCKS5.
- The wikipedia article is the best surviving documentation for SOCKS4 and SOCKS4a.
- See socks-extensions.txt for a description of Tor's extensions and restrictions on the SOCKS protocol.
Design notes
Arti uses this crate instead of some other SOCKS implementation, for two reasons:
- First, because we need to support Tor SOCKS extensions.
- Second, and because we sometimes need to see particular details of the individual handshakes that most other SOCKS implementations don't expose. (For example, if we are told to connect to a raw IP address, the type of the handshake can help us guess whether that IP address came from a DNS response–in which case we should warn about a possible DNS leak.)
Currently, tor-socksproto does no networking code: it only
implements the server (proxy) side of the SOCKS handshake by
handling a series of bytes. We may (or may not) want to add
network functionality to this crate or elsewhere in the future.
We'll definitely want to add client functionality.
Possibly, this approach will prove useful for other uses. If it does, We can put the tor-only functionality behind a Cargo build feature, so that others can use this crate more safely.
License: MIT OR Apache-2.0