On Fri, Jun 11, 2021 at 06:27:18AM -0400, Neal Gompa wrote: > > We do not, however, have GPG signatures on repository metadata. Which True. > means that we can't guarantee the repositories aren't tampered with. False. > This is especially problematic for people who use local mirrors or do > net installs. We could do more for local mirrors indeed. On Fri, Jun 11, 2021 at 01:48:50PM +0200, Björn Persson wrote: ...snip... > > As it is now, mirrors can't modify RPM packages without a key that the > clients have installed. Mirrors could however withhold security updates > so that clients remain vulnerable. Is that a thing that Rekor could > prevent? They cannot in the default, normal case where users use metalinks. (well, they could for 3 days or less, but then they cannot) > I believe Yum has a feature to verify signed repository metadata. I > don't know why it's not used. If that verification would be turned on, > are there any attacks that would still be possible then, that Rekor > could prevent? You mean dnf? :) It does, but it has... a number of issues. ...snip... On Fri, Jun 11, 2021 at 07:55:49AM -0400, Neal Gompa wrote: > > Fedora Infrastructure has stonewalled on signing our RPM repositories > for almost a decade. Reasons have ranged from "I don't like it" to > "It's useless because metalinks" to "RPM repository format should be > modified first". However, openSUSE signs their repositories and it > works fine there. I would like to strongly object to this being called 'stonewalling' You make it sound like there's a simple config switch we just need to turn on that we refuse to do. Thats completely 100% not the case. The reasons this is not enabled have in fact changed over the years, not because we 'made up a new reason', but because progress has been made and you can't instantly enable something before everything to enable that is in place. First the issue was that we were manually signing things. This meant in order to sign repodata we would need to have a releng person sitting there and signing away at the _end_ of pushes. Then, that was fixed by sigul, but then there were issues with other tools in the chain, like bodhi needs to be able to inject security update info into the repodata at the end of a compose, so you have to make sure it's signed after that, etc, etc. Those issues have all slowly moved forward over the years. Then, we actually did enable signed repodata a number of years ago for the cisco h264 repo. This exposed all kinds of dnf issues with signed repodata: The keystore it has is seperate from the rpmdb one, so it has to import things and get a 'ok' from the user again, it doesn't error correctly on non interactive cases, and in fact this blocked a fedora release a while back. So, we changed it to not use signed repodata. IN summary: I'm ok with enabling signed repodata when it is possible to do so and don't cause pain and suffering for our users. This has in fact always been my answer to this. It's not a priority for me personally because metalinks handle almost all the cases. The only things that would be improved by signed repodata are local mirrors that sync without checking for the mirror they sync from being up to date in mirrormanager. If you know of more cases, please share them. kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
