gemrb
MacOS Arm64 0.9.2 Binary - "GemRB" is damaged and can't be opened. You should move it to the Trash.
Bug description
I've downloaded the ZIP files from Sourceforge twice now. I unzipped with two different programs in case it was an issue with the Unarchiver. Launching GemRB results
Steps to reproduce
- Download MacOS Arm64 0.9.2 ZIP from SourceForge
- Extract file
- Open GemRB.
- See error
Expected behavior
Program should launch.
Screenshots
GemRB version (check as many as you know apply)
- [ ] master as of this issue
- [X] 0.9.2
- [ ] 0.9.1
- [ ] 0.9.0
Video Driver (check as many as you know apply)
- [ ] SDL1.2
- [ ] SDL2 built with
USE_OPENGL_BACKEND - [ ] SDL2 without
USE_OPENGL_BACKEND
It's probably built for a different macos version, that's why (running it in the terminal would give you an actual error to think about). You can't do anything but build it yourself until #1861 and #1863 get fixed.
We build for MacOS 10.9 or later, so it's not that. The issue is code signing IIRC. Just strip the signature (and resign yourself if you don't allow unsigned execution)
No, I'm pretty sure it's the same brew problem as discussed elsewhere, where the brew target version doesn't match.
This might be caused by the quarantine attribute being set on the app. It was the cause of the same error for me with 0.9.3.
To remove the attribute execute
xattr -r -d com.apple.quarantine GemRB.app
in the same folder as the app.
Although there must be a reason why this attribute gets set in the first place.
It's done by default in newer macoses for downloads; we can't pre-set this attribute unfortunately. This is something that signing could fix though.
It looks easier now, definitely feasible for releases: https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/customizing_the_notarization_workflow#3087734 The nondeterministic timing makes it less than ideal for buildbot builds, but anyone using them surely knows how to work around this, so we could just ignore them.