the logic behind Context.decrypt()'s signature verification looks like it's going to throw an error if *any* signature does not validate.
However, the logic for most applications that pass verify=True is that they need *one* signature to validate -- the rest could be garbage, or signatures using new algorithms that we don't know anything about, or signatures from keys we don't know about yet.
I think the current implementation is brittle, and is prone to cause problems, and the logic probably needs an overhaul.
furthermore, if a list of keys is passed to verify=, the logic says that a signature from each key is needed. that's fine, but the current logic is that *even if that's the case*, an additional (spurious, broken, or noisy) signature will cause the decrypt operation to throw an error.
This function should be less brittle, and the test suite should exercise it (maybe by making someting that has two signatures: one of them a deliberately broken, but the other one valid).