Hello everyone, As I'm sure we're all aware of at this point, Debian has been a victim of a relatively sophisticated first-party attack whereby a backdoor of the XZ package was smuggled into sshd via a systemd dependency. This backdoor, at a minimum, attacked key verification. As far as I understand, it is not yet understood what exactly the effects of these backdoors are. (There are two versions 5.6.0 and 5.6.1 that are affected, and investigation is ongoing.)
There are many things to talk about here, but one that involves the task of package maintainers, and that I would like to discuss now, is the way the backdoor was distributed. The code in the xz git repository does not build a vulnerable version, while the code in the 5.6.0 and 5.6.1 source tarballs do. This is a vector I've been somewhat paranoid about myself, and I typically check the difference between git archive $TAG and the downloaded tar, whenever I package things. Obviously a backdoor could have been inserted into the git repository directly, but there is a culture surrounding good hygiene in commits: they ought to be small, focused, and well described. People are comfortable discussing and challenging a commit that looks fishy, even if that commit is by the main developer of a package. I have been assuming tooling existed in package maintainers' toolkits to verify the faithful reproduction of the published git tag in the downloaded source tarball, beyond a signature check by the upstream developer. Apparently, this is not universal. Had tooling existed in Debian to automatically validate this faithful reproduction, we might not have been exposed to this issue. Having done this myself, it has been my experience that many partial build artifacts are captured in source tarballs that are not otherwise maintained in the git repository. For instance, in zfs (which I have contributed to in the past), many automake files are regenerated. (I do not believe that specific package is vulnerable to an attack on the autoconf/automake files, since the debian package calls the upstream tooling to regenerate those files.) We already have a policy of not shipping upstream-built artifacts, so I am making a proposal that I believe simply takes that one step further: 1. Move towards allowing, and then favoring, git-tags over source tarballs 2. Require upstream-built artifacts be removed (instead, generate these ab-initio during build) 3. Have tooling that automatically checks the sanitized sources against the development RCSs. 4. Look unfavorably on upstreams without RCS. In the present case, the triggering modification was in a modified .m4 file that injected a snippet into the configure script. That modification could have been flagged using this kind of process. While this would be a lot of work, I believe doing so would require a much larger amount of additional complexity in orchestrating attacks against Debian in the future. Best, Antonio Russo
OpenPGP_0xB01C53D5DED4A4EE.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
