On Tuesday, June 18, 2024 8:28:14 AM MST Thomas Goirand wrote: > How do you upload then? There's somewhere a script that actually creates > the .dsc and .changes files for upload, right? > > So, you're proposing to upload a signed git tag. I'm proposing that you > do that, PLUS 2 signed artifact within that git tag, that are later > check (expected to be bit-by-bit identical) against something that's > generated in a trusted environment. > > Agreed 100%. I'm just voting for a different way to write the > automation, one where the .dsc and .changes *SIGNATURES* are produce on > a DD laptop, just like now. Everything else is the way you describe.
From a security perspective, it makes sense to me that the DD should create a .dsc and .changes and sign them, and then tag2upload should create them as well and verify they match exactly. In terms of preventing the insertion of malicious code into the final build that is not represented in Git, this prevents either the DD’s computer or the infrastructure running tag2upload from doing so if they are compromised (unless they are both compromised in the same way). It also removes any concerns of Salsa or any other Git server being compromised as the host for the signed tag, including any concerns about SHA1 weakness. It addresses the FTP Master’s concerns by allowing anyone to verify the original intent of the DD by checking the DD signature on the .dsc and .changes. And it improves the security posture of Debian by generating the source package in tag2upload's controlled environment. From my perspective, the extra work that needs to be done on the DD’s system to create and sign the .dsc and .changes is worth the benefits in the previous four paragraphs. -- Soren Stoutner so...@debian.org
signature.asc
Description: This is a digitally signed message part.
