Red Hat Bugzilla – Full Text Bug Listing
|Summary:||automatically import default GPG keys|
|Product:||[Fedora] Fedora||Reporter:||Charles R. Anderson <cra>|
|Component:||anaconda||Assignee:||Anaconda Maintenance Team <anaconda-maint-list>|
|Status:||NEW ---||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||anaconda-maint-list, awilliam, bnocera, collura, davidz, daw-redhatbugzilla, dennis, fweimer, g.kaviyarasu, hughsient, jdisnard, jonathan, jsmith.fedora, kparal, mads, nphilipp, redhat-bugzilla, rhughes, robatino, rstrode, rvitale, smparrish, tburke, tflink, vanmeeuwen+fedora, walters|
|Fixed In Version:||Doc Type:||Enhancement|
|Doc Text:||Story Points:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
|Bug Blocks:||998, 438944, 713566, 752653|
Description Charles R. Anderson 2011-10-24 01:49:48 EDT
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): gnome-settings-daemon-3.2.1-1.fc16.x86_64 Fedora 16 Final TC2 x86_64, installed from DVD NFSISO How reproducible: always Steps to Reproduce: 1. install Fedora 16 Final TC2 2. log in 3. wait a while Actual results: A "random" dialog pops up asking for your password. Expected results: No unexpected, unsolicited password authentication dialogs. Additional info:
Comment 1 Charles R. Anderson 2011-10-24 02:00:57 EDT
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?
Comment 2 Adam Williamson 2011-10-24 12:32:05 EDT
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 https://fedoraproject.org/wiki/BugZappers
Comment 3 Adam Williamson 2011-10-24 16:42:00 EDT
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!
Comment 4 Adam Williamson 2011-10-24 17:10:45 EDT
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.
Comment 5 Adam Williamson 2011-10-24 17:11:25 EDT
(I assume it asks for the user's key if you added the user to the admin group - I didn't).
Comment 6 Adam Williamson 2011-10-24 20:02:33 EDT
Adding some CCs for blocker votes. please vote! since we shipped F15 with this i'm probably -1 blocker +1 nth...
Comment 7 Kamil Páral 2011-10-25 07:32:09 EDT
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
Comment 8 Jared Smith 2011-10-25 15:54:00 EDT
-1 for blocker. +1 for NTH
Comment 9 Dennis Gilmore 2011-10-25 15:54:37 EDT
im +1 to NTH on this
Comment 10 Tim Flink 2011-10-25 16:13:51 EDT
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
Comment 11 Nils Philippsen 2011-10-26 04:05:13 EDT
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 > 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? 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.
Comment 12 Richard Hughes 2011-10-28 05:37:46 EDT
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.
Comment 13 Kamil Páral 2011-10-28 07:42:52 EDT
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.
Comment 14 Mads Kiilerich 2011-10-28 09:48:33 EDT
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.)
Comment 15 Brian Lane 2011-10-28 13:12:36 EDT
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
Comment 16 Adam Williamson 2012-01-23 15:46:07 EST
Bumping to Rawhide. If we're going to fix this for F17 we should probably do it soon. Dennis? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 17 Tim Flink 2012-05-17 15:08:13 EDT
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
Comment 18 Colin Walters 2012-05-24 15:48:22 EDT
Comment 19 Adam Williamson 2013-01-22 21:03:04 EST
This kinda seems like it ought to be getting fixed. Any movement here?
Comment 20 Richard Hughes 2013-01-23 07:34:06 EST
(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.
Comment 21 Adam Williamson 2013-01-24 19:18:38 EST
I'm unsetting NEEDINFO, as comment #15 addressed the needinfo request.
Comment 22 Jens Petersen 2013-03-15 04:04:43 EDT
*** Bug 253897 has been marked as a duplicate of this bug. ***
Comment 23 Fedora End Of Life 2013-04-03 10:31:34 EDT
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: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 24 Dennis Gilmore 2013-11-13 23:14:19 EST
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.
Comment 25 Dennis Gilmore 2013-11-13 23:17:57 EST
reassigning to anaconda as it knows we are doing an install
Comment 26 David Shea 2014-02-21 13:56:53 EST
(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 > chroot. 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.
Comment 27 Fedora End Of Life 2015-01-09 11:50:12 EST
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.
Comment 28 Kamil Páral 2015-01-13 07:16:42 EST
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.
Comment 29 Dennis Gilmore 2015-01-13 13:28:59 EST
This still belongs in anaconda. not in fedora-release
Comment 30 Dennis Gilmore 2015-01-13 14:10:50 EST
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.
Comment 31 Kamil Páral 2015-01-14 10:03:44 EST
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.
Comment 32 David Shea 2015-01-16 14:34:49 EST
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.
Comment 33 Dennis Gilmore 2015-01-17 11:15:21 EST
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