[MacPorts] #46601: caff cannot find public keys due to stderr redirection

[MacPorts]

#46601: caff cannot find public keys due to stderr redirection
----------------------------+----------------------
  Reporter:  macports@…     |      Owner:  cal@…
      Type:  defect         |     Status:  assigned
  Priority:  Normal         |  Milestone:
 Component:  ports          |    Version:  2.3.3
Resolution:                 |   Keywords:
      Port:  signing-party  |
----------------------------+----------------------

Comment (by macports@…):

 That's a very insightful question, it turns out:

 {{{
 ewen at ashram:~$ echo $PATH
 /Users/ewen/.bin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin
 ewen at ashram:~$ which gpg
 /Users/ewen/.bin/gpg
 ewen at ashram:~$
 }}}

 where it turns out that `~/.bin/gpg` is an old shell script wrapper I
 clearly put in Some Time Ago (tm) and then forgot about over the years,
 which tries to auto-set `GPG_TTY` if it is not set... by looking at stdin
 and stderr.  So if neither stdin nor stderr points at a tty it is unable
 to set `GPG_TTY`.  (IIRC I ignored stdout because gpg may well be in a
 pipeline.)

 In particular that solves the mystery for where the error message is
 coming from:

 {{{
   if [ "$GPG_TTY" = "not a tty" ]; then
     echo "GPG_TTY must be set in shell (cannot determine automatically)."
 >&2
     exit 1
   fi
 }}}

 which is triggered when neither stdin or stderr is a tty (''and''
 `GPG_TTY` is not already set).  (And in hindsight explicitly redirecting
 the error message to /dev/null when it's only triggerable if stderr is
 redirected to /dev/null is probably a.... less useful reflex!)

 Looking at the date on that particular wrapper script (and the comments in
 it for why it exists) this appears to be a pretty old (ie, many years)
 work around for other issues that I was seeing.

 So... the problem turns out to be at least partly self inflicted.  But the
 trigger condition of redirecting stdin ''and'' stderr to `/dev/null` does
 mean it's rather hard to debug.  So picking up the eventual upstream
 (Debian) `caff` patch seems useful for other issues.

 However at this point, closing this ticket and eventually picking the up a
 later upstream caff with the fix, is the best resolution.

 Thanks for pointing me in the right direction.

 Ewen

-- 
Ticket URL: <https://trac.macports.org/ticket/46601#comment:8>
MacPorts <https://www.macports.org/>
Ports system for OS X