mastodon - Link to source

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

opensourcesecurity.io/2025/202…


Detecting XZ in Debian with Otto Kekäläinen

In this episode, Josh and Otto dive into the world of Debian packaging, exploring the challenges of supply chain security and the importance of transparency in open source projects.
Josh Bressers (Open Source Security)
#opensourcesecurity @Otto
in reply to Josh Bressers

mastodon - Link to source

daniel:// stenberg://

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.
#curl
in reply to Josh Bressers

mastodon - Link to source

daniel:// stenberg://

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.

#curl
in reply to daniel:// stenberg://

mastodon - Link to source

Otto

@bagder 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.
@daniel:// stenberg://
⇧