Was the xy-utils compromise not happening until we became aware of it? There could be packages in Debian compromised this way right now and we wouldn't know unless we specifically looked for it. And even then we would not have much to actually compare to in order to detect such problem. Which developer change is legit and which is an injection?
To detect this each developer would have to download Debian source of all their packages, unpack (on a separate computer) and compare the source tree to the contents of their main computer. There is no cryptographic relationship between the signed source *package* and the actual source. That *is* the problem. Inspecting one thing and then signing something else is the problem. On Mon, 24 Jun 2024, 23:00 Scott Kitterman, <deb...@kitterman.com> wrote: > 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. > >> > >> > >
