Do you actually check that the contents of the source *package* (after all operations done by dpkg-source and possibly other tools) actually match what you were looking at before in your source work tree folder?
Using the package compiled for the source package does very little to check for malicious code injections. You are not checking for unexpected network traffic or trying it in all environments that might contain trigger conditions. Like if attacker working you is actually targeting Iranian nuclear projects and the code will only activate if the local network has some peculiar network names or numbers. Your stamp of approval should be on the thing you actually read and checked, like your local git tree, which is then pushed (with the signature) to the public repos for all to see and then all subsequent processes can run out of that *public* true source. An official Debian build server for tag2upload is not a random 3rd party. It has the same exact security as the buildd servers that all of us have been relying on for years for much more complex (and less reproducible) binary builds. If it was good enough for binary packages (even when reproducibility was terrible), then it must be good enough got tag2upload as well. On Tue, 25 Jun 2024, 11:23 Thomas Goirand, <tho...@goirand.fr> wrote: > On 6/24/24 23:31, Aigars Mahinovs wrote: > > 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. > > I'm sorry, but I cannot make a reasonable sense of the above, even if > you're repeating it over, and over and over... > > Of course what I expect in a source package is ... my source code! In so > many ways, I'm checking what I upload. For example, by using and testing > what I uploaded. Right, I haven't checked all files checksums one by > one. Never the less, I am currently confident that what I uploaded is > what I expected. That doesn't change much with the workflow you're > proposing, I'd still check that things are working as expected. > > But to the contrary of what you're saying, that *is not* the problem. > The problem is that you're proposing to sign something, and upload > something else, signed by 3rd party CI that you're willing us to blindly > trust. This makes no sense. We want your stamp of approval on the thing > you're actually uploading, not something else. You may as well make a > signed request to a REST API, it wouldn't be very different from signing > a tag in a random Git repository. > > Cheers, > > Thomas Goirand (zigo) > >
