GHSA-JJGP-WHRP-GQ8M

in-toto: PGP trust model not (fully) considered

References

• "Handle GPG revocation signatures" -- https://github.com/secure-systems-lab/securesystemslib/issues/190
• "inconsistent use of GnuPG" -- https://github.com/in-toto/in-toto/issues/569

This security advisory lists multiple concerns about how in-toto uses PGP keys. The findings are aggregated here, because they are all eligible to the same mitigation strategy. Note that the findings are rated with different severities (see inline) and the highest score was chosen for this advisory:

• PGP Key Creation Time Not Validated (severity: low)
  in-toto does not check, if the validity period of a PGP Key (starting with the key creation time) is in the future, when copying the key from GnuPG to a layout, or when verifying signatures. A validity period in the future is usually a sign of a wrong system clock, meaning it can’t be trusted for verifying the validity period. A MITM attacker who is able to manipulate delivered software products might also be able to control the system time by manipulating NTP. In a scenario where an attacker gained control over two expired subkeys with no overlapping validity period, the attacker could set the system time to a time before the validity period of either key, resulting in both keys being accepted.

• PGP Key Revocation Not Considered (severity: medium)
  in-toto does not check PGP revocation signatures, when copying the key from GnuPG to a layout, or when verifying signatures. This means that a key may still be accepted in signatures, even if it has been revoked in GnuPG.

• PGP Key Usage Flags Not Considered (severity: low)
  in-toto does not check PGP usage flags, when copying the key from GnuPG to a layout, or when verifying signatures. This means that at a key may still be accepted in signatures, even if it is not permitted to sign data as per its key usage flags.

Security auditors recommend to verify these properties at signature verification time.

However, this is not planned, as in-toto does not rely on PGP’s trust model, because it should not be required to consult with a separate PKI/web-of-trust at verification time. Instead the project owner establishes ultimate trust by adding a PGP public key to a layout, and thus is responsible for its validity, and also to revoke the layout, if the key is no longer trusted. The same is true for PGP public keys used to verify a layout.

The preferred mitigation strategy is to verify these properties when exporting a public key from GnuPG, and to clarify usage documentation that no verification against the PGP trust model is performed afterwards.

Kodem intelligence

Already deployed Kodem?

1. What is GHSA-JJGP-WHRP-GQ8M? GHSA-JJGP-WHRP-GQ8M is a medium-severity security vulnerability in in-toto (pip), affecting versions <= 1.4.0. No fixed version is listed yet.
2. Which versions of in-toto are affected by GHSA-JJGP-WHRP-GQ8M? in-toto (pip) versions <= 1.4.0 is affected.
3. Is there a fix for GHSA-JJGP-WHRP-GQ8M? No fixed version is listed for GHSA-JJGP-WHRP-GQ8M yet. Monitor the advisory for updates and apply mitigations in the interim.
4. Is GHSA-JJGP-WHRP-GQ8M exploitable, and should I be worried? Whether GHSA-JJGP-WHRP-GQ8M is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
5. What actually determines whether GHSA-JJGP-WHRP-GQ8M is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.

Other vulnerabilities in in-toto