I understand the theory. Are we aware of it happening? Scott K
On June 24, 2024 7:42:25 PM UTC, Aigars Mahinovs <aigar...@gmail.com> wrote: >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. >> >>
