Re: GnuPGv2 & 'pinentry' on Linux w/ remote access

[Sander Smeenk via Gnupg-users]

Quoting Ryan Beethe (r...@splintermail.com):

> I also was frustrated with how GPG pinentry worked by default. 
> What I did was write a custom pinentry wrapper, which I call rpinentry.
> It just dispaches either the curses-based pinentry or a gui pinentry
> based on the environment variable PINENTRY_USER_DATA which is read by
> gpg and passed to the pinentry program

I remembered i never followed up on this thread anymore.
Mostly because i had to make sure the setup now works as intended.
And it does.

Ryan, thank you so much for the pinentry wrapper idea / env-vars trick.

I still think it's a stupendous amount of effort to make this work but
at least it does. From vim, from mutt, from Ansible, on my urxvt
terminals, through ssh, anything that needs my GPG key(s) can now
prompt me for passwords.

Thanks a bundle.

For the mailinglist archives, see the previous post(s) by Ryan in this
thread for a working solution to this problem!

Regards,
-Sndr.
-- 
| aibohphobia - fear of palindromes.
| 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7  FBD6 F3A9 9442 20CC 6CD2

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

Re: GnuPGv2 & 'pinentry' on Linux w/ remote access

[Werner Koch]

On Tue,  7 Nov 2017 14:45, gnupg-users@gnupg.org said:

> Could you elaborate on the 'why' part of this enforced pinentry usage
> with GnuPG? It wasn't mandatory in 1.x, now it's forced on us.

It is definitely not new.  GnuPG 1.9 was released 14 years ago (it was
renamed to 2.0 2.0 11 years ago).  It has been used at quite some places
right away from that time on.  The new thing with 2.0 was the
modularized system: The private keys were only managed and accessible by
gpg-agent and gpgsm (gpg for S/MIME) used it this way.

Unfortunately it took until the summer of 2010 before I was able to port
gpg to use the same system as gpgsm and let gpg-agent handle the private
keys.  (Before that gpg used gpg-agent only for passphrase caching.)

Not having to care about private keys in gpg allowed us to remove a lot
of semi-duplicated code from gpg.  This instantly fixed the long
standing import/merging of secret key bugs.

For an architectural point of view gpg-agent can be viewed as a token
which can be accessed only via a well defined API.  gpg does not take
precautions against leaking secret keys.  The actual code to do secret
key operations (decrypt, signing) is done only at one place so that gpg
and gpgsm, and other possible crypto protocols share the same code.

Smartcard access is unified - gpg, gpgsm, and ssh can use the same
smartcard.

gpg-agent can be theoretically be run under a different account.
gpg-agent can actually be run on a remote machine, so that you don't
need to have a secret key on a server but delegate that work to a
desktop box or even a box which is used as a HSM.

The drawback is that application don't need to handle passphrases
anymore.  However, I would call that a huge benefit because applications
are relieved from handling the sensitive passphrase and can let another
process (pinentry) do that on demand from gpg-agent.  On X this works
very well, with curses it is more complicated and needs some adjustments
(or hitting Ctrl-L).  On Windows it was easy as well but later got
complicated due to new Windows security measurements so that there is a
small chance that the pinentry won't pop up but blonk only in the
taskbar.

While preparing for the 2.1 release, we decided to add a loopback mode
to gpg-agent/gpg/gpgsm so that instead of writing one's own loopback
pinentry it is in most cases possible to keep on using existing code
which expects to handle the passphrase.  Adding --pinentry-mode=loopback
to the gpg invocation does this.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpoHMZiTGvLJ.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GnuPGv2 & 'pinentry' on Linux w/ remote access

[Werner Koch]

On Wed,  8 Nov 2017 12:28, r...@splintermail.com said:

> Yes, I reset my gpg-agent (killall -1 gpg-agent) each time, and was
> prompted with a pinentry prompt each time.

[ Please use "pkill -HUP gpg-agent" and never ever killall - which has,
  aehm, funny effects on other Unices. ]

  gpgconf --reload gpg-agent

