You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[NEW-SPEC-2] Normative golden-vector distribution, pinning, and hashing for wire-format conformance vectors #140
Problem. §1.1 currently states wire formats are out of scope for RELAY's own embedded vectors
(confirmed at current HEAD: "RELAY does not define... Wire formats"), and §20.2's embedded golden
vectors cover only envelope ToMessage/FromMessage round-trips, not wire encoding. This is exactly
why THEME-C's wire-format bug classes (filed separately in this batch) each independently recurred in
2-4 ports with no shared fixture to catch them.
Proposal. Add a new §15.8 "Vector distribution" (referenced from §20.2 and the interop command):
canonical vectors MUST live at a single source (spec/vectors/) with a vectors_manifest.json file
carrying a vectors_version bound to the spec version and a SHA-256 per vector file. Each
implementation MUST embed the exact pinned vector set and MUST FAIL conformance if its embedded
manifest hash diverges from the published manifest for its declared spec_version. Extend the vector
set specifically to the wire-format bug classes named in REL-SPEC-2 (filed separately in this batch) —
this makes wire regressions machine-detectable even though the format itself remains
implementation-defined per §1.1. Concrete test-case shape (per-vector two-directional
encode/decode assertion against externally-derived bytes, not the implementation's own round-trip) is
sketched in §9.1/§9.2 of the audit and can seed the initial vector set directly, including boundary
cases like the MQTT varint upper bound and the LIN diagnostic-checksum selection.
Filed from the 2026-07-29 ecosystem audit register; independently re-verified against current HEAD before filing.
Implemented and merged in #181 (squash commit 05a5300).
Scope decision (important)
The originating issue's proposal had two parts:
Pin/hash/version the vector distribution — implemented.
Extend the vector set itself with byte-for-byte wire-format vectors (MQTT varint boundary, LIN diagnostic-checksum selection, etc.) — explicitly declined. This contradicts RELAY's own pre-existing scope boundary at §1.1/§17.1 (established by REL-SPEC-2, already merged): "RELAY does not define wire formats... so RELAY cannot ship byte-for-byte wire vectors itself without exceeding that boundary." §15.8's new text states this explicitly. Only part 1 shipped.
What was implemented
New §17 Requirement 16 — Vector manifest. A conformant implementation that embeds a local copy of the canonical vectors MUST embed the exact pinned set and MUST have a CI step that fails on any SHA-256 divergence from the published manifest for its targeted vectors_version.
New §15.8 defines the relay-vectors/1 manifest shape (kind, manifest_version, vectors_version, vectors[] of {name, sha256}).
New embedded schemaspec/schemas/vectors-manifest.json.
New §20.1 CI gate for manifest regeneration/diffing.
Reference implementation: spec/vectors/vectors_manifest.json (16 entries, all hashes independently computed via shasum -a 256), plus VectorsManifest()/ParsedVectorsManifest()/VerifyVectorManifest() in vectors.go.
VectorNames() now excludes the manifest file itself — it's metadata about the distribution, not a vector. Required matching fixes in two pre-existing tests (spec_vectors_test.go, cmd/relay/jsonschema_test.go) that globbed spec/vectors/*.json directly.
New REQ-RELAY-096.
SpecVersion bumped 2.3 → 2.4 (MINOR).
Verification (double-checked, before and after merge)
go build ./... && go vet ./... && go test ./... — clean, both pre-merge and from a fresh post-merge clone of main at 05a5300.
gofmt -l . and golangci-lint run (latest, matching CI's pin) — clean (caught and fixed one unused finding on the first push — a leftover dead helper function).
Real mutation test: temporarily corrupted one hash in the committed manifest, confirmed TestVerifyVectorManifestClean failed with the exact expected finding, reverted, confirmed clean again.
Manually ran the reference VerifyVectorManifest() against the post-merge clone's embedded vectors: 16 vectors (manifest correctly excluded), vectors_version: "2.4", zero findings.
Activity
SoundMatt commentedon Aug 21, 2026
Implemented and merged in #181 (squash commit
05a5300).Scope decision (important)
The originating issue's proposal had two parts:
What was implemented
vectors_version.relay-vectors/1manifest shape (kind,manifest_version,vectors_version,vectors[]of{name, sha256}).spec/schemas/vectors-manifest.json.spec/vectors/vectors_manifest.json(16 entries, all hashes independently computed viashasum -a 256), plusVectorsManifest()/ParsedVectorsManifest()/VerifyVectorManifest()invectors.go.VectorNames()now excludes the manifest file itself — it's metadata about the distribution, not a vector. Required matching fixes in two pre-existing tests (spec_vectors_test.go,cmd/relay/jsonschema_test.go) that globbedspec/vectors/*.jsondirectly.REQ-RELAY-096.SpecVersionbumped2.3→2.4(MINOR).Verification (double-checked, before and after merge)
go build ./... && go vet ./... && go test ./...— clean, both pre-merge and from a fresh post-merge clone ofmainat05a5300.gofmt -l .andgolangci-lint run(latest, matching CI's pin) — clean (caught and fixed oneunusedfinding on the first push — a leftover dead helper function).gofusa check(pinned v0.48.0): 0 errors.gofusa trace -req-coverage 100: 100% (96/96).TestVerifyVectorManifestCleanfailed with the exact expected finding, reverted, confirmed clean again.VerifyVectorManifest()against the post-merge clone's embedded vectors: 16 vectors (manifest correctly excluded),vectors_version: "2.4", zero findings.mainCI run for merge commit05a5300independently confirmed green (Docker build,Lint,Security,Test,go-FuSa full safety lifecycle,Self-conformanceallsuccess).Closing.