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.

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?

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

(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.

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.

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...

(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....

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.

(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.

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.

(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.

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.

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!

5) works for liveCD installs too that aren't done from a RPM context

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?

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.

s/unlike/unlikely/ in comment 16. Sorry, I really wish there was an "Edit"
button in Bugzilla sometimes.

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'.

(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.

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.

(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?

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

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

(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.

(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?

(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.

(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

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.

To clarify, as of yesterday, I didn't know that that worked...

(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?

I don't think so, and I've lost a lot of context on this issue too :/  Need to
review for F10

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

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

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

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

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

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

Still broken.

Clearing need-info flag based on comment #38

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

Making this a duplicate of the newer bug.

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

*** Bug 1509968 has been marked as a duplicate of this bug. ***