4 ms·
I don't think air-gapping is particularly helpful in practice - for large and active codebases, you'd need to read all of the changed source code on the air-gap
by geofft 8y ago
I don't think air-gapping is particularly helpful in practice - for large and active codebases, you'd need to read all of the changed source code on the air-gapped machine to look for subtle back doors, which is difficult. Alternatively, if you want to do air-gapped builds and binary signatures, you're going to have to copy over the build-dependencies, which for most build environments are assumed trusted (i.e., they can compromise your air-gapped machine).
For small and intermittently-active ones, the primary development constraint is the OSS maintainer having free time, and doing dev or builds on an air-gapped machine is a big time sink. I maintain very little open-source software and I have still tried to at least use a separate machine for builds + PGP signatures and not my day-to-day machine, and maintaining this machine is just overhead that eats into my, what, one evening every two months that I get to spend on my project.
The solution I'd like to see is a) better tracking of community code reviews/audits; if every line of code has been read by multiple people (perhaps identified with a PGP key, but something simpler would be fine), you're more confident that there are no subtle backdoors than if you make one person stare at the entire diff between major versions on an air-gappped machine until their eyes glaze over, and b) better ways to do builds on multiple clouds and verify that they're identical. The Reproducible Builds effort is a good approach here; if you do that plus a CI infrastructure that runs on two different clouds with two different signing keys, and client systems require both signatures, you can be reasonably assured that the build process wasn't compromised.