Bug 1023178 - RPM GPG key not imported on live images
Summary: RPM GPG key not imported on live images
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: spin-kickstarts
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jeroen van Meeuwen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker AcceptedFreezeException
Depends On:
Blocks: F20FinalFreezeException
TreeView+ depends on / blocked
 
Reported: 2013-10-24 19:46 UTC by nucleo
Modified: 2013-12-31 01:58 UTC (History)
17 users (show)

Fixed In Version: spin-kickstarts-0.20.25-1.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-12-31 01:58:41 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description nucleo 2013-10-24 19:46:01 UTC
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.

Comment 1 nucleo 2013-10-28 16:01:53 UTC
Looks like bug should be fixed in spin-kickstarts
https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?id=32e066e039d130698396c2435f15db7232e47e06

Comment 2 Bruno Wolff III 2013-10-28 16:20:35 UTC
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.

Comment 3 nucleo 2013-10-28 16:41:10 UTC
Commit was at 2013-10-16 but problem still present on 20-Beta-TC6 images created at 26-Oct-2013.

Comment 4 nucleo 2013-11-02 16:25:03 UTC
Problem still on 20-Beta-RC2 images.

Comment 5 nucleo 2013-11-12 15:03:13 UTC
Released F20 Beta live images also with this problem.

Comment 6 nucleo 2013-11-25 19:36:04 UTC
Fedora-Live-KDE-i686-20-TC2, rpm gpg key not imported.

Comment 7 nucleo 2013-11-27 14:31:32 UTC
The same on TC3.

Comment 8 nucleo 2013-12-04 13:23:20 UTC
Fedora-Live-KDE-i686-20-TC4.iso, same problem.
Nobody working on fixing?

Comment 9 Kevin Fenzi 2013-12-04 19:35:30 UTC
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...

Comment 10 Kevin Fenzi 2013-12-04 21:00:40 UTC
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?

Comment 11 Fedora Blocker Bugs Application 2013-12-04 22:04:19 UTC
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.

Comment 12 Kevin Kofler 2013-12-04 22:07:09 UTC
Also, how does this affect the graphical updaters? If it breaks them, it's a clear blocker!

Comment 13 satellitgo 2013-12-04 22:51:21 UTC
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.

Comment 14 Kevin Kofler 2013-12-04 22:54:55 UTC
The point is, it should NOT ask, the key should ALREADY be imported!

Comment 15 satellitgo 2013-12-04 23:30:42 UTC
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.

Comment 16 satellitgo 2013-12-04 23:31:03 UTC
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

Comment 17 Adam Williamson 2013-12-05 01:22:03 UTC
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.

Comment 18 Dennis Gilmore 2013-12-05 04:20:06 UTC
-1 Blocker
on the fence over FE

Comment 19 Mike Ruckman 2013-12-05 19:12:47 UTC
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/

Comment 20 Adam Williamson 2013-12-05 19:53:34 UTC
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.

Comment 21 Matthew Miller 2013-12-10 20:13:59 UTC
(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

Comment 22 Adam Williamson 2013-12-10 22:00:31 UTC
oh god no that's horrible, let's just please use wildcards?

Comment 23 Matthew Miller 2013-12-10 22:23:20 UTC
(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*

Comment 24 Kevin Kofler 2013-12-10 22:51:39 UTC
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.

Comment 25 Kevin Fenzi 2013-12-11 19:00:36 UTC
I cherry picked matts version into f20.

Comment 26 Fedora Update System 2013-12-11 19:17:30 UTC
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

Comment 27 Kevin Fenzi 2013-12-12 03:24:10 UTC
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.

Comment 28 Adam Williamson 2013-12-12 04:03:05 UTC
see? wildcards. i told ya.

Comment 29 Kevin Kofler 2013-12-12 10:38:22 UTC
Use uname -i instead of uname -m.

Comment 30 Matthew Miller 2013-12-12 12:23:44 UTC
Gah, sorry about that. Sure, wildcards or uname -i. Whatever works!

I also don't know what the right thing is on ARM.

Comment 31 Bruno Wolff III 2013-12-12 14:01:53 UTC
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.

Comment 32 Fedora Update System 2013-12-12 16:30:35 UTC
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).

Comment 33 Fedora Update System 2013-12-13 05:35:20 UTC
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.

Comment 34 Bruno Wolff III 2013-12-13 06:15:07 UTC
We still want a fix in the f20 branch.

Comment 35 Kevin Fenzi 2013-12-13 18:53:42 UTC
Well, if we want a fix we could just cherry pick the one from master.

Comment 36 Fedora Update System 2013-12-21 21:52:42 UTC
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

Comment 37 Fedora Update System 2013-12-23 03:51:46 UTC
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).

Comment 38 nucleo 2013-12-28 17:49:16 UTC
Fixed on Fedora-Live-KDE-i686-rawhide-20131228.iso and Fedora-Live-KDE-x86_64-rawhide-20131228.iso images.

Comment 39 Fedora Update System 2013-12-31 01:58:41 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.