Firmware security is a chain: source review, trusted build inputs, signed artifacts, a verified update path, safe defaults and a recovery route. DCENT_OS documents each boundary instead of treating “open source” as the whole answer.
Threats in scope
- Compromised or downgraded update packages.
- Unauthorized dashboard, API, WebSocket or MCP control actions.
- Credential or release-key leakage.
- Unsafe voltage, thermal, fan or PSU changes.
- Pool redirection and configuration tampering.
- Persistent-install failures that damage boot or recovery state.
Release and update controls
Published DCENT_OS security controls and current assurance limits| Control | Published behavior | Current caveat |
|---|
| Artifact integrity | SHA-256 checksum file plus an Ed25519-signed manifest inside current packages | Verify the exact file and model lane before any write |
| Install preflight | Backup-first, degraded-hardware refusal and dry-run planning through DCENT_Toolbox | Install readiness remains model-specific and guarded |
| First boot | Management-only state; mining must be explicitly enabled | Does not replace a tested SD/UART recovery path |
| Control authorization | Release-image writes require authenticated owner sessions and fail closed without a token | Local root access is intentionally operator-owned and outside that boundary |
| Network policy | Local dashboard/API; project states no cloud account, telemetry or license server | Independent network-capture verification is invited and should name the tested build |
| Vendor boot components | Explicitly isolated and attributed | They remain outside the source-level security guarantee |
Verify a package
- Download only the artifact for the exact model and control-board lane.
- Compare its SHA-256 digest with the published checksum list.
- Inspect the package's
MANIFEST.json, MANIFEST.sig and release_ed25519.pub; DCENT_Toolbox is designed to fail closed on signature mismatch. - Run a dry-run preflight and keep a known-good recovery image plus UART access.
Independent network-verification recipe
- Record the artifact filename, SHA-256 digest, build/commit and exact miner/control-board lane.
- Place the miner on an isolated test VLAN with packet capture at the gateway.
- Exercise first boot, pool configuration, mining, dashboard/API reads, authenticated writes, update checks and a reboot.
- Publish DNS lookups, destination IPs, ports, byte counts and the redacted capture; distinguish configured pool traffic from unsolicited traffic.
- Repeat after a factory reset and disclose every test limitation. Do not turn a single quiet capture into a universal claim for other builds.
Disclosure and audit status
Report vulnerabilities through the repository's coordinated disclosure policy, not a public issue. The policy covers the firmware, dashboard, build/flash tooling and update path and includes safe-harbor language.
This page does not claim an independent security audit, a reproducible-build certification or a published SBOM unless those artifacts are linked from the repository for the named build. Independent researchers can use the reviewer and researcher kit; negative findings and failed reproductions are explicitly welcome.
Assurance ledger
DCENT_OS assurance state for beta20260709| GPL-3.0 source | Published for daemon, dashboard and Buildroot integration; vendor boot-input boundary documented. |
|---|
| Signed artifacts | Published for exact S9 XIL and S19j Pro XIL files. |
|---|
| Independent security audit | None published. |
|---|
| SBOM | Not published for the named artifact set. |
|---|
| Reproducible-build certification | None; byte-for-byte reproducibility is not claimed. |
|---|
| Independent network-egress capture | None published. |
|---|
| Production-supported release | None; all current artifacts are experimental and guarded. |
|---|
Security surface reviewed 2026-08-08. See also D-Central's firmware verification guide.
