otfried / ipe

The Ipe extensible drawing editor
http://ipe.otfried.org
125 stars 9 forks source link

Cannot run on Mac #478

Closed duhd1993 closed 8 months ago

duhd1993 commented 10 months ago
CleanShot 2023-08-30 at 01 27 08@2x

This is different from the cannot verify Developer error.

Machine: Apple M1 Pro OS: 13.3.1

otfried commented 10 months ago

It seems this is some new security mechanism of MacOS 13 - they are making it harder and harder to run code that has not been signed by a paying Apple developer.

If you click on the information icon, it says that the code differs from the signed version of the code. This is misleading, because I do not sign the Ipe executable at all, not having the certificate of a paying Apple developer.

I will have to dig around a bit to see if this is anything I can solve. Otherwise you should be able to run Ipe by disabling this specific security setting for the program.

In the long run this will probably mean that Ipe will only be available to MacOS users who are willing to compile it themselves.

duhd1993 commented 10 months ago

If it's a unsigned program, I just need to right click and open it. This still works on the current version of macos. But it doesn't work with ipe. I cannot find a way to run it if it's indeed not damaged.

otfried commented 10 months ago

Do you have codesign installed so you could check which of the executables are signed and how?

I can only look into this when somebody gives me access to an M1 laptop again to investigate. I have seen Ipe running on M1 hardware...

In the meantime, I'm afraid you'll have to run the intel version.

duhd1993 commented 10 months ago
$ codesign --display --verbose=4 Chromium
Executable=/Applications/Chromium.app/Contents/MacOS/Chromium
Identifier=org.chromium.Chromium
Format=app bundle with Mach-O thin (arm64)
CodeDirectory v=20400 size=2062 flags=0x2(adhoc) hashes=58+3 location=embedded
VersionPlatform=1
VersionMin=720896
VersionSDK=852736
Hash type=sha256 size=32
CandidateCDHash sha256=9aa38c7f60014c92564805077514b2faed66c948
CandidateCDHashFull sha256=9aa38c7f60014c92564805077514b2faed66c948176dc5225ac8dc20459345ae
Hash choices=sha256
CMSDigest=9aa38c7f60014c92564805077514b2faed66c948176dc5225ac8dc20459345ae
CMSDigestType=2
Executable Segment base=0
Executable Segment limit=196608
Executable Segment flags=0x1
Page size=4096
Launch Constraints:
        None
CDHash=9aa38c7f60014c92564805077514b2faed66c948
Signature=adhoc
Info.plist entries=34
TeamIdentifier=not set
Sealed Resources version=2 rules=13 files=61
Internal requirements count=0 size=12

This is a unsigned Chrome from https://github.com/ungoogled-software/ungoogled-chromium-macos Also built on github actions. You don't have to have a mac to debug. You can ssh into github action runner. https://github.com/marketplace/actions/debugging-with-ssh

duhd1993 commented 10 months ago

Run this command sudo xattr -r -d com.apple.quarantine /Application/Ipe.app

otfried commented 8 months ago

It turns out this statement is not correct:

If it's a unsigned program, I just need to right click and open it. This still works on the current version of macos. But it doesn't work with ipe. I cannot find a way to run it if it's indeed not damaged.

Apparently, Apple silicon requires all code to be signed, otherwise it will simply not run. So there is no such thing as an "unsigned program" anymore (https://wiki.lazarus.freepascal.org/Code_Signing_for_macOS).

Indeed, also the Ipe binaries are signed, as I found out today when I finally had some time to look at them using codesign (although using codesign on Intel hardware to look at the arm binaries...) The linker does this automatically, and codesign displays them as adhoc,linker-signed.

Apparently this is what causes the problem. Perhaps copying the dependencies into the Ipe.app bundle is enough to break the validity of the linker signage.

Chromium seems to be properly signed with an "adhoc" signature, so I will try to add that to Ipe as well.

otfried commented 8 months ago

So the problem was that I run install_name_tool on the dependency libraries after they have been linked. This modifies the binary so it causes the signature by the linker to become invalid, and results in the "damaged file" message.

I have no added adhoc signing to the pipeline that builds the MacOS ARM binaries, and a friend has tested that now you can indeed download it and start it as before (of cause you still get the developer warning).

Thanks for your help debugging this!