Security Policy

This page reproduces docs/SECURITY.md from qanum-core v0.9.0 (release tag). Links to files that are not published on this site are shown as plain text until the source repository is public.

Supported Versions

Qanum L1 is pre-mainnet software. Security fixes ship on the current release line only; all users are expected to upgrade to the latest release.

How many release lines receive security fixes on mainnet, and for how long, will be published here before the mainnet genesis.

The current release and its checksums are listed in its release notes (docs/release-notes/) and on the official site https://qanum.org. Each release also ships a CycloneDX SBOM per crate (the full dependency list, including the vendored liboqs with its exact commit), and no release is tagged while cargo audit reports a vulnerability. Releases are signed with post-quantum keys: see Verifying a Release.

Reporting a Vulnerability

To report security issues send an email to security@qanum.org (not for support).

Please include:

• a description of the issue and its potential impact (consensus split, remote crash, wallet/key exposure, denial of service, funds at risk, …),
• the exact version or commit affected,
• minimal reproduction steps or a proof of concept, if possible,
• whether the issue is already known publicly.

Reports can be encrypted with the project disclosure key (published on keys.openpgp.org, email-verified):

# import the key
gpg --keyserver hkps://keys.openpgp.org --recv-keys 8013E1BFF91CA30EE6A5F27301D9622680BAFCA9

# encrypt a report
gpg --encrypt --armor -r security@qanum.org report.txt

Please never include secret key material or other sensitive data in plain email. Every report is acknowledged, assigned a severity and followed through fix, release and disclosure as described below; the reporter is kept informed at each step and credited in the advisory unless they prefer not to be.

Severity

Each report is assigned one of four levels, following Bitcoin Core’s classification:

• Critical — threatens the security of the whole network: theft of coins at the protocol level, creation of coins outside the issuance schedule, a permanent network-wide chain split, or forging signatures the node accepts.
• High — significant impact on nodes or the network, typically exploitable remotely under the default configuration: a remote crash, a long stall of block or transaction processing, remote memory or disk exhaustion.
• Medium — noticeably degrades a node or the network but is limited in scope or exploitability: needs non-default settings or special conditions, or degrades service without taking the node down.
• Low — hard to exploit or minor impact: only under non-default configurations or from the local machine/network, no immediate or widespread threat.

A report may also be judged not to be a vulnerability, or serious but not in need of an embargo; it is then handled in public.

Response Timeline

Every fix ships no later than 90 days after the report. If a target cannot be met, the reporter is told why and given a new date.

Disclosure

Details are published after the fix, so that users have time to upgrade:

• Low — two weeks after the release that contains the fix.
• Medium and High — two weeks after the last affected release line stops being supported. Before mainnet only the current line is supported, so in practice this is two weeks after the next release line ships.
• Critical — handled case by case.

Two weeks before details are published, the release notes of a new release announce how many vulnerabilities it fixes and their severity, without details. In every case the details are published no later than 90 days after the report, unless the reporter agrees to a longer embargo; after that window the reporter is free to publish.

Vulnerability Records

Every published vulnerability gets an advisory in the release notes and a row in CVE-REGISTER.md, with its severity, the fixing release and commit. Fixes that close a known Bitcoin Core vulnerability are recorded there under the Core CVE. CVE identifiers for vulnerabilities in Qanum itself are requested through GitHub Security Advisories (GitHub is a CVE Numbering Authority).

Actively Exploited Vulnerabilities

Qanum is free and open-source software, published free of charge and not monetised by its developer. The project’s assessment is that it is not supplied in the course of a commercial activity in the sense of the EU Cyber Resilience Act (Regulation (EU) 2024/2847); if that changes, this policy will be updated first. Independently of that, if a vulnerability is known to be actively exploited, a fix and an advisory are published as fast as possible, node operators are warned through the release notes, a PGP-signed notice and https://qanum.org, and the case is recorded in CVE-REGISTER.md.

security.txt

contrib/security.txt is the machine-readable contact file (RFC 9116), published signed with the disclosure key at https://qanum.org/.well-known/security.txt. It is renewed before it expires as part of every release (CONTRIBUTING.md, release checklist).

Scope

In scope: consensus rules and validation, the P2P protocol and message handling (net_v2, the Noise transport, node identities and TOFU), cryptography (ML-DSA / SLH-DSA / ML-KEM integration, signature verification and VERIFY-UNITS accounting), wallet storage and key handling, header pre-sync / minimum chain work / assumevalid handling, and the RPC surface (loopback-only by default).

Out of scope: attacks requiring physical access, social engineering, and loss of testnet coins — testnet coins have no economic value (see TESTNET-TERMS.md).

Safe Harbor

Good-faith security research on Qanum software and testnet infrastructure is welcome. We will not pursue legal action against researchers who report vulnerabilities responsibly, coordinate disclosure with us, and avoid accessing or affecting other users’ funds, data, or nodes beyond what is needed to demonstrate the issue. Please do not disclose before the fix is released, within the windows in Disclosure (never more than 90 days after the report without your agreement).

Verifying a Release

Every release ships, next to the source tarball and the SBOMs:

• SHA512SUMS — the SHA-512 of every published file (sha512sum format);
• SHA512SUMS.qsig — two post-quantum signatures of that list, ML-DSA-87 (FIPS 204) and SLH-DSA-SHAKE-256s (FIPS 205), by the project release keys. Both must verify: they rest on unrelated mathematics, so breaking one scheme is not enough to forge a release;
• SHA512SUMS.asc — a PGP signature with the disclosure key above. Classical (not quantum-resistant), for compatibility with standard tools only; the post-quantum signatures are authoritative.

Every release also ships qanum-security-X.Y.Z.json, the security facts of the release: the signature suites, the P2P transport, the networks, the release keys, the toolchain and liboqs, the cargo audit result and the SHA-512 of the SBOMs, written from the code of the tag. It is listed in SHA512SUMS, so the signatures cover it. It claims no certification and no external audit.

With a qanum-cli you already trust:

qanum-cli verifyrelease <directory-with-the-downloaded-files>

It works offline (no node), checks both signatures against the release keys built into qanum-cli and the SHA-512 of every listed file, and exits with code 0 only if everything matches.

First download (no trusted qanum-cli yet): compare the release key ids below with the ones published on https://qanum.org, check the classical signature and the checksums, then build and run verifyrelease on the same files:

gpg --verify SHA512SUMS.asc SHA512SUMS
sha512sum -c SHA512SUMS

Release Signing Keys

Generated offline on 2026-10-11. Their public keys are in src/release_keys.rs; a test checks that the key ids above match them.

The secret keys are created with qanum-release-sign keygen and live only on an offline machine, encrypted under a passphrase (Argon2id + AES-256-GCM). How releases are built, signed and published: RELEASE-SIGNING.md. Rotation: a release signed with the current keys ships the next keys in src/release_keys.rs. Compromise: the key is removed in the next release and the compromise is announced here, in a PGP-signed notice and on https://qanum.org.

Testnet Note

Testnet coins have no value, the chain may be reset at any time, and mainnet does not exist yet (mainnet genesis is not defined). Never send anything of value to any Qanum address. Full terms: TESTNET-TERMS.md.