2d4507ff35
With this change, each individual identity type becomes optional. The functions that expose them unconditionally are now in a "legacy" trait that only some downstream types are expected to implement. There are new convenience APIs in HasRelayIds: * to return Option<&keytype>, * to see if one identity-set contains another. This commit will break several downstream crates! For the reviewer's convenience, I will put the fixes for those crates into a series of squash! commits on this one. tor-netdir ---------- Revise tor-netdir to accept optional identities. This required some caveats and workarounds about the cases where we have to deal with a key type that the tor-netdir code does not currently recognize at all. If we start to add more identity types in the future, we may well want more internal indices in this code. tor-proto --------- In order to make tor-proto support optional identities, there were fewer changes than I thought. Some "check" functions needed to start looking at "all the ids we want" rather than at "the two known IDs"; they also needed to accommodate that case where we don't have an ID that we demand. This change will also help with bridges, since we want to be able to connect to a bridge without knowing all of its IDs up front. The protocol currently _requires_ the two current ID types in some places. To deal with that, I added a new `MissingId` error. I also removed a couple of unconditional identity accessors for chanmgr; code should use `target().identity(...)` instead. tor-chanmgr ----------- This is an incomplete conversion: it does not at all handle channel targets without Ed25519 identities yet. It still uses those identities to index its internal map from identity to channel; but it gives a new `MissingId` error type if it's given a channel target that doesn't have one. We'll want to revise the map type again down the road when we implement bridges, but I'd rather not step on the channel-padding work in progress right now. tor-guardmgr ------------ This change is mostly a matter of constructing owned identity types more sensibly, rather than unwrapping them directly. There are some places marked with TODOs where we still depend on particular identity types, because of how the directory protocol works. This will need revisiting when we add bridge support here. tor-circmgr ----------- These changes are just relatively simple API changes in the tests. |
||
|---|---|---|
| .gitlab/issue_templates | ||
| arti-corpora@bd32029dad | ||
| crates | ||
| doc | ||
| maint | ||
| tests/chutney | ||
| .ecrc | ||
| .editorconfig | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .gitmodules | ||
| .typos.toml | ||
| CHANGELOG.md | ||
| CODE_OF_CONDUCT | ||
| CONTRIBUTING.md | ||
| Cargo.lock | ||
| Cargo.toml | ||
| LICENSE-APACHE | ||
| LICENSE-MIT | ||
| README.md | ||
| WANT_FROM_OTHER_CRATES | ||
| clippy-nightly.toml | ||
| clippy.toml | ||
| tomlfmt.toml | ||
README.md
Arti: reimplementing Tor in Rust
Arti is a project to produce an embeddable, production-quality implementation of the Tor anonymity protocols in the Rust programming language.
Arti is not ready for production use; see below for more information.
Links:
Why rewrite Tor in Rust?
Rust is more secure than C. Despite our efforts, it's all too simple to mess up when using a language that does not enforce memory safety. We estimate that at least half of our tracked security vulnerabilities would have been impossible in Rust, and many of the others would have been very unlikely.
Rust enables faster development than C. Because of Rust's expressiveness and strong guarantees, we've found that we can be far more efficient and confident writing code in Rust. We hope that in the long run this will improve the pace of our software development.
Arti is more flexible than our C tor implementation. Unlike our C tor,
which was designed as SOCKS proxy originally, and whose integration features
were later "bolted on", Arti is designed from the ground up to work as a
modular, embeddable library that other applications can use.
Arti is cleaner than our C tor implementation. Although we've tried to develop C tor well, we've learned a lot since we started it back in 2002. There are lots of places in the current C codebase where complicated "spaghetti" relationships between different pieces of code make our software needlessly hard to understand and improve.
Current status
Arti is a work-in-progress. It can connect to the Tor network, bootstrap a view of the Tor directory, and make anonymized connections over the network.
We're not aware of any critical security features missing in Arti; but however, since Arti is comparatively new software, you should probably be cautious about using it in production.
Now that Arti has reached version 0.1.0, we believe it is suitable for
experimental embedding within other Rust applications. We will try to keep
the API as exposed by the top-level arti_client crate more or less stable
over time. (We may have to break existing programs from time to time, but we
will try not to do so without a very good reason. Either way, we will try to
follow Rust's semantic versioning best practices.)
Trying it out today
Arti can act as a SOCKS proxy that uses the Tor network.
To try it out, compile and run the arti binary using the below. It will open a
SOCKS proxy on port 9150.
$ cargo run -p arti --release -- proxy
Again, do not use this program yet if you seriously need anonymity, privacy, security, or stability.
You can build a binary (but not run it) with:
$ cargo build -p arti --release
The result can be found as target/release/arti.
If you run into any trouble building the program, please have a look at the troubleshooting guide.
Custom compile-time options
Arti has a number of configurable Cargo features that, among other things, can affect which asynchronous runtime to use. Use
$ cargo doc -p arti --open
to view the Arti crate-level docs in your browser, which contain a full list.
You can pass these features to Cargo while building with --features (note that you might need --no-default-features
in order to not use the default runtime choices, too). For example, to use async-std instead of Tokio:
$ cargo run -p arti --no-default-features --features async-std,native-tls -- proxy
Use target/release/arti --version to see what features the currently built Arti binary is using.
Minimum supported Rust Version
Our current Minimum Supported Rust Version (MSRV) is 1.56.
When increasing this MSRV, we won't require any Rust version released in the last six months. (That is, we'll only require Rust versions released at least six months ago.)
We will not increase MSRV on PATCH releases, though our dependencies might.
We won't increase MSRV just because we can: we'll only do so when we have a reason. (We don't guarantee that you'll agree with our reasoning; only that it will exist.)
Helping out
Have a look at our contributor guidelines.
Roadmap
Thanks to a generous grant from Zcash Open Major Grants (ZOMG), we're able to devote some significant time to Arti in the years 2021-2022. Here is our rough set of plans for what we hope to deliver when.
The goal times below are complete imagination, based on broad assumptions about developer availability. Please don't take them too seriously until we can get our project manager to sign off on them.
-
Arti 0.0.1: Minimal Secure Client (Goal: end of October 2021??)
- Target audience: developers
- Guard support
- Stream Isolation
- High test coverage
- Draft APIs for basic usage
- Code cleanups
- and more...
-
Arti 0.1.0: Okay for experimental embedding (Goal: Mid March, 2022??)
- Target audience: beta testers
- Performance: preemptive circuit construction
- Performance: circuit build timeout inference
- API support for embedding
- API support for status reporting
- Correct timeout behavior
- and more...
-
Arti 1.0.0: Initial stable release (Goal: Mid September, 2022??)
- Target audience: initial users
- Stable API
- Stable CLI
- Stable configuration format
- Automatic detection and response of more kinds of network problems
- At least as secure as C Tor
- Client performance similar to C Tor
- More performance work
- and more...
-
Arti 1.1.0: Anti-censorship features (Goal: End of October, 2022?)
- Target audience: censored users
- Bridges
- Pluggable transports
- and more...?
-
Arti 1.2.0: Onion service support (not funded, timeframe TBD)
-
Arti 2.0.0: Feature parity with C tor as a client (not funded, timeframe TBD)
-
Arti ?.?.?: Relay support
How can I report bugs?
When you find bugs, please report them on our bugtracker. If you don't already have an account there, you can either request an account or report a bug anonymously.
How can I help out?
See CONTRIBUTING.md for a few ideas for how to get
started.
License
This code is licensed under either of
at your option.
Contribution
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.
(The above notice, or something like it, seems to be pretty standard in Rust projects, so I'm using it here too. This instance of it is copied from the RustCrypto project's README.md file.)