v0.5.7 — What a real machine said

Installed on an Ubuntu 24.04.5 arm64 machine, kernel 7.0.0, and started as a service — which is how almost everybody will run this, and the one path nothing here had ever taken. Two bugs, both in released code, and a hint the validator had been printing all along.

Interception could never start from the systemd unit

not intercepting: preparing the certificate authority: … creating /usr/local/share/flowlight:
Read-only file system (os error 30). Watching continues.

The unit sets ProtectSystem=full, so /usr is read-only to the service, and the daemon published its certificate authority to /usr/local/share/flowlight by default. The feature was unavailable the normal way round, and said so in a line of the journal nobody reads.

The unit already granted write access to exactly one directory — ConfigurationDirectory=flowlight — and its own comment said the certificate belonged there. The binary disagreed with it. The default is now /etc/flowlight.

Why nothing caught it, which is the part that needed fixing more than the path did:

• the smoke test always passes --certificates explicitly, so the default was the one path nothing exercised;
• CI installed the package and asserted the unit had not started, which is not the same as finding out whether it could.

CI now starts it, insists it is watching, and fails on any read-only filesystem error in its journal.

flowlightd check told a person their machine could not be watched

On Ubuntu /sys/kernel/tracing is drwx------. That refuses a person entry, so looking inside it to find out whether it exists answers "it does not" — and the report read that as "no tracefs" rather than "you are not root", then concluded the machine was unwatchable. It watches perfectly well.

The v0.5.4 fix for exactly this was verified on a runner whose directory is searchable, so CI agreed with the mistake. It is now decided by what the machine actually said: an io::ErrorKind::PermissionDenied anywhere in the error chain, and not root, is unknown.

flowlight-platform has a test that creates a directory nobody may enter and asserts a refusal and an absence are told apart — and asserts it is not running as root rather than passing quietly if it is. tracefs::mounted reads /proc/mounts as well, because the mount table is readable by everybody and is the thing that actually knows.

A hint that had been printed and ignored

Categories named three main categories, and desktop-file-validate said so: "application might appear more than once in the application menu". It exits zero for a hint, so CI was reading the status and ignoring the sentence. It now fails on any output — and earned its keep immediately by catching a second hint inside the fix for the first: Security asks for Settings or System beside it, and adding either brings back the original complaint. So Security goes. Network;Monitor is what a network monitor is.

What the machine confirmed, for the record

A static binary with no declared dependencies; installed disabled; check as root saying everything is here; probes loaded into kernel 7.0.0 and six requests read in the clear through OpenSSL (python3) and GnuTLS (wget), each attributed to the right process and pid; Firefox's NSS found inside its snap; Coverage reporting nothing unread and nothing dropped; the window resolving all 104 of its shared libraries against libadwaita 1.5.0 and GTK 4.14.5.

Four distributions' worth of CI missed both bugs, because both lived in the gap between "the package installs" and "the service runs". One machine, four minutes.