This repository documents and configures a private home network. It is not a product and has no users other than its owner, so "supported versions" does not really apply — main is the only branch that means anything, and it is what the lab runs.

What is useful here is a clear answer to two questions: what to do if you spot a problem, and what is already known.

If you find a misconfiguration, a leaked credential, or a weakness in what is published here, please report it privately rather than opening a public issue:

• GitHub Security Advisories — open a draft advisory (preferred; it stays private until fixed)
• Failing that, a GitHub issue without details, asking for a contact.

Please do not open a public issue containing a working credential, a capture, or anything that would let someone else reach the network before it can be fixed.

This is a personal project, so there is no SLA. Realistically: acknowledgement within a few days, and credential exposure treated as urgent.

The lab is a home network, not a bug bounty target. Scanning, probing or attempting to reach any host described in docs/network.md is unwelcome and not authorised. Everything worth reviewing is in this repository — review the configuration, not the running system.

Documented rather than quietly fixed, because a known and written-down exposure is a very different thing from an overlooked one. Full detail in docs/security.md.

The switch is the honest gap, and it is a deliberate one. neo (10.7.7.2) is rotated and polling, but it also still accepts the community it held before the rotation, verified after a reboot so the result reflects its saved configuration rather than a stale agent. Its firmware does not persist a deletion from the SNMP community table: the row can be removed, applied and saved, and the entry is still there after a restart. Each attempt also drops the SNMP agent until the switch is rebooted, and it is the switch the whole network runs through.

The residual risk is accepted rather than overlooked. The community is read-only, and reaching UDP/161 on 10.7.7.2 requires both a foothold on the management VLAN and the specific pfSense rule that permits 10.0.99.20 to reach it — it is not exposed beyond the management segment. The way to close it without fighting the firmware is to overwrite that row rather than delete it, on some future pass when the switch is already being taken down for something else. That is now written out as a procedure — §2.5, The MokerLink switch: overwrite the row — including what to record here if the overwrite does not persist either.

Remediation is tracked in docs/roadmap.md, with procedures in docs/runbooks/rotate-snmp-community.md and docs/runbooks/purge-git-history.md.

There is no .gitleaksignore. There was one, enumerating nine historical findings so the full-history scan stayed meaningful; the purge removed what it acknowledged, so it was deleted. CI now scans the whole history with no exceptions, which is the only way to know the purge worked — an ignore file large enough to cover real findings can also hide new ones.

The unencrypted disk is a different kind of entry from the rest of that table. The others each happened once and have a date; this one is a standing property of the host. Measured on prometheus (10.0.99.20): /dev/mapper holds only control and the LVM logical volume, so there is no LUKS anywhere — the root filesystem is plain ext4 on LVM — and /swap.img is 4 GiB, unencrypted, on that same filesystem.

The observability containers no longer page into it. Since #114 every service sets memswap_limit equal to its mem_limit, which disables container swap outright; the default is twice mem_limit, so adding memory limits without it would have made this entry worse rather than better. The disk itself is unchanged, and so is this row's status.

So ~/.config/sops/age/keys.txt and the rendered artefacts under snmp-exporter/.rendered/, alertmanager/.rendered/ and stacks/observability/.env — which hold plaintext by design — are all mode 600 and owned by robo, and file permissions are the only thing protecting them.

Which makes anything that can ignore file permissions worth naming. Until 2026-08-31 the Alloy container was one: uid 0, every capability, and / mounted read-only, so it could read the age key outright. It now holds no capabilities and cannot (#188). The Docker socket it mounted was the remaining path — that API can start a container with / mounted read-write — and it is no longer mounted into Alloy at all: an allowlisting proxy holds it and refuses POST (#193). That moves the boundary rather than removing it, and the proxy is now the container to look at. Permissions mean nothing to someone holding the disk.

This is accepted rather than tracked as work. The threat model in docs/security.md already excludes an attacker with physical access to the rack, and this is that same exclusion stated at the filesystem level: recycled hardware, a home lab, and full-disk encryption on a headless host that must boot unattended after a power cut is a trade with its own failure mode. It is written down because the undo-file row above was only serious because of this — an undo file at mode 664 on an encrypted disk is a much smaller problem, and the two facts are easy to lose track of separately.

--storage.tsdb.retention.size=12GB bounds Prometheus. Loki has retention_period: 720h and no size equivalent, because Loki has no size-based retention to configure — so it is the only store on this disk bounded by time alone, fed by a push endpoint that is unauthenticated for the reason the ingest-port row above gives (#189).

Rate limits are the obvious response and they do not solve it. The lab produces roughly 0.012 MB/s of logs, so even a deliberately tight 0.5 MB/s ingestion_rate_mb is 40x headroom — and 0.5 MB/s still fills 59 GiB inside a day and a half. Any limit loose enough not to drop real logs is loose enough to fill the disk. There is no clean number, which is why one has not been picked.

What actually bounds this is who can write, not how fast, and that is authentication in front of the ingest ports — the work in #182, which this is a second justification for rather than a separate task. Until then the volume is bounded by trust in the segments that can reach 10.0.99.20:3100, which is the same control and the same firewall rules as the row above.

The measured position, so a later reader can tell drift from noise: loki-data was 461 MB on 2026-08-31 and 549 MB on 2026-09-04 — about 22 MB a day against 53 GiB free, which is years rather than months. Nothing here is urgent; it is unbounded, which is a different property from close.

HostDiskWillFillIn24h is the whole control if that ever changes, so it is no longer an untested rule: prometheus/tests/host.test.yaml asserts it fires on a disk that is filling, and stays quiet both on one that is full but stable and on one that is filling with room to spare. That file was added with this residual and for it — a residual is only as good as the control it leans on, and that control had no test at all.

Deliberate omissions, so their absence is not mistaken for an oversight:

• Full MAC addresses. Truncated to the vendor OUI, which keeps the useful half and drops the unique identifier.
• Owner-linked device names, and no room labelled as a child's.
• Camera-to-room mapping. That there are cameras is fine; which one covers which door is not.
• The WAN address, firewall rule bodies, and Wi-Fi configuration.
• Any plaintext credential. Secrets are SOPS + age encrypted; the private key never enters the repository. See secrets/README.md.

Every push and pull request runs:

• gitleaks over the working tree and full history, with rules for SNMP communities, inline Grafana passwords, PEM private keys and age secret keys.
• An assertion that every secrets/*.sops.yaml is genuinely encrypted, which needs no ability to decrypt.
• An assertion that no rendered or decrypted artefact — .env, .rendered/, .purge-secrets.txt — is ever a tracked file.
• Verification that every container image is pinned by tag and digest, so a moved tag cannot silently change what is deployed.
• Verification that every image any script, recipe, workflow step or runbook runs is resolved from compose.yaml, so a container cannot be started from an image the digest check never saw.

See docs/security.md for the threat model and segmentation rationale.