Bug 253897

Summary: Import/trust Fedora GPG keys by default
Product: [Fedora] Fedora Reporter: David Zeuthen <davidz>
Component: fedora-releaseAssignee: Peter Jones <pjones>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: bnocera, djuran, herrold, kms, mattdm, mclasen, mjc, notting, pjones, robatino, walters
Target Milestone: ---Keywords: FutureFeature, Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-03-15 04:04:43 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 998, 438944    

Description David Zeuthen 2007-08-22 15:08:44 EDT
A fresh install of Fedora should have the GPG keys installed by default to avoid
asking the user "Import GPG key for Fedora <hexnumber>". The rationale is here
(see the replies too)

https://www.redhat.com/archives/fedora-desktop-list/2007-August/msg00285.html
Comment 1 Mark J. Cox (Product Security) 2007-08-23 08:17:12 EDT
It seems reasonable to me that we should import the key RPM-GPG-KEY-fedora
(4f2a6fd2) by default.  The user has trusted the media they used to install
Fedora, and therefore should implicitly trust anything else signed with the same
key as we use for those base packages.  We're not exposing the user to more
risk; either they checked the media/image before installation (in which case we
know the key we're installing by default is good), or they didn't (in which case
an attacker could have trojaned anything without having to bother messing with 
malicious keys).  

I don't believe we should import any of the other keys (Red Hat key, test keys,
other popular repo keys).  (Except we might want the -test builds to just
install the test key for example)

Perhaps it's a good opportunity for us to also make the installation
instructions include more information about verification -- we give the SHA1
sums on the page but not a signed version, or instructions how to verify signed
SHA1 sums.
Comment 2 Jesse Keating 2007-09-18 17:23:44 EDT
The lingering questions become:

When is this done (pre-install, post-install, post-boot)
How is this done (obviously rpm --import is used, but what calls it)
How do we figure out which keys to import?
Comment 3 R P Herrold 2007-09-18 17:39:59 EDT
Just so it is said ...  The practice of trusting a yum port 80 network retrieval
and injection of non-counter-signed keys, without assent, confirmation,
verification, or other human mediation, leaves a whole class of unknowable users
who do not and cannot check 'in time' vulnerable to:
  - MitM substitutions, as from a compromised cache or proxy, and 
  - outright compromised or malicious mirrors, and 
  - incremental attacks once a false signing key part is injected.

