# GHSA-jjgp-whrp-gq8m: in-toto: PGP trust model not (fully) considered

> in-toto fails to validate PGP key expiration, revocation, and usage flags, allowing attackers to bypass signature verification using invalid or revoked keys.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** No
- **Published:** 11 May 2023

## What is GHSA-jjgp-whrp-gq8m?

GHSA-jjgp-whrp-gq8m is a vulnerability in in-toto, published on 11 May 2023. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official description

### Impact

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.

### 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

## Which versions are affected by GHSA-jjgp-whrp-gq8m?

2 open source packages ship an affected version, including in-toto.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `in-toto` | PyPI | All versions to 1.4.0 | None |
| `in-toto` | PyPI | All versions to 1.4.0 | None |

## How do I fix GHSA-jjgp-whrp-gq8m?

No fix has been published for GHSA-jjgp-whrp-gq8m yet. Limit exposure of the affected software until one is available.

## Is GHSA-jjgp-whrp-gq8m being exploited?

There is no known exploitation of GHSA-jjgp-whrp-gq8m in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-jjgp-whrp-gq8m and fix it if it is affected.

What it is: GHSA-jjgp-whrp-gq8m is a vulnerability in in-toto, published on 11 May 2023. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of GHSA-jjgp-whrp-gq8m in the wild and no public exploit code.

Affected packages and fixed versions:
- in-toto (PyPI): affected all versions up to 1.4.0; no fix listed
- in-toto (PyPI): affected all versions up to 1.4.0; no fix listed

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-jjgp-whrp-gq8m/ (Markdown: https://insights.sbomify.com/GHSA-jjgp-whrp-gq8m/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-jjgp-whrp-gq8m

---
From sbomify Insights: https://insights.sbomify.com/GHSA-jjgp-whrp-gq8m/
Summaries are generated and may contain mistakes; the official description above is the record.