Help Understanding Code Signing

[Ryan Schmidt]

On Apr 22, 2021, at 00:09, Marcus Calhoun-Lopez wrote:

> I must admit that whan issues like code signing come up, I tend to
> tune out, so please forgive me if this is well trodden territory.
> 
> While working on the netgen, I added the following code to get the
> destroot phase working (where ${pdv} is 3.8, 3.9, etc.):
>    destroot.env-append
> PYTHONPATH=${destroot}${prefix}/lib/python${pdv}/site-packages/ \
> 
> DYLD_LIBRARY_PATH=${destroot}${prefix}/lib
> 
> In the CMake file, PYTHONPATH is respected by execute_process [1], but
> DYLD_LIBRARY_PATH is not.
> From what I can tell, this is an OS issue and not a cmake problem [2].
> Apparently, the solution is to run codesign on cmake.
> Is this at all feasible?
> Is there another possible workaround anyone can think of?
> I am afraid I know little to nothing about how codesign [3] works.
> 
> Thank you,
> Marcus
> 
> [1] https://cmake.org/cmake/help/latest/command/execute_process.html
> [2] https://gitlab.kitware.com/cmake/cmake/-/issues/20678
> [3] https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html

https://gitlab.kitware.com/cmake/cmake/-/issues/20678 seems to be about restrictions encountered when using a binary distributed by cmake.org. The reporter said he did not experience those restrictions when building cmake himself or when using cmake from Homebrew, so I would not expect you to experience those restrictions with cmake from MacPorts either. Presumably the binary from cmake.org is built with settings (hardened runtime?) that cause this to occur, settings that we are presumably not using.

DYLD_LIBRARY_PATH needs to be set when invoking the binary that needs it. Ever since OS X 10.11, DYLD environment variables are not inherited by subprocesses, so you can't just set it at the top level and expect it to be there in whatever subprocess or subsubprocess needs it. (Other environment variables are still inherited.) So you might need to follow the execution path a little and figure out where the executable that needs DYLD_LIBRARY_PATH is being run and set DYLD_LIBRARY_PATH when running it.