I’ve searched a while for an answer but found nothing yet.
Some repos (e.g. the Foreman itself) use a different GPG key for each release. Now one can put a certain release of Foreman into a content view, but the GPG key is not part of it. When the repo gets assigned a new key, then on every host with that content view, install or upgrade of packages can fail with “The GPG keys listed for the repository are already installed but they are not correct for this package”.
How is this supposed to be handled? Create a separate repo for each release and create content views accordingly?
From my experience the GPG key is set at the repository. So if you have a Product “Foreman” with a Repo “Foreman 2.2” and “Foreman 2.3” inside, you need to specify a different GPG key for each. The CV will use the corresponding key from the selected repository.
That’s clear, and I already had planned to do it that way. However it feels quite awkward to create a new repo each time the key changes. So my question would be: Is this the recommended way to do it, or even the only possible way?
That part I don’t get. Inside one repo you usually find all packages signed with the same key. If the key would change, all packages (including older ones) in that repo would need to be resigned. Thats sounds quite unusual.
However, if you have two different versions of the same product, lets say Foreman 2.2 and 2.3, you add both repos to your product, each having a different (or the same, depending on the issuer of the RPMs) signing key.
Thank you.