create+publish key trust chain

[electroniceel]

Currently all commits in this repo are signed. This is good and I can verify them from example with git log --show-signature.

There are two keys that were used to sign commits, 4AEE930798874F0D018886BDB37E62D143879B36 and 4E1CD92D4E2096B647933E276735C0E1BD65D048. Of these, only 4AEE930798874F0D018886BDB37E62D143879B36 is available to download via the keyservers listed in the readme.

But while the keys might contain a developer name not unheard of in Rocky Linux land, there is no signature from the official Rocky Linux GPG key (RPM-GPG-KEY-rockyofficial), as published on the Rocky Website, to these keys. So how do I verify that this key is indeed related to Rocky Linux? A green checkmark shown on the Github website doesn't tell me that.

In the long run I want to be able import the official Rocky Linux key into my GPG-keyring once and then be able to verify the releases and checksums against this key over the years, regardless of which individual developer does the commits. When the same key is used for years, many people will have it in their keyrings, making fraudulent key changes much harder.

I think the best solution would be to sign all commits into this repo just with this one key. The second best solution would be if the keys used to sign the commits are signed by the official Rocky Linux GPG key and these signatures were published for easy download.

[nazunalika]

I understand your concern here and I think it's valid. The previous key you can't find was done with a non-rockylinux GPG key, so that may explain that situation. That may have been before I realized I didn't have the right key set.

As for the rockyofficial key, that is actually the signing key used for Rocky Linux 8. Looking back at it, it was erroneously named. rocky-linux/rockylinux.org#418 was opened to add the Rocky Linux 9 keys. While that key can be used in general, I don't think it's a good idea as again, that is the EL8 gpg key.

The one thing that the key servers seem to strip out is who has cross signed keys. Some time last year, we had our GPG keys cross signed (signing party) when we were getting Secure Boot ready to go, among other things. This may or may not provide any more validation, but it would be some minor assurance. Unfortunately this information is missing from the key.

A different key altogether in my opinion would need to be issued. This then poses a new problem with who gets access to said key, where are the commits performed, and so on. This could likely be automated, but may require some thinking on our end.

[electroniceel]

As for the rockyofficial key, that is actually the signing key used for Rocky Linux 8. Looking back at it, it was erroneously named. rocky-linux/rockylinux.org#418 was opened to add the Rocky Linux 9 keys. While that key can be used in general, I don't think it's a good idea as again, that is the EL8 gpg key.

Ah, ok. Maybe there should then be some text be added to the website ( https://rockylinux.org/keys ) explaining that.

I think there should be a new key created then that serves as version independent project-wide key.

The one thing that the key servers seem to strip out is who has cross signed keys.

This is due to keyserver poisoning attacks. Since this seems a fundamental problem of the keyserver design, GnuPG ignores all signatures received from keyservers since release 2.2.17.

Unfortunately this makes using a published key trust chain quite complicated to use. One could create a dedicated Rocky Linux keyserver which does not allow public uploads, so no malicious signatures could be uploaded. Then the users could run gpg --keyserver-options no-self-sigs-only --keyserver keyserver.rockylinux.org --refresh-keys to get the signatures.

But I think this is becoming really really complicated and expecting some user to go through all of this is not realistic. The number of people actually doing it would be minimal, making detection of malicious tampering harder.

I think just having to trust one key for all things Rocky would make it much easier to use.

How do you organize access to other single keys, for example the UEFI secure boot key? Would it be possible to do something similar with the key to sign the commits to this repo?