Shadowfetch Linux

Security model

Shadowfetch Linux is a Debian-testing derivative with a small Shadowfetch layer: branding, defaults, curated packages, optional agent setup, installer polish, and a signed APT repository. We do not claim Debian endorsement, magic anonymity, or enterprise hardening.

Verify the current release →

What is inherited

  • Most packages come directly from Debian testing and its normal security/update flow.
  • KDE Plasma, Calamares, PipeWire, Mesa, systemd, apt, dpkg, and core userland follow their upstream projects.
  • Debian tooling still works: apt, dpkg,systemctl, and standard logs are intact.

What Shadowfetch adds

  • Signed ISO artifacts and a public GPG key for verification.
  • A signed APT repository athttps://www.shadowfetch.com/linux/apt/for Shadowfetch packages.
  • UFW firewall enabled, MAC-address randomization defaults, hardened sysctl settings, zram, theming, the Welcome flow, and optional agent setup.
  • From 5.0, ShadowCode is preinstalled as upstream's signed .deb, republished byte for byte. Its Ed25519 release signature is re-verified against a vendored trust policy at fetch, package-gate and ISO-gate time, and the gates fail if its bundled llama.cpp appears outside /usr/lib/shadowcode/. shadowfetch-agent-network online|offline decides whether Firebreak sandboxes start with network and pauses the optional agents when offline.

Signing

GPG signing key
8F13CE1535EE1F4A2916A1F73C5C900B7BE80CA1
APT repository
https://www.shadowfetch.com/linux/apt/

Download the public keyFull verification guide

The key is served from the freeze host over HTTPS (www.shadowfetch.com). A copy is also at/shadowfetch.gpg.asc on this site. Fetch it and print its fingerprint without importing anything into your keyring, then compare the result against the fingerprint above:

curl -fsSL https://www.shadowfetch.com/linux/shadowfetch.gpg.asc | gpg --show-keys --with-fingerprint

It is not on keys.openpgp.org orkeyserver.ubuntu.com; a --recv-keys against either fails, so this page does not tell you to try. Verifying the key you fetched against the fingerprint published here is what establishes the trust anchor.

Local records and connected services

Firewatch reads hardware metrics locally and exposes them on the system bus. Mission Control keeps its queue and execution receipts on this computer. Using the desktop does not require a Shadowfetch account. The website and download infrastructure may still produce ordinary web/CDN logs at the hosting layer. Optional vendor apps have their own privacy policies and may contact their services for accounts, updates, relays, model discovery or downloads. Verifying a local Mission Control request does not certify all background traffic from those apps.

Current security caveats

  1. Secure Boot signing is not available yet.
  2. Advisory for 4.x installs: ISOs through 4.1.0 shipped one shared DKMS module-signing key (/var/lib/dkms/mok.key). If you enrolled its certificate in Secure Boot, anyone with the ISO could sign a kernel module your machine trusts; replace and re-enroll it as described on the known-issues page. If you never enrolled it, no action is needed. The 5.0.0 image is built without it and each machine generates its own.
  3. Debian testing moves faster than Debian stable; update risk is part of the model.
  4. Official native Grok Bot, Hermes Agent, OpenClaw and any vendor CLI you connect to ShadowCode use their providers' own sign-in and network services; Shadowfetch does not grant them an account or publishing authority.
  5. OpenClaw has a long security-advisory record. It runs inside Firebreak with its Gateway off by default, which narrows exposure but does not make it safe; an enabled Gateway runs outside the sandbox with your file access. Hermes Agent is not sandboxed and runs commands and edits files as you.
  6. ShadowCode's own shell sandbox covers its own agent; vendor CLIs it drives enforce their own sandboxes. shadowfetch-agent-network does not set ShadowCode's network mode, which has its own Offline setting.
  7. The egress allowlist is a control only where a mission declares destinations. A connected task with none declared installs no ruleset and reaches anything this machine can reach — the local network is not the extent of it.
  8. DNS leaves a sandbox whose filter is working: the resolver has to be reachable or nothing routes. An allowlist narrows where bytes may be sent, not what can be signalled out in a query name. Filtering is by resolved IPv4 address, fixed once at launch.
  9. Masking is by path. A hardlink to the same inode under a name that is not masked is still readable.
  10. A credential you grant a mission is present in the sandbox environment, so anything the agent starts can read it. What is enforced is that a credential you did not grant is not there at all.
  11. The sandbox runs as your own user. Root inside its user namespace is not a different account outside it.
  12. The distribution is young. Treat the known-issues page as required reading before installing on a production machine.

DKMS signing-key advisory →Read the known issues →

Debian is a registered trademark of Software in the Public Interest, Inc. Shadowfetch Linux is an independent derivative and is not affiliated with or endorsed by the Debian project.