Security
Email the maintainers
Break it — and tell us first.
Cryptographic evidence deserves cryptographic seriousness. If you find a way to forge, bypass or mislead GOVP verification, we want to know before the world does — and we will credit you when it ships fixed.
Report privately
contact@gemacode.org · subject: "GOVP security"
Scope
What counts as a vulnerability
| Scope | Examples |
|---|---|
| ✓ in scope | Signature or canonicalization flaws (two records, one signing input); GOVP-ID collisions or mis-derivation accepted by a reference verifier; verifier bypasses (a record that passes but shouldn't, per the spec); SVL authorization gaps (a source counting without anchor authorization); trust-model manipulation (inflating T beyond what independence supports); key-handling flaws in reference implementations; conformance vectors that pin an incorrect expectation. |
| — not a vuln | Backdating under GOVP-BASIC — documented, disclosed behavior; the fix is an anchoring profile, not a patch. Comments being unsigned — stated in spec §12.2; renderers must not present comments as verified. Public evidence being public — CORS-open reads are the design. Content being false — GOVP proves integrity, not truth. |
Unsure which side your finding lands on? Report it anyway — a boundary question is worth an email.
Process
Coordinated disclosure
- You report privatelyEmail with reproduction steps — ideally a record or vector that demonstrates the issue. We acknowledge within 72 hours.
- We fix — and re-pinA protocol-level flaw means new or amended conformance vectors, so every implementation is forced to pick up the fix. Implementation flaws ship as patched releases with updated checksums.
- Public advisory, with creditOnce fixes are available, we publish the advisory in the changelog and credit the reporter (or keep you anonymous, your choice).
Please don't test against third-party production nodes without their consent — the playground and your own installs give you everything needed to demonstrate an issue.