Redacting network identifiers from a debug report

The bug template asks reporters to attach omarchy-debug output, and nothing warns them what is in it. install/config/firewall.sh enables ufw, ufw ships LOGLEVEL=low, and so every blocked packet lands in the kernel log with the addresses of devices on the LAN. Two cases are sharper than that. The kernel’s wifi association lines carry the access point BSSID, which resolves to a street address through public wardriving databases, and bluetoothd logs the address of every paired device.

The scrub drops [UFW BLOCK] lines and substitutes MACs in all three renderings (aa:bb:, dev_AA_BB_, wlxaabbccddeeff) plus IPv4 and IPv6, through one shared function applied to both the dmesg and the journal sections so the two cannot drift.

Most of the work is in not destroying the diagnosis. Loopback, link-local and the unspecified address stand aside first, because 169.254.x.x is a failed DHCP lease, 127.0.0.53 a query to the resolved stub, and 0.0.0.0 a wildcard bind. An octet range check spares firmware versions such as 10.1.467.2. IPv6 substitutes before MAC, and neither may begin after a colon, so the MAC rule cannot eat six groups out of the middle of an address and leave the prefix.

The part worth recording is the verification. The first check used the same lowercase pattern the code used, so it reported eleven down to zero when the truth was eleven down to one. A later one looked for survivors rather than for corruption, so it could not have caught a rule mangling caf::actor_system. A redaction check has to be written wider than the redaction.

The hostname is still in there, on purpose. Whether these reports carry one is a product decision, and it changes every future report.