GHSA-whwv-ppvg-jwgx: 
JavaScript vulnerability analysis and mitigation

Several checks in @veritasacta/verify returned VALID (exit 0) for records an attacker can produce:

• --key was not enforced for proof requests, admission decisions, run manifests and action bundles.
  • A record re-signed with any key verified even when the expected key was pinned with --key and --strict was set.
  • An action bundle reported signers_pinned: true for any --key. (Proof requests, admission decisions and action bundles from 0.10.0; run manifests from 0.10.1.)
• VOPRF tokens. The CLI passed --key under a name the engine never read, and the engine fell back to the token's own issuer key, so a self-issued legacy token verified against any --key. Genuine BRASS v2 tokens could not be verified on the CLI at all. (0.5.0 to 0.10.28.)
• Knowledge units with no receipts, or only receipts in formats the engine does not read, verified as valid, and receipt_sig and receipt_hash were never checked. (0.5.0 to 0.10.28.)
• --strict accepted carried keys. It accepted results that rested only on a key the file carries, although its help said such keys are always rejected. (From 0.7.0, as each carried-key format arrived, to 0.10.28.)
• verify prompt and --fips. verify prompt reported a prompt's provenance as verified without checking any signature. --fips judged the algorithm from an unsigned field, so an Ed25519 record labelled ml-dsa-65 passed. (verify prompt from 0.5.1 and --fips from 0.5.0, to 0.10.28.)
• Daemon receipts did not bind nested arguments. Receipts written by verify daemon did not bind nested tool arguments, so {query:{sql:"DROP TABLE users"}} and {query:{}} produced the same input hash. (From the daemon's first release, 0.5.0, to 0.10.28.) 0.11.0 fixes each one:
• A key that differs from the pinned one is invalid (key_mismatch).
• VOPRF tokens are checked only against the issuer key given with --key.
• A knowledge unit with nothing verified, or with receipt_sig or receipt_hash unchecked, is undecidable (exit 2).
• A result that rests only on a key the file carries is undecidable (exit 2) by default, and always under --strict. --allow-carried-key restores exit 0 and says that only the carried key was checked.
• verify prompt never reports verified provenance without a verified signature.
• --fips uses the algorithm the engine verified.
• Daemon receipts hash the canonical form of the full arguments. Also changed in 0.11.0:
• Duplicate JSON members are refused in every file a verification reads.
• Unchecked cosignatures and delegation chains are reported as not checked. Upgrade to 0.11.0. Until then:
• do not rely on a VALID result for proof requests, admission decisions, run manifests, action bundles, VOPRF tokens or knowledge units;
• for every other format, always pass the issuer's key with --key.