Support repoids (at least) in rpmdb

[cgwalters]

rpm doesn't know about rpm-md repositories, that's always lived in higher level things like zypper and yum/dnf etc.

Some of those tools have grown their own databases that live separately from rpm and there's a few tension points from that.

Recently we hit an issue at Red Hat where security scanners really need the repo identifiers for packages in addition to the raw rpmdb.

This PR to clair is I think objectively quite hacky.

It'd be much cleaner to start if this data lived in the rpmdb - that'd mean one API to access it, and it would better express the expected 1-1 mapping of this data - today it's quite easy for the higher level database to become wrong if rpm is invoked directly, but if a package was installed directly from rpm the field could contain e.g. "file://" or so for a local file or http:// for URL.

[hdonnay]

The rpmdb recording where an rpm is from (after some fashion) would be amazing. The higher-level tools would need API to be able to pass that information, and we'd need to set an expectation that the information should refer to the "point of distribution" as best as possible.

Expounding on that:

Consider the following two sets of (end-user) equivalent commands:

dnf download hello
dnf install hello

dnf install hello

It'd have to be specified that these should both record the URI that's constructed via the repository information; ideally the one actually used. Even though in the former install the package is directly from disk, the cache should be transparent.

Higher level tools should also refrain from providing URIs that are correct in some sense but don't serve the ultimate goal, e.g. dnf5:fedora/hello-2.12.1-1.fc40.

Another option would be to record a purl and make similar recommendations about recording provenance information.

[cgwalters]

dnf download hello
dnf install hello

I think you mean

dnf download hello
dnf install ./hello*.rpm

right? It's important to be clear here.

Even though in the former install the package is directly from disk, the cache should be transparent.

I was going to reply at first "why the heck would you type "dnf download foo" and then "dnf install foo*.rpm" but actually that is of course how dnf itself does things today (which has its own problems around transient disk usage spikes, but that's an aside).

And I guess that's actually how the "hermetic" build stuff with lockfiles works in konflux today. (edit no, that's just a repo proxy)

It does argue that it would make sense for dnf to e.g. store the repo (and other metadata) as say a user.dnf.repoid xattr on the file, and then when installing, pass that information to rpm. (Or equivalently I guess for now, just consume it itself).

[hdonnay]

I think you mean [...]

Okay, rereading the man page, I meant:

dnf install --downloadonly hello
dnf install hello

It does argue that it would make sense for dnf to e.g. store the repo (and other metadata) as say a user.dnf.repoid xattr on the file, and then when installing, pass that information to rpm. (Or equivalently I guess for now, just consume it itself).

Ideally it's more than just the repoid, as that's not stable over time.

[hdonnay]

Thinking about this more, it'd be ideal to be able to associate a pair of CPEs with every package, one for the package itself and the other for a repository¹.

Footnotes

1. Using a CPE to describe a repository may be a Red Hat-ism, so maybe a set of tags that can describe the repos a few different ways. ↩

[p-rog]

CPE represents a product's specific stream (version), where can be many repositories and one repository can be associated with many CPEs as well. Better would be to associate precisely package with source repository URL, which can be represented by package purl like you mentioned earlier.