On Fri, Jun 14, 2024 at 02:35:24PM -0700, Russ Allbery wrote: > Phil Morrell <deb...@emorrp1.name> writes: > > > 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. > > I also have questions about whether pristine-tar is a viable long-term > technical design.
It's not. It *could* be viable, pending implementation details, if we could get the archive to verify checksums on uncompressed tarballs, i.e. dak would effectively ignore the compression, and then only verify the contents of the uncompressed tarball. The plain tar format is simple enough that is easy to produce, and even in the cases where it's not (like tarballs produced with a weird tar), a binary diff would be ridiculously small because the metadata embedded in the tarball is very small compared to the actual data. But that would open yet another can of worms, not to speak of the amount of tools that would need changing to support storing and verifying hashses on the uncompressed content tarballs. > We have to maintain a lot of changes in underlying > tools to make it work, and my understanding is that we've had failure > modes in the past where a tarball is reproducible with pristine-tar at the > time, but if you try to reproduce it five years later with the current set > of tools in unstable, that may fail. The problem that it is trying to > solve is technically very difficult and also not prioritized by various > upstreams, which puts it on rather shaky ground. > > If we want to continue supporting verbatim upstream tarballs as the basis > for Debian packaging (which I think we clearly do for at least some > packages), I think it would be better to think about how to introduce the > actual tarball as an artifact using git-lfs or some similar approach, > rather than attempt to reconstruct it from Git. That already exists: pristine-lfs. > The tools simply don't support doing the latter, and pristine-tar has > to go to heroic efforts to try to make this work. > > This of course has all of the known problems with potentially malicious > upstream tarballs that differ from Git tags, but there are ways to detect > some of those problems while still basing the packaging on the actual > tarball as released. And it would let us reuse the upstream signature on > the tarball, which is useful in some cases to provide a bit of additional > provenance and tracing. That too.
signature.asc
Description: PGP signature