is the suggest way to reload the gpg-agent configuraion and flush the
caches.

> Hm... now that I think about it I think the pinentry prompt has been
> broken in my vim with that plugin for some time (due to improper

Not sure what your problem is but nevertheless here this hint: When
calling gpg you should watch the status fd (commonly stderr,
"--status-fd 2") for a line

  [GNUPG:] PINENTRY_LAUNCHED

and set a flag to redraw your screen after gpg returned.  The other
approach would be to write an vim-internal pinentry in the same way the
pinentry-emacs pinentry works.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpbe2jaJS7EA.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GnuPGv2 & 'pinentry' on Linux w/ remote access

[Ryan Beethe]

On Wed, Nov 08, 2017 at 10:50:45AM +0100, Sander Smeenk via Gnupg-users wrote:
> Quoting Ryan Beethe (r...@splintermail.com):
>
> > Well... it happens that when I copy your script to my archlinux
> > machine, everything works fine.
>
> Are you sure your key wasn't already unlocked in the gpg-agent?

Yes, I reset my gpg-agent (killall -1 gpg-agent) each time, and was
prompted with a pinentry prompt each time.

> > Personally, I use a plugin (https://github.com/jamessan/vim-gnupg) and
> > I have never had problems.  Then in my ~/.vimrc, I just had to set:
> > let GPGUsePipes=1
> > let GPGDefaultRecipients=['my.em...@address.com']
>
> Wow! Quite some code for decrypting a file!
> I'll give it a shot after i learn how to use that beast.

Hm... now that I think about it I think the pinentry prompt has been
broken in my vim with that plugin for some time (due to improper
handling of stderr from the looks of it).  It just hasn't bothered me
because I almost never use vim until after I have entered the gpg
password for something else.

So it might be worth a shot but I can't make any promises.

Ryan

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

Re: GnuPGv2 & 'pinentry' on Linux w/ remote access

[Sander Smeenk via Gnupg-users]

Quoting Ryan Beethe (r...@splintermail.com):

> Well... it happens that when I copy your script to my archlinux
> machine, everything works fine.

Are you sure your key wasn't already unlocked in the gpg-agent?


> It also happens that when I copy your script into my ubuntu machine, I
> had to change both references of `gpg` to `gpg2`, [ .. ]

Yes, thanks for that hint but it is not my case.
I made the deliberate step and now only use GnuPG 2.x


> Personally, I use a plugin (https://github.com/jamessan/vim-gnupg) and
> I have never had problems.  Then in my ~/.vimrc, I just had to set:
> let GPGUsePipes=1
> let GPGDefaultRecipients=['my.em...@address.com']

Wow! Quite some code for decrypting a file!
I'll give it a shot after i learn how to use that beast.


Rgds,
Sndr.
-- 
| It’s hard to explain puns to kleptomaniacs
| because they always take things literally.
| 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7  FBD6 F3A9 9442 20CC 6CD2

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

Re: GnuPGv2 & 'pinentry' on Linux w/ remote access

[Dan Kegel]

On Tue, Nov 7, 2017 at 5:45 AM, Sander Smeenk via Gnupg-users
 wrote:
> Could you elaborate on the 'why' part of this enforced pinentry usage
> with GnuPG? It wasn't mandatory in 1.x, now it's forced on us.
>
> Where did that come from?
> What problem did it solve?

I'm curious, too.

It sure makes scripting hard.
- Dan

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

Re: GnuPGv2 & 'pinentry' on Linux w/ remote access

[Ryan Beethe]

Well... it happens that when I copy your script to my archlinux machine,
everything works fine.

It also happens that when I copy your script into my ubuntu machine, I
had to change both references of `gpg` to `gpg2`, since in ubuntu gpg is
not the same program as gpg2.  I also would find it convenient to add a
`--default-recipient-self` to the `gpg2 -ea` line, but maybe that's just
me.  If the same change works for you, perhaps you have an
"alias gpg=gpg2" in your ~/.bashrc, causing your shell to behave
differently that vim?

Personally, I use a plugin (https://github.com/jamessan/vim-gnupg) and I
have never had problems.  Then in my ~/.vimrc, I just had to set:

let GPGUsePipes=1
let GPGDefaultRecipients=['my.em...@address.com']


Ryan

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

Re: GnuPGv2 & 'pinentry' on Linux w/ remote access

[Sander Smeenk via Gnupg-users]

Quoting Ryan Beethe (r...@splintermail.com):

> I think my setup might be almost a drop-in fix for your gpg-over-ssh
> issue, although you will have to figure out where to set the
> environment variable for your particular window manager.

Thanks for your tips and tricks. It's the less bodgy version of the
"wrapper" i wrote. I've adapted them to my system and it seems this is
actually working for the remote-ssh-on-a-system-running-X issue.

However; i still can't use 'gpg -qd' in vim like so:

| augroup GPGEncrypted
| au!
| au BufReadPre,FileReadPre  *.asc,*.gpg set viminfo=
| au BufReadPre,FileReadPre  *.asc,*.gpg set noswapfile
| au BufReadPre,FileReadPre  *.asc,*.gpg set bin
| au BufReadPre,FileReadPre  *.asc,*.gpg let ch_save = |set ch=2
| au BufReadPost,FileReadPost*.asc,*.gpg '[,']!gpg -qd 2> /dev/null
| au BufReadPost,FileReadPost*.asc,*.gpg set nobin
| au BufReadPost,FileReadPost*.asc,*.gpg let  = ch_save|unlet ch_save
| au BufReadPost,FileReadPost*.asc,*.gpg execute ":doautocmd 
BufReadPost " . expand("%:r")
| au BufReadPost,FileReadPost*.asc,*.gpg set ff=unix
| au BufWritePre,FileWritePre*.asc,*.gpg '[,']!gpg -ae 2>/dev/null
| au BufWritePost,FileWritePost  *.asc,*.gpg u
| augroup END

It seems pinentry(-curses) doesn't want to start from within vim.

Do you also have any brilliant ideas there?

Rgds,
Sndr.
-- 
| Cat, n.: Lapwarmer with built-in buzzer.
| 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7  FBD6 F3A9 9442 20CC 6CD2

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

Re: GnuPGv2 & 'pinentry' on Linux w/ remote access

[Sander Smeenk via Gnupg-users]

Quoting Werner Koch (w...@gnupg.org):

> > It's rather cumbersome and very dodgy at least. How do others deal with
> > this? Or is everyone using GPG solely in GUI environments nowadays? ;)
> The current develppment version of Pinentry uses this info on Linux to
> to show the process name in the titlebar.

Thanks for your insights and continued efforts to keep our data safe!

Could you elaborate on the 'why' part of this enforced pinentry usage
with GnuPG? It wasn't mandatory in 1.x, now it's forced on us.

Where did that come from?
What problem did it solve?

Thanks again,
-Sndr.
-- 
| Bakers trade bread recipes on a knead to know basis.  
| 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7  FBD6 F3A9 9442 20CC 6CD2


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GnuPGv2 & 'pinentry' on Linux w/ remote access

[Werner Koch]

On Mon,  6 Nov 2017 22:49, gnupg-users@gnupg.org said:

> It's rather cumbersome and very dodgy at least. How do others deal with
> this? Or is everyone using GPG solely in GUI environments nowadays? ;)

