29 lines
1.8 KiB
Markdown
29 lines
1.8 KiB
Markdown
# 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.
|