On Tue, Apr 25, 2017 at 05:55:18PM -0400, Daniel Kahn Gillmor wrote: > Hi Thomas-- > > I'm sorry, but i don't understand what you're trying to do here. I'm > re-closing this bug report (#851462) because it doesn't seem to be > related to the original report anyway, other than the string "gpg-agent > is already running" appearing in both of them. > > I've asked you some questions below about what you're trying to do -- > feel free to open a new bug report when answering them with a clearer > description (or to reopen this one again if you're sure this is the same > issue).
You should reopen it.
> On Sat 2017-02-11 19:51:29 -0500, Thomas Dickey wrote:
> > It's broken, and recently. I noticed this about a week ago.
> >
> > On my machines, I mostly use ssh to connect, and have a script which
> > ties together gpg/ssh, using gpg-agent. I do this to get the keys
> > for both in - package signing and network connections.
>
> "to get the keys for both in" what?
both means two:
1 = ssh
2 = gpg
Referring to the manual page:
gpg-agent --daemon --enable-ssh-support \
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.
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:
gnupg-agent (2.1.18-1) unstable; urgency=medium
If your machine is configured with system user session management,
gpg-agent will be managed automatically by systemd's user sessions on
machines configured with use systemd. Please consider installing the
packages that the gnupg-agent package Suggests:, and see
/usr/share/doc/gnupg-agent/README.Debian for more details.
and
Users who don't want systemd to manage their gpg-agent in this way for
all future sessions should do:
systemctl --user mask --now gpg-agent.service gpg-agent.socket
gpg-agent-ssh.socket gpg-agent-extra.socket gpg-agent-browser.socket
Doing this means that gpg-agent will fall back to its manual mode of
operation. (This decision can be reversed by the user with "unmask"
instead of "mask")
leaves a lot unsaid. In my case, there was no desktop session.
(The package still depends upon either pinentry-curses or pinentry).
> > Here's the script:
> >
> > #!/bin/sh
> > # $Id: wrapssh,v 1.9 2015/12/21 09:47:59 tom Exp $
> > # vi:ts=4 sw=4
> > # Initialize a subshell which will run ssh-agent, sets a variable that we
> > can
> > # use in the initialization to force an ssh-add prompt.
> >
> > unset SSH_AGENT_PID
> > unset SSH_AUTH_SOCK
> > unset SSH2_AUTH_SOCK
> > unset SSH2_AGENT_PID
> >
> > if test -f /usr/bin/ssh-agent
> > then
> > SSH_ADD="passphrase"
> > export SSH_ADD
> > if test -f /usr/bin/gpg-agent && test -f /usr/bin/pinentry-curses
> > then
> > killall gpg-agent 2>/dev/null
> > ssh-agent presign
> > else
> > ssh-agent $SHELL
> > fi
> > fi
>
> why are you doing "killall gpg-agent" ? what do you hope to gain from that?
>
> what is "presign" ? is that the script below?
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
#!/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.
unset GPG_ADD
if test -f /usr/bin/gpg-agent && test -f /usr/bin/pinentry-curses
then
GPG_ADD="${GNUPGHOME:=HOME}/.gpg-agent-`hostname`"
export GPG_ADD
pgrep gpg-agent
killall gpg-agent 2>/dev/null
OPTS="--csh"
OPTS="$OPTS --pinentry-program /usr/bin/pinentry-curses"
OPTS="$OPTS -vvv --debug-level 8 --debug-all"
PROG=$SHELL
/usr/bin/gpg-agent --log-file /tmp/gpgagent.log --daemon $OPTS
--write-env-file $GPG_ADD $PROG
fi
... and Debian/testing isn't the only system that I use it on.
> > ...and it calls back with a new shell (tcsh in my case) to activate this:
> >
> > if ( $?GPG_ADD ) then
> > setenv GPG_TTY `tty`
> > unsetenv GPG_ADD
> > echo "GPG-signing on $GPG_TTY ..."
> > if ( -e /usr/bin/gpg ) then
> > echo | gpg -s >/dev/null
> > else
> > echo | gpg2 -s >/dev/null
> > endif
> > echo "...GPG-signing"
> > endif
> > if ( $?SSH_ADD ) then
> > echo "prompt $SSH_ADD"
> > unsetenv SSH_ADD
> > ssh-add
> > endif
>
> the trace (below) doesn't seem to trace into this stuff, does it? I
> don't speak tsch fluently, and i don't understand what the SSH_ADD and
> GPG_ADD environment variables are trying to do here. can you explain?
It's checking if the variable is set.
> > With the newly broken package, I don't get a gpg-prompt.
> > Ditto for ssh-prompt. What I get is this (turning on the trace):
> >
> > ~ (101) sh -x wrapssh
> > + unset SSH_AGENT_PID
> > + unset SSH_AUTH_SOCK
> > + unset SSH2_AUTH_SOCK
> > + unset SSH2_AGENT_PID
> > + test -f /usr/bin/ssh-agent
> > + SSH_ADD=passphrase
> > + export SSH_ADD
> > + test -f /usr/bin/gpg-agent
> > + test -f /usr/bin/pinentry-curses
> > + killall gpg-agent
> > + ssh-agent presign
> > gpg-agent[1791]: reading options from '/users/tom/.gnupg/gpg-agent.conf'
> > gpg-agent[1791]: WARNING: "--write-env-file" is an obsolete option - it has
> > no effect
> > gpg-agent[1791]: enabled debug flags: cache ipc
> > gpg-agent: a gpg-agent is already running - not starting a new one
> > gpg-agent: secmem usage: 0/65536 bytes in 0 blocks
> >
> > By the way, I don't have a gpg-agent.conf (so that's another error).
>
> Are you saying that /users/tom/.gnupg/gpg-agent.conf doesn't exist, but
> gpg-agent is somehow claiming that it does?
no - I misread a message (there's an empty file created for an older
version of gnupg).
Back to the bug report: what I'm reading is that gpg-agent can no longer
be used as documented.
--
Thomas E. Dickey <dic...@invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net
signature.asc
Description: Digital signature
