On Wed 2016-07-13 16:04:17 +0200, Gaute Hope wrote:
Ok, that makes sense. That explains why the GMimeCertificate structure has more fields set when verifying signatures. I would have to fetch the rest of the information manually, keeping in mind that it may be forged.
right. unless you really have a use case for that information, and you've thought carefully about how to present to the user or some sensible upper layer it in all its uncertainty and ambiguity, you're probably better off just leaving it alone.
When encrypting for (or decrypting from) pubkeys that you either do not have or that are not locally trusted the gpg2 instance will ask interactively whether to continue anyway.
a few clarifications might be in order here: * if you don't have the public key you're trying to encrypt to, gpg will just fail, it won't ask you whether you should continue. (if you're trying to encrypt to multiple keys and you have at least one but not all, maybe that's the case you're running into?) * when you say "locally trusted" i think you mean "are considered valid" -- what matters is the mapping between User IDs and keys, not whether the user actually trusts the keyholder to make new certifications. * if you're using gpg programmatically, you should be sending --batch no matter what. in that case, there should be no interactive questions. If you find a place where you're supplying --batch and there are interactive questions, that's a bug that should be reported to the gnupg folks upstream.
Thanks for the discussion - that cleared up quite a bit!
thanks for thinking it through with me. i've learned from the
conversation too.
--dkg
Attachment:
signature.asc
Description: PGP signature