Would it make sense to distinguish the cases where no certs are found or multiple certs are returned? Something like:

if certs.is_empty() {
  return Err(...);
}
// At most one cert should be returned by lookup_by_cert, when searched with a fingerprint
assert!(certs.len() == 1);

I didn’t test that, but lookup_by_cert not finding anything should fail with StoreError::NotFound already; that’s one of the failures the with_context()? above is supposed to be handling.

So, here I think len() ≥ 1.

Also, len() > 1 is not an indication of a program bug that would merit an assert at this point — the input is parsed as KeyHandle, which is not only a full fingerprint, but also a key ID, and key IDs are short enough to be possibly ambiguous. So, it is ~legitimately possible for the lookup to return multiple results.

(At the c/image level, the API is named WithKeyFingerprint and it’s undocumented that it also accepts short key IDs. That’s really a bug in c/image option validation; it might still be an option for podman-sequoia to turn the key_handle parameter into a key_fingerprint parameter, and then this could be an assert.)

Compare also the “For gpgme, allow lookup by user ID? grep_userid, or what is the compatible semantics?” FIXME: the pre-existing simple signing API names the parameter “fingerprint” but allows it to match, as gpgme does, against the user ID, including an email address. I don’t really want such a loose matching in the Sequoia API — I think adding extra methods for various lookup mechanisms is better.)

I might have suggested it before, but I would collect errors as a dedicated error type (you can define it easily with thiserror).

All of the values of rejected_key_errors currently get concatenated into a single string that is returned back to Go.

And the Go client, at this moment, doesn’t really need any more granularity: this package does not provide any API to inspect a key, list subkeys, or anything else that would allow the Go client to somehow process the errors or to make decisions based on them. All of that is potentially interesting and could be built for other users, but it’s not something I’m likely to be working on for c/image.

Alternatively, it would be interesting to not just use a single string for localization purposes. Conceptually, I would very much like software to talk my language, but in the container ecosystem as is, everything is English everywhere. Similarly, providing structured errors to build a nice GUI — even if this failure case ever were something a GUI designer would choose to prioritize — is limited by c/image error reporting all using just a Go error (~string provider) type.

Late thought — I’d really argue that a higher-level key choice feature (or even, a higher-level “create a streaming signature from a streaming input” feature?) should exist in Sequoia-PGP, not in callers like this.

Right now, https://docs.rs/sequoia-openpgp/latest/sequoia_openpgp/cert/amalgamation/key/index.html#selecting-keys documents what needs to be done, but it’s an amount of code to copy&paste.