make RedHatSignedRpmScanner distribution agnostic

[evgeni]

The original detection covered only RHEL system, requiring rpms
to be signed by Red Hat (hardcoded). Also the model
InstalledRedHatSignedRPM didn't provide to much space for detection
of other distros.

The new solution checks RPMs signatures based on the detected
distribution ID (currently: rhel, centos). Fingerprints of GPG keys
and the packager string are stored under
repos/system_upgrade/common/files/distro//signatures.json
where is the distribution id.

InstalledRedHatSignedRPM is deprecated, replaced by the DistributionSignedRPM
message. The original InstalledRedHatSignedRPM will contain (till the removal)
just packages signed by RH (as before).

All actors have been updated to consume DistributionSignedRPM msg instead of the deprecated one.

jira: OAMG-9824

---

update:

• rebased against the master and squashed commits.
• resolved conflicts and updated newly created actors to use the new msg
• make pylint happy (at least locally on my machine, waiting for the public test)

TODO:

• update paths to stored keys based on the voting: files/distro/<distro>/...
• update some imports to be multiline again (fast_lint usually creates one line imports that are not so nice..) (stretch)
  • pstodulk: skipped: isort is annoying here...
• update commit msg
• passing tests
• ask for review

[github-actions]

Thank you for contributing to the Leapp project!

Please note that every PR needs to comply with the Leapp Guidelines and must pass all tests in order to be mergable.
If you want to request a review or rebuild a package in copr, you can use following commands as a comment:

• review please to notify leapp developers of review request
• /packit copr-build to submit a public copr build using packit

To launch regression testing public members of oamg organization can leave the following comment:

• /rerun to schedule tests using this pr build and leappmaster as artifacts
• /rerun 42 to schedule tests using this pr build and leappPR42 as artifacts

Please open ticket in case you experience technical problem with the CI. (RH internal only)

Note: In case there are problems with tests not being triggered automatically on new PR/commit or pending for a long time, please consider rerunning the CI by commenting leapp-ci build (might require several comments). If the problem persists, contact leapp-infra.

[Conan-Kudo]

This seems like a reasonable approach. Would it be possible to make the vendor sigs available through drop-in configuration files? That would make it easier to extend across all the various EL distributions...

[evgeni]

You mean by a file in /etc/leapp/files? I guess so.

No idea how complicated the delivery of additional files via the Red Hat portal is, but probably others can weigh in here.

[Conan-Kudo]

If it's delivered as an RPM, that shouldn't be an issue either way, right?

[evgeni]

For Red Hat systems, those files are not shipped in an RPM but delivered by either the Portal API or a downloadable tarball (edit: https://access.redhat.com/articles/3664871 if you have a sub).
For CentOS/Alma/etc it's an RPM, yeah.

Thinking more about this, we could just have a vendor.json and if that's missing fallback to the hard-coded RH values here?

[ekohl]

Thinking more about this, we could just have a vendor.json and if that's missing fallback to the hard-coded RH values here?

I wonder if it makes sense to have some vendor.d/*.json style. Then it's easy to drop in additional files which could even be done by distros in packaging.

[Conan-Kudo]

Yeah, perhaps what we have here could be a fallback if there are no vendor json files.

[evgeni]

Thinking more about this, we could just have a vendor.json and if that's missing fallback to the hard-coded RH values here?

I wonder if it makes sense to have some vendor.d/*.json style. Then it's easy to drop in additional files which could even be done by distros in packaging.

I wouldn't overcomplicate things. Multiple files would require merging and stuff, which can get hairy.

[pirat89]

hi @evgeni, basically the RedHatSignedRPMs msgs have to always contain just packages signed by RH - otherwise the name does not make sense. We are thinking about something like DistributionSignedRPMs or something like that, where would be packages delivered by the vendor of the particular distribution. We haven't had a time to discuss what will be the wanted solution yet. Having the set of vendors & keys specified in one json is good idea (but not configuration file! but data file; this file will not be expected to be configurable by users for sure). Currently I do not have an idea for use cases where we would need multiple json files to obtain this information.

[ekohl]

We are thinking about something like DistributionSignedRPMs or something like that, where would be packages delivered by the vendor of the particular distribution.

Does it make sense to have InstalledRedHatSignedRPM inherit from DistributionSignedRPMs?

[pirat89]

Does it make sense to have InstalledRedHatSignedRPM inherit from DistributionSignedRPMs?

It depends wdyt by that. If you mean something like

class DistributionSignedRPM(InstalledRPM):
    pass

class InstalledRedHatSignedRPM(DistributionsignedRPM):
    pass

then yes, but in fact it does not make so much difference when both classes have same fields and I guess the InstalledRedHatSignedRPM should be replaced in future by the new one. But as I told, we will have a discussion about this yet, to decide what is the desired way we would like to go. So it's not carved in the rock the DistributionSignedRPM name is the one. Or whether the desired solution will go in this way at all.

[ekohl]

That is indeed what I meant, but you're right that it may not make sense to keep InstalledRedHatSignedRPM around at all.

[pirat89]

class DistributionSignedRPM(InstalledRPM):
    pass

@deprecated("since=<date>",  message='Replaced by DistributionSignedRPM')
class InstalledRedHatSignedRPM(InstalledRPM):
    pass

[fernflower]

/rerun

[github-actions]

Copr build succeeded: https://copr.fedorainfracloud.org/coprs/build/5201514

[github-actions]

Testing Farm request for RHEL-7.9-rhui/5201514 regression testing has been created.
Once finished, results should be available here.
Full pipeline log.

[pirat89]

@fernflower we want this, but it needs more changes. so postponing that, but keeping it opened.

[github-actions]

Testing Farm request for RHEL-8.6.0-Nightly/5201514 regression testing has been created.
Once finished, results should be available here.
Full pipeline log.

[github-actions]

Testing Farm request for RHEL-8.7.0-Nightly/5201514 regression testing has been created.
Once finished, results should be available here.
Full pipeline log.

[github-actions]

Testing Farm request for RHEL-7.9-ZStream/5201514 regression testing has been created.
Once finished, results should be available here.
Full pipeline log.

[github-actions]

Testing Farm request for RHEL-7.9-ZStream/5201514 regression testing has been created.
Once finished, results should be available here.
Full pipeline log.

[github-actions]

Testing Farm request for RHEL-8.6-rhui/5201514 regression testing has been created.
Once finished, results should be available here.
Full pipeline log.

[pirat89]

We know we will not make it for the upcoming release. rolling the stone

[pirat89]

@fernflower re-review it please after the return from PTO. it's the first PR I would like to merge in this year, before we get to anything else.

[fernflower]

Can't find anything wrong :) lgtm

[pirat89]

Hmm...I think this old PR needs some love in this moment: "It's a little leap for actors, but a big leap for community" 😋 (or the opposite? :D)

[evgeni]

Hah! Thanks a ton for finishing this one up and merging it!

[pirat89]

@evgeni thanks for kicking this one out! :)