Please consider signing the metadata of epel(8) repositories. Albeit it includes more then just the adaption of the release package. I hope that the process is adaptable. It would increase the integrity and security of the repo consumption ... Description of problem: repository's metadata not signed Version-Release number of selected component (if applicable): $ rpm -q epel-release epel-release-8-8.el8.noarch How reproducible: Look for repomd.xml.asc in repodata/ directory. Actual results: NULL Expected results: 1. Adapted repo creation (signing included) 2. Option repo_gpgcheck=1 for repo files /etc/yum.repos.d/epel-modular.repo /etc/yum.repos.d/epel-playground.repo /etc/yum.repos.d/epel-testing-modular.repo /etc/yum.repos.d/epel-testing.repo /etc/yum.repos.d/epel.repo
So, if you are using the default epel configuration (which uses metalinks) this provides no additional security and just more hassle. With metalinks: * you contact mirrors.fedoraproject.org via https and get the metalink * your local yum/dnf parses this and then uses it to contact mirrors. * The metalink has checksums of the current repomd.xml and the last 2 valid previous ones. * your local yum/dnf checks mirrors and checksums and errors out on any tampering. Since all the checksums are in repomd.xml and you get that via a https connection, any repo tampering or downgrading or the like will fail. I'd be happy to hear of a case this doesn't protect against, but as far as I know it handles all of them. Additionally, signed repos have some bad UI issues... at least with dnf. Feel free to re-open if there's something further we need to consider.
Thanks for your answer. As depicted above the "only" security layer is the "TLS+mirrors.fedoraproject.org"-layer. My suggestion was an additional layer by signing ... BTW: If someone uses a hardcoded region mirror (common scenario), then the above layer to protect the checksums are gone and not all mirrors use https. Just an example for non https mirror: http://mirror.netcologne.de/fedora/linux/updates/32/Everything/x86_64/repodata/repomd.xml There are more ... curl -s "https://mirrors.fedoraproject.org/metalink?repo=epel-8&arch=x86_64" |grep "http://" Some security profiles enable a global repo_gpgcheck option (RHEL). So it would be nice to have it at least for EPEL. Maybe this can be seen as test balloon for Fedora repos. Thanks!
This isn't a "bug" for package maintainers. They have no control over how EPEL is built or manufacturered and so putting in a ticket here is like asking the trash pickup person about road repairs because they both work for the city. What you are asking is not a "oh just flip this flag" and it will work. It would require a lot of changes in a lot of infrastructure throughout Fedora which is interconnected and can't just be done as a "test" for one "product". If you want to pursue this, please follow the right procedure for the resources needed to do it to be assigned. Put in a ticket with the Fedora Engineer Steering Committee or Fedora Council that this is needed as a focus and why. While Fedora Infrastructure would be the ones who put it into place, it will affect all Fedora releases so it needs to be coordinated, resourced, and driven like any other major project which affects multiple releases, users and tools.
(In reply to Leon Fauster from comment #2) > Thanks for your answer. As depicted above the "only" security layer is the > "TLS+mirrors.fedoraproject.org"-layer. Well, and all the packages being signed. > My suggestion was an additional layer by signing ... > > BTW: If someone uses a hardcoded region mirror (common scenario), then the > above layer to > protect the checksums are gone and not all mirrors use https. yes, you must trust a mirror if you bypass the metalink and go to it directly. > Just an example for non https mirror: > > http://mirror.netcologne.de/fedora/linux/updates/32/Everything/x86_64/ > repodata/repomd.xml > > There are more ... > > curl -s "https://mirrors.fedoraproject.org/metalink?repo=epel-8&arch=x86_64" > |grep "http://" > > > Some security profiles enable a global repo_gpgcheck option (RHEL). So it > would be nice to > have it at least for EPEL. Maybe this can be seen as test balloon for Fedora > repos. Thanks! As mentioned there's also ui issues with this. We had a repo that had signed metadata in fedora, and it caused all kinds of problems because the gpg keys have to be imported by dnf (it can't use the existing rpm ones) and that broke non interactive uses, caused confusion for users and didn't really add any extra security.
(In reply to Stephen John Smoogen from comment #3) > This isn't a "bug" for package maintainers. They have no control over how > EPEL is built or manufacturered and so putting in a ticket here is like > asking the trash pickup person about road repairs because they both work for > the city. What you are asking is not a "oh just flip this flag" and it will > work. It would require a lot of changes in a lot of infrastructure > throughout Fedora which is interconnected and can't just be done as a "test" > for one "product". > > If you want to pursue this, please follow the right procedure for the > resources needed to do it to be assigned. Put in a ticket with the Fedora > Engineer Steering Committee or Fedora Council that this is needed as a focus > and why. While Fedora Infrastructure would be the ones who put it into > place, it will affect all Fedora releases so it needs to be coordinated, > resourced, and driven like any other major project which affects multiple > releases, users and tools. My intention was not to step on the feed of some one. As stated in the bug description; I was aware of the impact of such change albeit not aware of depicted process as mentioned by you.
(In reply to Kevin Fenzi from comment #4) > (In reply to Leon Fauster from comment #2) > > Thanks for your answer. As depicted above the "only" security layer is the > > "TLS+mirrors.fedoraproject.org"-layer. > > Well, and all the packages being signed. This fact was reflected by the quotes of "only" above. As of course the package are signed. While on this I wonder if anaconda installations do really check the integrity of rpms? Do the rpm db has the key already imported, I do not see it. Anyway, this is maybe a different question. <snip> > > > > Some security profiles enable a global repo_gpgcheck option (RHEL). So it > > would be nice to > > have it at least for EPEL. Maybe this can be seen as test balloon for Fedora > > repos. Thanks! > > As mentioned there's also ui issues with this. We had a repo that had signed > metadata in fedora, and it caused all kinds of problems because the gpg keys > have to be imported by dnf (it can't use the existing rpm ones) and that > broke non interactive uses, caused confusion for users and didn't really add > any extra security. Thanks for the input, Kevin. Have a nice week ...