Michael Catanzaro venit, vidit, dixit 2025-03-31 23:37:42: > On Mon, Mar 31 2025 at 08:09:49 PM +00:00:00, Zbigniew > Jędrzejewski-Szmek <zbys...@in.waw.pl> wrote: > > OK, I guess I need to work on my English. You're the second person who > > read the abovequoted part in the exact opposite way to what I > > intended :( > > Hm, well I misread. You didn't write the wrong thing. > > But honestly I'm not sure that using an upstream GPG-signed tarball is > really more trustworthy than using a forge-generated tarball. The > question is: do I trust the upstream forge infrastructure more, or do I > trust the computers of the maintainers who have access to the GPG > signing key more? I think a compromise of GitHub infrastructure is less > likely than a compromise of an individual maintainer, so it really > probably does make sense to trust the forge.
Please note that when I raised the question about trustworthiness, I raised it as an open question to be answered before changing things, simply because: - trustworthiness (or lack thereof) was part of the argument - trust is implemented as "should check signed tarball" in the packaging guidelines So, open question, not "derailing attempt". The change should be a change to the better, not just different solution. The "signed release tarball" approach puts trust into a single person/key, which is why we commit the actual key to dist-git - i.e. we document and state whom we trust. If it's "unsigned release tarball" vs "forge generated tarball" (from unsigned commit) there is the same low level of trust (if both can be "committed" from the same set of committers), but the "forge generated tarball" is certainly more reproducible (its contents) and checked more easily. Indeed, if we document the commit hash in the spec (or a future version of "sources") then it serves a purpose similar to the tarball hash (as far as verification goes). Effectively, we put our trust into the maintainer who commits that hash, i.e. "signs off" on that hash. We could think about signed commits or tags in dist-git (or source-git) if needs be. And we may very well decide that that trust is enough, or even the more relevant trust for us as a distro. After all, reproducibility is the technical side of the trust medal - and model ;-) Michael -- _______________________________________________ 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
