[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFC] General Resolution to deploy tag2upload



I sure want to stay clear of this conversation, so I'm going to drop this and make it brief

(not to grandstand, but in the spirit of being honest and speaking my truth -- I personally (without any hats on) I'm interested in the end-goals -- this effort seems like a good thing to help move the project forward, reduce toil and secure the archive. This specific project was done in such a way that I want to avoid this tag2upload thing as much as I can. I don't think my time and thoughts would be respected, given the lack of communication and interest in collaboration. This isn't a great start to a project -- 5 years of radio silence and stories re-told within a team about others, and a GR threat dropped on a team that's the repeated subject of project ire rather than in interest in talking directly isn't fun -- I know i'm being a bit harsh here but it's not pleasant to see this come out, even I agree with the end goals)

It sure seems like there's a foundational disagreement that needs to be overcome before we mash through a specific implementation given mismatched constraints -- which is, "what does source mean to Debian".

I wonder if we have a good idea of what the project believes to be the case between #1 and #2:

1) Is the source of a package the debian source distribution?
2) Is the source of a package the VCS where the source is held?

Or, to extend it once more in the context of this discussion -- should the source be built by a buildd from the "true" source? Why do we bother having a maintainer sign this intermediate artifact, like we used to with debs?

Even more extremely -- should we bother with dscs anymore if they're just an intermediate artifact?

Most extremely -- do we need a new dpkg source format? Should buildds build off git tags? Do we need to overhaul how we treat sources?

Galaxy brain extremely -- what does GPL compliance mean if the dsc is not the true source? (ok this one isn't serious, there's no doubt it's corresponding source :) )




On Tue, Jun 18, 2024 at 11:57 AM Aigars Mahinovs <aigarius@gmail.com> wrote:
On Tue, 18 Jun 2024 at 17:44, Soren Stoutner <soren@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



--
:wq

Reply to: