Description of problem: Since debuginfod is up and working, would it make sense for epel-release to drop some sort of `fedora-epel.urls` or something in /etc/debuginfod/ so these artifacts can be fetched automatically? Version-Release number of selected component (if applicable):epel-10 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Probably also need to drop the IMA key in /etc/keys/ima in DER format too....
Adding fche here for comment on the debuginfod idea. On the IMA thing... I am not sure how useful it would be. We do not have the epel key trusted/setup in the RHEL kernel, and I doubt that that would be something they would want to do. I suppose it could be helpful for debuginfod verification...
The fedora debuginfod servers could certainly start indexing epel rpms (adjusting the -I regexp to include the .el* file name glob, not just .fc*), and if so, absolutely, including their URL in a new .url file in centos-release would make sense. Ditto re. /etc/keys/ima: the debuginfod clients can verify file integrity apart from any kernel-side enforcement support presence.
We're using ~33% of VM storage at the moment. Does someone have a ready estimate of how much EPEL RPM content exists (let's say .el9 upward?), in comparison to Fedora (we index .fc35 onward)?