Bug 5814

No, theses are all wrongs assumptions.
- Don't rely on the wiki for anything critical. (wiki will be changed at some point).
- Don't assume the gpg keys can be derived from path, there is no stability to expect there.
- 2020 is not the year of use, it's the year the key was created, we will keep using it for "few years" until changed.


Fix is easy:

    - name: import rpmfusion gpg keys into rpm database
      rpm_key:
        state: present
        key: "{{ item }}"
      loop:
        - https://rpmfusion.org/keys?action=AttachFile&do=get&target=RPM-GPG-KEY-rpmfusion-free-fedora-2020
        - https://rpmfusion.org/keys?action=AttachFile&do=get&target=RPM-GPG-KEY-rpmfusion-nonfree-fedora-2020
      when: ansible_distribution_major_version|int >= 33

(In reply to Nicolas Chauvet from comment #1)
> - Don't assume the gpg keys can be derived from path, there is no stability
> to expect there.
> - 2020 is not the year of use, it's the year the key was created, we will
> keep using it for "few years" until changed.

Thanks for the information and the suggested fix for the Ansible task. But like you already said, this will be a valid fix for only a while. Manual fixes will be needed because of this unpredictable structure.

I would still suggest the solution to create aliases that point each Fedora release. Just like there is an RPM for each Fedora release. This alias could still point to the same key. This makes automation possible and prevents these ugly manual and redundant fixes with almost identical Ansible tasks.

Another solution would be to upload the 2020 key to the improved GPG key server: https://keys.openpgp.org/about/faq and not to the other traditional key servers. This is because the old key server structure (SKS pool) is broken in terms of security. The new https://keys.openpgp.org/ fixes that and also provides more control over your keys.

If you upload the 2020 key to https://keys.openpgp.org/ then everyone fetch all the supported keys from there based on the email address associated with it: rpmfusion-buildsys@lists.rpmfusion.org and then import those keys into the RPM database. This solution would also have the least maintenance for you.

Thanks for considering.

I've tried to upload the gpg keys in keys.openpgp.org but unfortunately the interface don't allow to verify more than one gpg key by email address...
We can eventually use a different email when creating new keys, but it won't be soon... and we won't fix existing gpg keys (el7/el8 older fedoras).


To me the appropriate approach with ansible is to:
 - verify if rpmfusion-*-release are installed (and if not...)
 - install the distant rpmfusion*-release with https from mirrors.rf.o
 - import the gpg-keys from the local path located in the .repo file, as there is the maintained symlinks from a fedora version.

This approach won't rely on the "keys" wiki page parsing, and only rely on one external resources (from mirrors.rpmfusion.org) which is "purposely" redondant.

The wiki is a single instance host so far. If down for any reason, your script will break.

If you want to publish such a role for rpmfusion activation with ansible, we may document it in our wiki or elsewhere.
https://rpmfusion.org/Contribute

(In reply to Nicolas Chauvet from comment #3)
> I've tried to upload the gpg keys in keys.openpgp.org but unfortunately the
> interface don't allow to verify more than one gpg key by email address...

That's odd. I have an RSA 4096 and an ED25519 key on there with the same UIDs (mail addresses) verified.


> To me the appropriate approach with ansible is to:
>  - verify if rpmfusion-*-release are installed (and if not...)
>  - install the distant rpmfusion*-release with https from mirrors.rf.o
>  - import the gpg-keys from the local path located in the .repo file, as
> there is the maintained symlinks from a fedora version.

I see what you mean, and indeed the key is installed locally in /etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-free-fedora-2020. However, before I can install the repo RPM containing this key, I need to verify it with a GPG key. For that I first need to retrieve the key. Otherwise the install will fail. Chicken and the egg story. Disabling the GPG check to fix this is then the only method, but not a valid fix of course.

So a predictable way to lookup the related key for the repo RPM would only allow an automated and secure setup. If this is not possible anymore because of this new prolonged key usage without aliases that point the F33 key to the 2020 key, then it's simply not doable. Manual intervention every few years is then the only way.


> If you want to publish such a role for rpmfusion activation with ansible, we
> may document it in our wiki or elsewhere.
> https://rpmfusion.org/Contribute

At the moment these are just 2 tasks (install the keys and install the repo RPMs), but when I have this working and have time I can separate it and create a role then I'll submit it to Ansible Galaxy.

Finally I'm going to implement that, but I recommend to only download the gpg key from our primary mirror location.

Fixed with https://download1.rpmfusion.org/free/fedora/RPM-GPG-KEY-rpmfusion-free-fedora-2020 and so on...

*** Bug 6352 has been marked as a duplicate of this bug. ***

(In reply to Nicolas Chauvet from comment #7)
> Fixed with
> https://download1.rpmfusion.org/free/fedora/RPM-GPG-KEY-rpmfusion-free-
> fedora-2020 and so on...

What exactly has been fixed? This report was about the fact that the URLs are not predictable anymore. This URL can still change any moment to another year and that will break automation. As you mention yourself, "few years", so that doesn't work well with automation.

> Don't assume the gpg keys can be derived from path, there is no stability to expect there

This is something you have in control, you can strip off the 2020 from the URL and just upload a new key with the same name. Automated tools such as Ansible will notice the difference and can then react to that change. Now people are waiting for it to break and then they have to manually fix it. Not ideal, but I suppose there is a reason for this name scheme.

Another fix can also be this:
> If you upload the 2020 key to https://keys.openpgp.org/ then everyone fetch all the supported keys from there based on the email address associated with it: rpmfusion-buildsys@lists.rpmfusion.org and then import those keys into the RPM database. This solution would also have the least maintenance for you.

Then you can keep the 2020 URL online, while people can automated the retrieval of the key via openpgp.org.

Automation will have to check anytime we change the key anyway
Some day or later things will break.

(In reply to Nicolas Chauvet from comment #10)
> Automation will have to check anytime we change the key anyway
> Some day or later things will break.

There is a clear difference. If the URL to retrieve the key is stable, then the new key will be downloaded once there is a hash mismatch. If the key changes in that scenario then things will automatically fix itself.

In the current situation the automation will fail because the URL will change because it will be 202x, that's not stable setup. I find the resistance to this argument a bit strange. It's an easy fix and totally in your control which will help people to setup a stable user experience with your repository. There is no reason to put a date in a URL, especially for key material that automation needs to pull. Unless of course you rotate the key on a yearly basis. Then it's stable again, because that's predictable. But now it's 2020 and sometime in the future it will be something else.

(In reply to kees.dejong+dev from comment #11)
...
> There is a clear difference. If the URL to retrieve the key is stable, then
> the new key will be downloaded once there is a hash mismatch. If the key
> changes in that scenario then things will automatically fix itself.

We are a free service, and I find extremely difficult to answer when people ask a tremendous amount of "easy things" but not that easy when there is a need to maintain after all.

What you describes is simply not how things are going to happen with the GPG key rotation in some scenari. 
If the key change, then we may only migrate only the newer distro to the new key. You will have to keep the old key for older distros.
But then if the GPG is rotated anytime for any reason, we will just replace the older key and end-users will have to distrust the older one.

The only method we will guaranty to maintain is with the RPM method, because there we want the transition to the new key as smooth as possible for all our users.

Then you will have the distribution-gpg-keys package that is not in our control but still provide an reasonable alternative for some use-case.

The 2020 GPG keys are not year based, it's the usual way to describe the year a gpg/certificate was generated specially when those are expected to be usefull for many years (10 or so).

Fair points, but you can use HTTP redirects, e.g. RPM-GPG-KEY-rpmfusion-free-fedora-37 will point to the 2020 key, RPM-GPG-KEY-rpmfusion-free-fedora-39 will point to the 2024 key. Just as an example of course.

This is a technical problem and has technical solutions. Rotating the key with every Fedora release made most sense to me. It's what Fedora does as well. For a new release you have to sign the packages anyway, it's not that you save work by using the same key again.

Thanks for spending your free time on this, I'm in no way bashing you. I'm proposing solutions for something that one day will affect many people. This can be easily avoided.