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

MacPorts noreply at macports.org
Tue Jan 20 14:27:58 PST 2015


#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@…):

 After further investigating prompted by the Debian maintainer, the problem
 does appear to be MacPorts (or OS X) specific, and to not involve gpg-
 agent directly.  In particular with the MacPorts version of gnupg, this
 fails:
 {{{
 gpg --trust-model=always --no-auto-check-trustdb --fingerprint --with-
 colons --list-public-keys --no-tty --batch -- E4D3E863 </dev/null
 2>/dev/null
 }}}
 with exit code 1 and no output.  But on Debian unstable, using the same
 gnupg version, the command works and produces the expected output.

 With the MacPorts version it is necessary to do:
 {{{
 GPG_TTY=$(tty) gpg --trust-model=always --no-auto-check-trustdb
 --fingerprint --with-colons --list-public-keys --no-tty --batch --
 E4D3E863 </dev/null 2>/dev/null
 }}}
 (or otherwise have set GPG_TTY) in order to get the expected output ''if''
 stderr is redirected to /dev/null (the command also works ''without''
 GPG_TTY set ''providing'' stderr is ''not'' redirected).

 It does not seem to matter whether GPG_AGENT_INFO is set or not.  (The
 Debian bug has some full command output illustrating this, at
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775702#15)

 At this stage I do not know what is different about the MacPorts/OS X
 build (and/or OS X) to trigger this.

 For reference, these are the versions I have installed from MacPorts at
 present:
 {{{
 ewen at ashram:~$ port installed | grep gnupg
   gnupg @1.4.18_0
   gnupg @1.4.18_1 (active)
   p5.16-gnupg-interface @0.500.0_3 (active)
 ewen at ashram:~$ port installed | grep gpg
   gpg-agent @2.0.26_4+pinentry_mac (active)
   libgpg-error @1.16_0
   libgpg-error @1.17_0 (active)
 ewen at ashram:~$ port installed | grep signing-party
   signing-party @1.1.9_0 (active)
 ewen at ashram:~$
 }}}

 Possibly this will want either (a) a MacPorts-specific work around patch
 like the one I originally posted (but that didn't seem to be sufficient by
 itself), (b) a MacPorts-specific warning patch ("you don't have GPG_TTY
 set, caff may fail") or (c) some investigation of how gnupg is built
 differently in MacPorts from Debian.  But it might be worth waiting and
 seeing if there is any follow up on the Debian ticket first.

 Ewen

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


More information about the macports-tickets mailing list