I was considering replying to this comment on the “please update xz package” bugreport earlier with that the discussion is not irrelevant and that it’s the maintainer’s responsibility on new upgrades to check for new legal issues and “other hidden gems”.
I didn’t because I didn’t want to bother going in with an annoyed self-righteous “user”.
Now it turns out all three of the involved ones were “string + number @ freemailer” #JiaT75 sockpuppets, so it’s probably okay I didn’t bother.
Not that I blame Sebastian — it was very well hidden, and even my usual diffing between old and new version would not have found it.
I do take away from this to also check the diff between VCS repo at the time of the release and release tarball. Perhaps also between branch and tag if they, like Apache Tomcat, introduce extra commits there.
@mirabilos What I do at work (mostly because I don't want to end up with test code/test artefacts in production binaries): I build each component twice in my build pipeline. All tests are run this first time, but I discard the output. Then, I do a fresh checkout, delete all test code, and then compile everything again, using the build output for packaging. Would that have helped in the current scenario? So far, I understand the malicious payload was disguised as test data.
Add comment