gh: @2.10.x: destroot fails for prebuilt binary: symbol not found: _SecTrustEvaluateWithError

[mascguy (Christopher Nielsen)]

As of the 2.10.x releases, gh is now failing during destroot with the prebuilt binary - the latter used for 10.12 and earlier - with the following:

Error: Failed to destroot gh: dyld: Symbol not found: _SecTrustEvaluateWithError
Referenced from: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_gh/gh/work/destroot/opt/local/bin/gh
Expected in: flat namespace

​https://ports.macports.org/port/gh/builds/

[RobK88]

I am having the same problem on my Mac running Lion.

bash-3.2$ sudo port clean gh
Password:
--->  Cleaning gh
bash-3.2$ sudo port upgrade  gh
--->  Computing dependencies for gh
--->  Fetching distfiles for gh
--->  Verifying checksums for gh
--->  Extracting gh
--->  Configuring gh
--->  Building gh
--->  Staging gh into destroot
Error: Failed to destroot gh: dyld: Symbol not found: _SecTrustEvaluateWithError
  Referenced from: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_gh/gh/work/destroot/opt/local/bin/gh
  Expected in: flat namespace

Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_gh/gh/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
bash-3.2$

[RobK88]

It looks like the problem may be related to the GO programming language in which gh is written.

See ​https://github.com/golang/go/issues/52757

I suspect gh will build just fine when one is running Mac 10.13.3 or later. I am hoping for a fix but I doubt the developers at GO will address it since the GO language now only officially supports 10.13 or later.

[krackers]

Would it be possible to add a function to macports legacy support to polyfill the SecTrustEvaluateWithError function? Its core functionality is similar to the existing SecTrustEvaluate. We just need to parse the output of that ourselves and return a boolean pass/fail accordingly, and construct a CFErrorRef ourselves from the underlying status code in the out parameter.

[kencu (Ken)]

It might be.

I have also wondered about building the Security Framework from 10.13 and using it on older systems:

​https://github.com/apple-opensource/Security

​https://github.com/darlinghq/darling-security

Also, someone has been maintaining a fork of go that keeps up compatibility with at least some older systems, and has a workaround for this issue in that repo:

See these:

​https://github.com/golang/go/issues/52112

​https://github.com/fancybits/go/compare/6432f144aef0...989d1b18ee4a

​https://github.com/fancybits/go/tree/fancybits-1.19

[krackers]

I believe someone did try building a newer security.framework in ​https://apple.stackexchange.com/questions/396462/how-do-i-compile-apples-security-framework, but it didn't completely work:

The built Framework does not appear to actually function—replacing it on my hard drive makes the computer (a VM, thankfully) unable to boot. I initially expected this to be a code signing issue, but it doesn't look like that's the problem. But, still, it built!

It's possible that the open-source releases are incomplete though (in the same way xnu sources lack some private iopower stuff that iMessage uses for validation that you're running on genuine apple hardware). Someone would need to try again and obtain more detailed logs. Even if it's incomplete wrapping the existing libSecurity to reexport newer versions of symbols might be an option.

[aeiouaeiouaeiouaeiouaeiouaeiou]

Here's my silly patch to workaround this issue.

When I was using OS X 10.8 I had some progress with the Go compilation, but encountered a crash when the bootstrapped $go_amdbin_dist executable does not contain some symbols to launch. As far as I know, legacysupport can only be linked to compiled binaries via MacPorts, not to those downloaded from the network.

Due to some personal problems I do not have time to deal with it, plus I decided to switch to a more recent version of the system.

[krackers]

can only be linked to compiled binaries via MacPorts, not to those downloaded from the network.

That's not true, you can in fact use legacysupport with arbitrary binaries, either by telling dyld to use it at load-time via DYLD_INSERT_DYLIB, or more permanently by patching the mach-o to add a LOAD_DYLIB command. The latter can be done easily via ​https://github.com/tyilo/insert_dylib or ​https://github.com/alexzielenski/optool.

This is particularly handy for Go binaries, because with the extra symbols supplied they usually work perfectly. Well... that used to be the case until Go 1.18, which started making use of the SecTrustEvaluateWithError that's the focus of this bug. I did verify that the polyfill in ​https://trac.macports.org/ticket/66749 works fine, someone just needs to PR it in.