+ address that hopefully doesn't bounce for Moritz

On Sat, Jul 23, 2022 at 11:51 AM George Colpitts <george.colpitts@gmail.com> wrote:

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 <ben@well-typed.com> wrote:
George Colpitts <george.colpitts@gmail.com> 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 </ghc/ghc/-/issues/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