QuantumSSH is cryptographic infrastructure. Security is the project's primary product. This document explains how to report vulnerabilities, what you can expect from us in return, and the boundaries of the embargoed-disclosure process.

Please do not open public GitHub issues for security vulnerabilities.

Send a private report to:

security@quantumssh.org

If you wish to encrypt your report, use the project's PGP key:

Primary key fingerprint:    66DB 5100 B070 0E4A E051  971F 9A8D FF06 AFD2 5B24
Encryption subkey:          12A8 BCF0 3709 5A50 06E9  E6F6 4CFE 72E9 E72F A113
UID:                        QuantumSSH Security <security@quantumssh.org>
Algorithm:                  Ed25519 (sign, cert) + Curve25519 (encrypt)
Created:                    2026-05-10
Expires:                    2028-05-09

The full ASCII-armored public key is published in this repository at keys/security.asc. To import it locally and verify the fingerprint before trusting it — never skip this step on a security-sensitive key:

# 1. Download (do NOT pipe directly to gpg --import without inspecting).
curl -fsSL -o quantumssh-security.asc \
  https://raw.githubusercontent.com/gonzafg2/quantumssh/main/keys/security.asc

# 2. Verify the fingerprint OFFLINE against the value printed above.
#    Expected primary fingerprint:
#      66DB 5100 B070 0E4A E051  971F 9A8D FF06 AFD2 5B24
gpg --show-keys quantumssh-security.asc

# 3. Only after the fingerprint matches, import.
gpg --import quantumssh-security.asc

For extra assurance, cross-check the fingerprint against the DNSSEC-signed record _release-key.quantumssh.org, which a separate credential controls (ADR-0057):

delv @1.1.1.1 TXT _release-key.quantumssh.org

Accept it only when the output says ; fully validated. delv validates the DNSSEC chain against the root trust anchor itself, so the resolver only carries the records. Neither dig +dnssec nor a resolver's ad flag over plain UDP proves anything. macOS's own delv is built without crypto support and cannot validate; use the one in Homebrew's bind, or bind9-dnsutils/bind-tools on Linux. quantumssh.org itself is not a second channel, because it redirects to this repository.

If you cannot encrypt your report, plain email is acceptable; do not delay disclosure waiting on PGP setup.

A useful report typically includes:

• A clear description of the vulnerability and its impact.
• Affected versions, commits, or configurations.
• Steps to reproduce, ideally with a minimal proof of concept.
• Any suggested mitigation or fix, if you have one.
• Whether you intend to publish independently, and your preferred attribution (real name, handle, or anonymous).

From 0.2.0 on, each release publishes three tarballs (Linux x86_64 and aarch64, macOS arm64), a CycloneDX SBOM, SHA256SUMS and SHA256SUMS.asc. The same key as above signs the release's v* tag and its SHA256SUMS (ADR-0057). In this order (ADR-0054 §6):

1. The pin set and the signature. keys/release-keys.txt lists every release key and its role: current, retired (rotated out, valid within its window) or revoked. From a checkout of main, run scripts/verify-download.sh vX.Y.Z <dir> on the directory holding SHA256SUMS and SHA256SUMS.asc. It imports every listed key into a throwaway GnuPG home and runs the pinned signature check:

   • it fails on a revoked, bad or, for the current key, expired signature;
   • it accepts a retired key only for a release whose immutable record GitHub timestamped inside the key's window, on that release's recorded assets.

   A bare gpg --verify is not enough, because it reports "Good signature" for a revoked or expired key. Check the current fingerprint the script prints against the one above.

2. The downloads: sha256sum --ignore-missing -c SHA256SUMS.

3. The provenance (recommended):

   gh attestation verify <tarball> -R gonzafg2/quantumssh \
     --signer-workflow gonzafg2/quantumssh/.github/workflows/release.yml \
     --source-ref refs/tags/vX.Y.Z --deny-self-hosted-runners

Steps 1 and 2 are the minimum. Checking only the attestation gives no check of the maintainer's signature. To check a tag itself, with the key imported, run git verify-tag --raw vX.Y.Z 2>&1 | scripts/release/pinned-signature-check.sh keys/release-keys.txt. That runs the same pinned check on GnuPG's status lines. docs/deployment.md §1 walks through a Linux install with these steps.

If the release key is ever revoked for compromise, step 1 fails for every release, by design. For a release the advisory lists as unaffected, the recipe becomes:

1. gh release verify-asset vX.Y.Z SHA256SUMS, which checks the file against the immutable release's recorded digest;
2. a match between that SHA256SUMS digest and the advisory, which the successor key signs;
3. sha256sum --ignore-missing -c SHA256SUMS, so the downloads match the SHA256SUMS just authenticated;
4. the provenance check, gh attestation verify with the pins shown above. It is not optional here, because the PGP path is unavailable.

We commit publicly to the following response targets:

If a report falls outside our scope, we will say so explicitly and quickly, rather than leaving you waiting.

The default embargo period is 90 days from the date of acknowledgement. The embargo may be extended to up to 120 days when coordination with downstream packagers, distributions, or interoperating projects justifies it. Any extension beyond 90 days will be discussed with the reporter.

For vulnerabilities that warrant a CVE identifier, we will request one through MITRE's CVE Numbering Authority program.

We will credit reporters by name (or pseudonym, or anonymously) in the release notes, the advisory, and the project changelog, unless they request otherwise.

In scope:

• The QuantumSSH server and any first-party crates published from this repository.
• Cryptographic protocol logic, key handling, authentication, and session management code authored in this repository.
• Configuration parsing, command-line handling, and any exposed control surfaces shipped with the server.

Out of scope (please report to the upstream project instead):

• Vulnerabilities in the third-party crates we build on (ml-kem, x25519-dalek, ed25519-dalek, chacha20, poly1305, aes-gcm, tokio, or any other dependency in Cargo.lock). We will of course react to upstream advisories, but primary disclosure should be coordinated with the upstream maintainers.
• Issues in operating system kernels, system libraries, or container runtimes that QuantumSSH happens to run on.
• Social-engineering, phishing, or physical-access attack scenarios that do not exploit a defect in QuantumSSH itself.

• No bug bounty program. We do not currently offer monetary rewards for vulnerability reports. We hope to introduce one as the project matures and funding allows; until then, we will be honest that we cannot pay you, and will credit your work generously.
• No safe-harbor legal commitments beyond good faith. Fleming Science and Technologies SpA will not pursue legal action against researchers acting in good faith and in accordance with this policy. We cannot speak for third parties whose systems may be involved in your testing.

Reports of weak defaults, configuration footguns, or hardening opportunities that are not exploitable vulnerabilities are very welcome as ordinary issues or pull requests. The same goes for documentation improvements that reduce the chance of users misconfiguring the server.

The people who report vulnerabilities responsibly are doing the project, and its users, a substantial favour. We take that seriously.