--passphrase-fd only works when combined with --batch

Lukas Pitschl lukele at gpgtools.org
Wed Aug 6 19:14:36 CEST 2014

Hi Werner, et al,

Am 06.08.2014 um 18:26 schrieb Werner Koch <wk at gnupg.org>:

> You don't need to care about the passphrase-id - leave that to gpg-agent
> and pinentry.  It does a much better job than what one can implement in
> a MUA etc.  With 2.1 this even more important.  2.0 and the gpg-agent
> are more than a decade old.  Stop using such hacks.

We’re very aware that 2.0 and gpg-agent are very old and can’t wait for 2.1 to be released.

> If you need another integration into the GUI, you may want to look at
> what the guardianproject did for Android (pinentry daemon).

We’ll definitely have a look at their implementation. Our request is based on the use case described in the previous email.
Since we want to create a key pair and the revocation certificate in one step, pinentry would popup at least 3 times.
Once for the passphrase for the key being generated, once for the confirmation of the passphrase and once for the revocation certificate to be created. Unfortunately that’s a pretty terrible user experience.
>> Before applying this patch to our MacGPG2 version of gnupg we wanted
>> to know if there’s a specific reason or anything we’re overseeing, why
>> this requirement makes sense.
> I am a bit surprised that you do not use gnupg-devel@ for development
> questions.  It would help to understand that the MacGPG stuff is
> quite different from standard GnuPG.  There are some patches which I
> consider problematic  enough not to suggest gpgtools anymore.

Not posting to gnupg-devel was a mistake, I didn’t think twice and had your email address popping up once I typed „gnupg“, I apologize for that.
It would be great if you could let us know which patches you find problematic. We’ve cleaned up our set of patches quite some time ago, since many were no longer necessary. Those that still exists are pretty Mac centric, but if any of them could be integrated into the upstream version, that would be great.

Off topic, but an interesting question, since quite a few of our users are running into that problem.
Would it very complicated to replace the locking algorithm currently using „link" with a different one?
„link“ doesn’t seem to properly work on network shares.

> Let us please continue a discussion on gnupg-devel at gnupg.org so that the
> public is involved.  Feel free to forward this.
> Shalom-Salam,
>  Werner
> --
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </pipermail/attachments/20140806/5a8b8135/attachment.sig>

More information about the Gnupg-devel mailing list