Re: [ANNOUNCE] GHC 9.4.1-rc1 is now available

+ address that hopefully doesn't bounce for Moritz On Sat, Jul 23, 2022 at 11:51 AM George Colpitts wrote:

+Kazu Yamamoto

Hi Ben

My 2 machines also have:

$ spctl --status assessments enabled

I've duplicated the issue on both of my machines. It would be good to know if anybody else is seeing it. Kazu, I know you have seen this in the past. Do you get the same error installing rc1? When I run sudo make install I get a popup that says:

*“libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib” cannot be opened because the developer cannot be verified.*

When I cancel out of that I get another popup with the same error. When I hit cancel on that the script ends with the output:

# We finally replace the original file. mv '/usr/local/lib/ghc-9.4.0.20220721/lib/package.conf.d/process-1.6.14.0.conf.copy.copy' '/usr/local/lib/ghc-9.4.0.20220721/lib/package.conf.d/process-1.6.14.0.conf' '/usr/local/lib/ghc-9.4.0.20220721/bin/ghc-pkg' --global-package-db "/usr/local/lib/ghc-9.4.0.20220721/lib/package.conf.d" recache dyld[32239]: Library not loaded: '@rpath/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' Referenced from: '/usr/local/lib/ghc-9.4.0.20220721/bin/ghc-pkg-9.4.0.20220721' Reason: tried:* '/usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' (code signature in <CA45AED4-4028-3B3F-9AA6-91EDE1078A7E> '/usr/local/lib/ghc-9.4.0.20220721/lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' not valid for use in process: library load disallowed by system policy), '$ORIGIN/../../../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' (no such file), '/usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' (code signature in <CA45AED4-4028-3B3F-9AA6-91EDE1078A7E> '/usr/local/lib/ghc-9.4.0.20220721/lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' not valid for use in process: library load disallowed by system policy),* '$ORIGIN/../../../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' (no such file), '/usr/local/lib/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' (no such file), '/usr/lib/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' (no such file) make: *** [update_package_db] Abort trap: 6 gcolpitts@macMini-2018 ghc-9.4.0.20220721-x86_64-apple-darwin %

Hope this helps.

Speculations:

/usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib is created after xattr -rc . was run so it doesn't have the necessary attributes. Is it possible that ghc developers and/or the test machines have this file on another of the paths in the error message and that is why it works for them?

I hope I didn't offend you by asking if the fix had been tested; I assume it had been but I thought it was important to rule that out.

More than happy to test. I really appreciate all the work you and others have put into GHC !

Cheers George

On Sat, Jul 23, 2022 at 10:03 AM Ben Gamari wrote:

...

George Colpitts writes:

...

Hi Ben

/ust/bin/xattr exists on my machine. Running "xattr -rc ." manually does not fix the bug as noted at the start of 21506. It was sufficient in the past but no longer fixes this error. As noted farther down in 21506

the workaround given in #17418 no longer works. It did not work in 9.2.2 either. The current workaround is similar to what Kazu explained in https://twitter.com/kazu_yamamoto/status/1500643489985761282

sudo xattr -rc .

sudo spctl --global-disable

./configure

sudo make install

sudo spctl --global-enable

It seems there are files created during sudo make install that have an issue as xattr -rc . was never run on them. Perhaps this is related to using Hadrian. Is it possible that the fix that was made was never tested?

I tested the change both manually and via CI on the hardware that I have access to; in both cases installing the binary distribution resulted in a functional compiler. However, given how the effects of SIP are essentially undocumented, it is very hard to know what variables may be at play here. Running spctl --status on the machine on which I tested claims:

> spctl --status objc[48908]: Class SPExecutionPolicy is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class AppWrapper is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class AppWrapperPolicyResult is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class AppWrapperPolicy is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class SPLog is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class MIS is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class SPExecutionHistoryItem is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class SPExecutionPolicyItem is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class SPDeveloperPolicy is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class GKScanResult is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. assessments enabled

Which to me suggests that SIP (which, I imagine, is responsible for #21506) is enabled. However, the lack of comprehensive documentation here makes it very hard to say with certainty what might differ between your machine and mine. Without more information I don't know how to proceed here. Perhaps someone (Moritz or Simon, perhaps) with more familiarity with macOS has some insight?

Thanks for your help in testing, George!

Cheers,

- Ben