auth/oauth and internal/keymanager sit under the coverage gate, hidden by the aggregate

[Jaro-c]

The go-ci gate is 90 and the aggregate passes, but it is carrying two packages that do not. Measured on develop at v1.11.4, go1.26.4, go test -coverprofile:

Package	Coverage
internal/clock	100.0%
authcore (root)	98.1%
auth/username	97.5%
auth/password	95.8%
auth/apikey	94.6%
auth/jwt	94.4%
auth/email	90.9%
auth/oauth	87.7%
internal/keymanager	85.7%
total	91.0%

The two under the bar are the two I would least like to be thin: the OIDC client, which parses JWKS, validates ID tokens and talks to remote endpoints, and the package that generates and persists the Ed25519 keys. A 100% internal/clock is what is paying for them.

Worth deciding as part of this: whether the gate should be per-package rather than aggregate. An aggregate gate on a library whose packages differ this much in risk rewards covering the easy ones.

I am not proposing a coverage-chasing sweep. The useful version of this is to look at what is actually uncovered in those two packages — my expectation is that it is mostly error paths, which for a security library is the half that matters.

[Jaro-c]

Measured the uncovered blocks rather than guessing at them, on develop after #221, #223 and #228.

First, a hypothesis of mine that turned out to be wrong. I expected the per-package numbers to under-report, because helpers exercised from a sibling package do not count towards their own package's profile. Comparing an isolated profile against -coverpkg=./...:

package	isolated	cross-package	delta
internal/keymanager	87.4%	87.9%	+0.5
auth/oauth	87.7%	87.7%	0.0
everything else	—	—	0.0

Only keymanager.KeyID changes materially — 0% isolated, 100% cross — because the JWT rotation tests are what exercise it. Four statements. So the per-package measure is fair here, and a per-package gate would not be measuring an artefact. That removes the main argument against switching to one.

What is actually uncovered

40 statements in auth/oauth, 24 in internal/keymanager, almost all error paths. Two groups in oauth are worth more than the rest, because they validate data that arrives from the remote provider:

• jwks.go:225-230 and jwks.go:251-254 — the P-384 and P-521 branches of ecCurve, and its default rejection of an unknown curve. Never executed. The library accepts EC keys on three curves and only one of them is tested.
• jwks.go:234-236 — the bounds check in ecPointOnCurve that rejects negative or oversized coordinates. Never executed. This is the guard against a malformed point in a JWKS document.

Then a smaller one:

• config.go:105-107 — the len(via) >= 5 redirect limit in safeRedirect, which is the loop guard on the token and JWKS fetches.

The rest are ordinary if err != nil on network and JSON paths, plus pkce.go:19, the CSPRNG failure branch, which is not worth contorting the code to reach.

Suggested shape

Cover the three above and the numbers follow on their own. internal/keymanager is already at 88.9% after #228 and gets there with a couple of loader error paths.

The gate question is now cleanly decidable: the per-package numbers are honest, so a per-package floor would say what the aggregate currently hides — that the two packages with the largest attack surface are the two thinnest.

[Jaro-c]

#232 covered the three blocks named above — the P-384/P-521 branches of ecCurve plus its unknown-curve rejection, the bounds check in ecPointOnCurve, and the redirect limit in safeRedirect — as a side effect of the mutation sweep in #229, since all three turned out to be controls that could be deleted with the suite green.

Where the numbers stand now:

package	before tonight	now
auth/oauth	87.7%	90.2%
internal/keymanager	85.7%	88.9%
total	91.0%	92.2%

So auth/oauth clears the gate on its own and internal/keymanager is the only package left under it, at 88.9%. Its remaining gaps are loader error paths — writeMetadata's encode failure, a couple of PEM read branches, and generateAndSaveEd25519's cleanup path when the public-key write fails.

The per-package gate question is unchanged and still worth deciding: the measurement above says the per-package numbers are honest, so a per-package floor would be enforcing something real rather than an artefact.