On 15.06.24 09:03, Simon Josefsson wrote:
As far as I can tell, tag2upload will make reproducible source artifacts harder to achieve (git-archive is run as a SaaS, and may not match what upstream publish) and verify (any PGP signatures from upstream on the git-archive is thrown away), but in Didier's approach both properties seems native and built in from the start.
You're assuming that Upstream actually publishes tarballs. That assumption becomes more and more unlikely, these days.
On the other hand, Upstream has presumably tagged their release; a tag which then was used to build their tarball, if it exists. They might even have signed that tag. :-P
So why would we want to use the tarball instead of the tag?When I work with git (i.e. all the time, these days) I want the sources to be in git. I want "git blame" to work. I want to be sure that what's in my git tree corresponds to what the build system saw. And so on. I do *not* want to manually check that the Upstream tarball corresponds to the Upstream tag, much less being forced to do so because Debian chooses to use the latter.
That upstream tarball might well be signed, but I know nothing about how clean it is and whether it contains any artifacts that aren't in git but have been added by some random build system (not to speak of malicious agency, as in the xz compromise).
To me the source tarball is a necessary evil, required by our builders because they haven't yet learned to simply "git clone" the Debian branch from Salsa, push to an append-only git store for archiving and reproducibility, and be done with it.
To me, tag2upload is one step towards that goal, frankly we can't get there fast enough IMHO. One thing we definitely do *not* need on the way there is increased reliance on upstream tarballs, whether implied or explicit.
-- -- regards -- -- Matthias Urlichs
OpenPGP_signature.asc
Description: OpenPGP digital signature
