Bug 837776 - RFE: Mechanism to deploy GPG keys for new channels to existing RHEL system rpm databases
RFE: Mechanism to deploy GPG keys for new channels to existing RHEL system rp...
Status: CLOSED WONTFIX
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Registration (Show other bugs)
541
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Todd Warner
Red Hat Satellite QA List
: FutureFeature
Depends On:
Blocks: 260381
  Show dependency treegraph
 
Reported: 2012-07-05 04:44 EDT by riotintoti
Modified: 2012-07-11 20:00 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-07-11 14:50:09 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description riotintoti 2012-07-05 04:44:51 EDT
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 14:50:09 EDT
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-11 20:00:44 EDT
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

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