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.

Crate agave-precompiles

Dependencies

(14 total, 3 outdated, 2 possibly insecure)

CrateRequiredLatestStatus
 agave-feature-set=2.3.32.3.3up to date
 bincode^1.3.32.0.1out of date
 digest^0.10.70.10.7up to date
 ed25519-dalek ⚠️=1.0.12.1.1out of date
 libsecp256k1^0.6.00.7.2out of date
 openssl ⚠️^0.100.10.73maybe insecure
 sha3^0.10.80.10.8up to date
 solana-ed25519-program^2.2.32.2.3up to date
 solana-message^2.4.02.4.0up to date
 solana-precompile-error^2.2.22.2.2up to date
 solana-pubkey^2.4.02.4.0up to date
 solana-sdk-ids^2.2.12.2.1up to date
 solana-secp256k1-program^2.2.12.2.3up to date
 solana-secp256r1-program^2.2.32.2.4up to date

Dev dependencies

(7 total, 1 outdated)

CrateRequiredLatestStatus
 bytemuck^1.23.01.23.1up to date
 hex^0.4.30.4.3up to date
 rand^0.70.9.1out of date
 solana-instruction^2.3.02.3.0up to date
 solana-keccak-hasher^2.2.12.2.1up to date
 solana-logger^2.3.12.3.1up to date
 solana-secp256k1-program^2.2.12.2.3up to date

Security Vulnerabilities

ed25519-dalek: Double Public Key Signing Function Oracle Attack on `ed25519-dalek`

RUSTSEC-2022-0093

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.

openssl: Use-After-Free in `Md::fetch` and `Cipher::fetch`

RUSTSEC-2025-0022

When a Some(...) value was passed to the properties argument of either of these functions, a use-after-free would result.

In practice this would nearly always result in OpenSSL treating the properties as an empty string (due to CString::drop's behavior).

The maintainers thank quitbug for reporting this vulnerability to us.