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 <aigar...@gmail.com> wrote: > 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 > > -- :wq
