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.
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.
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.