-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
weekly builds are not signed and are shown as "damaged" on arm64 macOS #291
Comments
Might be related? #290 |
Is this how Apple solves all issues? XD |
Is this the arm or intel package? Intel doesn't seem to be damaged, but does now require MacOS 13.6 or later. |
On my ARM mac mini (M1 running MacOS 14.5) neither is working. The arm version gives me the same error that was posted in the pictures. The x86 version allows me to uncompress it and open it. Once I to open it, there is an error that says it can't initialize somthing. I don't know if this is a known error or if Rosetta is supposed to be able to run the x86 version of freecad. However I know that i was able to run the the x86 version successfully before switching to the arm version. |
@BillTuttle It's the ARM package |
Same issue Using |
FreeCAD_weekly-builds-38495-conda-macOS-arm64-py311 doesn't start on my mac either |
Attempts to fix are happening at #293 |
The Intel build should be working again. The Apple Silicon build requires additional steps. My notes on the investigation are here. The QRD is that FreeCAD was launched by a shell script that caused macOS to think the application required Rosetta (it does not). The shell script was replaced by a native program that fixes the Rosetta issue, but I had an error in it. The fixed version works on Intel, but Gatekeeper (macOS code signature enforcement) behaves differently on Apple Silicon. A command at the CLI will permit running the Apple Silicon version. A better solution that does not require user intervention is being investigated. |
I can confirm that the following steps fix the problem for me:
|
this was always the case for me in the weekly builds for over a year now :D |
The whole point of this issue is that right clicking isn’t doing the job. 🫠 |
My hypothesis is that Apple has decided to change the behavior of unsigned builds that are identified as Intel vs ARM. The Intel builds permit right-click and open to run unsigned code from the internet, but ARM builds do not. Before the recent changes to the FreeCAD launcher, the launcher was a architecture-independent shell script. Apple's Gatekeeper could not identify the application as an ARM binary, which is why it claimed to require Rosetta 2 despite not needing it. This also meant that the legacy behavior of right-click and open would work. Now that the ARM binaries are correctly identified, they will not open without removing the attribute. |
I'm not sure about this. I've used right-click to open on other projects before and it works. I'm not about to say Apple would not force this issue by expiration of old systems, but I don't know why other downloads would allow me to right-click and open (and they are ARM64 builds, I have checked) while FreeCAD is some special case. |
@skandragon See my analysis here: #293 (comment) |
Same problem with FreeCAD_weekly-builds-38553-conda-macOS-arm64-py311. |
@theosib see my comment here: #293 (comment) |
Same for me with the rc1 build on macos/arm |
I had the same issue with the 1.0.0RC1 arm64 version for MacOS, however this allowed me to run it: |
Today's signed bundle launches correctly on my M1/arm Mac.
|
As far as I know, the current plan is the Release Candidates and final versions will be signed, but the weekly development builds won't be signed. Yes - known issue. I believe that'll be resolved when @oursland and/or @looooo refine the build process. |
I have the same issue with the weekly build, because it was not codesigned. Rolf |
Same problem on my M2 MacBook Pro running Sonoma 14.6.1. I don't have the problem with the pre-release FreeCAD V1.0. |
@martin1951 Run |
FreeCAD_weekly-builds-38467-conda-macOS-arm64-py311.dmg
The text was updated successfully, but these errors were encountered: