Report a security vulnerability

Two private channels

1. GitHub private vulnerability reporting is the primary channel. Open a private report, or use "Report a vulnerability" on the repository's Security tab. Only you and the maintainer can see it, and the fix and the advisory are coordinated in the same private thread.
2. Email to security@nails.run is the fallback, if you cannot or do not want to use a GitHub account, or do not want GitHub to be able to read the report.

What counts as a vulnerability

The policy covers the code in the NAILS repository and its official releases. Problems with this website, nails.run, can be reported to security@nails.run. A report shows a vulnerability when NAILS fails to uphold its threat model. Reports the policy treats as potentially high priority include:

• a trace of a hidden session that survives teardown on a decoy that meets the model's assumptions
• a way around the session's isolation, the way back or the rollback of an interrupted entry
• privilege escalation through an operation NAILS manages
• a problem with the integrity of the release files

Issues in upstream projects such as NixOS, Nixpkgs, VeraCrypt, LUKS or the Linux kernel belong with those projects. If you are unsure, report it anyway.

Protect yourself while reporting

• A pseudonymous or throwaway account or email address is fine.
• Replace real paths, host names, user names and volume labels with placeholders. Do not send unredacted nails status or nails verify output.
• Strip metadata from screenshots and log files.
• Say so if you do not want to be credited. Your name and account are then left out of the published advisory.
• Write and send the report from a hidden session or another device, not from the decoy system, whose browser history would keep a record of it.
• If you post something sensitive in a public issue by mistake, say so through one of the private channels, so the issue can be deleted. Editing it is not enough, because the original text stays in the issue's edit history and in notification emails that were already sent.

What to expect

The maintainer aims to acknowledge a report within 72 hours, to send a first assessment within 7 days and to keep you informed if a fix will take longer. NAILS has one maintainer, so these are best-effort goals, not guarantees.

The policy asks you to keep the issue private until a fix is available or you have agreed on a disclosure date together. The default goal is coordinated disclosure within 90 days. The window can be shorter or longer, depending on severity, active exploitation, the complexity of the fix or an agreement with you.

Supported versions

NAILS is alpha software. Only the most recent 0.2.x release carries security fixes, and there are no backports to earlier lines. The 0.1.x releases and earlier alpha builds are not supported.

The docs on this site describe v0.3.0-rc.3, a release candidate published as a prerelease. A problem in a release candidate is fixed in a new -rc.N, because a published release never changes.

How fixes reach you

A fix reaches you as a new release, so the releases feed is enough to hear of it. Any feed reader can follow it without a GitHub account. Follow it inside a hidden session or on another device, never on the decoy, where the reader's subscription would name the tool. The feed shows a version as soon as its tag is pushed. The version is out once GitHub Releases lists it with its files.

A fix can also be announced in the repository's published security advisories, which you can read without a GitHub account but which have no feed, and in the changelog. During the alpha, a fix may appear in the release notes before a formal advisory is published.

Questions that are not sensitive

For a question about hardening, the threat model or safe use that is not sensitive, read the docs and the answers to common questions first. If they leave a gap, open a public issue about it, following the advice above. Use the private channels only when the question itself is sensitive.

Read the full security policy