0.23.7 — diff review from 0.22.4 only (older version)
From bytecodealliance/wasmtime. By Andrew Brown.
These reviews are from cargo-vet. To add your review, set up cargo-vet and submit your URL to its registry.
The current version of Rustls is 0.23.20.
0.22.2 (older version)
From kornelski/crev-proofs copy of git.savannah.gnu.org.
Packaged for Guix (crates-tls)
0.21.12 — diff review from 0.21.8 only (older version)
From zcash/rust-ecosystem copy of zcash/librustzcash. By Daira Emma Hopwood.
A comment in get_sni_extension asks whether the behaviour of parsing an IPv4 or IPv6 address in a host_name field of a server_name extension, but then ignoring the extension (because 'Literal IPv4 and IPv6 addresses are not permitted in "HostName"'), as the server, is compliant with RFC 6066. As an original author of RFC 3546 which has very similar wording, I can speak to the intent: yes this is fine. The client is clearly nonconformant in this case, but the server isn't.
RFC 3546 said "If the server understood the client hello extension but does not recognize the server name, it SHOULD send an "unrecognized_name" alert (which MAY be fatal)." This wording was preserved in RFC 5746, and then updated in RFC 6066 to:
If the server understood the ClientHello extension but does not recognize the server name, the server SHOULD take one of two actions: either abort the handshake by sending a fatal-level unrecognized_name(112) alert or continue the handshake. It is NOT RECOMMENDED to send a warning-level unrecognized_name(112) alert, because the client's behavior in response to warning-level alerts is unpredictable. If there is a mismatch between the server name used by the client application and the server name of the credential chosen by the server, this mismatch will become apparent when the client application performs the server endpoint identification, at which point the client application will have to decide whether to proceed with the communication.
To me it's clear that it is reasonable to consider an IP address as a name that the server does not recognize. And so the server SHOULD either send a fatal unrecognized_name alert, or continue the handshake and let the client application decide when it "performs the server endpoint identification". There's no conformance requirement for the server to take any notice of a host_name that is "not permitted". (It would have been clearer to express this by specifying the allowed client and server behaviour separately, i.e. saying that the client MUST NOT send an IP address in host_name, and then explicitly specifying the server behaviour if it does so anyway. That's how I would write it now. But honestly this extension was one of the most bikeshedded parts of RFC 3546, to a much greater extent than I'd anticipated, and I was tired.)
0.21.6 (older version)
From bytecodealliance/wasmtime. Audited without comment by Pat Hickey.
0.20.6 (older version)
From kornelski/crev-proofs copy of salsa.debian.org.
Only in debcargo (unstable). Changelog:
- Team upload.
- Update base64 dev-dependency to 0.21
cargo-vet does not verify reviewers' identity. You have to fully trust the source the audits are from.
- safe-to-deploy (implies safe-to-run)
-
This crate will not introduce a serious security vulnerability to production software exposed to untrusted input. More…
- safe-to-run
Implied by other criteria
This crate can be compiled, run, and tested on a local workstation or in controlled automation without surprising consequences. More…
- unknown
-
May have been packaged automatically without a review
This review is from Crev, a distributed system for code reviews. To add your review, set up cargo-crev.
The current version of Rustls is 0.23.20.
0.16.0 (older version) Thoroughness: None Understanding: None
by kornelski on 2020-06-15
Positive external audit: https://github.com/ctz/rustls/blob/master/audit/TLS-01-report.pdf
Lib.rs has been able to verify that all files in the crate's tarball, except Cargo.lock,
are in the crate's repository with a git tag matching the version. Please note that this check is still in beta, and absence of this confirmation does not mean that the files don't match.
Crates in the crates.io registry are tarball snapshots uploaded by crates' publishers. The registry is not using crates' git repositories, so there is a possibility that published crates have a misleading repository URL, or contain different code from the code in the repository.
To review the actual code of the crate, it's best to use cargo crev open rustls. Alternatively, you can download the tarball of rustls v0.23.20 or view the source online.
No new unsafe code.