On Tue, 18 Jun 2024 at 17:44, Soren Stoutner <so...@debian.org> wrote:
> 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.
They will not. Translation from a git tree to a Debian source package
with dsc and changes
is not a trivial operation. The results of it change over time as
tooling and procedures evolve.
And that is a good thing. The exact formatting of the changelog
entries generated from git commits
or of the patch files generated from git changes can and will change
over time. So a Debian
source package generated for the same exact git source may be
different depending on what
versions or the involved tooling the maintainer and the tag2upload are using.
But none of those changes *actually* matter, because what the
maintainer is looking at, verifying and
signing is the state of his development folder, his git tree. He is
not changing, inspecting or
validating the Debian source package. That is why it makes no sense
for the developer to sign
the Debian source package - he has no idea what is in it.
The git tree, the commit id and the associated git object hashes *is*
the actual manifest of the
actual source code files that the developer inspected and is attesting
to be correct.
Not their transformed versions in the Debian package format.
This is *exactly* the same situation as we already have with
source-only uploads. There is a
state of the software upload that the developer signs off on and then
there are further technical
build artifacts that the developer does *not* sign - they are signed
by the technical systems that
generated those artifacts. And those systems are centrally maintained
for scalability, convenience
and security.
All this is just an extension of the source-only upload to be even
more "source".
--
Best regards,
Aigars Mahinovs
