Mailing List Archive

v2.3 of gnupg for automation?
We’ve been using v1.4 of gnupg because I read in the documentation and user comments and in my testing, that v2.X couldn’t be used in software automation workflows. As I recall from the comments a year or two ago, there was a feature (that seemed intentional) that the passphrase had to be entered manually in a popup window in v2.X. And that even when that was supposedly not required, it still happened occasionally to users, that their automation couldn’t process the file because gnupg v2.X required the manual input.

Can anyone clarify this, or say if this has definitely been removed from v 2.3.3, that manual intervention is no longer required? A new developer has moved to that version in his testing, and it seems to be working for us, but I remember that people said the problem was intermittent before.

Thanks for any assistance!

Rich Hammett
Re: v2.3 of gnupg for automation? [ In reply to ]
> We’ve been using v1.4 of gnupg because I read in the documentation
> and user comments and in my testing, that v2.X couldn’t be used in
> software automation workflows.

This might have been true several years ago, but it isn't true today.

> there was a feature (that seemed intentional) that the passphrase had
> to be entered manually in a popup window in v2.X.

That's true, and is correct. If you're passing a passphrase via the
command line, that passphrase becomes visible to anyone with the
privileges to get a list of processes and arguments. At that point the
passphrase really isn't providing much in the way of security.

> And that even when that was supposedly not required, it still
> happened occasionally to users, that their automation couldn’t
> process the file because gnupg v2.X required the manual input.

I'm unaware of any instance of this being true. I am aware of *many*
instances of people discovering they did, in fact, have a passphrase on
their key after swearing up and down they didn't.
Re: v2.3 of gnupg for automation? [ In reply to ]
On Tue, 26 Oct 2021 18:21, Robert J. Hansen said:

> That's true, and is correct. If you're passing a passphrase via the
> command line, that passphrase becomes visible to anyone with the
> privileges to get a list of processes and arguments. At that point the
> passphrase really isn't providing much in the way of security.

I fully agree.

If, for whatever reasons, a passphrase is required the suggested
workaround is to add

--pinentry-mode=loopback

to the gpg invocation.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: v2.3 of gnupg for automation? [ In reply to ]
On Wed, Oct 27, 2021 at 09:33:16AM +0200, Werner Koch via Gnupg-users <gnupg-users@gnupg.org> wrote:

> On Tue, 26 Oct 2021 18:21, Robert J. Hansen said:
>
> > That's true, and is correct. If you're passing a passphrase via the
> > command line, that passphrase becomes visible to anyone with the
> > privileges to get a list of processes and arguments. At that point the
> > passphrase really isn't providing much in the way of security.
>
> I fully agree.
>
> If, for whatever reasons, a passphrase is required the suggested
> workaround is to add
>
> --pinentry-mode=loopback
>
> to the gpg invocation.
>
> Salam-Shalom,
>
> Werner

But be warned, loopback doesn't handle password retries after a failure.
If it did, it would be great. But for automation, that shouldn't matter.

cheers,
raf


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users