fss-mqtt-broker

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

The repository carries the full development history — every change lands as a reviewed pull request on main between releases (hundreds of interim commits between v0.9.0, v0.9.1 and v1.0.0), not only release snapshots. Releases are tags on that same public history.

Repository on GitHub, which uses git. git is distributed.

Every release has a unique semantic version (v0.9.0, v0.9.1, v1.0.0) — a signed, annotated git tag whose exact commit builds all published artifacts; images and binaries carry the same version, and the versioning policy is documented in RELEASING.md and SUPPORT.md.

Every release is a signed, annotated git tag (vX.Y.Z) on the public repository — the tag is the release: pushing it is what triggers the pipeline that builds and signs every artifact from that commit alone (RELEASING.md).

Non-trivial release notes file in repository: https://github.com/mbilling/fss-mqtt-broker/blob/main/CHANGELOG.md.

No publicly known vulnerability (CVE or similar) has been assigned against mqttd to date, so no release has had one to identify. The process for when it happens exists: GitHub Security Advisories are the channel (SECURITY.md), release notes are generated per release, and fixed advisories would be named in both the advisory and the per-release OpenVEX document (security/vex/).

Non-trivial SECURITY[.md] file found file in repository: https://github.com/mbilling/fss-mqtt-broker/blob/main/SECURITY.md. [osps_do_02_01]

