Post
This week on #OpenSourceSecurity I talk to @ottok about his blog post about detecting an attack like xz in Debian
It's a fascinating conversation about a very complicated topic
There are things that could be detected, but this one would have been very very difficult
@joshbressers @ottok one thing we finally made real in #curl as a direct consequence of the xz attack was reproducible builds. Since the xz release added things into the release that did not come from autotools nor git, verifying reproducible builds would have caught that. Having that in place forces attackers to land their backdoor in git to be able to ship it, which should increase the bar significantly.
@joshbressers @ottok building from git means building without autotools on every single platform and would mean I would have to use cmake on a daily basis which would drive me nuts. So not likely to happen anytime soon in curl 😃
@bagder @joshbressers There are also many projects not using git. The plain files collection (tarball) will remain as the lowest common denominator for a long time. Anyway the build change could have also been committed to git just like the new test files were. Doing it in only the tarball was just one layer of extra obscurity, not really the key here.
@ottok @joshbressers I think it was part of the key for the xz attack. The git repository gets wider exposure and review by the public - that was avoided by injecting the files directly into the tarball.
@joshbressers @ottok yeah, in the #curl case I hope and wish that the people making the curl packages for distros (or build curl for other purposes) do the reproducible check - so that they know for sure that the one doing the curl releases didn't smuggle anything in. It also usually also requires that a few people do it and can trigger the alarm if they would find something odd.
At least we make it possible.
A space for Bonfire maintainers and contributors to communicate
