Jeffrey Stedfast writes on juli 14, 2016 4:42:
On 7/13/2016 7:22 PM, Daniel Kahn Gillmor wrote:This is arguably a bug in gmime -- shouldn't all these requests use --batch?It's possible. When is Gaute having these "hangs"? I did not see mention of what operation was being done.
This is what I do through gmime with GPG:
* Set up gpg context
- always_trust = False
- use_agent = true
* Fetch a pub key for a recipient
- Do not locally sign it (--lsign)
- Do not have always-trust in your gpg config
* Encrypt message for recipient using [0]:
*out = g_mime_multipart_encrypted_new ();
GError *err = NULL;
int r = g_mime_multipart_encrypted_encrypt (
*out,
in,
gpgctx,
sign,
userid.c_str (),
GMIME_DIGEST_ALGO_DEFAULT,
recpa,
&err);
* GPG will now ask whether to continue encrypting for 'untrusted' key in
the terminal if there is one.
You could simulate this on the command line with:
$ gpg -e -r untrusted-receiver file
[strange ~] $ gpg -e -r esvn DSC_0021.JPG
gpg: AD4C1217CBD6E73E: There is no assurance this key belongs to the named user
sub elg2048/AD4C1217CBD6E73E 2005-03-05 esvn (Primary eSvn key) <esvn umputun com>
Primary key fingerprint: 70AA 2F8E 9C99 200C 82F7 737E B031 86E8 D744 F044
Subkey fingerprint: 6BC1 9C9C ABF1 752C D967 AAC4 AD4C 1217 CBD6 E73E
It is NOT certain that the key belongs to the person named
in the user ID. If you *really* know what you are doing,
you may answer the next question with yes.
Use this key anyway? (y/N)
If I use --batch (without --yes).
[strange ~] $ gpg -e --batch -r esvn DSC_0021.JPG gpg: AD4C1217CBD6E73E: There is no assurance this key belongs to the named user gpg: DSC_0021.JPG: encryption failed: Unusable public key
If I trust the key, gpg is quiet:
[strange ~] $ gpg -e -r gaute DSC_0021.JPG [strange ~] $
Encrypting and Verifying should use --batch --yes from what I can tell. The other operations do not, probably because it broke gpg 1.x somehow (maybe --batch --yes was too aggressive in feeding "yes" to all requests for gpg's input requests?). Of course, it's also possible that I was over optimizing...If it's always safe to pass --batch --yes to gpg, then I have no problem enabling that code always.
I think it would be more appropriate to not use --yes. My understanding is that --batch avoids interactive'ness, while the user can already set always_trust = true if he wants gpg to continue anyway in this case. --yes would perhaps ignore other errors. Regards, Gaute [0] https://github.com/astroidmail/astroid/blob/crypto-2/src/crypto.cc#L184
Attachment:
pgps6h98Xu_Vx.pgp
Description: PGP signature