-- Russ Herrold
Comment 4 David Zeuthen 2007-09-19 10:03:05 EDT
(In reply to comment #3)
> Just so it is said ...  The practice of trusting a yum port 80 network retrieval
> and injection of non-counter-signed keys, without assent, confirmation,
> verification, or other human mediation, leaves a whole class of unknowable users
> who do not and cannot check 'in time' vulnerable to:
>   - MitM substitutions, as from a compromised cache or proxy, and 
>   - outright compromised or malicious mirrors, and 
>   - incremental attacks once a false signing key part is injected.

The user is already vulnerable to attacks of this class if he didn't verify the
authenticity of the installation media he used to install the OS (check SHA1 of
media). Please read the link in the original bug report and comment 1 again. Thanks.
Comment 5 Jesse Keating 2007-10-03 10:06:18 EDT
Moving to F9 Target.  Still need to come up with a clever way of importing the
key, that is generic enough to work for downstream distros that may use a
different key.
Comment 6 Jesse Keating 2007-11-15 12:14:59 EST
Perhaps a firstboot module that looks at the yum repos configured enabled by
default and finds the keys referenced to import them at that time...
Comment 7 David Zeuthen 2007-11-15 12:35:11 EST
(In reply to comment #6)
> Perhaps a firstboot module that looks at the yum repos configured enabled by
> default and finds the keys referenced to import them at that time...

I really wonder if this needs to be this complicated. I mean, why don't you just
check with the RPM developers and ask them if it's OK to import the keys using
rpm(8) in %post? I'd be surprised if it's a problem... if it's a problem, then
maybe rpm(8) can be fixed....
Comment 8 Jesse Keating 2007-11-15 12:53:10 EST
The keys don't exist in rpm, and how is rpm to know /which/ keys to import? 
Keys are something that are added on via each distributor of the packages.  Be
it Fedora, or RHEL, or somebody else entirely.
Comment 9 David Zeuthen 2007-11-15 13:06:28 EST
(In reply to comment #8)
> The keys don't exist in rpm, and how is rpm to know /which/ keys to import? 
> Keys are something that are added on via each distributor of the packages.  Be
> it Fedora, or RHEL, or somebody else entirely.

I'm not sure what you're saying here. The keys exist in fedora-release

$ rpm -ql fedora-release |grep KEY
/etc/pki/rpm-gpg/RPM-GPG-KEY
/etc/pki/rpm-gpg/RPM-GPG-KEY-beta
/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora
/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-rawhide
/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-test
/etc/pki/rpm-gpg/RPM-GPG-KEY-rawhide

I'm asking you to run 'rpm --import ...' in %post. Hope this makes it clear.
Comment 10 Jesse Keating 2007-11-15 13:14:09 EST
I see, I thought you were asking to do it from the rpm rpm.  Much confusion.

Generally I'm /really/ not a fan of seeing rpms call rpm from within them, this
has led to lots of problems in the past, particularly with creating a chroot
install when the host rpm is different from the inside chroot rpm.  I'd rather
see this done as a post-install thing.
Comment 11 David Zeuthen 2007-11-15 13:21:27 EST
(In reply to comment #10)
> I see, I thought you were asking to do it from the rpm rpm.  Much confusion.
> 
> Generally I'm /really/ not a fan of seeing rpms call rpm from within them, this
> has led to lots of problems in the past, particularly with creating a chroot
> install when the host rpm is different from the inside chroot rpm.  I'd rather
> see this done as a post-install thing.

My point is: there's certainly a lot less confusion if this happens as early in
the stack as possible. Think of live cd's and other ways of people consuming
Fedora. For example running this in firstboot is not going to work for live cd.
Better keep things as simple as possible, yes?

I asked you to check with the rpm developers whether rpm can handle this. I
think they are in the best position to tell whether it leads to lots of
problems. Can you do this please? Thanks.
Comment 12 Jesse Keating 2007-11-15 13:30:04 EST
It's not about "confusion".  We're going to hide it no matter what so that the
user just doesn't notice that it got imported.

I'll ask Panu about this, just to satisfy you.
Comment 13 Bill Nottingham 2007-11-15 13:32:26 EST
Honestly, I think it's simpler from anaconda.

anaconda:
1) knows what repos it's installing from
2) therefore, we don't need to code anything fedora specific
3) can do it outside the RPM transaction (after initializing the DB)
4) hey, we can then check signatures in anaconda!
Comment 14 Bill Nottingham 2007-11-15 13:34:51 EST
5) works for liveCD installs too that aren't done from a RPM context
Comment 15 David Zeuthen 2007-11-15 13:57:19 EST
Possible technical short-comings of rpm aside, I'm unable to understand why it's
"easier" to do from Anaconda. You'd need to add code for this. Not everyone uses
anaconda. Won't work while on the live cd itself before it's installed. See,
these are the funny heisenbugs you get when you violate layering in software.

Look at it like this: If our package manager can't import GPG keys while a
transaction is ongoing then it simply needs to be fixed. We have way to many
examples of where we work around bugs in underlying software and history have
shown this is not a sustainable solution.

Bill, can you honestly say you disagree with this?
Comment 16 David Zeuthen 2007-11-15 13:59:03 EST
Also, it's not unlike 3rd party repos wants to do this while installing their
-release package. Coding this into anaconda is a big mistake I think.
Comment 17 David Zeuthen 2007-11-15 14:00:06 EST
s/unlike/unlikely/ in comment 16. Sorry, I really wish there was an "Edit"
button in Bugzilla sometimes.
Comment 18 Bill Nottingham 2007-11-15 14:14:38 EST
I guess my concern is that whether or not to trust a key XYZ is either:
a) a distro level decision (packages on media)
b) a user/admin level decision (package downloaded from internet)

and doing 'rpm --import' in %post takes that decision away from either of those
parties. But then again, I suppose that 'importing the key' should not
necessarily mean 'trusting the key'.
Comment 19 David Zeuthen 2007-11-15 14:24:00 EST
(In reply to comment #18)
> I guess my concern is that whether or not to trust a key XYZ is either:
> a) a distro level decision (packages on media)
> b) a user/admin level decision (package downloaded from internet)
> 
> and doing 'rpm --import' in %post takes that decision away from either of those
> parties. But then again, I suppose that 'importing the key' should not
> necessarily mean 'trusting the key'.