If I want to test the curses Pinentry I simply run

  DISPLAY= gpg ...

and get the curses pinentry even when using an xterm (which is my usual
environment). For example you could start mutt the same way

  DISPLAY= mutt 

and you get the curses.  Drawback is that you won't get an image viewer
either.

Instead of using the envvar you could also invoke gpg like

  gpg --display=none 

which sets the display to none and pinentry will fallback to curses.
Using "none" is not really correct but --display requires an option and
does not like an empty string.

It is also possible to write a pinentry which depends on the actual
program invoking gpg: gpg-agent tells pinentry the pid of the process
invoking gpg; e.g.

  OPTION owner=9798 wheatstone

The current develppment version of Pinentry uses this info on Linux to
to show the process name in the titlebar.



Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpFyNyD0Dna8.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GnuPGv2 & 'pinentry' on Linux w/ remote access

[Ryan Beethe]

Hi Sander,

I also was frustrated with how GPG pinentry worked by default.  In
particular, I *almost* always want to use the ncurses pinentry, unless
through a key shortcut my window manager tries to call gpg (for my
password manager).  But if I want to encrypt a file with mutt, I don't
want a popup!  I hate popups!

What I did was write a custom pinentry wrapper, which I call rpinentry.
It just dispaches either the curses-based pinentry or a gui pinentry
based on the environment variable PINENTRY_USER_DATA which is read by
gpg and passed to the pinentry program, for jobs like this:

