User Details
- User Since
- Mar 27 2017, 4:48 PM (404 w, 9 h)
- Availability
- Available
Jun 1 2017
@aheinecke thanks! My apologies for not making that clear in the initial report.
@aheinecke Yes, the issue is with INTERFACE_LINK_LIBRARIES not IMPORTED_LOCATION.
May 25 2017
May 17 2017
Yes that fixes it!
Apr 5 2017
@justus no problem. Looks like it works now with 01e84d429aeeb1450012ff0576a6a24de50693c6!
Incidentally, without any of the new commits, it does "work" to reverse the order of make check and make install again.
@justus hmm … still seems to be failing even with the new commits:
Apr 4 2017
Mar 15 2017
Yup! Fix works. Thanks, Justus.
You're welcome. By the way, you may be interested in this PR since you are
obviously a stakeholder in the matter:
https://github.com/Homebrew/homebrew-core/pull/11083
Please feel free to comment/suggest/etc. if you have any thoughts!
Any other suggestions?
Mar 9 2017
4ce4f2f683a17be3ddb93729f3f25014a97934ad allows make check to complete without
the other workaround. So it works as advertised! Thanks, Niibe and Justus.
Mar 2 2017
Thanks to you and thanks to Niibe in advance :)
And it has now passed CI:
https://github.com/Homebrew/homebrew-versions/pull/1536
https://bot.brew.sh/job/Homebrew%20Versions%20Pull%20Requests/1824/
So I've merged the PR.
The patch works!
Here's the referenced crash file:
https://gist.github.com/ilovezfs/ebfccf2515fc7d7952edcc4c13ff8013
Here's what's happening in the system log when the failed test runs:
Mar 2 03:06:53 iMac-TMP com.apple.xpc.launchd[1] (com.apple.auditd[39537]) <Warning>: Endpoint has been activated through legacy launch(3) APIs. Please switch to XPC or bootstrap_check_in(): com.apple.auditd Mar 2 03:06:53 iMac-TMP com.apple.ctkpcscd[39536] <Notice>: SecTaskLoadEntitlements failed error=22 Mar 2 03:06:53 iMac-TMP com.apple.ctkpcscd[39536] <Warning>: Refusing sandboxed PCSC.framework client without com.apple.security.smartcard entitlement Mar 2 03:06:53 iMac-TMP joe[39540] <Warning>: audit warning: soft /var/audit Mar 2 03:06:53 iMac-TMP joe[39541] <Warning>: audit warning: allsoft Mar 2 03:06:54 iMac-TMP joe[39544] <Warning>: audit warning: closefile /var/audit/20170302110453.20170302110653 Mar 2 03:06:54 iMac-TMP com.apple.ctkpcscd[39536] <Notice>: SecTaskLoadEntitlements failed error=22 Mar 2 03:06:54 iMac-TMP com.apple.ctkpcscd[39536] <Warning>: Refusing sandboxed PCSC.framework client without com.apple.security.smartcard entitlement Mar 2 03:06:54 iMac-TMP com.apple.xpc.launchd[1] (com.apple.ReportCrash[39548]) <Warning>: Endpoint has been activated through legacy launch(3) APIs. Please switch to XPC or bootstrap_check_in(): com.apple.ReportCrash Mar 2 03:06:54 iMac-TMP ReportCrash[39548] <Notice>: Saved crash report for scdaemon[39535] version 0 to /Users/joe/Library/Logs/DiagnosticReports/scdaemon_2017-03-02-030654_iMac-TMP.crash
Can you please give us ssh -V, and describe the sandbox environment? Does it
affect which ssh version is used?
It's the system default. There's no other version of ssh that gets installed.
Our own ssh formula is homebrew/dupes/openssh and is explicitly barred from
being used as a dependency by anything else, as is anything else in homebrew/dupes.
10.12.3
robotunicorn ~ # ssh -V
OpenSSH_7.3p1, LibreSSL 2.4.1
10.11.6
iMac-TMP:~ joe$ ssh -V
OpenSSH_6.9p1, LibreSSL 2.1.8
yosemitevm ~ # ssh -V
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
Regarding the sandbox, here's where it's implemented:
https://github.com/Homebrew/brew/blob/master/Library/Homebrew/sandbox.rb
It's invoked as
/usr/bin/sandbox-exec -f /tmp/homebrew20170302-24230-1xmlw7l.sb nice /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/bin/ruby -W0 -I /usr/local/Homebrew/Library/Homebrew -- /usr/local/Homebrew/Library/Homebrew/build.rb /usr/local/Homebrew/Library/Taps/homebrew/homebrew-versions/gnupg21.rb
The contents of the .sb file are as follows:
iMac-TMP:~ joe$ cat /tmp/homebrew20170302-24230-1xmlw7l.sb (version 1) (debug deny) ; log all denied operations to /var/log/system.log (allow file-write* (subpath "/private/tmp")) (allow file-write* (subpath "/private/var/tmp")) (allow file-write* (regex #"^/private/var/folders/[^/]+/[^/]+/[C,T]/")) (allow file-write* (subpath "/private/tmp")) (allow file-write* (subpath "/Users/joe/Library/Caches/Homebrew")) (allow file-write* (subpath "/Users/joe/Library/Logs/Homebrew/gnupg21")) (allow file-write* (subpath "/Users/joe/Library/Developer")) (allow file-write* (subpath "/usr/local/Cellar/gnupg21")) (allow file-write* (subpath "/usr/local/etc")) (allow file-write* (subpath "/usr/local/var")) (allow file-write* (literal "/dev/ptmx") (literal "/dev/dtracehelper") (literal "/dev/null") (literal "/dev/zero") (regex #"^/dev/fd/[0-9]+$") (regex #"^/dev/ttys?[0-9]*$") ) (deny file-write*) ; deny non-whitelist file write operations (allow process-exec (literal "/bin/ps") (with no-sandbox) ) ; allow certain processes running without sandbox (allow default) ; allow everything else
The environment variables themselves are not different between sandboxed and
non-sandboxed builds.
Here's the successful log with --no-sandbox:
https://gist.githubusercontent.com/ilovezfs/a886421569e625d0b7051cf8e9bfea53/raw/77aec417f54ed3d996eb340f826de9d7569088f5/gistfile1.txt
mkdir /run/user/YOURUID
/run is not a thing on macOS. /var/run is but requires root access. The default
socket location on macOS is
iMac-TMP:~ joe$ ls -al /tmp/com.apple.launchd.OWt2QNcw7V total 0 drwx------ 2 joe wheel 102 Mar 1 21:13 . drwxrwxrwt 76 root wheel 2686 Mar 2 00:44 .. srw-rw-rw- 1 joe admin 0 Mar 1 21:13 Listeners
One such directory and socket are created for each user when using ssh.
Note that I had tried hacking in /usr/local/var/run in place of your /run, and
creating the directory, etc., which the test did proceed to use but it didn't
resolve the problem. (I had done that before reporting here.)
Yup! And remember, that was only a <= 10.10 issue, whereas the new "fun" is
across the board, 10.10, 10.11, and 10.12 (probably <= 10.9 too but we don't
test those).
Your T2947 says otherwise. So does T2847. Can you please clarify that?
Sure. I'm referring to 2.1.18 with your subsequent fixes. See
https://github.com/Homebrew/homebrew-versions/commit/8243792932da5b7746bf229d4b63abd7592b21b3
which has the relevant patches (thank you) on the left side of the diff.
macOS 10.10, 10.11, 10.12
They're nearly the same, but T2980 has the workaround for this issue in
place (running make install first), so that it's clear the ssh-import.scm
problem is an independent issue.
Feb 17 2017
dkg thank you. One of the user reporting the issue has confirmed that fixes it:
https://github.com/Homebrew/homebrew-versions/pull/1527#issuecomment-280667350
Feb 16 2017
We have Homebrew users reporting this problem to us.
https://github.com/Homebrew/homebrew-versions/commit/bece3fdbb732bcf646589c051f2f882e2bbf0875#commitcomment-20846337
https://github.com/Homebrew/homebrew-versions/commit/bece3fdbb732bcf646589c051f2f882e2bbf0875#commitcomment-20910048
"I had to revert to 2.1.17, gnupg was unable to access my yubikey with 2.1.18.
The error was "gpg: selecting openpgp failed: Operation not supported by
device". Not sure if I'm the only one with the problem, if not I'd recommend
reverting the version."
Feb 7 2017
Here's the make check verbose=2 log for 2.1.18 on macOS 10.10.5 Yosemite:
https://gist.github.com/ilovezfs/d9de58955697858a1eb3c6d3a5e48bea
And ssh -V:
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
I feel that this is the very same issue as T2847
I assumed they were different issues since this is ssh-import.scm and that was
ssh.scm.
I asked what version of ssh you were using over there, and sadly you
did not react.
Sorry
Additional findings. If I depend on homebrew/dupes/openssh (which is not
actually permissible in homebrew/core, but just for the sake of testing this
here), then the test passes. The homebrew/dupes/openssh formula is 7.4p1, so
this bug appears to be specific to 6.2p2 (possible all of 6.2 or all of 6.x?)
Note this is
yosemitevm:brew brew$ ssh -V OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
Nov 20 2016
The ssh.scm failure is still happening intermittently with 2.1.16
https://bot.brew.sh/job/Homebrew%20Versions%20Pull%20Requests/1733/version=yosemite/console
$ ssh -V
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
Ah I spoke too soon. Just got the ssh.scm:
https://bot.brew.sh/job/Homebrew%20Versions%20Pull%20Requests/1733/version=yosemite/console
No problem. Thanks for looking into it.
Everything looks fine now that I removed all of the dependencies and started
from a blank slate. Sorry for the noise.
So far I'm not seeing the old "FAIL: gpgtar.scm" and "FAIL: ssh.scm"
Were those specifically fixed in some new commit(s), or am I just lucky so far?
Nov 19 2016
Jul 26 2016
Hi Justus,
Thanks for your response. In further testing, I was able to trigger the "FAIL:
gpgtar.scm" during a make check for 2.1.13 (actually "FAIL: gpgtar.test" for
2.1.13 since it's pre-tiny-scheme). In particular, it's vanilla 2.1.13 + your
fix in 8f79c31b. So I think what may be going on is that 8f79c31b didn't
actually fully resolve that problem after all since I've now seen it occur, with
that commit included, in 2.1.13, and in 2.1.14, and in HEAD.
Tbere were two cases where a more specific error was emitted:
In one run, I saw this:
((/private/tmp/gnupg21-20160725-43964-l18ixl/gnupg-2.1.14/tools/gpgtar --gpg /private/tmp/gnupg21-20160725-43964-l18ixl/gnupg-2.1.14/g10/gpg --gpg-args --no-permission-warning --always-trust --tar-args --directory=. --decrypt /tmp/gpgscm-PgAlmV/archive) failed: gpgtar: gpg: [don't know]: invalid packet (ctb=2d) gpgtar: gpg: [don't know]: invalid packet (ctb=2a) gpgtar: error running '/private/tmp/gnupg21-20160725-43964-l18ixl/gnupg-2.1.14/g10/gpg': exit status 2 ) FAIL: gpgtar.scm
and in another run I saw this
Checking gpgtar with signature ((/private/tmp/gnupg21-20160726-74591-maikty/gnupg-2.1.14/tools/gpgtar --gpg /private/tmp/gnupg21-20160726-74591-maikty/gnupg-2.1.14/g10/gpg --gpg-args --no-permission-warning --always-trust --tar-args --directory=. --decrypt /tmp/gpgscm-0U4bUB/archive) failed: gpgtar: gpg: Fatal: zlib inflate problem: invalid block type gpgtar: error running '/private/tmp/gnupg21-20160726-74591-maikty/gnupg-2.1.14/g10/gpg': exit status 2 ) FAIL: gpgtar.scm
It's also worth noting that I've only been able to trigger the problem on
Jenkins during CI, not locally, so I don't know if the lack of TTY is relevant
or something like that.
I will do the ssh check you requested.
I have now tested HEAD at revision 4ba11251aff578394000bf480f47160f0879c763 and
2.1.13 (including this patch
https://raw.githubusercontent.com/Homebrew/formula-patches/7b2211b/gnupg21/spawned_child_8f79c31b.diff)
The results are
- The "FAIL: gpgtar.scm" does *not* affect the patched 2.1.13, so it appears to
be a regression.
- The "FAIL: gpgtar.scm" is not fixed in HEAD at
4ba11251aff578394000bf480f47160f0879c763.
- There is a further regression in HEAD at
4ba11251aff578394000bf480f47160f0879c763, which seems not to be found in 2.1.14:
PASS: default-key.scm Checking key export > D74C5F22 C40FDECF ECABF51D < PASS: export.scm Importing ssh keys... > dsa key not added FAIL: ssh.scm Checking passphrase cache (issue2015)... PASS: T2015.scm Checking import statistics (issue2346)... PASS: T2346.scm
Jul 25 2016
Here's the relevant snippet:
PASS: tofu.scm Checking gpgtar without encryption Checking gpgtar without encryption with nicer actions Checking gpgtar with asymmetric encryption Checking gpgtar with asymmetric encryption and signature Checking gpgtar with signature ((/private/tmp/gnupg21-20160725-43964-l18ixl/gnupg-2.1.14/tools/gpgtar --gpg /private/tmp/gnupg21-20160725-43964-l18ixl/gnupg-2.1.14/g10/gpg --gpg-args --no-permission-warning --always-trust --tar-args --directory=. --decrypt /tmp/gpgscm-PgAlmV/archive) failed: gpgtar: gpg: [don't know]: invalid packet (ctb=2d) gpgtar: gpg: [don't know]: invalid packet (ctb=2a) gpgtar: error running '/private/tmp/gnupg21-20160725-43964-l18ixl/gnupg-2.1.14/g10/gpg': exit status 2 ) FAIL: gpgtar.scm Importing public key. Checking that the most recent, valid signing subkey is used by default > 8BC90111 3E880CFF F5F77B83 45117079 1EA97479 < Checking that we can select a specific signing key > 8BC90111 F5F77B83 1EA97479 < PASS: use-exact-key.scm Importing public key.
Yeah, unfortunately this is still happening even with my attempt to fix it with
deparallelization, so that's not the issue.
macOS 10.9 build bot has failed in the same place again.