1.8 KiB
Security reports and incidents
For exploitable code failures or sensitive link-poisoning evidence, contact Nic
Weyand at the maintainer address in the verified signed source-release commit
(git show -s --format=%ae COMMIT). Check the signature and maintainer identity
first. Do not post credentials or an active exploit in a public issue. Ordinary
data corrections can follow CONTRIBUTING.md. No response-time SLA is offered.
Include the software commit, generation receipt pin, source snapshot/statement IDs, exact fingerprint, affected command and a minimal sanitized reproduction. Describe what was expected, what happened and whether anyone has received the affected generation. Use inert or local fixtures where possible.
Publishers should append a revocation for a suspected malicious destination, build and inspect a replacement generation with the full review history, sign it with a trusted key and deliver its new pin to consumers. Consumers must refresh their verified registry and any derived routing catalogue. Merely appending a local revocation does not notify running applications or invalidate their caches.
For signer compromise, remove that signer from consumer trust files through an independent authenticated channel, investigate affected releases and rotate the key. Do not accept a replacement key solely because it appears inside a suspect dataset. Preserve affected source bytes and receipts as evidence; publish a sanitized advisory identifying affected pins and corrective versions.
Source release CI receives no dataset credentials or signing keys. Configure it on a disposable isolated runner without production mounts or access to trusted publisher state. The source archive verifier checks hashes and safe contents; it is not a malware scanner or a substitute for source review.