GitHub Issues is the tracker — every review-panel finding, bug, and enhancement is filed as an individual issue and closed by the PR that resolves it (the repository’s convention is “Closes #N” in PR bodies; the 2026-08-13 external review alone filed and closed 28 tracked issues).

Every bug report filed to date has been acknowledged and dispositioned — the full issue history shows each filed issue closed by a fix PR or an explicit recorded decision, with none left unanswered (most recently: all 28 findings from the 2026-08-13 external review panel). The project is younger than 12 months, so this covers its entire history.

Enhancement requests are filed as issues and have all been responded to — accepted ones become ADR-backed work items with delivery tracking (docs/delivery/STATUS.md), and declined ones are closed with the reasoning recorded (the repository’s rule is that every issue gets one of two exits: fix it, or record the decision). Over the project’s entire sub-12-month history the response rate is 100%.

https://github.com/mbilling/fss-mqtt-broker/issues?q=is%3Aissue — GitHub Issues (including closed ones) is the permanent, publicly searchable archive of every report and its responses; pull requests and security advisories are archived and searchable the same way on the repository

https://github.com/mbilling/fss-mqtt-broker/blob/main/SECURITY.md — the published process: report privately via GitHub’s coordinated-disclosure form (https://github.com/mbilling/fss-mqtt-broker/security/advisories/new), never a public issue; the document states what a good report includes, what to expect, and how fixes ship.

https://github.com/mbilling/fss-mqtt-broker/blob/main/SECURITY.md — private reporting is the required path: GitHub’s private vulnerability reporting (Security → Report a vulnerability, i.e. https://github.com/mbilling/fss-mqtt-broker/security/advisories/new) opens an advisory visible only to the reporter and maintainers; SECURITY.md explicitly forbids public issues for suspected vulnerabilities.

No vulnerability reports have been received in the last 6 months (or ever, to date), so none has waited. SECURITY.md publishes the response expectations for when one arrives, and the project’s demonstrated response practice on all other reports (issue tracker history) is same-day to a few days — well inside 14.

Standard Cargo workspace: cargo build --release rebuilds everything from source. The release pipeline proves it continuously — published binaries are reproducible (anyone rebuilding the tagged commit gets byte-identical output, verification steps in https://github.com/mbilling/fss-mqtt-broker/blob/main/RELEASING.md), and CI rebuilds from clean checkouts on every PR.

Built entirely with the standard Rust toolchain — cargo and rustc (stable channel) — plus Docker for the container images. No custom or exotic build tooling; the one variant needing more (the FIPS build) uses cmake and Go, both standard and documented in docs/compliance/crypto-policy.md.

The entire toolchain is FLOSS: Rust/cargo (MIT/Apache-2.0), and for containers Docker/BuildKit (Apache-2.0). The FIPS variant adds cmake (BSD) and Go (BSD) — all free and open source; no proprietary tool is required for any build.

The test suite ships in the repository under Apache-2.0: ~1,400 tests (unit + 70+ integration binaries) run with cargo test --all, documented in CONTRIBUTING.md’s build-and-test section and executed by CI on every PR (.github/workflows/ci.yml) plus nightly chaos/soak/upgrade tiers. CI additionally runs an independent external FLOSS conformance suite, eclipse/paho.mqtt.testing (EPL), against the broker.

cargo test — the standard Rust invocation — runs the suite; CI uses exactly that (cargo test --all --no-fail-fast in .github/workflows/ci.yml), with no wrapper scripts required.

Test code outweighs production code ~1.4:1 (~69k vs ~49k lines; 1,400+ tests). Coverage is enforced structurally rather than by percentage: every emittable protocol failure code must have a test that provokes it (CI gate scripts/check-reason-codes.py), the test inventory itself is CI-gated against silent shrinkage (scripts/check-test-hygiene.py), critical guards are mutation-tested, and docs/TEST-PLAN.md documents the strategy including its known limits.

Every PR runs the full CI battery (eight jobs: build/test/lint, docs gates, foreign-client interop, mqttui, supply-chain audit, helm, fips variant, CodeQL) and must be green before merge — enforced by a branch ruleset on main. Nightly tiers add chaos, soak, two-binary rolling-upgrade, fuzzing, and benchmark runs.

The policy is documented in CONTRIBUTING.md and stronger than informal: the repository’s working convention is red-first (the test demonstrating the defect or feature lands with the change), delivery records must carry test evidence per task (docs/delivery/), and two CI gates make untested surface visible — every emittable reason code needs a provoking test, and the gated test inventory fails if tests vanish.

Recent major changes demonstrate it directly: MQTT 5 Subscription Identifier delivery landed with per-subscription attribution tests, reconnect-survival tests, and byte-level codec tests (PR #314); the audit-chain work landed with tamper/boundary/cross-boot tests and a process-level export verification test (PRs #340, #343); the FIPS variant landed with posture tests pinning the approved algorithm set (PR #347). The delivery dashboard (docs/delivery/STATUS.md) records test evidence per completed task.

Documented in CONTRIBUTING.md (the change-proposal instructions): the build-and-test section states the required checks, and the pull-request section states the review bar including tests accompanying functional changes — with the delivery-evidence convention requiring completed work to cite its tests.

clippy (the standard Rust linter) runs across all targets with warnings denied (cargo clippy --all-targets -- -D warnings) as a required CI check on every PR; rustc’s own warnings are part of the same gate, and rustfmt enforces formatting.

Warnings are build failures: clippy runs with -D warnings as a required check, so a warning cannot merge. The few deliberate exceptions are explicit #[allow] attributes carrying a written justification at the site — a documented decision, never an ignored warning.

Maximal in practice: clippy with -D warnings across all targets (tests and benches included, not just the library), pedantic-class lints addressed as they appear (recent history includes fixing doc-markdown and must-use-candidate class lints), and every exception is a site-local #[allow] with a stated reason rather than a blanket suppression.

Demonstrated in the produced software rather than asserted: the design record applies the standard secure-design principles by name — deny-by-default authentication and authorization, fail-closed refusal on every ambiguous path, least privilege (job-scoped CI tokens, non-root distroless images, hardened systemd unit), defense in depth across five documented trust surfaces, and economy of mechanism (single crypto provider, deliberately absent admin API). See docs/THREAT-MODEL.md and the 70 architecture decision records under docs/adr/, each recording the security reasoning for its surface.

The codebase counters the common vulnerability classes for network servers explicitly and by name: injection via topic metacharacters (identities containing +/#// rejected at every auth source), authentication oracles (identical error for unknown-user vs wrong-password), algorithm-confusion attacks (JWT HS* refused outright, asymmetric-only), replay (QUIC 0-RTT disabled; sequenced gossip posture), resource exhaustion (admission caps before TLS work, auth penalty box, bounded queues everywhere), TLS downgrade (1.3-only default), deserialization of untrusted data (strict codecs that tear down the link on trailing bytes), and memory-safety errors (Rust, no unsafe in product code). Each mitigation is documented with its threat in docs/THREAT-MODEL.md.

Only published, expert-reviewed cryptography: TLS 1.3 (RFC 8446) via rustls, AES-GCM/ChaCha20-Poly1305 suites, ECDSA P-256/P-384 and Ed25519, SHA-256, HMAC-SHA256, and Argon2id (RFC 9106) for password hashing — all through one audited provider (AWS-LC via aws-lc-rs, ADR 0053). No homegrown algorithms; the full policy is docs/compliance/crypto-policy.md.

All cryptography is called through purpose-built libraries — rustls for TLS and aws-lc-rs (AWS-LC) for every primitive (digests, HMAC, signatures, random) — consolidated deliberately onto that single provider by ADR 0053 precisely so no second or hand-rolled implementation exists in the tree. Nothing cryptographic is re-implemented.

The entire cryptographic stack is FLOSS: rustls (Apache-2.0/MIT/ISC) and AWS-LC via aws-lc-rs (Apache-2.0/ISC). No proprietary cryptographic component exists in any build, including the FIPS variant (AWS-LC’s FIPS module is the same open-source project).

Defaults exceed the NIST 112-bit minimum everywhere: TLS 1.3 with AES-128/256-GCM and ChaCha20-Poly1305, key exchange X25519/P-256/P-384, ECDSA P-256/P-384 and Ed25519 signatures, HMAC-SHA256 for gossip (short keys are a startup error — there is no weak-key mode, ADR 0003). Weaker configurations aren’t merely disableable, they are absent: TLS 1.3-only by default, and even the hardened TLS 1.2 opt-in is structurally restricted to ECDHE+AEAD suites.

No broken algorithm is present in any code path: no MD4/MD5, DES/3DES, RC4, or CBC-mode TLS suites exist in the provider configuration at all — TLS 1.3 suites by default, and the TLS 1.2 opt-in is structurally AEAD-only (its residual risks and the EMS requirement are documented at the opt-in, docs/HARDENING.md H-1.3/H-1.7). SHA-1-signed CA artifacts are rejected rather than grandfathered (gossip verification, ADR 0022).

Nothing depends on SHA-1, CBC modes, or any known-weakened algorithm: hashing is SHA-256 throughout (audit chain, backup integrity, gossip HMAC), TLS is 1.3-default with AEAD-only suites even in the 1.2 opt-in, and SHA-1-signed certificates are explicitly rejected in gossip verification rather than accepted for compatibility.

All key agreement is ephemeral: TLS 1.3 provides forward secrecy by construction (ephemeral ECDHE only), and the TLS 1.2 opt-in is structurally restricted to ECDHE suites — static-RSA key exchange does not exist in the configuration, which is called out explicitly in the suite allowlist’s rationale (forward secrecy; no static-RSA/ROBOT).

Passwords are stored exclusively as Argon2id PHC hashes with per-user salts — the criterion’s first-listed recommended algorithm. The shipped tool mqttd --hash-password mints the entries, the broker never accepts or stores plaintext, and the hardening baseline includes an auditable check that the password file contains only $argon2id$ lines (docs/HARDENING.md H-2.2).

All key and nonce generation goes through AWS-LC’s CSPRNG (aws-lc-rs rand, the workspace’s single crypto provider) — TLS session material via rustls/aws-lc-rs, salts and identifiers via the same source (e.g. the audit chain’s boot id explicitly uses aws_lc_rs::rand::fill). No std or non-cryptographic RNG is used for any security purpose; the one-provider rule (ADR 0053) makes an insecure-generator path structurally absent.

Distribution channels use HTTPS exclusively. [osps_br_03_02]

Nothing is retrieved over plain HTTP: dependencies come via cargo over HTTPS with lockfile-pinned checksums, base images are digest-pinned, and release artifacts publish sha256 checksums that are themselves cosign-signed (keyless, Rekor-logged) — the documented verification checks the signature, not a bare hash (RELEASING.md).

No vulnerability of any severity is unpatched: no CVE has ever been assigned against mqttd itself, cargo-audit gates every PR and release (currently zero vulnerabilities in the dependency tree), Dependabot streams fixes weekly with security updates immediate, and the three advisories scanners surface against transitive dependencies are each analyzed and dispositioned not-affected with evidence in the per-release OpenVEX (security/vex/).

No critical vulnerability has been reported to date, so the record is vacuously clean — and the machinery for speed exists and is exercised: fixes land on all supported lines (SUPPORT.md), patch releases change no formats by policy so they are adoptable immediately (ADR 0039), and the project’s demonstrated turnaround on externally-reported defects (28 review-panel findings) was days, not weeks.

No working credential is committed: configuration references secret material by filesystem path only (the schema enforces this — inline keys are rejected), deployment PKI is minted at install time by the bootstrap scripts, and GitHub secret scanning is active. The single committed private key is a test fixture (crates/mqtt-auth/src/testdata/rs256_private.pem) used only to sign JWTs inside unit tests — it is public by design and protects nothing.