[IanFrelinger]

An operator can now turn Ed25519 pinning on. Nothing could before.

CertificationVerifyOptions.TrustedEd25519PublicKeys has always been { get; init; }, so it was
always settable. The defect was that nothing in non-test code ever assigned it, so
PinningEnabled was false in every production path and verification ran against the key the record
itself carries — which the options file, in its own words, says is close to worthless. An attacker's
self-consistent record verified exactly as the operator's would.

CertificationTrustPolicy reads ASHLAR_CERT_TRUSTED_ED25519_KEYS (Base64 raw public keys, from
any configuration source, not only the environment) and hands the resulting
CertificationVerifyOptions to every production verifier. ASHLAR_CERT_PINNING_REQUIRED makes
"pinning is in effect" a checkable startup assertion rather than a hope.

Strict as a static preset is unchanged, and with nothing configured Ambient.Strict is
reference-identical to it — so an unconfigured host behaves exactly as today.

Three defects found while building it, each worse than the feature's absence

A fail-open in the one switch whose job is to make pinning checkable. ParsePinningRequired read a
present-but-empty value as "pinning not required", while the type's own doc comment promised the
opposite and the sibling keys variable threw on identical input. A deployment template rendering
ASHLAR_CERT_PINNING_REQUIRED= unsubstituted would start a host unpinned while the operator believed
they had demanded pinning. Blank now falls through to the refusal; configured is null still separates
absent from blank.

SameKeys compared counts and only one direction, so a basis of {A, A} against a configuration of
{A, B} reported "same set", raised no conflict, and Apply returned options accepting B — the
exact widening Apply's own summary promises never happens.

Validation by bytes, enforcement by string. Validate decoded a key only to check its length and
then stored the operator's raw text, while both verification tiers compare ordinally against
Convert.ToBase64String output. A non-canonical encoding of a trusted key therefore would not match,
and two encodings of one key counted as two keys. Keys are now canonicalised on store.

And two tests that could not fail

The operator-facing variable names were pinned by nothing. Every fact wrote and read through
TrustedKeysVariable itself, so arrange and act shared one symbol: renaming that constant's value
reddened zero of 26 cases, while every operator following docs/Configuration.md would be setting a
variable nothing reads — pinning silently off. The names are now pinned to their literals and to the
document that tells an operator to set them.

Apply's field copy was unfalsifiable in the dangerous direction. Hardcoding three of its fields so
it ignored its argument left the suite green, because the only fact applied Strict as the basis and
compared back to Strict. A configured policy's Default and Apply(Legacy) are now asserted.

How much of the wiring is itself verified — stated, not implied

Seven production verifiers apply the policy and they are not equally covered.

	sites	covered by
5 of 7	file record store, brick registry, hot-swap verify-at-load, composition constituent check, self-extend admission edge	a behavioural fact that reddens when the call site reverts to the bare preset
2 of 7	StateLogVerifier's 5-arg overload, the adaptation DI factory	nothing behavioural — both resolve process-wide Ambient directly, and with nothing configured that IS the preset, so reverting either is invisible to any test

That gap is not hypothetical: five of these seven were in that state when pinning was first wired in.
PinnedWiringSiteConventionTests now asserts on shipped IL (via Mono.Cecil, already a dependency —
this branch adds no package) that all seven still call CertificationTrustPolicy.Ambient, so deleting
any wiring reddens. It does not prove the pinned set is enforced at the two uncovered sites, and
both lines carry a comment saying exactly that, with the reason: Ambient is a Lazy resolved once per
process, so a test cannot vary it without pinning the whole run. Giving those two a policy parameter is
the fix and it is a public API change on a packable library — flagged rather than taken.

Verification

Linux devtest container, never the host:

• cert-gate: 1248/1248 passed, 0 warnings.
• Full Ashlar.sln build succeeded.
• Every fact mutation-checked, and the mutations were chosen adversarially: two independent reviewers
  ran their own, deliberately including the ones the author had not, and re-confirmed 8 of 8
  blocking findings resolved in the committed code rather than from the author's report.

Decisions this leaves open — deliberately

1. This is a third location for trust material, and the type ships in a IsPackable=true library.
   SPEC-006 §3 designates ~/.ashlar/keys/trusted/ for trust material, and the enumeration hazard
   documented there (rotation re-authorizes a stolen key) is why configuration was chosen instead.

   An earlier draft of this section claimed an external consumer of Ashlar.Certification.Contracts
   "has its verification decisions influenced by ambient process environment it never opted into."
   That was measured and is not true, so it is corrected here rather than left to be acted on:
   nothing inside the packable assembly consults Ambient implicitly — grep over the whole project
   finds only its own definition (CertificationTrustPolicy.cs:87,107) — and
   CertificationTrustVerifier falls back to CertificationVerifyOptions.Default, the static preset,
   when options is null. Reaching ambient behaviour requires naming CertificationTrustPolicy.Ambient.
   Every ambient read is in Ashlar.Infrastructure's wiring, i.e. Ashlar's own hosts, which is exactly
   where an operator's configuration should apply. No breaking API change is needed.

   What IS worth guaranteeing is that this stays true, because it is the kind of property that
   regresses silently: a later convenience fallback of options ?? Ambient.Strict inside the packable
   library would make every consumer environment-dependent without anyone deciding to. A follow-up adds
   an IL convention test asserting no type in the packable assembly calls get_Ambient, in the same
   shape as PinnedWiringSiteConventionTests.

2. Nothing in this repository or CI sets either variable, so this ships a capability, not a
   posture, and the limitation row is downgraded from an open hole to a configurable one — not closed.
   Public keys are safe to publish. Recommendation: set them in a CI lane.

3. Whether CertificationTrustPolicy should read operator.pub by default, which would make pinning
   on-by-default for any host that has run ashlar keys init. A posture change, not taken.

4. Whether StateLogVerifier's 5-arg overload should refuse rather than throw on unusable trust
   configuration. A taste call on an overload with no production callers (verified by grep over
   src/ application/ tools/ products/ samples/). Neither convention was changed.

🤖 Generated with Claude Code