OpenTTD-patches
OpenTTD-patches copied to clipboard
JGRennison
OpenTTD keeps asking for documents permission upon opening
Version of OpenTTD
v0.42.3, macOS 12.0 Beta (21A5506j)
Expected result
You give the permission once
Actual result
It keeps asking and never stops
Steps to reproduce
Open OpenTTD on macOS, (Might need to do it on the beta)
https://ipfs.io/ipfs/QmS2wqbnfRsF4EnF6x9VeqiRjQ5warjAj3x2DtexF7ZkEi?filename=Screen%20Recording%202021-09-06%20at%2016.09.02.tar.gz
Unfortunately I don't have access to any devices running macos at the moment. Does this also occur in non-beta versions of macos, or in vanilla OpenTTD?
It does not occur in vanilla OpenTTD, ~~and I can't test on a non-beta macos now, but I probably can tomorrow~~ Nevermind, I'll just use VNC
Now it only asks twice upon each launch, which is good enough for me
Oddly enough, starting the game using the OpenTTD binary (/Applications/OpenTTD.app/Contents/MacOS/openttd) doesn't make the dialogue pop up.
Now it only asks twice upon each launch, which is good enough for me
Also it is actually random
When I launch the binary directly from the terminal it generates no permissions prompts whatsoever.
I know this probably isn't much help, but I tried slipping the JGR executable into a vanilla app bundle. It still generated the same permissions spam, unfortunately.
As an interim solution, you can write a one-line script that executes the binary directly and just double-click that to play. Though it will generate a terminal window that you have to close afterwards.
I'm running macOS 12.0.1 (arm64)
Does the app need notarised?
(Might be a red herring, I didn't keep up with what Gatekeeper etc want per macOS version).
Actually, yeah. Why didn't I think of that?
You get this prompt on a fresh install:
"OpenTTD.app" cannot be opened because the developer cannot be verified.
@darrenrhs @andythenorth I doubt that is the issue, as you can completely get rid of that alert before even running it by running xattr -c /Applications/OpenTTD.app
Hmm. I could go look what was done for the vanilla client. I believe that is notarised and builds an application bundle (packaged app), but I'm out of my depth with those questions
I usually just run vanilla self-compiled from terminal. I haven't built JGRPP for a while, but I'll try compiling it later maybe :)
Last time I built JGRPP was x86 on a different Mac, which has been migrated to an m1.
I just pulled for my pre-existing JGRPP checkout, rm-ed the existing build folder, and re-compiled from scratch (m1, Monterey 12.0.1, XCode toolchain; seems to produce a native arm build with no further intervention).
I don't get any Gatekeeper warnings for the openttd executable, nor any warnings about accessing e.g. ~/Documents. I may have pre-existing authorisations for Gatekeeper, but the Mac hardware, OS, architecture and XCode version have all changed since the last JGRPP build. Sorry this gives no further insight to the problem :(
I confirm the bug. I started experiencing it after I moved from Intel to Apple silicon. Vanilla OpenTTD works fine even with Apple silicon.
Version 0.44.2 (downloaded as .dmg) macOS Monterey (12.0.1) Apple M1 Pro Silicon
I confirm the bug. I started experiencing it after I moved from Intel to Apple silicon. Vanilla OpenTTD works fine even with Apple silicon.
Is anybody on x86 having this issue, or is it just arm64?
@darrenrhs @andythenorth I doubt that is the issue, as you can completely get rid of that alert before even running it by running
xattr -c /Applications/OpenTTD.app
or if you want to be specific, you can do xattr -r -d com.apple.quarantine /Applications/OpenTTD.app
also just wanted to add another monterey (12.1)/m1 max/0.44.2 user with this issue. the dialog also pops up when connecting to a multiplayer server and periodically while connected. I think (but I'm not entirely sure) that if you wait too long to grant permission in the latter case, you'll desync from the server as well
It's been over 7 months since this issue was reported and it's still happening on the latest stable version of Mac OS (12.3.1) as well as the latest stable version of OpenTTD JGR (v0.47.1). At this point, I spend about 5 minutes dismissing a few hundred warnings each time I want to play the game. The two workaround commands mentioned do not make a difference. None of this happens with the vanilla OpenTTD builds.
What can I do or provide to help you debug and hopefully fix this?
At this point, I spend about 5 minutes dismissing a few hundred warnings each time I want to play the game
Do you get fewer warnings when you start OpenTTD-jgrpp with no preexisting openttd folder inside your documents folder? (You can rename any existing openttd folder in your documents folder to something different but related to preserve the contents inside but temporarily make it invisible to the openttd process)
Do you get fewer warnings when you start OpenTTD-jgrpp with no preexisting openttd folder inside your documents folder?
Yes, there are a lot less, only about 5. But any activity involving the disk (e.g. downloading online content) causes 10-20 more prompts. If I then quit and re-open the game a few times it seems to add more and more prompts to the point of it becoming unplayable.
It's been over 7 months since this issue was reported and it's still happening on the latest stable version of Mac OS (12.3.1) as well as the latest stable version of OpenTTD JGR (v0.47.1). At this point, I spend about 5 minutes dismissing a few hundred warnings each time I want to play the game. The two workaround commands mentioned do not make a difference. None of this happens with the vanilla OpenTTD builds.
What can I do or provide to help you debug and hopefully fix this?
There's not a lot I can do about problems created by Apple which only exist on Apple platforms.
There's not a lot I can do about problems created by Apple which only exist on Apple platforms.
Seeing as the vanilla game runs perfectly fine on the exact same platform, I think there is something that can be done.
I do understand it can be difficult though, especially since it's a less popular platform and you don't have a device to test it on, which is why I asked what I can provide to help debug this. :)
Are you still able to reproduce this issue? If so, can you please attach a screenshot of the prompt you're getting?
It should say something along the lines of "OpenTTD would like to access files in your Documents folder. [Don't Allow] [OK]"
Here is a video of it happening
https://user-images.githubusercontent.com/58151048/167321569-5eec8121-6680-412f-93fa-3bae9a25db30.mp4
I found an identical issue with qBittorrent here. They alleviated the issue by issuing the following command in a terminal:
codesign -s - --deep PATH_TO_APP
For most users here this would be:
codesign -s - --deep /Applications/OpenTTD.app
After this, you should only be prompted once and never again.
Please note that this does not "resolve" this bug as it continues to ship in the current build and is not intended behaviour.
It is also not a command that users should be using routinely or blindly because it is a circumvention of system security. It essentially allows the user to "ad-hoc" sign code, which if you do not trust the code in question you should not be doing. The command in question signs recursively into the app folder, so any bundled code gets signed as well.
I found an identical issue with qBittorrent here. They alleviated the issue by issuing the following command in a terminal:
codesign -s - --deep PATH_TO_APPFor most users here this would be:
codesign -s - --deep /Applications/OpenTTD.appAfter this, you should only be prompted once and never again.
Please note that this does not "resolve" this bug as it continues to ship in the current build and is not intended behaviour.
It is also not a command that users should be using routinely or blindly because it is a circumvention of system security. It essentially allows the user to "ad-hoc" sign code, which if you do not trust the code in question you should not be doing. The command in question signs recursively into the app folder, so any bundled code gets signed as well.
This did the trick! Thank you so much. While still "unresolved", I find this an acceptable workaround for my own purposes. Also FWIW, I just encountered this problem today so... timely!
