Daniel Kahn Gillmor writes on juli 13, 2016 19:31:
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.
Yes, I think it is interesting information - but it must be made clear that it cannot be trusted. My main use-case is for composing messages and showing who the message has been encrypted for.
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?)
Yes. I always have some of the keys, since I am always encrypting to myself as well. The issue also happens if the key is not trusted/verified.
* 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.
Yes, I agree. But the terms seem to be mixed up in gpg and gmime docs, the always-trust option would have the same effect. Or the always-trust just has the same effect. I need to read up on the PGP terminology again..
* 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.
At this point I have only used gpg through gmime. I was assuming gmime used '--batch', but I am getting suspicious after these errors.
Thanks for the discussion - that cleared up quite a bit!thanks for thinking it through with me. i've learned from the conversation too.
Cheers, Gaute
Attachment:
pgp2ni_5SUNHK.pgp
Description: PGP signature