On 6/25/24 08:55, Matthias Urlichs wrote:
On 24.06.24 23:20, tho...@goirand.fr wrote:
I see it as signing the very thing that is pushed to the Debian
archive. You aren't uploading a bunch of git SHA to the archive but a
source package. It feels very normal that therefor, that is the thing
that we would like you to sign. Too bad this is less convenient for
your workflow, but that is the correct semantic.
Well, yes. Right now this is the case, and t2u adds an additional step
to that equation which historically we didn't have.
However …
(a) the thing I'm signing isn't the thing I worked on. I didn't look at
it and, given a git-centric work flow, nobody else will either. It feels
very unnormal to me that I'm signing some artifact that I didn't even
look at. Heck it felt unnormal to me 20 years ago when I joined and
built my first packages.
I do not feel like it is a good point of argumentation that you're
saying you wont look at the uploaded source package as an excuse. I do
not believe it's a good thing as well, that you're saying you have a
completely different view of what's going to end up in the archive.
Altogether, it feels very wrong that you're taking all of that as an
excuse to say you prefer to only sign a git tag and not bother with
anything that goes after that.
(b) we might decide, sometime in the future, that sources.dgit.d.o is to
be treated as part of "the Debian archive" and that our builders shall
pull from there instead of unpacking a tarball if the maintainer used
t2u, thus effectively removing your objection.
I do not care if it's the buildd or the Salsa CI that does the job of
transforming your git tree into something usable by DAK. I don't care
either whatever transformation of your source thing is involved, that's
your own sauce, and I'm fine with whatever tooling you end up using. You
have the full freedom to do what you feel like is more productive or
convenient.
Though I do care that one signs (meaning: puts their approval stamp on)
a source package when uploading, as this is the artifact that DAK will
actually use (plus the resulting .deb built by the buildd network, but
they use the same source package we're talking about, and it's supposed
to be reproducible).
I do not think it is reasonable that a particular (git?) workflow,
specific to the way *YOU* prefer working, gains special upload rights.
I've read about the deb-rebase workflow, I would hate it, and prefer
managing patches with quilt directly. Does this mean your tag2upload
doesn't work for me? What if I do not like your workflow, and prefer my
own way, and then we need a 2nd way of doing tag2upload? Do you think
that then, a 2nd key used to sign tags shall be trusted by DAK? Or a 3rd
one? Is there a limit and what is it, to your opinion?
Please do not misread me: I would love a tag2upload feature, and would
use it myself. But I very much dislike the implementation you're
proposing, which is basically, that we need to blindly trust a signed
tag in Git + Salsa CI, and nothing else. This is broken in so many ways.
Cheers,
Thomas Goirand (zigo)
