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.
|
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
README.md
tor-checkable
Traits for wrapping up signed and/or time-bound objects
Overview
Frequently (for testing reasons or otherwise), we want to ensure that an object can only be used if a signature is valid, or if some timestamp is recent enough.
As an example, consider a self-signed certificate. You can parse it cheaply enough (and find its key by doing so), but you probably want to make sure that nobody will use that certificate unless its signature is correct and its timestamps are not expired.
With the tor-checkable crate, you can instead return an object that represents the certificate in its unchecked state. The caller can access the certificate, but only after checking the signature and the time.
This crate is part of Arti, a project to implement Tor in Rust. Many other crates in Arti depend on it, but it should be generally useful outside of Arti.
Design notes and alternatives
The types in this crate provide functions to return the underlying
objects without checking them. This is very convenient for testing,
though you wouldn't want to do it in production code. To prevent
mistakes, these functions all begin with the word dangerously.
Another approach you might take is to put signature and timeliness checks inside your parsing function. But if you do that, it will get hard to test your code: you will only be able to parse certificates that are valid when the parser is running. And if you want to test parsing a new kind of certificate, you'll need to make sure to put a valid signature on it. (And all of this signature parsing will slow down any attempts to fuzz your parser.)
You could have your parser take a flag to tell it whether to check signatures and timeliness, but that could be error prone: if anybody sets the flag wrong, they will skip doing the checks.
License: MIT OR Apache-2.0