InterGenOS takes security seriously. This document describes how to report vulnerabilities and how we respond.

Project status: the current release is R001, published 2026-08-16. InterGenOS keeps a single supported line — the latest release is the supported release, and fixes reach users by advancing that line rather than through maintenance branches or backports, so every user runs the package set the project evaluates. The full policy is in docs/release-policy.md. This policy applies to all InterGenOS code and infrastructure from the date below onward. We are a small team; if we cannot meet a target, we will communicate openly and directly with the reporter.

Primary: Email security@intergenstudios.com

Alternative: Open a private security advisory on GitHub.

Machine-readable contact info also published at https://intergenstudios.com/.well-known/security.txt per RFC 9116.

Anonymous reports accepted. We will never retaliate against good-faith reporters.

Encrypted submissions are fully supported and encouraged. The canonical PGP fingerprint for the project release and encryption keys is published at docs/signing-key.md, and you can import the armored public key from docs/signing-key.asc.

• Within 48 hours of receipt, we will confirm we have your report and begin triage.

At fix release or 90 days from acknowledgment, whichever comes first. This is a deliberate safety net: we will not sit on unresolved vulnerabilities indefinitely.

If the vulnerability is in upstream code (kernel, systemd, glibc, etc.), we coordinate with their embargo. Our users receive the fix on the same timeline as upstream users — never later.

Published advisories include:

• CVE number (assigned via MITRE)
• CVSS score
• Affected versions
• Mitigation steps
• Patch commit reference
• Timeline (reported / triaged / fixed / disclosed)
• Reporter credit (see below)

A signing-key compromise is not a bug — it is a break in the foundation of trust. The standard framework above does not apply; this track is dedicated and aggressive. For details on how users should handle these trust failures, see the Repository Trust Model.

A confirmed compromise requires evidence, not claim:

• (a) Direct evidence — artifact of private-key material exposure, device-tampering indicator, or credential leak, OR
• (b) Anomalous signature — a valid signature observed in the wild that we did not authorize.

Mere claims route to the standard 48-hour triage and are likely closed without action.

Target: users running pkm update within 24 hours of the incident receive the new keyring and revoke trust in the compromised key.

• Fingerprint of compromised key
• First known compromised signature timestamp (if determinable)
• Downstream artifacts suspected tampered
• Replacement key fingerprint
• Verification instructions
• Incident timeline

• Convenience is never a reason to delay trust-anchor revocation.
• Our update infrastructure must be trustworthy. A compromised signing key means the update path itself is the attack.
• If there is any doubt about key integrity, we revoke. Re-issuing unnecessarily is preferable to leaving users exposed once.

For full details on the key custody architecture that defends against compromise, see the Signing Procedure and Signing Key Ceremony Procedure.

Accepted reports: we credit reporters in the advisory and on our Hall of Fame page, unless anonymity is requested.

Rejected reports: default to anonymity. If a reporter wishes to be publicly credited for a rejected or duplicate report, they may request it.

No bug bounty program at this time. We appreciate responsible disclosure and will credit researchers publicly, but we do not pay monetary rewards. This policy may change as the project grows.

This policy applies to:

• InterGenOS core packages and distribution artifacts
• The pkm package manager and repository infrastructure
• Signing keys and related trust infrastructure
• intergenstudios.com web properties

Out of scope:

• Upstream projects we package (report to them directly; we will coordinate)
• Third-party software installed by users post-install

Every release is published with the artifacts needed to verify it, and none of them requires trusting this document:

Verification is two steps and the order matters: check the signature on the checksum file first, then check the image against the checksum. The signature proves the checksum file is the project's and was not altered on the mirror or in transit; hashing the image against that checksum is what catches a truncated download or a substituted image. Neither step substitutes for the other.

The fingerprint to compare is the primary key's — 5597 A3E0 587B 2530 06D0 DD7B 8C50 8261 8208 3050. Your tools will report the subkey that made a signature; subkeys rotate, the primary fingerprint is the one to check, and it is also published in docs/signing-key.md.

The commands, with the same filenames, are in docs/getting-started.md. The signed source tag is verified with git tag -v R001.

If any of these checks fails, do not install the image, and report it to security@intergenstudios.com — a verification failure on a published artifact is treated as a potential trust-anchor incident, not a download problem.

Known vulnerabilities and our response. InterGenOS ships with mitigations pre-applied.

Last updated: 2026-07-29