On 6/18/24 10:03, Aigars Mahinovs wrote:
The point is that with certain git-centric workflows (like what Russ described for git-debrebase) there never is a *.dsc or a debian.tar.xz or even an orig.tar.gz. Those are never there to be checksummed. And the process for getting from the real git tree that a developer *actually* does their work on and verifies the contents of to these generated source artifacts is sufficiently non-trivial that people end up never actually verifying the files they are signing. The signature on the dsc is signing something that people never actually check.
How do you upload then? There's somewhere a script that actually creates the .dsc and .changes files for upload, right?
It is bad from a process perspective because it means that generation of these artifacts from the real source happens on many developer machines with many different configurations and versions and may be influenced by old bugs.
If the CI also write such .dsc and .changes files, then check that they match the version signed in the tag2upload tool, problem solved!
And it is bad from security perspective, because it is sufficient for one developer machine to have any piece of software in the software chain that assembles and signs the source package to be compromised and you will end up signing an artifact containing malicious code that never appeared in your source code tree or in any collaborative git repository.
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.
I then fail to understand how what I'm proposing (well, in fact what Didier demonstrated) is less safe...
And there is zero trace of that ever happening, except the already signed code package. Same as a compromised compiler (or any other component) injecting a malicious code packages directly into a binary while a developer is compiling a deb package.
We're talking about source-only upload, right?!?
The whole point of open source is to go back as much as possible from binaries running on the computer to a human-editable form of software. That is the source.
Nobody is proposing anything else.
So our release and signing processes should take that into account and start automated processing and signing of the source as close to the human-editable source as possible. tag2upload moves this a full step forward.
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.
The only annoying bit is we can't, with the Git workflow, have the CI go back to the DD's laptop when build is finished, to make it do the signature. So it must be done when the tag is created by a "tag2upload" tool. With the correct local tooling, that's not such a big deal, and it has been demonstrated that it works (watch again the lightning talk from Debconf Kosovo...). I really don't understand why you still believe it would be more complicated from the contributor point of view once the tooling are available.
Cheers, Thomas Goirand (zigo)
