Description of problem: RPM GPG key not imported on live images. Version-Release number of selected component (if applicable): livecd-tools-20.0-1.fc20 Steps to Reproduce: 1. Run Fedora 20 Beta TC5 live image. 2. Try to install or update any package. 3. Actual results: Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-20-i386 Importing GPG key 0x246110C1: Userid : "Fedora (20) <fedora>" Fingerprint: c7c9 a9c8 9153 f201 83ce 7cba 2eb1 61fa 2461 10c1 Package : fedora-release-20-0.7.noarch (@koji-override-0/$releasever) From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-20-i386 Is this ok [y/N]: y Expected results: RPM GPG key should be imported.
Looks like bug should be fixed in spin-kickstarts https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?id=32e066e039d130698396c2435f15db7232e47e06
Note that composes use git (currently the f20 branch) directly. So new composes should pull in the above fix (which is also in the f20 branch). I've been waiting for the size issues to be fixed before doing a new version of the packaged spin-kickstarts. There will be an update after beta is signed off on.
Commit was at 2013-10-16 but problem still present on 20-Beta-TC6 images created at 26-Oct-2013.
Problem still on 20-Beta-RC2 images.
Released F20 Beta live images also with this problem.
Fedora-Live-KDE-i686-20-TC2, rpm gpg key not imported.
The same on TC3.
Fedora-Live-KDE-i686-20-TC4.iso, same problem. Nobody working on fixing?
So, here's a snippet from a recent livecd build in koji: ... No '/dev/log' or 'logger' included for syslog logging No '/dev/log' or 'logger' included for syslog logging Opening default zone 'public' No changes to default zone needed. Note: Forwarding request to 'systemctl enable NetworkManager.service'. Note: Forwarding request to 'systemctl disable sshd.service'. rm '/etc/systemd/system/multi-user.target.wants/sshd.service' mkfs.fat 3.0.23 (2013-10-15) Loop device does not match a floppy size, using default hd params Initialized /dev/loop2 as a 20 MB HFS Plus volume The unit files have no [Install] section. They are not meant to be enabled using systemctl. Possible reasons for having this kind of units are: 1) A unit may be statically enabled by being symlinked from another unit's .wants/ or .requires/ directory. 2) A unit's purpose may be to act as a helper for some other unit which has a requirement dependency on it. 3) A unit may be started when needed via activation (socket, path, timer, D-Bus, udev, scripted systemctl call, ...). error: /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora--: import read failed(2). Packages within this LiveCD ... It's not got the releasever/buildarch set at that point (it's in the chroot I think). So, we will need to adjust this...
This small change seems to fix it here: diff --git a/fedora-live-base.ks b/fedora-live-base.ks index a87bc62..513410c 100644 --- a/fedora-live-base.ks +++ b/fedora-live-base.ks @@ -280,7 +280,7 @@ systemctl enable tmp.mount # 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-$releasever-$basearch +rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-*-primary echo "Packages within this LiveCD" rpm -qa # Note that running rpm recreates the rpm db files which aren't needed or wanted We would need to get this accepted as a Blocker or FE in order to make the change now however. Would someone like to propose it?
Proposed as a Blocker and Freeze Exception for 20-final by Fedora user kkofler using the blocker tracking app because: Proposing as a blocker because this breaks the chain of trust and thus loosens security in a way not easily addressed post-release. May be violating: https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Security_bugs If not a blocker, please at least consider this as a freeze exception. The change is trivial and it is in spin-kickstarts, so it doesn't have to go through Bodhi.
Also, how does this affect the graphical updaters? If it breaks them, it's a clear blocker!
yum install @sugar-desktop in Installed to HD TC-4 KDE - live x86_64 as DVD asks for and imports GPG key successfully (wireless connection) Install is successful.
The point is, it should NOT ask, the key should ALREADY be imported!
2nd Test; live DVD: booted live DVD connected to wireless AP asked for wireless password su yum install gparted asks if it is OK TO load GPG [y] installed gparted gparted runs from root terminal
it seems impossible to consider this a blocker, since it's essentially the same as 998: for anyone who doesn't know, DVD installs behave like this and have done forever. So for consistency's sake, -1 blocker. +1 FE though, perfectly good idea to fix it for lives the way we've had it before.
-1 Blocker on the fence over FE
Discussed in 2013-12-05 Go/No-Go meeting [1]. Voted as a RejectedBlocker and a AcceptedFreezeException. The DVDs have always behaved like this, so it's illogical to block on the lives doing the same thing, however a fix can be considered past freeze. [1] http://meetbot.fedoraproject.org/fedora-meeting-2/2013-12-05/
Worth elaborating on a bit of history we discovered in the meeting. We've had this 'rpm --import' in fedora-live-base.ks for a long, long time - beyond the git history of spin-kickstarts, I think - with the comment "# work around for poor key import UI in PackageKit". It seems it was added way back in the mists of time and never re-evaluated once PackageKit was able to import keys properly. Ever since then, we've imported the key during live image compose and not required the user to approve importing it at first package install/update operation. It broke early in F20 because the key name changed, and we noticed because an early gnome-software build had the same problem as the old PK bug the workaround was introduced for in the first place: it couldn't do key import properly. Kalev tried to fix it, but it turns out you can't use those variables there, so his 'fix' wound up running "rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora--" (variables replaced with nothing). nirik suggests just using a wildcard instead. So, that's the story till now. The question is, did we originally intend to drop this once the tools handled key importing, and should we still do so? The reason we don't do this for the DVD/netinst boils down to 'security', or trust - we can't logically do so in such a way that the intent of having the key in the first place is respected, at least AIUI. Is that the case for the lives too, and hence we shouldn't do it? Or is it 'correct' to import the key for the lives? If there are no 'security' implications of doing so for lives, I'd suggest we should go ahead and fix it with a wildcard.
(In reply to Adam Williamson from comment #20) d, and we noticed because > an early gnome-software build had the same problem as the old PK bug the > workaround was introduced for in the first place: it couldn't do key import > properly. Kalev tried to fix it, but it turns out you can't use those > variables there, so his 'fix' wound up running "rpm --import > /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora--" (variables replaced with nothing). > nirik suggests just using a wildcard instead. Here's my workaround -- set those variables. I've tested this and it works. Even though it seems a little silly. diff --git a/fedora-live-base.ks b/fedora-live-base.ks index a87bc62..35099d3 100644 --- a/fedora-live-base.ks +++ b/fedora-live-base.ks @@ -280,6 +280,8 @@ systemctl enable tmp.mount # work around for poor key import UI in PackageKit rm -f /var/lib/rpm/__db* +releasever=$(rpm -q --qf '%{version}\n' fedora-release) +basearch=$(uname -m) rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch echo "Packages within this LiveCD" rpm -qa
oh god no that's horrible, let's just please use wildcards?
(In reply to Adam Williamson from comment #22) > oh god no that's horrible, let's just please use wildcards? Seems less horrible than wildcards to me, but they're both ugly... it's a kind of fine distinction between two shades of gross. *shrug*
I don't care which of the fixes you use, but please commit SOME fix before the last RC (the one that goes gold) is spun! The sooner, the better.
I cherry picked matts version into f20.
spin-kickstarts-0.20.24-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/spin-kickstarts-0.20.24-1.fc20
Sadly, this does not work on the 32bit images. ;( error: /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-20-i686: import read failed(2). uname -m is i686, but the yum basearch and the key use i386 in the name So, this fixes the 64bit live and cloud images, but not the 32bit ones.
see? wildcards. i told ya.
Use uname -i instead of uname -m.
Gah, sorry about that. Sure, wildcards or uname -i. Whatever works! I also don't know what the right thing is on ARM.
If we don't slip I don't think there is going to be another chance to get an update in before gold. If we either slip, or gold is declared, we should do another build with the fix. I think the fix has been committed to the master branch already. There seems to be a related arm patch that we might also want at the same time? In the (post gold) update situation I think we'll want to wait a few days and give other people a chance to backport stuff before doing a new build.
Package spin-kickstarts-0.20.24-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing spin-kickstarts-0.20.24-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-23254/spin-kickstarts-0.20.24-1.fc20 then log in and leave karma (feedback).
spin-kickstarts-0.20.24-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
We still want a fix in the f20 branch.
Well, if we want a fix we could just cherry pick the one from master.
spin-kickstarts-0.20.25-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/spin-kickstarts-0.20.25-1.fc20
Package spin-kickstarts-0.20.25-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing spin-kickstarts-0.20.25-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-23884/spin-kickstarts-0.20.25-1.fc20 then log in and leave karma (feedback).
Fixed on Fedora-Live-KDE-i686-rawhide-20131228.iso and Fedora-Live-KDE-x86_64-rawhide-20131228.iso images.
spin-kickstarts-0.20.25-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.