# Security review results — August 2026

Open Print's first release-candidate review used a clean snapshot of commit
`9ea12ac26059af050a6ffc74bcfea0f094b9266c`. The review ran in a separate AI
context with parallel specialist passes for cryptography and registry state,
storage and command-line behavior, and the release supply chain. Findings were
required to have a reachable path and a deterministic local reproduction.

This was an AI-assisted internal adversarial review, not a claim of formal
certification. It is recorded as such so adopters can judge the evidence rather
than infer a human audit that did not happen.

## Baseline evidence

The review verified the pinned source manifest before testing. On the reviewed
snapshot, the existing suite, independent Python conformance verifier,
production dependency audit, package inspection, and two-build reproducibility
check all passed. The reviewer then tested behavior outside those existing
cases.

## Findings and disposition

The IDs below consolidate the specialist reproductions into the project's
finding format.

| ID | Severity | Finding | Disposition |
| --- | --- | --- | --- |
| OP-AI-001 | Critical | A trusted small-order Ed25519 public key admitted a universal signature that required no private key. | Fixed by rejecting every small-order encoding during validation and import. |
| OP-AI-002 | High | A second trusted issuer could sign cancellation or supersession events for another issuer's certificate; repeated terminal events and invalid replacement relationships were also accepted. | Fixed by binding terminal events and replacements to the original issuance issuer and enforcing one terminal event. |
| OP-AI-003 | High | Certificate registry status and archives matched only ID and fingerprint, allowing signed issuance metadata to disagree with edition, work, issuer, or sequence claims. | Fixed by binding every issuance field and independently rejecting repeated certificate edition sequences. |
| OP-AI-004 | High | A longer registry on another event fork could be presented with a checkpoint extending a retained checkpoint digest. | Fixed by checking that the supplied registry contains the exact retained checkpoint prefix. |
| OP-AI-005 | High | Automatic stale-lock deletion could remove a live writer's lock and allow duplicate sequence allocation and lost writes. | Fixed by rejecting automatic stale-lock takeover; orphaned locks require an operator decision. |
| OP-AI-006 | Medium | Some malformed nested archive or checkpoint combinations could escape the intended fail-closed reporting path. | Fixed by operating only on validated nested records and adding malformed-registry regression coverage. |
| OP-AI-007 | Low | A valid JSON string containing an unpaired surrogate could be issued but could not be restored as an encoded filename. | Fixed by deriving portable filenames from a SHA-256 digest of the JSON string. |
| RS-001 | Low | The npm tarball included the public conformance private seed alongside its matching fixture issuer. | Fixed by excluding the fixture generator while retaining public fixture JSON and the independent verifier. |
| RS-002 | Medium | Privileged CI and release jobs selected reusable actions through mutable major tags. | Fixed by pinning each action to the verified commit behind the stated release tag and disabling persisted checkout credentials. |

Every finding has a regression test. The fixes do not change v1 schemas,
canonical record bytes, signature input, or the signed conformance fixtures.
They do tighten verification behavior and remove the unsafe non-null
`staleLockMs` behavior while the package is still in beta.

## Remaining boundaries

The review did not remove Open Print's explicit trust and operational limits:

- issuer records still need an authentic first-use route;
- signature time is asserted by the signer rather than a trusted clock;
- rollback detection still requires an independently retained checkpoint;
- the reference file store remains limited to one machine and a local
  filesystem;
- library callers must impose deployment-appropriate resource limits; and
- no review can prove that a program contains no vulnerabilities.

These boundaries remain in [THREAT_MODEL.md](THREAT_MODEL.md). Any future change
to schemas, signed inputs, key rules, state transitions, storage behavior, or
release automation requires focused review and new adversarial coverage.