It's pretty simple. Compromise the computer of one developer, the one they use for development. Have your code be in one of the tools being called during Debian source package build (you don't even need root, just writable element in PATH). Now you can inject a malicious payload directly into the tarball or debian diff of the target Debian source package. The developer will never see it in their code. It will arrive in the archive signed by the victim as part of normal delivery. There will be nothing suspicious about it unless someone else does a NMU and sees a bigger than expected debdiff.
Even if the developer is very security minded and maintains a separate air-gapped signing laptop, that doesn't help unless you first actually analyse the actual artifact that you are signing. Maybe it would even possible to trick the developer into to signing an upload of a different package (add a binary package with high version to their source package?). With tag2upload there is no obscured source package file to be signed, so all content going into the archive must already be visible in the git repo being signed and will also be visible in the dgit repo. Any difference to the upstream will be quite obvious in either case. That is the difference between signing something that no human will ever be reading and singing the actual source that everyone will be looking at. And that is the difference between needing to secure just one service (tag2upload) instead of securing a thousand work PCs of all DDs. And we do this already for build machines. If one would want to sneak stuff into Debian, hacking a buildd would be the best target - you are putting hacked binaries into end user machines without leaving traces in source packages or repos. An attack on upstream where a release tarball is different form upstream git tree would also be side-stepped by the Debian maintainer simply using only the git tree as upstream and completely ignoring the tarballs. It would not provide a solution for code hidden in the upstream git itself that the maintainer missed. On Mon, 24 Jun 2024, 22:03 Scott Kitterman, <deb...@kitterman.com> wrote: > Do you have any examples of problems that this would have avoided > (xz-utils isn't one - due to the way it's releases are done, it wouldn't be > suitable for tag2upload)? > > Scott K > > On June 24, 2024 6:36:59 PM UTC, Aigars Mahinovs <aigar...@gmail.com> > wrote: > >Signing something that you did not write and something that you don't read > >is a bad security practice that exposes you to various attacks. > > > >Just because we have been doing this poor security practice for a long > time > >does not make it better. Now better methods are possible and we shouldn't > >prevent them from being used just because we are used to the weaker > >approach. > > > >On Mon, 24 Jun 2024, 18:34 Scott Kitterman, <deb...@kitterman.com> wrote: > > > >> > >> None of that changes the fact that it's what they signed. Historically, > >> the project has found that useful and I think it still is. > >
