Daniel Kahn Gillmor writes on juli 13, 2016 15:03:
On Wed 2016-07-13 12:11:16 +0200, Gaute Hope wrote:So a sender could forge the ENC_TO fields? And I would need the senders (or receivers secret key) to detect that? Anyway, I would be sure it is encrypted to me - since I have my own secret key, however GMime does not link the public key information of the master key with that.actually, anyone can forge the ENC_TO fields, since the PKESK is outside of the encrypted data, and the signature is inside it.If this is the case, then it is a good argument for not automatically associating the alleged subkey with the master pub key. Is this a concious decision?I agree that associating full certificates to these forgeable key IDs would be based on some pretty shaky (certainly not cryptographically-sound) assumptions. As for whether it's conscious or not, i would expect that gmime is just populating whatever data it gets from gpg, rather than trying to do a full association, and it's probably re-using the GMimeCertificate object to do so. a GMimeCertificate produced by the result of a successful signature verification would have more of its fields filled in because it is usually populated by GnuPG status lines like: [GNUPG:] GOODSIG 24ECFF5AFF68370A Daniel Kahn Gillmor <dkg fifthhorseman net> [GNUPG:] VALIDSIG EDB2E74F56FCF2B67297B73524ECFF5AFF68370A 2016-07-13 1468414726 0 4 0 1 10 01 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9
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.
On a side note, I get random hangups, presumably when gpg is asking for interactive input.i don't know what "random hangups" means -- can you provide more details? perhaps that belongs in a separate thread though.
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. Unless you set the always_trust option to TRUE on the gpg context. Unless you have a regular TTY this doesn't work very well. It can be avoided by setting always_trust, if there are other cases I'll report back in a separate thread. Thanks for the discussion - that cleared up quite a bit! Regards, Gaute
Attachment:
pgpAJuYCP83Fa.pgp
Description: PGP signature