RFE: Identify crypto backend in --showrc output

[j-mracek]

In librepo we prepare implementation without GPGme (rpm-software-management/librepo#275). I would prefer to require rpm with rpm-sequoia back-end when librepo will use RPM instead of GPGME. It will ensure that we will use the tested backend and if someone will need to rpm without rpm-sequoia then they will also need to rebuild librepo.

May I ask you to ship rpm or rpm-libs with a provide that signals rpm with sequoia back-end?

[pmatilai]

We don't ship any packages upstream so there's no place to add a virtual provide to.
The closest thing to that is rpmlib() provides but those are for tracking capabilities required by binary packages.

So a regular virtual provide would have to be a distro packaging thing. Alternatively we could put something into rpm.pc for example.

[j-mracek]

In dnf5 source has BuildRequires: pkgconfig(rpm) >= 4.17.0
Then the library (libdnf5) requires librpm.so.9()(64bit)

In theory if rpm-libs will provide rpm-libs(sequoia) then we can use something like
Requires: ( rpm-libs{?_isa} >= %{rpm_version} with rpm-libs(sequoia) )`

If rpm-devel will provide let say rpm-devel(sequoia) then we can use
BuildRequires: ( pkgconfig(rpm) >= 4.17.0 with rpm-devel(sequoia) )

There are multiple ways how to achieve specific requirement for build and runtime, therefore take my comments as an example. I am sure you have a better idea.

The request is to prevent potential problems in other distributions where they can be creative.

[pmatilai]

Again, we don't HAVE a package where we could put such a provide. I know dnf ships with an upstream spec, but we don't.

[j-mracek]

My apology. I see other options. In past we faced a problem with librepo and zchunk where library was build without zchunk support (RHEL) but libdnf with support (copr). We resolved it by #define LRO_SUPPORTS_CACHEDIR in librepo. Then libdnf was able to detect whether librepo supports it or not. If rpm define such a variable we could provide a message that something is not available with a reason or fail nicely with a suggestion. The define will resolve the biggest issue - something behaves incorrectly and we have no idea why because we don't see any clue about back-end used in RPM.

You also suggested the option using modification of rpm.pc. I think this could resolve the build requirement part.

Or the request could be converted into FEDORA, RHEL downstream request.

[pmatilai]

Yeah there are various options. Checking at build-time doesn't work though, because the selected PGP option is an implementation detail inside rpm and can be changed without rebuilding API users. So it either needs to be an rpmlib() provide, but I dislike that because we'd be stuck with that forever, or a packaging side virtual provide. Which is of course what you were asking for all along, but in that case it will need to be handled on distro packaging level.

[ppisar]

I confirm it's an implementation detail without impact on API and ABI. Though It's clear that the two implementations are not equivalent (#2512). Would it make sense to add a function which would return which PGP implementation is used by the running librpmio? E.g.:

typedef enum pgpImplementation_e {
    PGPIMPLEMENTATION_INTERNAL = 0,
    PGPIMPLEMENTATION_SEQUOIA = 1,
} pgpImplementation;
pgpImplementation pgpImplmentationInUse(void);

[ppisar]

I moved the packaging request to Fedora's Bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=2239780.

[pmatilai]

It wouldn't be hard to add some API of course, but I'm loathe to add anything at all for a thing that's supposed to be going away 🤔

OTOH maybe we could just have each backend identify itself with an arbitrary string which could also cover things like the used lower level crypto, eg "sequoia:openssl" or "rpmpgp:gcrypt". @nwalfield , thoughts?

Outputing that in --showrc would be a useful debug aid too.

[nwalfield]

I support adding an interface for a backend to identify itself. This is useful for debugging, as you point out.

I'm not so excited about users of librpm changing their behavior based on the backend's name. If we want to support that (and I'm not convinced that we do), I'd rather introduce feature flags, which a user could query, e.g., "SUBKEYS". Otherwise, we'll end up with the nightmare that is user agent string parsing.

What do you think?

[pmatilai]

I too quite severely dislike the notion of librpm users caring about the backend (name) explicitly. Ideally an API user would be handled -ENOTIMPL which they could then handle the best they see fit, but we don't have such interfaces at the moment and again would loathe to do new developments for a thing that's on its way out.

So maybe we'll just add an internal API for the purposes of identifying itself in --showrc, but leave it out of the public API. And just handle the dnf/librepo case in packaging instead, that much is easy to do.

[nwalfield]

That sounds good to me.