#!/bin/sh

if [ "$PINENTRY_USER_DATA" == "terminal" ] ; then
# always use the terminal if one is handy
/usr/bin/pinentry-curses
else
# otherwise DISPLAY info is passed on command line, just forward it
/usr/bin/pinentry-qt "$@"
fi

Then in ~/.gnupg/gpg-agent.conf I set it to be my default pinentry
program:

pinentry-program /path/to/rpinentry

In my ~/.bashrc I have the following two lines:

export PINENTRY_USER_DATA="terminal"
export GPG_TTY=$(tty)

Then in the config file for my window manager, I have the equivalent of:

export PINENTRY_USER_DATA=qt

So this covers all of my bases.  If I do something that calls GPG from a
terminal, I get a curses-based pinentry prompt, because each individual
terminal has PINENTRY_USER_DATA set to "terminal" and GPG_TTY set
properly as soon as it is opened, thanks to my ~/.bashrc.

If my window manager does something which calls GPG (just my password
manager, really), then when the window manager spawns gpg it passes
PINENTRY_USER_DATA set to "qt" and I get a gui popup.

I think my setup might be almost a drop-in fix for your gpg-over-ssh
issue, although you will have to figure out where to set the environment
variable for your particular window manager.

Ryan

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

GnuPGv2 & 'pinentry' on Linux w/ remote access

[Sander Smeenk via Gnupg-users]

Hi!

Some time ago in March i was asking about the way the pinentry works and
i have not yet been able to get this working properly.

I have this vim macro that automatically decrypts and encrypts files
named .gpg. I use this in a terminal through SSH on my server and it
basically pipes a buffer through 'gpg -qd' and 'gpg -ae'.

Recently upgraded that server, and now this does not work anymore.
GPG just exists stating 'No secret key' while running that exact
command on the shell pops up the pinentry thingy and works fine.

Another situation (still) is my PC at work. It has my X session running
mostly always. I access it through SSH too with the same user account
and like to work there, but i can't do anything with GPG on a remotely
connected shell to this machine: The pinentry will consistently pop up
on the X display on that machine instead of the controlling tty (my ssh)
requesting the decryption. 

I've had varying success with exporting GPG_TTY and updatestartuptty,
usually having to restart gpg-agent. To try and keep this workable i
ended up wrapping gpg in a script that sets GPG_TTY, kills all
gpg-agent, starts it, runs gpg...

Then when a tool is not using the wrapper this results in pinentry
plopping up on terminals where i did not expect them, but it is the
terminal i last used the wrapper in.

It's rather cumbersome and very dodgy at least. How do others deal with
this? Or is everyone using GPG solely in GUI environments nowadays? ;)

Any insights welcome!
Sorry for the ranty mail.
I'm a nice guy. Really.

Rgds,
Sndr.
-- 
| Rookworst zonder 'r' is ook worst!
| 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7  FBD6 F3A9 9442 20CC 6CD2

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

Re: GnuPGv2 & 'pinentry' on Linux w/ remote access

[Sander Smeenk via Gnupg-users]

Quoting Peter Lebbing (pe...@digitalbrains.com):

