This project might be open to known security vulnerabilities, which can be prevented by tightening the version range of affected dependencies. Find detailed information at the bottom.
crev-data(11 total, 8 outdated, 3 possibly insecure)
| Crate | Required | Latest | Status |
|---|---|---|---|
| chrono ⚠️ | ^0.4 | 0.4.42 | maybe insecure |
| common_failures | ^0.1 | 0.2.0 | out of date |
| crev-common | ^0.9 | 0.26.1 | out of date |
| derive_builder | ^0.7 | 0.20.2 | out of date |
| ed25519-dalek ⚠️ | ^1.0.0-pre.1 | 2.2.0 | out of date |
| failure | ^0.1 | 0.1.8 | up to date |
| rand | ^0.6 | 0.9.2 | out of date |
| semver | ^0.9 | 1.0.27 | out of date |
| serde | ^1 | 1.0.228 | up to date |
| serde_yaml ⚠️ | ^0.8 | 0.9.34+deprecated | out of date |
| typed-builder | ^0.3 | 0.23.0 | out of date |
serde_yaml: Uncontrolled recursion leads to abort in deserializationAffected versions of this crate did not properly check for recursion while deserializing aliases.
This allows an attacker to make a YAML file with an alias referring to itself causing an abort.
The flaw was corrected by checking the recursion depth.
chrono: Potential segfault in `localtime_r` invocationsUnix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.
No workarounds are known.
ed25519-dalek: Double Public Key Signing Function Oracle Attack on `ed25519-dalek`Versions of ed25519-dalek prior to v2.0 model private and public keys as
separate types which can be assembled into a Keypair, and also provide APIs
for serializing and deserializing 64-byte private/public keypairs.
Such APIs and serializations are inherently unsafe as the public key is one of
the inputs used in the deterministic computation of the S part of the signature,
but not in the R value. An adversary could somehow use the signing function as
an oracle that allows arbitrary public keys as input can obtain two signatures
for the same message sharing the same R and only differ on the S part.
Unfortunately, when this happens, one can easily extract the private key.
Revised public APIs in v2.0 of ed25519-dalek do NOT allow a decoupled
private/public keypair as signing input, except as part of specially labeled
"hazmat" APIs which are clearly labeled as being dangerous if misused.