Re: [RFC] General Resolution to deploy tag2upload
On Tue, 18 Jun 2024 at 01:57, <thomas@goirand.fr> wrote:
> > There are plenty of valid use cases that do not create a dsc locally.
>
> Please be specific in why it is unacceptable to have a local tool do local (very quick) computation in a full automated way for you. Why is this unacceptable?
>
> > The whole point is that dsc package is *not* source. It is not the format most commonly used for development work. It is an intermediate software generated artifact.
>
> What point are you trying to make here? A .dsc is metadata for the upload indeed, just like the
> .changes. Then what? Why should you care if a local tooling on your laptop is building it, adding it to the signed tag, and maybe (optionnaly) deleting your local copy after sending it to Salsa CI for the upload?
>
> > Everything after that: dsc, deb, Packages.gz, Release.gz are generated from that actual source tree and can be handled by appropriate automation.
>
> Have you ever created a .dsc file by hand? I suppose answer is no. So what is the trouble ? Or are you saying I am proposing to do that ? I suppose no as well. So what bothers you? :)
>
> That your laptop need to calculate the hash of your debian.tar.xz when tagging? Isn't this a very small deal to make, so we don't need to touch a bit to our infrastructure, auth and ACLs? Plus having no "a single key to sign them all" would be an awesome feature.
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.
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. It is the exact same reason why we stopped
building all binary packages on developer local machines.
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. 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.
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. In a git-centric workflow the git tree is the
source of the software, not a tarball. 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.
--
Best regards,
Aigars Mahinovs mailto:aigarius@debian.org
#--------------------------------------------------------------#
| .''`. Debian GNU/Linux (http://www.debian.org) |
| : :' : Latvian Open Source Assoc. (http://www.laka.lv) |
| `. `' Linux Administration and Free Software Consulting |
| `- (http://www.aiteki.com) |
#--------------------------------------------------------------#
Reply to: