Aller au contenu
login
arrow_backRetour aux issues
Judgment-Pack/judgment-pack-gateway #78

Give every loadSeals drop row exactly one obstacle

ecoDébutant good first issue security-boundary

descriptionDescription

## Goal Strengthen `TestLoadSealDropShapes` (go/teeth_test.go, from #77) so every drop row *holds* the leg it names, and add the two authentication rows the table does not yet have. ## Why #77 gave `loadSeals` a thirteen-row table whose rows demonstrably reach ten of its legs, and two of those rows are the only things in the repository that hold what they pin (the signed negative-`finalCount` and the both-orders first-wins tie-break). The verification that accompanied its review found the remaining pattern: most drop rows carry an unverifiable signature, so when a named leg is mutated from drop to accept, the row still drops at the signature checks downstream and the suite stays green — the row reaches its leg but does not hold it. Two legs have no discriminating row at all, and they are the authentication core: ```go if keyID != keyIDFor(publicKey) { continue } if !ed25519.Verify(publicKey, sealSigningInput(sessionID, sealedAt, count), sig) { continue } ``` Mutation evidence, current main: deleting the `keyId` comparison, or making the `Verify` branch unreachable, passes `go test ./...` **and** `gateway conform` with 0 disagreements. A registry line with a well-formed signature that verifies under nothing would load. ## Scope - Change `go/teeth_test.go` only — extend or re-sign rows in `TestLoadSealDropShapes`; do not add a second test unless a row genuinely cannot live in the table. - **Do not enumerate shapes: derive.** Read `loadSeals` and give each existing member/count/hex drop row *exactly one obstacle*: sign each row over the `sealSigningInput` the relaxed code would verify, so the only thing dropping the line is the leg the row names. (For the missing-`sealedAt` row, that means a valid signature over the input with the empty `sealedAt`.) - Add: a row whose `keyId` names a foreign key — use the existing `sealLineKeyID` helper (probes_test.go) — and a row carrying 128 valid hex characters that decode to 64 bytes but are not a signature over the input. - Make the non-hex-signature row 128 characters with two non-hex characters, so ignoring the decode error is no longer saved by the length check. - Assert `finalCount` unconditionally — the current `wantCID != 0` gate silently skips the assertion for rows expecting zero, a legal seal value. - Do not change `go/verify.go`, `SPEC.md`, or `corpus/**`. ## Acceptance criteria - [ ] For every member/count/hex drop row: temporarily relax that row's leg in `go/verify.go`, confirm the row (and only expectedly-affected rows) fails, restore — and say in the pull request that you did this per row. - [ ] Deleting the `keyID != keyIDFor(publicKey)` comparison fails the new foreign-`keyId` row. - [ ] Making the `ed25519.Verify` branch unreachable fails the new wrong-signature row. - [ ] `finalCount` is asserted on every row, including zero. - [ ] `cd go && gofmt -l .` prints nothing; `go vet ./...` clean; `go test ./...` passing. - [ ] `cd go && go build -trimpath -o gateway . && ./gateway conform` reports 0 disagreements. - [ ] Every commit includes a DCO sign-off created with `git commit -s`. ## Contributor learning The difference between a test that reaches a branch and a test that holds it — and how to prove which one you wrote by breaking the code on purpose, leg by leg. ## Provenance The verification and review of #77 (see its review thread); the two authentication mutations above were run against current main and survive everything.
codeOuvre sur GitHub