Adopt a new PURL format for RPMs

[eskultety]

The official PURL spec for RPMs is vague [1]. Red Hat product security team published a PURL guideline for their internal build processes which addresses some of the pitfalls in the current upstream PURL spec and takes a slightly different approach with some of the qualifiers [2]. Some of the fields appear to be more standardized compared to its upstream counterpart this patch adopts the format for now, at least until a more refined vendor-agnostic PURL guideline for RPMs is posted in the upstream space. Most notable changes:

• RPM checksum is now formatted in PURL qualifiers if present
• repository ID obsoletes download URLs in the PURL if present

EXAMPLES:

• pkg:rpm/redhat/emacs@27.2-9.el9?arch=noarch&repository_id=ubi-9-appstream-rpms
• pkg:rpm/redhat/emacs@27.2-9.el9?epoch=1&arch=src&repository_id=ubi-9-appstream-rpms&checksum=sha256:abcd1234
• pkg:rpm/foo@1.0-1.el8?arch=x86_64&download_url=<quoted_example.com>

For what it's worth I also tried to revive an old thread on namespaces in the upstream PURL spec to request refreshment of the PURL to cover additional cases: https://github.com/package-url/purl-spec/issues/239 I used the opportunity to also mention [2] to the community and our intended approach as implemented by this PR.

[1] https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst#rpm [2] https://redhatproductsecurity.github.io/security-data-guidelines/purl/

Maintainers will complete the following section

• [ ] Commit messages are descriptive enough
• [ ] Code coverage from testing does not decrease and new code is covered
• [ ] Docs updated (if applicable)
• [ ] Docs links in the code are still valid (if docs were updated)

Note: if the contribution is external (not from an organization member), the CI pipeline will not run automatically. After verifying that the CI is safe to run:

• approve GitHub Actions workflows by clicking a button
• approve the Red Hat Trusted App Pipeline container build by commenting /ok-to-test (as is the standard for Pipelines as Code)

[eskultety]

Tests updated -> ready to review.

[eskultety]

Since v2:

• improved the instantiation of the Package class in context of mypy dict typing (dict[str, str] -> dict[str, Optional[str]))
• added a unit test case covering PURLs for noarch and .src.rpm

[brunoapimentel]

I noticed that this improvement has also solved the issue of duplicated SBOM components for noarch RPMs that come from the same repoid (although we still download them individually for each arch they happen to be listed under). Should we make not of this in the commit message?

[eskultety]

I noticed that this improvement has also solved the issue of duplicated SBOM components for noarch RPMs that come from the same repoid (although we still download them individually for each arch they happen to be listed under). Should we make not of this in the commit message?

Huh, I just noticed the code being part of the SBOM output model which I only noticed just now, sure.

[eskultety]

Since v3:

• generate the PURL with packageurl.PackageURL and make use of escaping in all fields
• restructure the last but one commit (integration test updates) so that it only contains a new use case and the test data update happens in the commit which introduces the PURL changes (otherwise it would kina break bisectability if one runs integration tests in an interactive rebase)
• CodeQL fix

[brunoapimentel]

/retest