gpg 2.1 gpg-agent over ssh

[Ximin Luo]

(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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150328/d5a0e351/attachment.sig>