arti/crates/tor-checkable
Nick Mathewson de13a7319b Bump patchlevel versions on crates with smaller changes
Done with the commands below.

The following crates have had various changes, and should get a
patchlevel bump. Since they are pre-1.0, we do not need to
distinguish new APIs from other changes.

```
cargo set-version --bump patch -p arti-client
cargo set-version --bump patch -p safelog
cargo set-version --bump patch -p tor-bytes
cargo set-version --bump patch -p tor-cert
cargo set-version --bump patch -p tor-circmgr
cargo set-version --bump patch -p tor-config
cargo set-version --bump patch -p tor-consdiff
cargo set-version --bump patch -p tor-dirclient
cargo set-version --bump patch -p tor-dirmgr
cargo set-version --bump patch -p tor-error
cargo set-version --bump patch -p tor-hsservice
cargo set-version --bump patch -p tor-linkspec
cargo set-version --bump patch -p tor-llcrypto
cargo set-version --bump patch -p tor-netdir
cargo set-version --bump patch -p tor-netdoc
cargo set-version --bump patch -p tor-proto
cargo set-version --bump patch -p tor-rpcbase
cargo set-version --bump patch -p tor-socksproto
```

This crate has new features, but no new non-experimental Rust APIs.
So even though it is post-1.0, it gets a patchlevel bump.

```
cargo set-version --bump patch -p arti
```
2023-06-30 08:42:21 -04:00
..
src lints: Run maint/add_warning to actually apply new lints 2023-06-21 12:15:41 +01:00
Cargo.toml Bump patchlevel versions on crates with smaller changes 2023-06-30 08:42:21 -04:00
README.md Move all crates into a `crates` subdirectory. 2021-08-27 09:53:09 -04:00

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