> > | GPG_TTY=$(tty)
> > | export GPG_TTY
> > | eval $(gpg-agent --daemon)
> This is the style for GnuPG 2.0, not for 2.1. 2.1 uses a standard
> socket location and the OpenPGP part of the agent will Just Work(tm).
> You still need something for the SSH part, and for GnuPG v1 if you
> want to have that use the agent.

Thanks for your detailed answer, Peter!

Indeed the pain seems to start with 'enable-ssh-support' and actually
using that interface. It all seems a bit cumbersome with the
updatestartuptty business, broken terminals and other foo.
Unfortunately.
It would have been nice if this actually worked well. ;-)

Currently i *don't* start a "session" gpg-agent on my work station, i
leave starting it to whatever needs it and then it keeps on running.
This works flawlessly it seems even when connecting remotely through SSH.
I only do terminal based GPG interaction...


> If you need the agent for GnuPG v1 [ .. ]

No, i've committed to 'upgrading' to v2 :-)


> Finally, there is the TTY issue. gpg will pass the TTY (or DISPLAY) it
> is running on to the agent, so the pinentry pops up on the TTY/DISPLAY
> where the invoking gpg was running. Unfortunately, SSH has no facility
> for that, so the pinentry pops up on the "startup TTY". When I'm using
> SSH from a terminal running on my graphical X session, it turns out
> just fine: pinentry-gtk-2 pops up on my X screen. When I'm connecting
> remotely, it goes wrong.

Now i read this, it makes sense that ssh isn't properly interfacing with
gpg-agent to make this operation seamless.

Has anyone dared submitting an API-patch to Theo yet? ;-))
 

> Personally before I SSH from a remote session[1], I run:
> gpg-connect-agent updatestartuptty /bye You could put that in a shell
> script with a shorter name...  As long as I don't forget to run the
> gpg-connect-agent command, it always works fine for me.

I tried putting that command in my bashrc but that was a bad idea when
running with enable-ssh-support. Perhaps one could alias 'ssh' (and
friends) to run the updatestartuptty command first...

Hm. Smells fish^Whacky.


> If you use a graphical pinentry and it needs to pop up on a text
> terminal instead, it will automatically fall back to the curses based
> pinentry.

I'm quite certain all my usage of GPG will be in text terminals, but
this is good advise not to mess with that setting and leave it to the
defaults. I believe i put that there when i was fighting with the
enable-ssh-support TTY-issue.


> > With this config, trying to decrypt a GPG-file, everything stalls
> > and undescriptive errors appear after staring at a blinking cursor
> > for quite some time.
> When using gpg?

Yes. But perhaps, considering the insights provided by your earlier
wisdom, gpg (pinentry) might have misbehaved because of the ssh-agent
TTY-issue. Set a broken 'updatestartuptty' and gpg will honour that too?

GPG (pinentry) works just fine when not using enable-ssh-support it seems.


> > Sometimes resulting in *'s being displayed while typing, or letters
> > disappearing from the input altogether.
> I think every other character goes to the terminal [ .. ]
> It's a great way to get half of your password in .bash_history if you just 
> keep on typing.

Hahah. :)


-- 
| 1 1 was a racehorse, 2 2 was 1 2, 1 1 1 1 race 1 day, 2 2 1 1 2
| 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7  FBD6 F3A9 9442 20CC 6CD2


pgp5rNQ_xQ0V5.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GnuPGv2 & 'pinentry' on Linux w/ remote access

[Peter Lebbing]

Hi!

On 22/03/17 15:46, Sander Smeenk via Gnupg-users wrote:
> I'm on Linux and i am not using Unity/Gnome/whatever, so i start X by
> calling 'startx' and it invokes my .xsession that has ...
>
> | GPG_TTY=$(tty)
> | export GPG_TTY
> | eval $(gpg-agent --daemon)

