[Rpm-maint] [rpm-software-management/rpm] Add an API for permanently removing public keys from keystore (Issue #3338)

[Panu Matilainen]

>From the PR, to keep discussion in one place:
> As said in https://github.com/rpm-software-management/rpm/issues/3338 I don't like the idea of passing the keyid to the backend. This even accepts short keyids which we are trying to get rid of. I also don't like that it makes use of the fact that the storage backends are based on the key ids. For one we want to change that. It also leaks this implementation detail into the API a bit too much for my taste.

Fingerprints are the main handle the public keys are known by, so I don't think it's an "implementation detail" any more than the fact that packages are accessed by their nvr. 

The fact that it now accepts the short keyid because there's just no other way to do it currently - that's ticket #3360, and I didn't want to drag that too into this PR. I brought this mismatch up in the discussions around changing the output to the fingerprint. 

The thought of passing rpmPubkey there did occur to me too, but right now there's no pubkey that can be passed there, that road is blocked on the keyring iterator. There are couple of reasons I dislike that: you need to get those keys somewhere, so you need to have the fingerprint/keyid visible on some public API, or you need to do a linear search on an iterator. Which doesn't seem that great either. The other thing is that constructing something just to delete it seems kinda strange - and if there's a bug or the key gets malformed, you might no longer be able to delete such a key then.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3338#issuecomment-2404817203
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/issues/3338/2404817203 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20241010/2c7c59c1/attachment.html>