Enterprise Linux 6 and 7 packages are signed with a weak key

[lubo]

The key in question, 1EE04CCE88A4AE4AA29A5DF5004E6F4700F97F56, uses 1024-bit DSA (only sufficient through 2010) and SHA-1 (completely broken, practical chosen-prefix attacks demostrated). A new, strong key should be used instead and it should provide enough security margin to provide security through EOL dates of these systems.

[remicollet]

Sorry but I don't plan to change the key used to sign RPM (this will be a nightmare to manage, as breaking most installations)

EL-6 will be EOL in ~2 months

EL-8 have a new key, and a new key is generated every year for new distro.

[lubo]

I understand changing the key for EL-6 isn't worth the trouble at this point, but EL-7 will be around for four more years. Is there something we can do to not break existing installations? How about you append a new key to RPM-GPG-KEY-remi file and then rebuild all the packages? When yum finds out it doesn't recognize the new key, it'll try to import keys from the file again, correct?

[remicollet]

The problem is with the "remi-release" new version providing the new key, which will fail to "update" on old server without the new key.

[remicollet]

.... and then rebuild all the packages?

Are you aware there is >28000 packages in the repository ?
by luck signing doesn't imply rebuilding ;)

The only "safe" thing I can imagine, is using a new key for any new repository in the future
(remi-php80 is already open and populated, next one will be remi-php81 in ~1 year)

[remicollet]

An additional issue: most repositories are not enabled by default ("remi", "remi-phpxx"...), so when enabled by user, won't be updated (new config file saved as .rpmnew), so won't be aware of new key

[lubo]

The problem is with the "remi-release" new version providing the new key, which will fail to "update" on old server without the new key.

How about you provide another package, equivalent to remi-release in functionality but signed with and providing a new key?

Are you aware there is >28000 packages in the repository ?
by luck signing doesn't imply rebuilding ;)

The only "safe" thing I can imagine, is using a new key for any new repository in the future
(remi-php80 is already open and populated, next one will be remi-php81 in ~1 year)

Shouldn't you bump package version if you use another signing key? I don't think changing signing key silently is right.

An additional issue: most repositories are not enabled by default ("remi", "remi-phpxx"...), so when enabled by user, won't be updated (new config file saved as .rpmnew), so won't be aware of new key

Again, if you append the new key to the existing key file, won't that solve the problem?

[remicollet]

I don't think changing signing key silently is right.

I obviously don't plan to rebuild 28k packages

Sorry, but no proper solution, so won't fix.

I remember when fedora has to change its key (compromised) it was a nightmare, requiring user action... and I don't want that.