can you add an explicit test please?

can you add an explicit test please?

good point. done.

So while I understand the priniciple fix, I am not 100% convinced this should be merged as is. My current concern is , this means ending up with a bunch of signatures that are invalid/not verified on these calls, without any information about it.

After thinking for a while, I'm unsure that we can do any better than this.

Third party signatures can - by definition - not be verified without having signer's key material at hand (in the context of this call, we definitely don't).

We could drop third-party signatures during verification, but that would be surprising for users who would like to keep them.

Or we could make the TPK data structure more elaborate, and store third-party signatures in a separate place. However, that would be a relatively big deviation from what the OpenPGP RFCs outline, and move rPGP further towards "high level behavior" (away from more or less straightforwardly doing just the things the RFC explicitly outlines).

So my current sense is that this PR is the best way forward, and that your concern is just another way of saying: "using OpenPGP through a low level API is scary, because OpenPGP is weird" (which I fully agree with 😅)

All of that said, if we do merge this change, we should make sure that Delta is able to handle TPKs that contain third-party signatures, even in the most unfortunate packet orderings.

I'm not sure if Delta looks into signature packets at all, though?

So, to make this better I would suggest this:

• change the signature of the verify function to also pass a list of other keys, that will be used to to verify signatures
  • if a signature is invalid, return an "invalid signature" error
  • if a signature is missing a key, return a "missing key for signature" error, this should only be returned if all other signatures are actual valid

This would allow callers like deltachat to accept missing keys, if they want to, without hiding the fact that there are potentially invalid signatures

That sounds like a reasonable direction, although it is a bit unfortunate that the "missing key for signature" case would use a Rust Error as a sort of warning.

I still wonder if it wouldn't be better to filter out elements that we don't "trust" (such as signatures that we can't verify, because we don't have the public key for them at hand). That would probably be a bigger change to the API, but I feel like it would be a smaller change in terms of the intended API semantics between rPGP and Delta Chat?

I still wonder if it wouldn't be better to filter out elements that we don't "trust"

I think that is very bad, and problematic behaviour, maaaybe at a very high level, but not at this low level, you want to make sure everything is accounted for by default

After some more discussion, I increasingly think that this type of API is hard to provide in a way that is general, defensive, and reasonable for callers.

It might be better to deprecate/remove this "medium level" verify API, or at least not to try and extend it beyond its current state.

Instead rPGP could document/suggest approaches how applications can cover their specific requirements with the existing low level primitives (e.g. something like key.bindings().map_res(|binding| binding.verify())).