Bug 837776

Summary:	RFE: Mechanism to deploy GPG keys for new channels to existing RHEL system rpm databases
Product:	Red Hat Satellite 5	Reporter:	riotintoti <michael.ferguson>
Component:	Registration	Assignee:	Todd Warner <taw>
Status:	CLOSED WONTFIX	QA Contact:	Red Hat Satellite QA List <satqe-list>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	541	CC:	cperry
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-07-11 18:50:09 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	260381

Description riotintoti 2012-07-05 08:44:51 UTC

Description of Problem:

When adding new channels to Satellite, GPG keys for packages associated with these channels are added to the Kickstart GPG/SSL Section. From here these keys are added to the applicable kickstart profiles.

This is OK for NEW systems that are deployed, however when adding new channels to EXISTING systems (by registering/re-registering EXISTING systems with the relevant activation key) there is no mechanism to also deploy the relevant GPG key to the system rpm database. This means that although the channel might be added to the existing system, the system can't install packages from it (as they are signed with the GPG channel key).

Currently as a workaround we have to manually deploy the associated GPG key to existing systems that we are adding a new channel to. This is not manageable and there should be a better mechanism to do this.

(and yes I could script the GPG deployment by manually editing a 'bootstrap.sh' file, but this is hackish, not scalable and Satellite should already have a mechanism to do this implicitly in the rhn_register process)

Comment 1 Clifford Perry 2012-07-11 18:50:09 UTC

Sadly, I cannot think of a good, sane, and secure process to do this. That would not open up potential security holes - where a user hacks Satellite and now has ability to install ANY package onto any managed system. Vs adding a layer of trust, by signing the custom RPM's with a GPG key that you keep secure. 

I'm sorry it is not 'easy' to do today, but the solution really is, to manually establish the GPG keys on established systems, for trusted gpg keys. (or automated/scripted deployments). 

As is today, I am going to decline this request. 

Cliff

Comment 2 riotintoti 2012-07-12 00:00:44 UTC

Hi Cliff,

Am a little confused with the reasoning here, as this functionality already exists for kickstart deployed systems (Satellite already has a mechanism to store and deploy GPG keys to new systems). How is it any more of a security flaw for that mechanism to be extended to already registered systems (more specifically systems I want to subscribe to an additional channel)?

Thanks,
Michael