On Thu, Nov 28, 2024 at 10:35:49AM +0100, Simon Josefsson wrote:
>
> I think this is a good example of us talking past each other in this
> thread: some people question the value of pristine in the first place
> (and I've been compelled by those arguments), and some people argue that
> the cost is small and there are no bugs (or at least lack of bug
> reports).
Our current system addresses a number of requirements, and it seems to
me that a number of the alternate solutions don't necessarily meet all
of the requirements.
Some of these requirements include:
*) We want an easy way to make sure the sources used to rebuild debian
packages aren't maliciously modified. We do this today via PGP
signed tarballs.
*) As much as possible, we want to be able to use the unmodified
source files are officially released by upstream. Which might be a
tarball and/or a signed git tag.
*) The sources that we redistribute alongside our binary packages must
be DFSG compliant. In some cases this might mean repacking the
tar file, and might interfere with using upstream's official signed git
tag.
*) We don't want to break the interface provided by "apt-get source" and
debian source packages more generally.
I have my own personal requirements that might not be shared by
others. For example, I don't like having to keep source tarballs
around when I need to rebuild debian packages, and tracking them down
by hand. I also want to keep the storage overhead as much as possible
(hence, why I like pristine-tar). And I want it to all work
automatically using my current build tools, which today is
git-buildpackage. And finally, I am occasionally doing work in
network constrained environments (for example, while using my laptop
in an airplane), so I prefer to avoid solutions that start with "and
then we download the tar.gz file from the network".
Perhaps we could avoid talking past we formally had a list of
requirements, and then match possible alternative approachs with how
well they meet the agreed-upon requirements, and which requirements
proponents want to dispense with because (at least for them), It's
Just Not Worth It?
> If we are worried about malicious upstreams replacing tarballs, or
> man-in-the-middle attacks, I think my debian/upstream/*SUMS approach is
> a more effective solution to that problem.
Maybe... if there were tools that made it super easy to validate the
tarball against the *SUMS files without needing to unpack the tarball
first? Possibly with an inline GPG signature so we don't have to have
separate SHA256SUM and SHA256SUM.asc files? For bonus points, maybe
also a tool that validates a SHA256SUM file with a git commit id,
again without needing to do a "git checkout" first?
I will note that this approach would break backwads compatibility with
existing Debian source packaging, right? That is, you're proposing
that the debian/usptream/*SUMS file would replace the
*.orig.tar.gz.asc file?
- Ted
