On 21/01/15 13:24, Guilhem Moulin wrote:
On Wed, 21 Jan 2015 at 11:12:44 +1300, Ewen McNeill wrote:
- MacPorts (OS X) (gpg 1.4.18): works _without_ sderr redirected, fails with
stderr redirected (no output, exit code 1), unless GPG_TTY is set then it
works again.
Wow that's odd.
I agree, it's pretty odd. My best guess is that there must be a code
path along the lines of "do we have a way to tell the user about
Important Information", and it's failing out if it does (ie, stderr
redirected, no GPG_TTY to re-open to send messages). But I don't know
why it's OS X specific/MacPorts specific/whatever. And "just exit,
error code 1" is hardly the most graceful way to handle it.
FTR, I've just verified it still happens like that (on OS X) even if I
move ~/.gnupg/gpg.conf aside, so it doesn't seem to be specific to my
gpg config either (I had wondered if having "use-agent" in there was
needed to trigger it, but apparently not).
I can't remember of a reason to redirect stderr, and right now it
doesn't seem like a good idea to me.
My best guess when trying to read the caff code was that it was done at
that point to hide gpg saying it couldn't find a key. But I think for
most reasonable use cases that shouldn't be reported often, and for most
cases where it is the user probably wants to see gpg report that anyway
(to help them figure out what is going wrong).
I'm a bit reluctant to modify the
environment though, especially since it's a weird behavior of GnuPG –
and OSX specific :-P — IMHO.
FWIW, I wasn't suggesting that caff should modify the environment. Just
issue a warning (eg, like the one about Mail::Mailer having config that
may or may not be right).
Eg, (completely untested; adjust to taste)
if (defined($ENV{MACHTYPE}) &&
$ENV{MACHTYPE} =~ /apple/ && ! defined($ENV{'GPG_TTY'})) {
warn "warning: Certain gpg actions may fail if GPG_TTY is not set, ",
"causing silent caff failures.\n";
}
But maybe there should be some other conditional on it (eg, if it's a
gpg build option that is the real trigger). (FTR: $MACHTYPE =
x86_64-apple-darwin13 on my OS X 10.9 system.)
So all in all I pushed your patch in r760.
Thanks. For future reference, there seems to be at least one other set
of gpg commands that caff uses (after the keys are signed, to figure out
what to send) which also fails without GPG_TTY set, but I didn't debug
that one as thoroughly once I'd guessed that setting GPG_TTY was a
viable workaround.
My blog post about caff on OS/X may possibly help someone else running
into the same issue:
http://ewen.mcneill.gen.nz/blog/entry/2015-01-19-keysigning-with-caff/
(and it also has a reasonable guide to Mail::Mailer settings for doing
SMTP Auth to an external mail server.)
Ewen
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
