gpg 2.1 gpg-agent over ssh

[Jim Hansson]

sorry, miss-read your original message to be something like a display
variable that was maybe pointing in the wrong direction.  And mixed up the
command line for gpg with another program so i was thinking --textmode was
for forcing a textmode entry of passphrases.

On Sat, Mar 28, 2015 at 12:42 PM, Ximin Luo <infinity0 at pwned.gg> wrote:

> (back to the list)
>
> No, it doesn't solve it. :(
>
> I am not sure why you think it would solve it... the man page says "Treat
> input  files  as  text and store them in the OpenPGP canonical text form "
> which does not have anything to do with X or the lack of it or tty and
> consoles.
>
> X
>
> On 27/03/15 14:09, Jim Hansson wrote:
> > does not using --textmode solve the non-X case?
> > But should not the normal case when no DISPLAY variable is defined be
> --textmode, I think so, this sounds more looks like you have some weird
> setup, I will try to replicate it tonight.
> >
> >
> > On Fri, Mar 27, 2015 at 1:01 PM, Ximin Luo <infinity0 at pwned.gg <mailto:
> infinity0 at pwned.gg>> wrote:
> >
> >     On 27/03/15 11:38, Ximin Luo wrote:
> >     > When running gpg 2.1.2 over SSH with a secret-key operation, the
> gpg in the ssh client appears to hang.
> >     >
> >     > What is actually happening is that the gpg-agent it's connecting
> to, is running a pinentry that's associated with the display on the desktop
> session the *gpg-agent* is attached to, rather than the ssh client, and
> there's no way for the ssh user to reach this.
> >     >
> >     > $ pgrep -a gpg-agent
> >     > 17902 gpg-agent --homedir /home/infinity0/.gnupg
> --use-standard-socket --daemon
> >     > $ kill -HUP 17902 # flush all secret keys
> >     > $ pgrep -af pinentry
> >     > (exit 1)
> >     >
> >     > $ gpg2 -as <<EOF
> >     > test
> >     > EOF
> >     >
> >     > ^C
> >     > gpg: signal Interrupt caught ... exiting
> >     >
> >     > (exit 130)
> >     > (exit 130)
> >     > $ pgrep -af pinentry
> >     > 22048
> >     > # this process sticks around and you need to kill it manually
> >     >
> >
> >     What's worse - if you don't kill this process, subsequent attempts
> to use secret-key operations (even from the desktop session!) fail because
> I guess gpg-agent queues up pinentry operations, and it's waiting on this
> one.
> >
> >     This wouldn't be obvious to most users.
> >
> >     > But physically going back to the desktop session doesn't show a
> pinentry popup, for some reason.
> >     >
> >     > It's unclear the best way to solve this. Thoughts?
> >     >
> >
> >     A workaround is to use `ssh -X`. I'm not sure if this translates
> into a solution for the original non-X case.
> >
> >     X
> >
> >     --
> >     GPG: 4096R/1318EFAC5FBBDBCE
> >     git://github.com/infinity0/pubkeys.git <
> http://github.com/infinity0/pubkeys.git>
> >
> >
> >     _______________________________________________
> >     Gnupg-devel mailing list
> >     Gnupg-devel at gnupg.org <mailto:Gnupg-devel at gnupg.org>
> >     http://lists.gnupg.org/mailman/listinfo/gnupg-devel
> >
> >
> >
> >
> > --
> > // Jim Hansson
> > // Tel: 0722019664
> > // http://se.linkedin.com/in/jimhansson
> > // ===== GPG =====
> > // key: 9AA942ED
> > // Fingerprint: 6947 5F70 7D4E D55D FCE2
> > //                      3A1E 0C21 D543 9AA9 42ED
> > // ===============
>
>
> --
> GPG: 4096R/1318EFAC5FBBDBCE
> git://github.com/infinity0/pubkeys.git
>
>
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
>
>


-- 
// Jim Hansson
// Tel: 0722019664
// http://se.linkedin.com/in/jimhansson
// ===== GPG =====
// key: 9AA942ED
// Fingerprint: 6947 5F70 7D4E D55D FCE2
//                      3A1E 0C21 D543 9AA9 42ED
// ===============
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150328/faa6aca7/attachment-0001.html>