Bug 1084721

Summary:	Gluster RPMs for CentOS/etc from download.gluster.org are not consistently signed
Product:	[Community] GlusterFS	Reporter:	Kurt Seifried <kseifried>
Component:	core	Assignee:	GlusterFS Bugs list <gluster-bugs>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	3.4.2	CC:	bressers, bugs, gluster-bugs
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-10-16 16:14:51 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:

Description Kurt Seifried 2014-04-05 22:31:05 UTC

Description of problem:

version 3.4.2 and 3.4.4 RPM's downloaded from:

https://download.gluster.org/pub/gluster/glusterfs/3.4/3.4.2/CentOS/epel-6.5/x86_64/

https://download.gluster.org/pub/gluster/glusterfs/3.4/3.4.3/CentOS/epel-6.5/x86_64/

They are signed but by different keys:

# rpm -Kv glusterfs-libs-3.4.2-1.el6.x86_64.rpm
glusterfs-libs-3.4.2-1.el6.x86_64.rpm:
    Header V4 RSA/SHA1 Signature, key ID 89ccae8b: OK
    Header SHA1 digest: OK (6ddb5e595a766c034eba9b5314746d32e83f75ee)
    V4 RSA/SHA1 Signature, key ID 89ccae8b: OK
    MD5 digest: OK (30c03a99f376bd4faa54c43bdb0aaffc)

# rpm -Kv glusterfs-libs-3.4.3-2.el6.x86_64.rpm 
glusterfs-libs-3.4.3-2.el6.x86_64.rpm:
    Header V4 RSA/SHA1 Signature, key ID 4ab22bb3: NOKEY
    Header SHA1 digest: OK (a608c3b9c2633b063310910d4ddaecbe33a4574e)
    V4 RSA/SHA1 Signature, key ID 4ab22bb3: NOKEY
    MD5 digest: OK (d1fa7523d3363047d583218ec0944dee)

Is this intentional? Why are they signed at all if the key being used keeps changing? Are they meant to be "properly" signed or are they signed by the (I assume developers?) so that we can claim we are not shipping unsigned RPMs?

Adding Security keyword as we (SRT) should probably figure out what is going on and make sure it's safe/documented/whatever.

Comment 1 Kurt Seifried 2014-04-05 22:35:33 UTC

So one concern: this either forces people using the gluster packages from download.gluster.org to either install several GPG keys of unknown safety (they are on developer machines? An internet connected server? Who knows?) or to disable checks for GPG signatures on the packages from downloads.gluster.org if they want to install/updates the packages (which they would). Both (especially the disabling of signatures) make it much easier for an attacker that compromises download.gluster.org to then insert rpms such as a kernel rpm or openssh rpm with modified contents that are then installed on the victims systems.

Comment 2 Kaleb KEITHLEY 2014-10-16 16:14:51 UTC

yup, the keys changed.

They haven't changed since. You seem to be inventing a problem that doesn't exist, i.e. continuously changing.

Closing as not a bug.