This is the style for GnuPG 2.0, not for 2.1. 2.1 uses a standard socket
location and the OpenPGP part of the agent will Just Work(tm). You still need
something for the SSH part, and for GnuPG v1 if you want to have that use the 
agent.

The following is a variation on the Debian GnuPG v2.1 Xsession script.

If you need the agent for GnuPG v1, include the following snippet:

-8<--->8-
agent_sock=$(gpgconf --list-dirs agent-socket)
export GPG_AGENT_INFO=${agent_sock}:0:1
-8<--->8-

However, note that the way the agent is used is fundamentally different. GnuPG
v1 uses it as a passphrase cache and retrieves the password to decrypt the
private key in secring.gpg on its own. GnuPG v2.1 delegates all private key
operations to the agent entirely, and the agent stores its private keys in
private-keys-v1.d. I'd advise against mixing use of GnuPG v1 and v2.1 at all. If
you don't want GnuPG v1 with use-agent, just omit the snippet.

For SSH, you can use the following snippet:
-8<--->8-
if [ -n "$(gpgconf --list-options gpg-agent | \
  awk -F: '/^enable-ssh-support:/{ print $10 }')" ]; then
export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)
# Launch the agent if it is not already running
gpgconf --launch gpg-agent
fi
-8<--->8-

Note that the agent survives the user session, so if you logout and log back in,
the agent will already be running. gpgconf will not launch it again. And your
keys will still be unlocked if the time to live hasn't expired.

Finally, there is the TTY issue. gpg will pass the TTY (or DISPLAY) it is
running on to the agent, so the pinentry pops up on the TTY/DISPLAY where the
invoking gpg was running. Unfortunately, SSH has no facility for that, so the
pinentry pops up on the "startup TTY". When I'm using SSH from a terminal
running on my graphical X session, it turns out just fine: pinentry-gtk-2 pops
up on my X screen. When I'm connecting remotely, it goes wrong. Personally,
before I SSH from a remote session[1], I run:

gpg-connect-agent updatestartuptty /bye

You could put that in a shell script with a shorter name...

As long as I don't forget to run the gpg-connect-agent command, it always works
fine for me.

> ... where ssh-agent used to be, just before starting the window manager.
> Then i have this gpg-agent.conf:
>
> | enable-ssh-support
> | pinentry-program /usr/bin/pinentry-curses
> | default-cache-ttl 300
> | max-cache-ttl 99

If you use a graphical pinentry and it needs to pop up on a text terminal
instead, it will automatically fall back to the curses based pinentry. So if you
want a graphical pinentry, you can use that as well. I don't think a curses
pinentry would actually work if some graphical program invoked gpg? Where would
it pop up? :-)

Furthermore, note that the ttl entries are only for OpenPGP. SSH keys have their
own entries, ending in -ssh.

> With this config, trying to decrypt a GPG-file, everything stalls
> and undescriptive errors appear after staring at a blinking cursor
> for quite some time.

When using gpg? I only have it with SSH, perhaps you really should switch to a
graphical pinentry. I can imagine gpg telling the agent "I'm running on
$DISPLAY", and then the pinentry cannot work with that. If gpg is not also
telling it on what TTY it is running...

> Then, when i then ^C the ssh command that is seemingly hanging because
> a pinentry popped up on some other workspace's terminal, the pinentry
> program on the unrelated terminal completely messes up said terminal.
>
> Sometimes resulting in *'s being displayed while typing, or letters
> disappearing from the input altogether. In such situations it turns out
> pinentry-curses was still running, even though my shell was also
> interactive.

Yes, this is also what I experience when I forget updatestartuptty and the last
updatestartuptty was on a text terminal.

I also see some of the letters I'm typing, as they are actually passed to the
shell running on the text terminal. I think every other character goes to the
terminal, with the messed up pinentry-curses getting half of the keystrokes and
the others going to your shell. It's a great way to get half of your password in
.bash_history if you just keep on typing. You could at least prevent that last
bit by immediately doing:
$ unset HISTFILE
But it will still end up in swappable memory. So just stop typing your
passphrase already! :-)

