George Colpitts writes:

Hi Ben,

I expected https://gitlab.haskell.org/ghc/ghc/-/issues/21506 (ghc-9.4.1-alpha1 does not install on macos: ghc-pkg-9.4.0-20220501 cannot be opened because the developer cannot be verified) to be fixed in rc1 but it is not. Are my expectations wrong? What is the ETA for fixing it?

Thanks for letting us know, George. The fix that we have [1] is present in 9.4.1-rc1. If that commit doesn't resolve the issue then there is something that we don't understand. Does `/usr/bin/xattr` exist? Running `xattr -rc` manually on the binary distribution allow you to run the compiler? Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/-/commit/641972d65b476aac11424bde6c3bcfda...

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

+ 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

Hi Ben Thanks for the quick responses particularly on the weekend before your vacation. you wrote: What happens if you try to install to do something like (in the extracted binary distribution), $ ./configure --prefix=`pwd`/tmp $ make install # this will fail $ xattr -rc . $ make install # perhaps this will finish successfully? # tmp/bin/ghc --version # GHC should be usable success on both my machines using a slightly modified version of your suggestion above for 21506: ./configure --prefix=`pwd`/tmp # specifying ./tmp seems to be critical xattr -rc . # seems to be necessary also sudo make install # seems to works , output ends with "recache" ./tmp/bin/ghc --version # success , although admittedly the smallest smoke test possible You wrote:

Ultimately I think we may just need to bite the bullet and start properly notarising/codesigning releases (resolving #17418). At this point we have spent more time trying to avoid the notarisation requirement than it would likely take to satisfy it. Unfortunately, this will require that I find an Apple device somewhere which may take a few weeks. I'm afraid I am on holiday next week but I would quite grateful if we could arrange for a chat after I return such that we can debug this in realtime. Sure, we can chat when you return from your vacation. Not sure if it is worth trying to fix the release on the basis of what I write above. My opinion is: it is if we can get reports of at least one other person having this issue. I am fine with not doing this for 9.4.1 I agree that we should raise the priority of "notarising/codesigning releases (resolving #17418)". My opinion is that it is not worth delaying 9.4.1 for this. Have a great vacation. Cheers George On Sun, Jul 24, 2022 at 11:33 AM Ben Gamari wrote:

George Colpitts writes:

...

+Kazu Yamamoto

Hi Ben

My 2 machines also have:

$ spctl --status assessments enabled

Hmm, interesting. Then I am truly perplexed.

...

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'm not sure where this would be but at this point anything is possible. What happens if you try to install to do something like (in the extracted binary distribution),

$ ./configure --prefix=`pwd`/tmp $ make install # this will fail $ xattr -rc . $ make install # perhaps this will finish successfully? # tmp/bin/ghc --version # GHC should be usable

...

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.

Not to worry; it's a very reasonable question to ask given the circumstances.

...

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

Ultimately I think we may just need to bite the bullet and start properly notarising/codesigning releases (resolving #17418). At this point we have spent more time trying to avoid the notarisation requirement than it would likely take to satisfy it. Unfortunately, this will require that I find an Apple device somewhere which may take a few weeks.

I'm afraid I am on holiday next week but I would quite grateful if we could arrange for a chat after I return such that we can debug this in realtime.

Cheers,

- Ben

Hi George,

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:

I had no problem on 9.4.1-rc1. "xattr -rc ." and "make install" worked perfectly. macOS Monterey v12.4 Xcode 13.4.1 --Kazu