[pkg-gnupg-maint] Bug#851462: Bug#851462: #851462 gpg-agent: a gpg-agent is already running - not starting a new one

[Thomas Dickey]

On Wed, Apr 26, 2017 at 07:28:56PM -0700, Daniel Kahn Gillmor wrote:
> Hi Thomas--
> 
> On Tue 2017-04-25 21:37:46 -0400, Thomas Dickey wrote:
> > Referring to the manual page:
> >
> >          gpg-agent --daemon --enable-ssh-support \
> 
> The above line doesn't appear in the gpg-agent manual page, afaict.  In

It certainly was in the version provided when I wrote the script.

(The most recent manual page has removed that information, trimming
about a third of the manual).

> a modern version of gpg-agent, ssh support is always enabled.
> 
>      The OpenSSH Agent protocol is always enabled
> 
> whether you decide to use it for ssh-agent or whether you decide to use
> a different ssh-agent implementation is up to you, and you can make that
> decision explicit by deciding how you'll set the $SSH_AUTH_SOCK
> environment variable.

It didn't connect to most of the machines I use.  I'm not going to consider
using the feature unless it works with all machines.
 
> > I tried using the ssh-support option, have never seen it work reliably.
> > After some experimentation a few years ago, I came up with this working
> > solution.
> 
> if it never worked reliably, and you found some complex workaround, it's
> entirely possible that upstream fixed the unreliability and was unaware
> of whatever workaround you've chosen to do.  I'm still having a hard
> time following it myself.
> 
> Perhaps using it as currently expected by upstream (and removing complex
> workarounds) will be the most fruitful result for you.

no - if it's not interoperable with the different machines I use,
it is of no use to me.  If gpgconf exists only on a few machines,
it's not useful (at best, it would be a choice provided via a
script, but if the script cannot be made reliable because the program
does not return useful error-codes, then that wouldn't be useful).
 
> > The updates for gpg-agent in January broke my solution (and the
> > explanation of the "new" behavior sounds as though it's been "improved"
> > to only work in a desktop session - if that is incorrect, you should
> > provide that information clearly in the README.Debian file - as written
> > it does not address this bug report:
> 
> you can use gpg-agent without needing a desktop session, but if you need
> interactive prompting, a desktop session is recommended.  desktops are
> good at that kind of interactivity :)

Combining "desktop" and "good" in the same sentence won't lead to
a productive discussion.  Don't go there.
 
> > leaves a lot unsaid.  In my case, there was no desktop session.
> > (The package still depends upon either pinentry-curses or pinentry).
> 
> ok, so you're running from a network console?  from a vt?  some other
> environment?  the more you can help me understand your setup, the better
> i'll be able to help.

You should read the mail.  I am using ssh to connect to a machine where
I want to run gpg-agent.  With the recent change, I can no longer use
gpg-agent.  With Debian for instance, I use it for signing packages.
 
> > hmm - no: I overlooked that.  It's been a couple of years since I put these
> > together.  The "killall" in "wrapssh" is redundant; I'm killing it in
> > "presign" so that I can force it to use pinentry-curses
> 
> if your goal is to force the use of pinentry-curses, and you're on a
> machine without a desktop environment, you should either ensure that
> /usr/bin/pinentry points to pinentry-curses, or you should put
> "pinentry-program /usr/bin/pinentry-curses" into ~/.gnupg/gpg-agent.conf

I'll investigate that (I recall that aspect not working on some systems,
which insisted on using the X version of pinentry, but don't have the
list in my memory).

> > #!/bin/sh
> > # $Id: presign,v 1.2 2014/09/01 14:54:50 tom Exp $
> > # vi:ts=4
> > # Initialize a subshell which will run gpg-agent, sets a variable that we can
> > # use in the initialization to force an gpg-sign prompt.
> 
> You should *not* expect to run multiple concurrent gpg-agents on the
> same GnuPG home directory.  That is explicitly not supported by
> upstream.
> 
> > ... and Debian/testing isn't the only system that I use it on.
> 
> I'm sorry, but i can't support arbitrary scripts that run on arbitrary
> operating systems.  My hands are pretty full with supporting GnuPG on
> debian :/

Likewise, I cannot make Debian a priority.  It has to cooperate with
other development.
 
> > Back to the bug report: what I'm reading is that gpg-agent can no longer
> > be used as documented.
> 
> I still don't see this, sorry.  Can you try to produce the simplest
> possible example that reproduces the problem?
> 
>          --dkg

I'll take a look to add information.

-- 
Thomas E. Dickey <dickey at invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20170427/d7b9e853/attachment.sig>