> And i haven't even started looking at "how can u use a gpg-agent that
> is already running on a box that i am logging in remotely" 

Re: GnuPGv2 & 'pinentry' on Linux w/ remote access

[Sander Smeenk via Gnupg-users]

Quoting Peter Lebbing (pe...@digitalbrains.com):
> > I'm trying to make the big step from GnuPG v1 to v2 but i'm experiencing
> > agonizing pains caused by the forced use of "pinentry" by gpg-agent and
> > friends, or rather the way the GPG_TTY stuff works?
> The first thing we really need to know before we can give good help, is:
> which version of GnuPG are you using?

Heh. D'oh! This is Ubuntu 16.10's gpg 2.1.15 w/ libgcrypt 1.7.2-beta.

When not starting gpg-agent from .xsession and thus not using it for
ssh-agent emulation, it seems a bit more well-behaved. I have yet to
run into pinentry trouble, but it is not that often that i use gpg.

Thanks!

-Sndr.
-- 
| Giraffiti: Vandalism spray-painted very, very high.
| 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7  FBD6 F3A9 9442 20CC 6CD2


pgptDyp_Mxbmq.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GnuPGv2 & 'pinentry' on Linux w/ remote access

[Peter Lebbing]

Hi Sndr,

On 22/03/17 15:46, Sander Smeenk via Gnupg-users wrote:
> I'm trying to make the big step from GnuPG v1 to v2 but i'm experiencing
> agonizing pains caused by the forced use of "pinentry" by gpg-agent and
> friends, or rather the way the GPG_TTY stuff works?

The first thing we really need to know before we can give good help, is:
which version of GnuPG are you using?

$ gpg2 --version
gpg (GnuPG) 2.1.18
libgcrypt 1.7.6-beta
[...]

Cheers,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

GnuPGv2 & 'pinentry' on Linux w/ remote access

[Sander Smeenk via Gnupg-users]

Hi,

I'm trying to make the big step from GnuPG v1 to v2 but i'm experiencing
agonizing pains caused by the forced use of "pinentry" by gpg-agent and
friends, or rather the way the GPG_TTY stuff works?

I'm on Linux and i am not using Unity/Gnome/whatever, so i start X by
calling 'startx' and it invokes my .xsession that has ...

| GPG_TTY=$(tty)
| export GPG_TTY
| eval $(gpg-agent --daemon)

... where ssh-agent used to be, just before starting the window manager.
Then i have this gpg-agent.conf:

| enable-ssh-support
| pinentry-program /usr/bin/pinentry-curses
| default-cache-ttl 300
| max-cache-ttl 99

With this config, trying to decrypt a GPG-file, everything stalls
and undescriptive errors appear after staring at a blinking cursor
for quite some time.

So i learned that i could update GPG_TTY from my shellrc by doing...

| GPG_TTY=$(tty)
| export GPG_TTY
| gpg-connect-agent updatestartuptty /bye >/dev/null

... every time a new shell spawns. This kind-of works.
At least the pinentry pops up in a terminal.

For GPG-related commands, the pinentry seems to pop-up at the terminal
that is running a GPG-related command, but trying to use ssh randomly
pops the pinentry in a terminal unrelated to where i am running ssh.
Probably the terminal that was started last?

Then, when i then ^C the ssh command that is seemingly hanging because
a pinentry popped up on some other workspace's terminal, the pinentry
program on the unrelated terminal completely messes up said terminal.

Sometimes resulting in *'s being displayed while typing, or letters
disappearing from the input altogether. In such situations it turns out
pinentry-curses was still running, even though my shell was also
interactive.

I can't fathom what i am doing wrong but i must be doing something wrong.

Any tips?

And i haven't even started looking at "how can u use a gpg-agent that
is already running on a box that i am logging in remotely" yet, sort of
what 'keychain' can do with ssh-agent.

Regards,
-Sndr.
-- 
| How can there be self-help "groups"?
| 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7  FBD6 F3A9 9442 20CC 6CD2

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