It was discovered that in ostree before 2022.5 the ed25519 signature
verification code did not check that the signature is the correct length. As a
result, if the signature is too short, libsodium would end up reading a few
bytes out of bounds. Theoretically, this could cause an bad signature to be
accepted. However, for this to happen, the out-of-bounds data would need to
form a valid signature when combined with the actual data, which means that the
file must have actually been signed. A more likely possibility is that
libsodium winds up reading into an adjacent unmapped page and crashes.

The second was that if there are N keys in the keyring, M revoked keys, and O
signatures, libostree will consume O(N * M * O) (cubic) time checking for key
revocation. This can be reduced to O(N * O + M log M + N) time or better by
using an associative array to filter out revoked keys and by moving the
revocation check out of the for-each-signature loop.

References:
https://github.com/ostreedev/ostree/security/advisories/GHSA-gqf4-p3gv-g8vw
https://github.com/ostreedev/ostree/commit/83e6357186be11fb8f2a6b66fab3730c44ee59dd