search

3-manifolds / Sage_macOS

SageMath as a macOS application bundle.
152 stars 15 forks source link

Installation errors on M2 Macbook Air #44

Closed culler closed 1 year ago

culler commented 2 years ago

There have been reports that attempting to install the latest release of the SageMath 9.6 app on an M2 Macbook Air produces a dialog claiming that "the developer cannot be verified". However, on those systems the command:

spctl -vvvvv --assess /Applications/SageMath-9-6.app

is able to correctly identify the developer and reports that the app is "accepted". This has not been seen on any M1 systems.

If you encounter this problem, please run the spctl command above in your Terminal.app and report the output as a comment in this issue.

gurgunday commented 1 year ago

I have the exact same issue on my M1 Macbook Air — OS version is 12.6.

Output of spctl command:

/Applications/SageMath-9-6.app: accepted
source=Notarized Developer ID
origin=Developer ID Application: Marc Culler (A3LBEGBB69)
herbs commented 1 year ago

Note: I have the arm-64 version of SageMath-9.6.app installed on an M1 iMac and it seems to run without a problem. I'm running macOS Monterey 12.6.

However running the command above returns:

/Applications/SageMath-9-6.app: a sealed resource is missing or invalid

rana-aerea commented 1 year ago

I installed Sagemath on MacBook Air (M2, 2022) with macOS Monterey 12.4 and another time with 12.6. The package is SageMath-9.6.-1.4.2_arm64.dmg. I began with the factory settings (macOS Monterey 12.4.) Installation was by administrator account. I tried to invoke it in a user account. I could not. I tried spctl -vvvvv --assess /Applications/SageMath-9-6.app in that account. This did not work. I tried spctl -vvvvv --assess /Applications/SageMath-9-6.app in administrator account. I got the same message as gunwd got. I double clicked SageMath-9-6 in administrator account. I had to open Security&Privacy and click open it anyway. I double clicked SageMath-9-6 again and click open on a dialog. Double clicking SageMath-9-6 seemed to work.

I went back to user account and double click SageMath-9-6. It crashed probably because of illegal access to certain region of memory.

I used AppCleaner to remove SageMath-9-6. (I also used lsregister to clear information on SageMath-9.6.) I installed SageMath-9-6. A dialog popped up. I clicked open but I did not use Security&Privacy. Double clicking SageMath-9-6 seemed to work.

I removed SageMath-9-6 by AppCleaner again. (I used lsregister again.) Then, I upgraded macOS to version 12.6. I installed SageMath-9-6 in a user account, in which I plan to use Sagemath. A dialog popped up and I had to click open it anyway on Security&Privacy. I also clicked open on a dialog. I chose Jupyter... and a folder on the start-up dialog of SageMath-9-6 and I clicked Launch. It took a while but I was lead to a page of Jupyter. (I did not click Launch in administrator account, which is the meaning of "Double clicking SageMath-9-6 seemed to work".)

I think my trial and failure is influenced by several factors.

Here is my guess.

Reports with additional information on previously installed SageMath might help understanding the situation.

herbs commented 1 year ago

On Sep 18, 2022, at 1:36 PM, rana-aerea @.***> wrote:

I installed SageMath-9-6 in a user account, in which I plan to use Sagemath.

Howdy,

Where did you install SageMath-9-6.app? Have you tried to install in /Applications?

Good Luck,

Herb Schulz @.***

rana-aerea commented 1 year ago

Thanks for response. I moved the app to /Applications as instructed by icons on the disk image (mounted). I double clicked /Applications/SageMath-9.6.app from two accounts. I think permission issue prevents opening file for write. Writing to a file descriptor, after failure of opening, might cause a segmentation fault. This is my guess.

herbs commented 1 year ago

When trying to find out what version of sagetex.sty was being installed on my M1 iMac running Monterey 12.6 I opened the SageMath-9.7_arm64.dmg file in Pacifist. Pacifist said it wasn't signed (even though it opened fine on that M1 iMac).

culler commented 1 year ago

Hi Herb,

i am afraid Pacifist is wrong about that. The arm64 disk image is signed (and stapled) with my developer certificate:

% spctl --assess --type open --context context:primary-signature -vvvv SageMath-9.7_arm64.dmg SageMath-9.7_arm64.dmg: accepted source=Notarized Developer ID origin=Developer ID Application: Marc Culler (A3LBEGBB69)

