On Mon, Mar 31, 2025 at 01:14:42PM +0200, Michael J Gruber wrote: > > This is only "SHOULD", because sometimes the git tarball is too large > > or has other deficiencies. Another reason is that the "upstream > > tarball" may be signed, and that'd be preferred to the unsigned "raw" > > archive. But those should be rare exceptions.
> we require to check signatures if present. Deliberately choosing an > unsigned tarball over a signed tarball circumvents that. That is why I listed the existence of a signature as one of the reasons to prefer the tarball _with the signature_. You seem to be arguing that we should not abandon signature checking, which is also what I said, so I don't know what the discussion is about. > Those (signed) should not be rare. In practice they are relatively rare. 'rg -l gpgverify *.spec | wc -l' says 525 / 24415 spec files (~2%) use the macro. > That also raises the question why an autogenerated tarball should be > more trustworthy - in the xz case, the person was able to commit a > release tarball and could have commit to the source tree as well. In my original email, I listed three reasons. Do you disagree with the other two? To expand on this one: it is true that the untrustworthy maintainer would have been able to add files to git too. But it is also true that people may much closer attention to the git commits than to the tarball. In fact, unless people get suspicious or something is broken, almost nobody analyses tarballs, in particular if they are *not* equivalent to 'git archive', but contain local irreproducible modifications, as is the case with autoconf scripts. Using the output from 'git archive' is better because it is easier to inspect. > Do we give up on signatures? Do we switch to signed commits (and trust > the forge's tarball creation for that commit)? The is a usability gap here. As an upstream maintainer, I can trivially sign release tags using 'git tag -s'. Those tags then the GPG signature of the maintainer doing the release, usually one of a few well-known maintainers. But I don't want to produce an archive and upload it, in particular because the git forge will autogenerate one. But then the user doesn't have an easy way to verify that that tarball corresponds to this tag. > Let me also mention the case where we have to clean sources (proprietary > material) before committing to the look-aside cache. We should document > how to do so in spec. > > Ideally, one could: > - get original sources > - check upstream's signature > - apply the checked-in clean script (which creates a tarball) > - check that the results matches the look-aside hash in "sources". That is why it's important for all the steps to be reproducible. If we have that, we can verify tarballs, even if they are produced via a script. Zbyszek -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
