Everything merged since v0.20.0 went in unreviewed, and the check reads green

[LKSNDRTMLKV]

Asked to investigate the security findings sitting on main before the 0.21.0 cut. There are none — and the reason is worse than a list of findings would have been.

Nothing on main was reviewed

Every pull request merged since the v0.20.0 cut reports the same CodeRabbit status:

CodeRabbit    pass    0    Review skipped: excluded by label configuration

Twelve of thirteen. The exception is #283, and only because it was labelled a few hours before merging.

merged since v0.20.0	reviewed
#271, #272, #273, #276, #281, #284, #285, #286, #288, #289, #290, #291	❌ none
#287, #292, #283	✅ labelled and read

So the honest answer to "what security findings went in" is: unknown, because nothing looked. A green CodeRabbit check on those twelve means "no review ran", not "a review found nothing" — and the two render identically in the checks list.

This is the configured behaviour, and .coderabbit.yaml predicted it

auto_review.enabled: false with an opt-in review-ready label. The config's own comment says what happens when nobody labels:

when no review happens at all, those checks are skipped with it and the CodeRabbit status passes vacuously, which is worse than not having them

That is the state. The setting is defensible — the open-source plan rate-limits reviews and one-per-push would spend the budget on typo fixes — but it depends on a human remembering a label, and over thirteen merges that held once.

What is going into 0.21.0 unread

git diff --stat v0.20.0 main → 76 files, +3924 / −607.

Several meet CLAUDE.md's own "worth a review" bar:

• feat(crypto): name the EU-recognised JAdES profile #290 feat(crypto): name the EU-recognised JAdES profile — dpp-crypto/src/jades/, a signing profile. "anything in dpp-crypto or the signing and verification paths".
• feat(domain)!: record whether an act is still law #271, fix(domain)!: give the manufacturer its Art. 27(6) contacts #272, feat(domain)!: let an item passport state its serial #273 — all feat/fix(domain)!, all touching persisted shapes (Passport, the manufacturer's Art. 27(6) field, item serial numbers). "any change to Passport … or a published JSON schema". A non-additive change here makes already-written documents unreadable per request, which is the failure that cost 244 of 276 passports once.
• feat(domain): resolve forward through an amendment #286 — forward resolution through an amendment, on PassportRepository.

None of that is an allegation that something is wrong. It is that nobody has looked, at the things the repo's own rules say to look at.

Proposed remedy, before the cut

A merged PR cannot be reviewed retroactively, but the accumulated diff can:

1. branch at the tag — git branch audit/v0-20-0-baseline v0.20.0 and push it;
2. open a PR with base audit/v0-20-0-baseline, head main, so the diff is everything 0.21.0 adds;
3. label it review-ready, take the one pass over all 76 files;
4. act on whatever it finds, then close without merging — it exists to be read, not landed;
5. delete the baseline branch.

One review, one rate-limit slot, covering everything in the release.

And the smaller fix that stops the recurrence

The label is load-bearing and invisible when forgotten. Options, cheapest first:

• a required status check, or a simple CI step, that fails a PR carrying neither review-ready nor an explicit @coderabbitai review — turning a silent skip into a visible one;
• or review_status: true, so the skip at least posts a comment instead of only a green tick.