michaelnoguera commented 1 year ago

I am having the same issue upon installation (via Homebrew). Here is some additional information that adds a plot twist: the signature of the executable .app file in the mounted disk image validates fine using spctl, but the same .app does not validate when the application is in the Applications folder.

Inspecting both with Objective-See's WhatsYourSign tool returns that both signatures are valid. WhatsYourSign also says that both have the same SHA256 hash, FDF28C02F4C1C2157B7399AEFE12EC89C0E75BFC348CE93BA5E99F5578BF0C91.

It's entirely possible that I am doing something wrong, but the two tools giving different answers looks strange to me.

image

michaelnoguera commented 1 year ago

So I did a bit more poking around, hopefully to helpful effect.

It turns out that the two directories are not exactly the same. I am not sure how WhatsYourSign computes its hashes, but it does not seem to include all the files in the .app archive.

In both the installed app folder and the app folder in the volume, I took hashes of all the files.

find . -type f -exec sha256sum {} \;

I sorted the outputs for each directory by filename, then compared them.

sort -k 2 volume.sha256sum > volume.sha256sum.sorted
sort -k 2 installed.sha256sum > installed.sha256sum.sorted
diff volume.sha256sum.sorted installed.sha256sum.sorted > SageMath-9-7.app.diff

The output has 1385 differences, and I have uploaded it to a gist here: https://gist.github.com/michaelnoguera/b59e156e57ca522d6fc60a214be1887c

Notably, ./Contents/CodeResources differs, and the copy in the Applications directory has this hash:

f1bb88427b204c81137075ac29aadeff193bd1d1949f33365bf753a4a06b110d  ./Contents/CodeResources

I installed the sage cask via Homebrew (the script is here: sage.rb), so the issue I am seeing might actually be with the cask script and not the binaries uploaded here.

I wonder if anyone else has a different hash for ./Contents/CodeResources, which can be obtained by running sha256sum /Applications/SageMath-9-7.app/Contents/CodeResources?

culler commented 1 year ago

I am not able to test this on my M1 system at the moment, but on my Intel system the CodeResources files are identical. The directories differ, but the difference is entirely due to .pyc files which get created in some of the __pycache__ directories within the bundle. I have tried to prevent that from happening by creating some .pyc files in advance and by configuring python to create .pyc files in ~/.sage rather than in the bundle. That works to some extent, but not perfectly. So, technically, the first run of sage could invalidate the signature if .pyc files are included in the signature. However, this has proved not to cause any problems with the gatekeeper on Intel and M1 systems. I see no reason why it should cause trouble on an M2 system running the identical OS to that on the M1 system. So I do not think that the fact that some .pyc files get added to the bundle after installation has any bearing on this issue, which is about the installation process itself.

michaelnoguera commented 1 year ago

Thanks @culler, you've clearly thought this through more than I have. The fact that it works in testing on other machines identical to mine without invalidating the signature leads me to conclude I must have done something wrong in installation. Maybe Homebrew changes something somewhere such that the applications are no longer 1:1 identical.

I am on an M1 system, running macOS 12.5.1, for what it's worth.

Your guesses as to the cause of this are much better than mine. If I can help by gathering information from my system, don't hesitate to ask, but I am happy just manually allowing it to run in System Preferences. Thank you for distributing these binaries, as they make installation much easier than building from source :-).

culler commented 1 year ago

Hi Michael. If you have an M1 then you do not have the problem that this issue is about. This issue is about M2 cpus only. There was a short period of time when the arm64 release image was not properly signed and notarized. Perhaps you ran into that. Would you please try installing the arm64 app from the most recent prerelease with tag 1.5.2 and use the "drag to /Applications" method? (The prerelease fixes other bugs related to the gfortran library.). If that works correctly then we can worry about the homebreinstallation seperately w

culler commented 1 year ago

I finally was able to test installing v1.5.2 on an M2 macbook air and encountered no issues. It was not necessary to open the Privacy & Security settings panel. There may still be cases where the gatekeeper complains, perhaps because of local configuration peculiarities or unexpected user behaviors such as installing the app as the root user. But if these events are not linked to a particular hardware configuration then they are a different issue.