On Wed, 21 Jan 2015 at 15:52:45 +1300, Ewen McNeill wrote:
> 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.)Yeah, it'd be great to dig that further. So far I only grepped the GnuPG source for "must be set in shell", but it didn't help. I guess the next step would be to mail gnupg-de...@gnupg.org, at least if the culprit is not the OSX maintainer (I dunno how things work there; assuming these macports are not built by upstream). >> 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. Alright. How about an error then? I mean, caff tends to produce a somewhat verbose output, and it's easy to overlook warnings (there has been some complaints about that in the past). > 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.) Great. The manpage includes some of it already, but TBH I didn't know SSL_CERT_DIR/SSL_CERT_FILE would affect the server authentication. -- Guilhem.
signature.asc
Description: Digital signature
