pinentry-curses can be forced to loop endlessly

Steffen Nurpmeso sdaoden at yandex.com
Mon Aug 25 15:17:36 CEST 2014


This is the fourth try to get through to this list.
I even subscribed to get it through, but still some black list hits first
and excludes anyone from a large provider.

Date: Mon, 18 Aug 2014 12:45:08 +0200
From: Steffen Nurpmeso <sdaoden at yandex.com>
To: gnupg-devel at gnupg.org
Subject: pinentry-curses can be forced to loop endlessly

Hello,

the bug i report here was not present in v2.0.24 (i think, looking
at the ArchLinux package history [1]) but then came into existence
with v2.0.25 and is still present in the new package that uses
v2.0.26.

  [1]
<https://projects.archlinux.org/svntogit/packages.git/log/trunk?h=packages/gnupg>

I am still (see ArchLinux bug report [2]) too lazy to find
a different way to reproduce it, so this example assumes the
default ArchLinux mailx(1) (v14.7.2 or later) (or CRUX-Linux or
Void Linux packages; or download S-nail directly [3]):

  [2] <https://bugs.archlinux.org/task/41193>
  [3] <https://downloads.sourceforge.net/project/s-nail/s-nail-14_7_6.tar.xz>

  $ eval `gpg-agent --daemon \
    --pinentry-program=/usr/bin/pinentry-curses \
    --max-cache-ttl 99999 --default-cache-ttl 99999`
  $ echo PASS > /tmp/.pass
  $ gpg -e /tmp/.pass
  $ cat > /tmp/t.rc <<__EOT
  set v15-compat
  set smtp=nobody at localhost
  set agent-shell-lookup='gpg -d /tmp/.pass.gpg'
  __EOT
  $ echo bla|MAILRC=/tmp/t.rc mailx/s-nail -n -dvv -s sub du at auch
  ..^C to interrupt here..

This should leave an endlessly looping pinentry-curses after
interruption around which needs to be kill(1)ed with -QUIT
explicitly.  The bug only occurs if S-nail is used (and thus
pinentry-curses is run) as part of a pipe, just as shown.

P.S.: i am not subscribed, but cannot say anything more anyway.

--steffen




More information about the Gnupg-devel mailing list