Top posting to answer all of you. It now accumulated a lot of reasons to not enabling it. Corner cases, race conditions, and practical ones in a wider scope. Very interesting. Thanks for the insights. Leon Am 09.09.20 um 17:00 schrieb Ken Dreyer: > On Tue, Sep 8, 2020 at 7:56 PM Brian Stinson <brian at bstinson.com> wrote: >> There's also the fact that we make a reasonable effort to keep the repodata >> signatures up to date, but every signature we make is done by hand. We put >> our focus on delivering the bits, and delays on a repodata signature or two >> have been known to happen (I think I'm personally on top of the leaderboard >> for pushing repos before signatures by mistake, so apologies here inline for >> that). > > Yeah, when we use this feature for publishing on download.ceph.com, > we've found two problems: > >> There's also the fact that we make a reasonable effort to keep the repodata >> signatures up to date, but every signature we make is done by hand. We put >> our focus on delivering the bits, and delays on a repodata signature or two >> have been known to happen (I think I'm personally on top of the leaderboard >> for pushing repos before signatures by mistake, so apologies here inline for >> that). > > Yeah, when we use this feature for download.ceph.com, we've found two problems: > > 1) In a perfect world, we would always publish the correct repomd.xml and > corresponding .asc file at the exact same time. In reality, this is > difficult to perfectly accomplish this 100% of the time. The goal of > "keeping the GPG material and signing process secure" is at odds with > "overall ease of use". > > 2) When it comes to volunteer-operated mirrors, all bets are off regarding > consistent updates. Mirrors update files at different times. If a CentOS > mirror syncs an updated repomd.xml but not the corresponding .asc file, > users hit problems. > > As far as ease-of-use goes, Fedora and Red Hat use the Robosignatory > project to make signing a bit more repeatable and automated, however > this issue for signing repomd.xml has been open for a long time: > https://pagure.io/robosignatory/issue/14 > > As far as the overall feature goes as implemented in DNF and Yum, > https://pagure.io/releng/issue/133 has some interesting reading on > this subject. Quoting from Colin Walters' comment there: > >> having both repomd.xml and repomd.xml.asc means two files, which introduces >> another race. Debian went through the same issue and recently changed to >> doing signatures inline: >> http://www.chiark.greenend.org.uk/~cjwatson/blog/no-more-hash-sum-mismatch-errors.html > > Colin's talking about the fact that modern versions of Apt load an > "InRelease" file that contains both the metadata and the inline GPG > signature, reducing the room for errors. > > I'd rather see some kind of inline signature support in DNF (and > MirrorManager) than see a lot of "howto" blogs talking about ignoring > CentOS GPG errors because the current implementation is racy and > confusing. > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel >