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

(16 total, 6 outdated, 2 possibly insecure)

CrateRequiredLatestStatus
 agave-feature-set=2.2.72.2.12out of date
 bincode^1.3.32.0.1out of date
 bytemuck^1.21.01.23.0up to date
 digest^0.10.70.10.7up to date
 ed25519-dalek ⚠️=1.0.12.1.1out of date
 lazy_static^1.5.01.5.0up to date
 libsecp256k1^0.6.00.7.2out of date
 openssl ⚠️^0.100.10.72maybe insecure
 sha3^0.10.80.10.8up to date
 solana-ed25519-program=2.2.22.2.2up to date
 solana-message=2.2.12.3.0out of date
 solana-precompile-error=2.2.12.2.1up to date
 solana-pubkey=2.2.12.3.0out of date
 solana-sdk-ids=2.2.12.2.1up to date
 solana-secp256k1-program=2.2.12.2.1up to date
 solana-secp256r1-program=2.2.22.2.2up to date

Dev dependencies

(6 total, 1 outdated)

CrateRequiredLatestStatus
 hex^0.4.30.4.3up to date
 rand^0.70.9.1out of date
 solana-instruction=2.2.12.2.1up 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.1up 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.