Uhm. See the start of this bug specifically comment 1. We're not discussing *if*
we should do this; that's already been decided. We're discussing *how* to do
this. Thanks.
Comment 20 Bill Nottingham 2007-11-15 14:31:25 EST
Right, if we're just doing a one-off for the base OS install, then I don't
understand the complaints about doing it in anaconda.
Comment 21 David Zeuthen 2007-11-15 14:38:29 EST
(In reply to comment #20)
> Right, if we're just doing a one-off for the base OS install, then I don't
> understand the complaints about doing it in anaconda.

Easy: livecd-creator don't use anaconda. Sketchy installs doing by the user
manually don't use anaconda.

I'm baffled why you can't see that having anaconda as the bag-of-hacks to do an
install is just not maintainable. Doing so will only hinder progress and
innovation. Is that really so hard to understand?
Comment 22 Bill Nottingham 2007-11-15 15:04:00 EST
Right now, our tools have the heuristic that 'imported key == trusted key'.

Because of this, auto-importing any key in the package is only a good idea if we
trust that package. We can make that decision for fedora-release (as in comment
#1), but not for anyone else.

Hence, given our current software:
- rpm --import in %post is good enough for fedora-release
- rpm --import is a BAD idea for third party repos

To fix this right, we need to fix our infrastructure, and I suspect the final
outcome of that is going to be something other than rpm --import in %post. 

In the meantime, doing *both* the hack in fedora-release, and key importing in
anaconda:

- allows livecd creation and all installs to DTRT
- allows user respun CDs with additional repos to correctly trust their
additional repos. i.e., someone can do a respin w/livna and get rid of that
dialog for their users for livna as well, without affecting users who manually
choose livna
Comment 23 David Zeuthen 2007-11-15 15:20:51 EST
Hi,

Good to see we're getting some traction on this bug.

(In reply to comment #22)
> Hence, given our current software:
> - rpm --import is a BAD idea for third party repos

I actually disagree; suppose I'm maintaining davidz-release.rpm for the davidz
repo. When the user installs davidz-release.rpm they (most likely) don't have my
GPG key. Thus, when installing davidz-release.rpm the user needs to make a
decision on whether to trust (= import) my key [1].

It would be a grave disservice to bother the users later on with "Import davidz
GPG key?" much like the problem this bug is about for Fedora. Installing the key
in the davidz-release.rpm %post takes care of this.

Perhaps you can explain why you disagree? Thanks.

(Notably, if we agree to encourage 3rd party repos to do this you won't need
special casing in anaconda at all.)

[1]: ok, so rpm(8) won't check GPG keys, only yum(1) does. That's IMNSHO opinion
a defect with rpm with possible security implications
Comment 24 Bill Nottingham 2007-11-15 15:29:57 EST
(In reply to comment #23)
> I actually disagree; suppose I'm maintaining davidz-release.rpm for the davidz
> repo. When the user installs davidz-release.rpm they (most likely) don't have my
> GPG key. Thus, when installing davidz-release.rpm the user needs to make a
> decision on whether to trust (= import) my key [1].

Because, with our current infrastructure, there's no way to inform
the user that 'by installing davidz-release, you are implicitly trusting any
package from davidz'. Heck, davidz-release could install and import keys from
SuSE and the user wouldn't be wiser. (And yes, you can do rm -rf in %post too.)

In many ways this is an issue with our current security/trust implementation,
but until that is fixed, I don't feel comfortable with that solution.
Comment 25 David Zeuthen 2007-11-15 16:52:04 EST
(In reply to comment #24)
> Because, with our current infrastructure, there's no way to inform
> the user that 'by installing davidz-release, you are implicitly trusting any
> package from davidz'. Heck, davidz-release could install and import keys from
> SuSE and the user wouldn't be wiser. (And yes, you can do rm -rf in %post too.)
> 
> In many ways this is an issue with our current security/trust implementation,
> but until that is fixed, I don't feel comfortable with that solution.

Not sure it's an issue and not sure what needs fixing. The Description: tag is a
fine place to put this information IMO. I'd also argue that it's insanity to say
"I want repo XYZ configured (so I install XYZ-release.rpm to get the yum files)
but I don't trust the vendor". Do you disagree?

Please try and look at the user experience here instead. Surely, if someone
installs davidz-release it's because the want to install packages from the repo
(duh!). So sooner or later they're going to get the "Do you want to import GPG
key for david's repo?" question. My proposal is to move this dialog to when you
actually install the -release rpm. Do you agree this is the only difference?

Apart from the better user interaction of getting the question at -release.rpm
install time, there's another interesting use case that comes into play when you
make package management more fine grained as the PackageKit team is currently
doing. Suppose that the administrator have granted the user bob the
authorization to install signed software from the configured repositories.
Suppose also that user bob lacks the authorization to install unsigned packages.
Do you agree this is an useful feature in enterprise deployments?

With what you're suggesting the administrator that deployed bob's machine would
have to take an extra manual step when selecting davidz-release.rpm; he would
manually have to run rpm --import. With what I'm suggesting this isn't the case
and things just work. Can you now see why this is important?
Comment 26 Bill Nottingham 2007-11-15 21:38:22 EST
(In reply to comment #25)
> Not sure it's an issue and not sure what needs fixing. The Description: tag is a
> fine place to put this information IMO. I'd also argue that it's insanity to say
> "I want repo XYZ configured (so I install XYZ-release.rpm to get the yum files)
> but I don't trust the vendor". Do you disagree?

The problem is, you're making the post do automatic installation of trust,
relying on metadata such as a description or how the package is named.

If *any other package* besides a blah-repo package would do these things (which
they certainly can), it would be labeled a trojan or worse.

Frankly, it makes me think that repo configuration/key handling is best handled
through a non-package mechanism, but that's a whole other can of worms.

> key for david's repo?" question. My proposal is to move this dialog to when you
> actually install the -release rpm. Do you agree this is the only difference?

Dialog? Sure (which you can't do in scriptlets). But I'm not sure %post hackery
is the best here; really, you almost want it before installation to verify and
trust the -release package itself.
Comment 27 David Zeuthen 2007-11-16 13:12:03 EST
(In reply to comment #26)
> (In reply to comment #25)
> > Not sure it's an issue and not sure what needs fixing. The Description: tag is a
> > fine place to put this information IMO. I'd also argue that it's insanity to say
> > "I want repo XYZ configured (so I install XYZ-release.rpm to get the yum files)
> > but I don't trust the vendor". Do you disagree?
> 
> The problem is, you're making the post do automatic installation of trust,
> relying on metadata such as a description or how the package is named.
> 
> If *any other package* besides a blah-repo package would do these things (which
> they certainly can), it would be labeled a trojan or worse.

I think that's overstating it a bit...

> Frankly, it makes me think that repo configuration/key handling is best handled
> through a non-package mechanism, but that's a whole other can of worms.

It indeed is.

> Dialog? Sure (which you can't do in scriptlets). But I'm not sure %post hackery
> is the best here; really, you almost want it before installation to verify and
> trust the -release package itself.

The program for verifying the installation is normally packaged in the same .iso
as the rpm itself. So it's pretty pointless as someone can just tamper with that
program. What we need to do is to educate the users to check the SHA1 sum of the
install media. We can build technology to make more users to do that but now I'm
also drifting off-topic.

Anyway, to sum up, we agree to run 'rpm --import' on the keys mentioned in
comment 1 during %post of fedora-release?

Thanks,
David
Comment 28 Bill Nottingham 2007-11-16 13:22:22 EST
I don't think that's necessary. In fact, if you use gpgcheck=1 when using yum to
create the live image/install, yum will install the keys for you. With
assumeyes=1, it won't even ask.
Comment 29 Bill Nottingham 2007-11-16 13:33:39 EST
To clarify, as of yesterday, I didn't know that that worked...
Comment 30 David Zeuthen 2008-04-04 01:01:50 EDT
(In reply to comment #28)
> I don't think that's necessary. In fact, if you use gpgcheck=1 when using yum to
> create the live image/install, yum will install the keys for you. With
> assumeyes=1, it won't even ask.

Jeremy, Jesse: are we doing this for current live images?
Comment 31 Jesse Keating 2008-04-04 12:06:07 EDT
I don't think so, and I've lost a lot of context on this issue too :/  Need to
review for F10
Comment 32 Bug Zapper 2008-05-13 23:08:37 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 33 Bug Zapper 2009-06-09 18:46:53 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 34 Bug Zapper 2010-03-15 07:54:45 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 35 Fedora Admin XMLRPC Client 2010-11-24 17:44:21 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 36 Colin Walters 2011-05-24 16:58:08 EDT
From current spin-kickstarts/fedora-live-base.ks:

# work around for poor key import UI in PackageKit
rm -f /var/lib/rpm/__db*
rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora
Comment 37 Bug Zapper 2011-06-02 14:39:43 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 38 Colin Walters 2011-06-04 10:28:04 EDT
Still broken.
Comment 39 David Juran 2011-06-06 09:17:20 EDT
Clearing need-info flag based on comment #38
Comment 40 Fedora End Of Life 2012-08-07 16:16:15 EDT
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 42 Jens Petersen 2013-03-15 04:04:43 EDT
Making this a duplicate of the newer bug.

*** This bug has been marked as a duplicate of bug 748320 ***