Recent searches
Search options
If there were another binary backdoor similar to the xz attack that was found today... how would you find it?
(The xz attack was found by chance and some trivial issues that caused performance degradation)
@dfeldman One measure we should introduce: distro package maintainers should fetch both git and release tarballs to compare before accepting a new version. Release tarballs not matching actually-reviewed project history are a huge gratuitous threat vector.
@dalias autoconf complicates this by putting generated files in release tarballs that aren’t in git, and which won’t match the versions you generate locally unless you use the exact same versions of autoconf, auto make, libtool, and all associated macros, as the xz hack made clear. Other build systems (like meson) that don’t need you to distribute files that aren’t in git will simplify this.
@alanc Lots of projects commit output of autoconf, which has its own issues of course, but I think this is a data point in support of that practice...
@alanc At least if they don't want autoconf output in the main commit timeline, it should be added as a final branched commit before release tag so the release tarball matches the repo rather than having undocumented changes in it.
@dalias as one of the primary maintainers of the ~260 X.Org packages, I think our existing plan to port them to meson so the tarball contents are the git checkout without generated files is going to be easier than modifying our processes to check in the autoconf output (which we'd probably want to do in the CI pipeline so it doesn't keep changing depending on the distro/version used by each contributor).