Phil Morrell <deb...@emorrp1.name> writes:
> On Fri, Jun 14, 2024 at 12:26:50PM +0100, Ian Jackson wrote:
>> Andreas Tille writes ("How is the original tarball obtained in tag2upload"):
>> > In many teams we keep the metadata about the
>> > orig.tar.$COMPRESSION tarball in pristine-tar branch. In most cases
>> > this works flawlessly but I've observed some exceptions and read about
>> > potential problems with pristine-tar.
>>
>> Firstly, if there is an orig in the archive, the t2u robot will use
>> that. Failing that, it will use "git-deborig" which will call
>> "git-archive". Currently there isn't any support for pristine-tar;
>> that would be possible in principle.
>
> (risking doing design on debian-vote, but it's a bit late for that)
>
> It's been my impression [citation needed] that pristine-tar/lfs still
> exists mainly out of inertia and simple tooling around it that makes it
> more of a why not. If we're gaining a mostly git-native upload workflow
> out of this, I think it would be wise to second-guess if this support is
> even needed in tag2upload.
>
> You're already using the archive to obtain the orig.tar where available,
> which neuters one of pristine-tar's purposes: to get everything needed
> to build past releases from just a git clone [1]. New upstream versions
> *for likely users of tag2upload*, I believe the git-archive generated
> tarball would be a sufficient incidental artifact to be uploaded -
> making tag2upload the authoritative one-off source instead of
> (presumably) upstream's forge generator.What I think is missing is for tag2upload to be able to use and/or verify upstream's PGP signed git-archive tarball. The git archive format is known to not be stable nor reproducible over time, and there are upstream who PGP sign the the git-archive tarball. I'm still a supporter of tag2upload on social grounds, but on technical and security grounds there are several things that leaves me unimpressed - but we are good at improving technical things over time. FWIW, I found Didier's "debconf22-94-lightning-talks.webm" talk to offer a better approach, which is more consistent with reproducible artifacts: https://meetings-archive.debian.net/pub/debian-meetings/2022/DebConf22/ 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. /Simon
signature.asc
Description: PGP signature
