Bug 1851242 - Metadata not signed / Repository security and integrity / Enable/provide repo_gpgcheck=1 functionality
Summary: Metadata not signed / Repository security and integrity / Enable/provide repo...
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: epel-release
Version: epel8
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Michael Stahnke
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-06-25 21:36 UTC by Leon Fauster
Modified: 2020-06-29 11:27 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-06-26 14:56:18 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Leon Fauster 2020-06-25 21:36:52 UTC
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

Comment 1 Kevin Fenzi 2020-06-26 00:11:25 UTC
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.

Comment 2 Leon Fauster 2020-06-26 14:31:11 UTC
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!

Comment 3 Stephen John Smoogen 2020-06-26 14:56:18 UTC
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.

Comment 4 Kevin Fenzi 2020-06-27 17:43:53 UTC
(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.

Comment 5 Leon Fauster 2020-06-29 11:18:54 UTC
(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.

Comment 6 Leon Fauster 2020-06-29 11:27:39 UTC
(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 ...


Note You need to log in before you can comment on or make changes to this bug.