On Tue, Sep 8, 2020 at 7:56 PM Brian Stinson brian@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-e...
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.