Red Hat Bugzilla – Bug 748320
automatically import default GPG keys
Last modified: 2015-01-17 11:15:21 EST
Description of problem:
Shortly after logging in to Gnome on Fedora 16 Final TC2, an unsolicited PolicyKit dialog box pops up requesting the user's password in order to authorize the installation of RPM package keys. This is caused by the default software updates setting to automatically install security updates. This is unexpected, can be scary to users who don't know what is going on (I cancelled it the first time until I realized what it had been trying to do), and it sets a bad precedent/creates a bad habit for users to type their password into unsolicited dialog boxes that have no relation to what tasks they are performing at the time.
Version-Release number of selected component (if applicable):
Fedora 16 Final TC2 x86_64, installed from DVD NFSISO
Steps to Reproduce:
1. install Fedora 16 Final TC2
2. log in
3. wait a while
A "random" dialog pops up asking for your password.
No unexpected, unsolicited password authentication dialogs.
Suggestion: Make some clearer indication of what task is being performed that needs the user's credentials, like "In order to install software updates, I need you to verify that this software is from a valid source. Please check that the key fingerprint below is published by your software vendor as a valid key, and if so enter your password to indicate that you trust this source."
I realize this is a hard problem to solve, but in its current state, it is unusable by anyone, including people who do know what a GPG key is and how to verify it.
Or, alternatively, come up with a better automatic "chain of trust" mechanism that can perhaps be derived from the initial installation media's GPG signed checksum.
Or, is this just a matter of a transient problem due to being a Test Compose/not a final release. Will the final Fedora release already have these GPG keys imported during the initial installation/upgrade?
for me this hits the spirit if not the letter of "In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login (see Blocker_Bug_FAQ) " - we shouldn't be popping up confusing dialogs seconds after you boot up.
This one's been around for a while but I think the dialog used to have more context, and changes in GNOME 3's design changed that.
Fedora Bugzappers volunteer triage team
Nils, Richard is away this week, so can you please look at this? It's a blocker so needs fixing ASAP, we have the RC compose scheduled tomorrow. thanks!
so...this isn't actually new, now I test it: F15 behaves much the same way.
After installing F15 clean and letting it sit for a bit you get a dialog with the window title 'Authenticate', bold message "Authentication is required to consider a key used for signing packages as trusted", non-bold text "An application is attempting to perform an action that requires privileges. Authentication as the super user is required to perform this action.', dialog 'Password for root:', a Details drop-down which shows 'Action: org.freedesktop.packagekit.system-trust-signing-key' and 'Vednor: The PackageKit Project' if expanded, and Cancel / Authenticate buttons. That seems pretty similar to F16 behaviour, actually.
So, that's input for the blocker voting.
(I assume it asks for the user's key if you added the user to the admin group - I didn't).
Adding some CCs for blocker votes. please vote!
since we shipped F15 with this i'm probably -1 blocker +1 nth...
I agree this is a very poor user experience. Unfortunately we have no UX team and our release criteria focus on more technical things. (I don't agree with comment#2 that it fails that particular criterion). I don't have an objective reason to vote for it as a blocker.
As to my subjective reasons, I don't see it as severe to hold the whole release on it. But I'd definitely like to see it fixed.
-1 blocker, +1 nth
-1 for blocker. +1 for NTH
im +1 to NTH on this
Since this did happen on F15, I think that I'm in agreement with the previous votes:
-1 blocker, +1 NTH
Since we're now -4 blocker, +5 NTH; rejecting as blocker and accepting as NTH
Changing component to PackageKit.
Note that while the message explaining the policy kit action org.freedesktop.packagekit.system-trust-signing-key could be enhanced, I'm wary to do this at this late point (at least without consulting Richard) because it would break translations.
Anaconda maintainers: I'd like your input on this:
(In reply to comment #1)
> Or, alternatively, come up with a better automatic "chain of trust" mechanism
> that can perhaps be derived from the initial installation media's GPG signed
> Or, is this just a matter of a transient problem due to being a Test
> Compose/not a final release. Will the final Fedora release already have these
> GPG keys imported during the initial installation/upgrade?
Namely: would it be possible to automatically import the RPM GPG keys of the default repositories (fedora, updates) during installation? Because I think the user really shouldn't see such an unsolicited dialog at all (or in order to update a freshly installed system), regardless of whether it's well explained or not.
Urgh, anaconda used to import the update keys at install time. If this is the case, and not some TC vs GA thing, I think it's insane Fedora does not trust it's own GPG keys by default.
To be blunt, if the media is compromised, then unsigned updates are the last of your worries. The only way you can guarantee the authenticity of the media is to post it's sha1sum in a well known place that we test the image against - which is basically what we do now.
Making the user agree to install the fingerprint 1d2e3a4d adds nothing to security - that's why Ubuntu and other distributions don't make you do this. The problem is further exacerbated by multiple keys being used.
The solution is easy -- something like firstboot or anaconda just needs to do:
rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora*
I was pretty sure F15 did this, as there was uproar in the F12-era when anaconda stopped doing this. It would be very embarrassing if we shipped a release that didn't trust it's own signing keys.
I completely agree with Richard, the default keys should be imported by default. Fedora doesn't do it as far back as I remember (two years) and I never understood why. Because it seems the whole issue could go away with anaconda importing the default keys, changing component.
For the record: fedora-live-base.ks and -mini do
# work around for poor key import UI in PackageKit
rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora
directly in %post, and installations from live images will thus already have the primary key imported.
(In reply to comment #12)
> rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora*
I agree that it would make sense to trust the primary keys by default, but should secondary arch keys be trusted too?
(OT: IMHO it would be nice if packages in koji/updates-testing automatically was signed with a separate 'you can import and trust it if you want to' key. That would prove that they came from the build servers and was build from the official source, without any tampering on the mirrors or while downloading.)
fedora-release owns the keys. It should handle importing them. Anaconda should have no specific logic about which keys to import. The trust argument had been thoroughly covered in bug 998
Bumping to Rawhide. If we're going to fix this for F17 we should probably do it soon. Dennis?
Fedora Bugzappers volunteer triage team
Discussed at the 2012-05-17 Fedora 17 final go/no-go meeting. Rejected as a blocker for Fedora 17 final as it doesn't directly hit any of the Fedora 17 release criteria and we've been shipping like this for a while now. However, this would improve the user experience and a tested fix would be considered for inclusion past code freeze
See also https://bugzilla.redhat.com/show_bug.cgi?id=253897
This kinda seems like it ought to be getting fixed. Any movement here?
(In reply to comment #19)
> This kinda seems like it ought to be getting fixed. Any movement here?
FWIW, Zif imports any keys installed in /etc/pki/rpm-gpg/* automatically into the *private* keyring for the transaction. I see no benefit at all asking the user to blindly click [yes] on a dialog they don't understand for a repository that they've already explicitly installed using a high level authentication.
If you've got evil programs writing files in /etc/pki/rpm-gpg/ running as root, then you've got bigger problems than letting the user installing unknown packages.
I think yum should automatically import anything in /etc/pki/rpm-gpg/* too, without confirmation.
I'm unsetting NEEDINFO, as comment #15 addressed the needinfo request.
*** Bug 253897 has been marked as a duplicate of this bug. ***
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.
(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)
More information and reason for this action is here:
This can not be fixed in fedora-release it needs to be fixed in anaconda, as it is anaconda that knows that an install is happening. in fedora-release we have no idea if we are being installed as part of an update or a chroot creation or an install or some other process. for instance we can not be sure that we can access the rpm databases when used in a mock chroot, this is because the chroot may have been created by an rpm that is using an older db format, if we tried to access the db to import the keys in the chroot we would be unable to build anything as the build would fail while initing the chroot.
reassigning to anaconda as it knows we are doing an install
(In reply to Dennis Gilmore from comment #24)
> in fedora-release we
> have no idea if we are being installed as part of an update
If it's an upgrade then $1 in %post will be greater than 1.
> or a chroot
> creation or an install or some other process. for instance we can not be
> sure that we can access the rpm databases when used in a mock chroot, this
> is because the chroot may have been created by an rpm that is using an older
> db format, if we tried to access the db to import the keys in the chroot we
> would be unable to build anything as the build would fail while initing the
Why would the fact that this happening in a chroot make a difference? Database version problems either sounds like a problem between you and rpm or something that you should check for in %post.
This message is a notice that Fedora 19 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 19. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.
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.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 19 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, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
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.
This still affects Fedora 21 Server, or Workstation installed from the network (installation from Live is OK). Cloud not tested.
Dennis, David, please find a solution already.
This still belongs in anaconda. not in fedora-release
trying to provide some additional info on why.
anaconda is the tool that knows a system is being installed. no other tool knows you are doing a system install. additinally you are not allowed to call rpm in scriptlets. main reason being that is is known to cause many failures in the buildsystem. where the host rpm is used to build the chroot. there has been many cases over the years where the hosts rpm and chroots is incompatible. koji using mock calls the hosts rpm in different stages. If we call rpm in a scriptlet we could force a change to the rpm database that the host can not read. as a result all builds will fail.
anaconda has to be the tool that imports the gpg keys from the repos used at install time. anaconda is also the only thing that knows what repos were enabled and therefore which keys should be imported.
Just a note, today I've found out that two quite serious bugs slipped into Fedora 21 as a direct consequence of this: bug 1182090 and bug 1182156. This is a recurring topic, almost every release we fix at least two bugs in yum/packagekit/something related to unimported gpg keys. This time we failed to find it before release, because Workstation lost netinst mid-cycle and we didn't realize to test it with Server netinst, even though it's a publicly communicated way of installation, e.g. for businesses.
It would save QA and especially our users a lot of trouble if this got finally resolved. Thanks.
How are we supposed to determine what keys we're even supposed to import? Everything in /etc/pki/rpm-gpg? That seems like an awfully big hammer.
Yes, anaconda knows that it is installing, but you don't tell us a whole lot else.
I imagine you would install the keys for the repos used at install time. assuming that they have a gpg key defined. the other option would be for the repos to be enabled post install