Put GPG fingerprint for RPM packages in GitHub repo

[szpak]

First of all, I really like the simplicity of installing NVidia proprietary driver in Fedora with negativo17!

Recently, I've been updating the kernel and Nvidia driver on Fedora 37 which hasn't been used for a few months and dnf asked be to import the new GPG key:

Importing GPG key 0x0D61C616:
 Userid     : "Simone Caronni (slaanesh) <negativo17@gmail.com>"
 Fingerprint: D495 00D3 43BB D8C2 98EC 0E79 7265 DCE4 0D61 C616
 From       : https://negativo17.org/repos/RPM-GPG-KEY-slaanesh
Is this ok [y/N]:

As I try to care about security, I wanted to verify if it is a regular change (although it's still Fedora 37, not 38) or maybe a malicious actor would like to infect my system with some nasty stuff. Unfortunately, I wasn't able to find that key on the webpage.

Assuming the new key is legit ;-), maybe it would be good to put the current key in some file in this GitHub repository to allow (meticulous) people to verify it (the repo and GitHub are two separate infrastructures)?

[scaronni]

That's a good idea, but i need to find a way for people to find it.

A new key is being used to sign packages as the old one was using one of the ciphers that is not supported anymore by the Fedora 38 crypto policies, so I replaced it with something that does not need user intervention to accept.

While at it, I made the new one expire after the CentOS/EL7 EOL date, so I can also use a new one with a stronger cipher that is not supported by current EL7.

The old and new keys are here: https://negativo17.org/repos/

And here: https://keyserver.ubuntu.com/pks/lookup?search=negativo17%40gmail.com&fingerprint=on&op=index

I thought that leaving the old one there would be enough but I would say is not. Do you think introducing a negativo17-something-release.rpm mechanism would help?

[szpak]

That's a good idea, but i need to find a way for people to find it.

As https://negativo17.org/repos/ is mentioned in the key comment, maybe you could put the file GPG-KEYS-VERIFICATION.txt there with the information to check the project infrastructure on GitHub where the key's fingerprint will be also mentioned?

A new key is being used to sign packages as the old one was using one of the ciphers that is not supported anymore by the Fedora 38 crypto policies, so I replaced it with something that does not need user intervention to accept.

Yes, Fedora is recently very "trailblazing" in the context of the cipher policy (which sometimes might "blackhole" some older systems where you SSH to :) ).

Do you think introducing a negativo17-something-release.rpm mechanism would help?

The release.rpm mechanism brings the keys to the computer (they are in /etc/pki/rpm-gpg/ instead of just on the server), however, I believe, even for the next version Fedora installation (with the changed key), I have to manually confirm it is ok (personally, in that case, I check on the Fedora webpage, which should have slightly separate infrastructure in comparison to the RPM repository/registry). From the security point of view, it is somehow better, as the release package with the new key has been signed with the old (verified) one (so, if it is feasible to do, it might be a good idea). However, I believe that some people could still want to "verify" the key somewhere (e.g. on GitHub, an attacker would need to take over 2 "accounts"). It might be also easier to implement.

[scaronni]

Better late then never:

https://github.com/negativo17/gpg-keys

Announcement: https://negativo17.org/gpg-key-rotation/

[szpak]

Better late then never:

Definitely :)

Thanks! I will try it next time upgrading the NVidia packages.