OSS Testbed & Discovery of the 'Big Leak'
Date: May 31, 2026
Status: Testbed Operational; Release Blocked (Critical Privacy Leak)
The Mission: Trust But Verify (Hard)
Shipping open-source isn't just about cleaning up the TODO comments. It’s about ensuring that the artifact you hand to the world doesn't contain the keys to your house—or the map of your internal network.
Today was supposed to be the final "go/no-go" for the ArgoBox OSS extraction. Instead of a green light, we got a radioactive purple alarm. We built a fully automated OSS release testbed—a clean-room Proxmox VM that takes a release candidate tarball, boots it, and tries to break it.
The testbed did exactly its job. It saved us from a catastrophic privacy failure.
The Infrastructure: The Clean Room
We didn't want to test the release on the same machine that builds it. That’s how you miss dependency leaks. We built a dedicated automation layer:
- Proxmox VM: A minimal Debian base, snapshotted for instant resets.
- Provisioning:
bin/provision.shhandles the one-time VM setup. - The Run:
bin/run.shtakes the locally built tarball, ships it to the VM viascp, unpacks it, and triggers adocker compose up --build.
It’s a brutal, honest loop. If a single npm install fails because a private package wasn't bundled, the testbed kills the run.
The 'Big Leak': Topology in the Clear
The critical failure wasn't a crash. It was a successful build that contained too much truth.
During the "Leak Gate" phase of the testbed run—where we grep the final artifact for known internal identifiers—we hit 567 matches.
The root cause was as simple as it was dangerous: scripts/prepare-public-release.sh was correctly excluding files, but it wasn't sanitizing content.
network-data.tsstill had the full list of internal IPs (192.168.50.x).- Hostnames like
Titan,MasaiMara, andBogartwere preserved. - Real usernames and local filesystem paths were baked into the source.
Because the release pipeline didn't apply the identity_map.json rewrites to the actual file contents, we were about to publish the full topology of our infrastructure.
The False Pass: SIGPIPE and the Silent Failure
Even scarier was the bug we found in the testbed itself.
A smoke test artifact leak-check was using a pipe: grep ... | grep -v ... | head -20 | grep -q ..
Because we had set -o pipefail enabled, and head closes the pipe after 20 matches, the grep process was getting hit with a SIGPIPE. In many shells, this causes a non-zero exit code.
The result? The if statement read the failure as "no leaks found" and returned a false PASS. We were one SIGPIPE away from thinking the leak was fixed when it wasn't. We’ve since refactored to a more robust capture-to-var strategy.
The Verdict
The OSS release is a hard STOP-SHIP until the content sanitization logic is integrated into the release pipeline.
The testbed proved its worth. It didn't just tell us the code worked; it told us the code wasn't safe to share. Engineering is a liberal art, and today’s lesson was about the ethics of the 'Big Leak.' We don't ship until the topology is a ghost.