🚨 Whatever is chosen, the thing to fix is that "not reviewed" and "reviewed clean" look the same in the checks list. Three separate variants of that cost time today: this one, a stacked PR whose base disabled reviews (#292), and a PR whose findings were all stale but still displayed (#280).

[LKSNDRTMLKV]

Audit pull request open: #294 — main against v0.20.0, labelled and requested. To be closed unmerged once read, and audit/v0-20-0-baseline deleted with it.

[LKSNDRTMLKV]

The audit ran, and it was worth running

#294 took one review pass over main against v0.20.0 — the 76-file, +3924/−607 diff that twelve unreviewed pull requests had built up. 15 findings, none security-category.

Three were defects and are fixed in #296, each with a test watched to fail first:

• a battery whose two placing dates disagree was exempting itself from the mandatory-content gate, because the exemption helper assumed validate had reconciled them and transition_to never calls it;
• find_superseding_head rejected a chain of exactly MAX_SUCCESSION_HOPS as too long;
• the frozen fixture for electronics v1.3.0 carried none of what v1.3.0 added, so the compat check could not have caught a rename of either new key.

🚨 A fourth, probably, and it needs a decision rather than a patch

crates/dpp-crypto/src/jades/header.rs — is_eu_recognised_profile is matches!(self, Self::ChainWithThumbprint { .. }). The variant alone. ChainWithThumbprint is publicly constructible, so an empty chain answers true: the method asserts the Annex I profile for a header with no x5c, and x5c is precisely what Annex I of CIR (EU) 2026/248 mandates.

A mismatched thumbprint answers true too, but that one is arguable — the method's own doc scopes it to format rather than validity, and a digest that does not identify the chain's first certificate is a validity question.

Left alone deliberately: it changes a compliance predicate on the signing path during a release cut, which is a call to take rather than a defect to close quietly. The empty-chain half looks indefensible either way.

The remaining eleven

Style, documentation and API shape. Worth a pass, not worth blocking a release.

Where	What
dpp-domain/src/error/dpp.rs	replace string fields with typed error data
dpp-domain/src/ports/backup/port.rs	SLA and authentication policy do not belong in dpp-domain
dpp-domain/src/schemas/citation.rs	reject slash-form calendar dates before creating an ActRef
dpp-domain/src/product_group/data/electronics/index_scope_exclusion.rs	preserve unknown exclusion tags
dpp-registry/src/endpoint.rs	invented route defaults should not sit in the public API
dpp-rules/src/electronics/spare_parts.rs	published docs should not depend on CLAUDE.md
dpp-tests/tests/doc_comment_citations.rs	scope each COMPLIANCE-PIN to the documentation it governs
dpp-vc/README.md	inline the disclosure-contract behaviour
docs/architecture/PORTS.md	correct the availability-period reference
CHANGELOG.md	mark ArchivePort as the former API
dpp-domain/src/status/lifecycle.rs	"preserve the old persisted lifecycle value" — the "archived" alias, for the third time. Already answered: the engine's 0041 rewrites doc, not only the projected status column, so stored records stay readable without putting the ambiguous word back on the wire

Closing #294

Its job is done and its body says to close it unmerged. One side effect worth recording before it is: opening it put a Codacy Static Code Analysis check-run on main's own HEAD commit — because the pull request's head is main — where it landed action_required and made main read red. main itself is fine: its combined commit status is success and no workflow run failed.

Codacy is a third-party app and its check-runs do not accept the GitHub re-request API (POST /check-runs/{id}/rerequest → 404), so it cannot be re-run from the CLI. It clears when main next moves — merging #296 does that — or from Codacy's own interface.

🚨 Worth knowing before the next audit: do not open an audit pull request with main as the head. Push the release diff to a throwaway branch and open that against the baseline instead, so no external app attaches a check to main's commit.

[LKSNDRTMLKV]

The fourth defect is fixed and merged: #297. is_eu_recognised_profile was matches! on the variant alone, so an empty x5c answered true — the format a Member State body must recognise, for a header identifying no certificate. Both legs are presence requirements, so both fields must now be non-empty, and to_json_bytes refuses an empty x5t#S256 as well (new JadesError::EmptyThumbprint) so the predicate and the serialiser cannot disagree.

The thumbprint-vs-chain mismatch is still not checked, and is now pinned by a test that says so — it is a correctness question, not a presence one, and answering it needs the DER to hash. Open if you want it.

Remaining from the audit: the eleven style/docs/API-shape items listed above.

[LKSNDRTMLKV]

This is the last item before the 0.21.0 cut, and its scope is now wider than the review gap.

Milestoned to v0.21.0 and positioned last deliberately: it runs once
everything else in the milestone has landed, because what it audits is the state
of main at the moment of publishing, not the state of any one branch.

Why it moved from "a review gap" to "the publish gate"

This was filed because 12 of 13 pull requests merged since v0.20.0 went in
unreviewed while the check read green — "not reviewed" and "reviewed clean" are
the same colour. The four defects that audit found are fixed and merged. What is
left is not those four; it is that the same shape keeps appearing, and each
new instance has been found by hand:

• a lens chain with a hole in the middle, invisible because the compat check only
  required the final hop (fix(schema): battery has no lens chain between v2.0.0 and v2.4.0 #299);
• eleven schema files announcing their predecessor's $id, invisible because
  nothing compared a header to its filename;
• a catalog entry declaring four of five versions, invisible because parity was
  checked in one direction only;
• every Decision resolving to a Regulation's CELEX, invisible because the wrong
  answer and the right answer are both well-formed (The prose citation gate cannot express a Decision, and derives the wrong CELEX for one #298);
• and, prospectively, a mock that is self-consistent rather than faithful (What a registry mock can build on, and the two things core should add before it #301).

Every one is a check that reads green whether or not it did anything. That is
the property to audit before publishing, not the review count.

What a clean publish has to mean

crates.io is irreversible. A released version cannot be unpublished, and this
workspace has already put a leak into a published version that can never be
withdrawn. So the audit is about what the release asserts, in the places a
vendored consumer reads:

1. Nothing in the published artifact names a private sibling or depends on
   outside context. crates/*/src, every doc comment, every crate README, the
   CHANGELOG. The 0.21.0 work has already produced three instances of
   publication-boundary wording that needed removing after being written, in code,
   in schema JSON and in a PR body.

2. No commercial claim about a third party. Same wave produced several.

3. Every citation resolves. With The prose citation gate cannot express a Decision, and derives the wrong CELEX for one #298 landed, the gate can express a
   Decision; the audit is whether anything already inventoried was recorded under
   a wrong CELEX before it could.

4. Every CITED_NOT_MODELLED reason marked Sourced was actually read. The
   basis field exists because reasons written from recall read identically to
   ones read from the Official Journal. CITED_NOT_MODELLED reasons assert dates and annex scope from unread texts #250 is the open half of this.

5. The CHANGELOG's ### Unreleased structure is sound. It currently carries
   two ### Added headings from a merge collision, and this repository has
   filed a breaking change under ### Added four times. Release notes come from
   this section.

6. Every gate in the suite can fail. Not "does it pass" — whether a
   deliberately broken input makes it fail. That is the check the five findings
   above all needed and none had.

7. The version, the tag and the three version sites agree before anything is
   pushed.

Ordering

Runs after #298, #299, #80, #259, #260 and #301 are merged. It is the gate, so it
has nothing to audit until they are in.

Not in this

The process question — making "reviewed" visually distinct from "skipped" in the
check itself — is real and is not a release blocker. Splitting it out rather than
holding the publish gate behind a CI configuration change.

[LKSNDRTMLKV]

Audit run 2026-09-17. Closing.

Scope: everything on main since v0.20.0 — 25 commits, 208 files,
+15 642/−921 — ahead of publishing 0.21.0. Each item from the checklist above,
with what was actually done rather than what was intended.

1. Nothing in the published artifact names a private sibling ✅

Swept crates/, every README, every doc comment and the CHANGELOG. No ADR
references, no paths into another repository.

Five mentions of a public sibling by name exist (dpp-calc/README.md, two in
ports/seal/, dpp-plugin-traits/README.md, dpp-registry/README.md). All
pre-existing — git diff v0.20.0..HEAD adds none — and CLAUDE.md §6
permits naming a public sibling where it helps a reader, forbidding only a path
into one. None of the five carries a path. Flagging because a memory note of mine
read stricter than the repository's own rule; the rule governs.

2. No commercial claim about a third party ✅

Clean. The GS1 subscription wording caught during #295's review is gone from the
CHANGELOG, scheme.rs and all eleven schema JSONs, and nothing has reintroduced
it.

3. Every citation resolves ✅

The prose gate is green, and #298 taught it Decisions — so the two
Implementing Decision citations in this workspace no longer resolve to a
Regulation's CELEX.

4. Every Sourced reason was actually read ✅ — and one was not

#315 read all four flagged acts against the Official Journal. Two of the four
reasons were wrong, and one of those was already marked Sourced:

• 32004R0648 cited Art. 36 for a repeal that is Art. 35, and said "the
  same article" for a transition that is a different one — while marked as read
  against the OJ.
• 32024R1252 was recorded as an act that "does not govern disclosure". False:
  Art. 28 mandates a label, a data carrier and a unique product identifier, and
  Art. 28(6) routes that content into the product passport. Tracked as The CRM Act is a passport-content instrument, not a list of materials #314.

32009R0661 and 32009R1222 were read and are accurate.

🚨 The lesson for this gate: Sourced is not a guarantee. The test behind it
checks that an article number is present, never that it is the right one —
that requires reading the act. The marker means "someone claims to have read
this", and spot-checking is the only thing that makes it trustworthy. Today's
spot-check found one of two wrong. Six entries remain Assumed and have never
been read: 32006R1907, 32009L0048, 32011L0065, 32017L1132,
32020R0740, 32023R1669.

5. The CHANGELOG's ### Unreleased structure ✅ — fixed

It carried two ### Added headings, a merge artefact from parallel PRs, so
0.21.0's release notes would have shipped with the section split in half.
Merged in #316.

6. Every gate can fail — sampled, not exhaustive, and it found the worst thing here

Mutation-tested rather than run. Proven to fail when they should: the schema
compatibility chain, the citation detectors, catalog↔registry parity in both
directions, the schema $id/title headers, the disclosure-key parity check,
the layout gates, and the payload identifier tripwire (via a type alias, since a
plain type change is caught by the compiler first).

🚨 One gate had stopped covering what ships. The end-to-end check that a
public battery view carries no Annex XIII point 2 or point 4 content built its
policy from a literal, for_schema_version("battery", "2.6.0"). #295 added
v2.7.0 and the literal was not updated, so every leak assertion in that test —
including assert!(public.filtered_data.get("sohMethodology").is_none()) — was
being evaluated against a schema that no longer ships. Flipping sohMethodology
to public in v2.7.0 left the test green.

No live leak: v2.6.0 and v2.7.0 carry the same 15 non-public fields with the
same classes, verified before claiming anything. What was lost is the guard, not
the classification — and this project has already shipped a state-of-health
public leak once, in ≤0.10.0. Fixed in #317, which is the one finding still
in flight.

7. Version sites agree ✅

Twelve occurrences of "0.20.0" in the root Cargo.toml — one
[workspace.package] version and eleven [workspace.dependencies] pins. The
plugins take version.workspace = true and follow automatically. There is no
ungated third site in this repository. After the bump, grep -c '"0.21.0"' Cargo.toml should read 12.

---

Security review

No HIGH or MEDIUM findings.

The surface I expected to be weakest holds: disclosed_payload() reads an
unverified JWT by design, so a caller skipping the signature check would be
an authentication bypass. There is exactly one caller in the workspace and its
order is correct — parse → verify_jws → typ → payload — with Ok(false) and
Err both refused. Duplicate digests are rejected in both the supplied
disclosures and the token's own _sd arrays; an unused disclosure refuses the
whole credential rather than dropping the claim; present() can only filter
what the holder already holds. No unwrap in the library path.

ProductGroupData::Other cannot yield an identifier from its untyped blob.
Everything else in range moves fail-closed: #297 tightened the JAdES profile
predicate, #295 routed deserialisation through the constructors, #310 replaced
silent "" defaults with refusals, #312 closed blank identifiers under schemes
the validator does not recognise. cargo audit clean across 374 dependencies.

On the original subject

Every pull request merged in this wave carried a review — #295, #300, #302,
#303, #304, #306, #309, #310, #312, #315 — and the reviews found real defects,
including a wrong CELEX arm, a blank-value hole, and the missing applicability
conditions on the CRM articles. The "12 of 13 unreviewed" state that opened this
issue is not the state 0.21.0 ships in.

What this issue was really about is unchanged and worth carrying forward: a
check that reads green whether or not it did anything. Item 6 found one, and
the Sourced marker in item 4 is another. Both are now known rather than
assumed, which is the most an audit can do.

Closing. #317 carries the one outstanding fix; #314 and the six unread Assumed
entries are tracked separately.