Package: signing-party
Version: 1.1.4-1
Severity: normal
Initially encountered on OS/X with MacPorts
(https://trac.macports.org/ticket/46601), but reported here
because (a) Debian appears to be the upstream for signing-party/caff
(http://pgp-tools.alioth.debian.org/) and (b) AFAICT by inspection the
same problem would happen on Debian (which I also use), up through the
version in Debian Unstable. (Email generated with reportbug from
representative Debian Stable system.)
When using caff with gpg-agent installed and active, but the GPG_TTY
environment variable is not set, certain operations that caff attempts
to get gpg to do silently fail, which cases caff to issue misleading
error messages. These appear to be primarily the ones where caff is
redirecting stderr to /dev/null (but there may be other cases too).
In particular with GPG_AGENT_INFO=... and GPG_TTY not set, for a
key that _does_ exist, caff is unable to find the key:
-=- cut here -=-
ewen@ashram:~$ caff --keys-from-gnupg -R e4d3e863
[INFO] Key E4D3E863 imported from your normal GnuPGHOME.
[WARN] No public keys found with list-key E4D3E863 (note that caff uses
its own keyring in /Users/ewen/.caff/gnupghome).
[NOTICE] No keys to sign found
ewen@ashram:~$
-=- cut here -=-
The problem goes away (ie, caff finds the key) if (a) the caff source
is edited to not redirect stderr in that situation (eg, diff on
https://trac.macports.org/ticket/46601) or (b) GPG_TTY is set.
Even if that particular problem is worked around, caff's use of gpg to
extract the signed subkeys also fails if gpg-agent is in use, but
GPG_TTY is not used, resulting in caff exiting without offering to email
keys.
By uncommenting trace2 one can see the error report for the latter case:
[trace2] stderr is now GPG_TTY must be set in shell (cannot determine
automatically).
which is what (eventually!) gave me the clue to the underlying cause.
In view of how difficult this is for a user to debug (eg, determine this
is the real cause), especially because caff is deliberately redirecting
stderr to /dev/null and thus hiding the gpg generated error messages
(!!) I think it would be best if caff were to warn about this risk.
Eg, if GPG_AGENT_INFO is set in the environment and GPG_TTY is *not*
set in the environment, then caff should at least issue a warning that
there may be silent failures and unpredictable behaviour (and possibly
should refuse to continue in that situation).
Ewen
-- System Information:
Debian Release: 7.7
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages signing-party depends on:
ii gnupg 1.4.12-7+deb7u6
ii libc6 2.13-38+deb7u6
ii libclass-methodmaker-perl 2.18-1+b1
ii libgnupg-interface-perl 0.45-1
ii libmailtools-perl 2.09-1
ii libmime-tools-perl 5.503-1
ii libterm-readkey-perl 2.30-4+b2
ii libtext-template-perl 1.45-2
ii perl 5.14.2-21+deb7u2
ii qprint 1.0.dfsg.2-2
Versions of packages signing-party recommends:
ii exim4-daemon-light [mail-transport-agent] 4.80-7+deb7u1
ii libgd-gd2-noxpm-perl 1:2.46-2+b1
ii libpaper-utils 1.1.24+nmu2
ii libtext-iconv-perl 1.7-5
ii whiptail 0.52.14-11.1
Versions of packages signing-party suggests:
ii imagemagick 8:6.7.7.10-5+deb7u3
pn mutt <none>
pn texlive-latex-recommended <none>
pn wipe <none>
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
