Le mardi, 25 juin 2024, 19.14:53 h CEST Russ Allbery a écrit :
> tho...@goirand.fr writes:
> > Watch the Kosovo lightning talk where Didier shows what he did. It is a
> > proven concept.
>
> If this is the proof of concept where the *.dsc file is encoded in a Git
> tag (sorry, there have been several proofs of concept and I lose track of
> which person was associated with which one), I understand it and have
> already said why I don't think it will work reliably enough in its current
> form. (Summary: It relies on the reproducibility of tar and compression
> programs.) We should measure reproducible source packages by comparing
> the unpacked source packages. It's a lot more robust.
For the record: I agree with Russ.
My PoC was written out of the desire to let Salsa CI upload _after successful
tests_, and I took the "inline the source package as built locally in a git
object" route for that. It inlines the .dsc and the _source.changes. As Russ
(and others) have demonstrated, this kind of concept is going to be very
fragile and very susceptible to breakage (with origins in varying versions of
dpkg, tar, git-archive, pristine-tar, source building workflows, etc etc): in
other words, it relies on the reproduciblity of _source packages_,
reproducibility of the conversion from a git repository to a source package
(which is out of scope of the reproducible builds' team, last I checked).
It also falls short on its original promise: given that (a modified, inlined
version of) the signed source package is pushed to Salsa, the uploader has
already vouched for the upload to Debian, even before the "required" tests
have ran.
The workflow I proposed was to delegate the actual upload to a CI job, but it
has no additional git-centric or security-centric properties than an uploader
pushing a git tag and uploading to DELAYED/1 simultaneously, and then
promoting, or cancelling depending on the CI test results (besides a bit less
manual work).
Another caveat with that approach, is that it clearly needs a Debian-specific
tool to build the inline data and add it to git (and then another to unpack it
and upload). As I wanted something auditable, I inlined text signatures and
refused to inline things out of the source tree, but it would be easy to
commit the actual signed source binaries to git and get the same process (and
effect). But then there's no point in using git, just upload it!
I think the tag2upload is a much better and stronger approach than my PoC for
these reasons:
- the dgit tools cover way more ground in terms of supported git workflows, to
get closer to reproducible source package building from git
- the PoC's promise to "only upload after successful CI" is nice, and not
covered by tag2upload (yet?), but is not really important in the big picture;
it's not such a fundamental property for a git workflow that it is worth
blocking the tag2upload proposal for. (and it's likely quite simple to get
that with tag2upload)
- tag2upload (especially with multiple, parallel instances of it) would test
reproducibility of the git-to-source process that is currently absolutely
untested. I totally concur with the impression that almost nobody is actually
dissecting source packages (as signed, I really mean the orig tar and
.debian.tar files) before upload; as well as the fact that even those doing so
are very likely to miss anything unusual in there, making the check mostly
useless.
OdyX
