open .scad first time --> need to confirm "access to Documents" every time + for every Preset

[3Dietrich]

OpenSCAD Version 2022.01.20:
macOS 12.0.1, MBAir 2020 M1

Every time I open a file.scad with presets the first time, I need to confirm for every preset(!) to get access to documents

what strange is: since installation and running this new OpenSCAD, I get this question also in OpenSCAD 2021.01. For every freashly opened file.scad

Bildschirmaufnahme.2022-01-20.um.17.55.26.mov

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[ChrisCoxArt]

I haven't been able to reproduce this on MacOS 12.1, Intel processor.
I've tried removing permissions for OpenSCAD, installing new dev snapshots, and making new development builds. But I only get prompted for the document directory of files I open, never presets.

[ChrisCoxArt]

OK, I now have 12.1 installed on my M1 machine, and still cannot reproduce it requesting permission for every preset.
Where did you install/copy the OpenSCAD.app bundle to run it?

[3Dietrich]

Yea, I can't reproduce it any more, it seems it was not because of the presets.

But maybe for several .scad file in the Download folder? I come to this idea because in this screenshot video the files are at the start greyed out (before I press ok the first time) and become 'accessible' (full colored) one by one each time I pressed "ok":

Bildschirmaufnahme.2022-01-23.um.12.17.45.1.mov

in any case, any question about "download [bla] ?" is totally superfluous because I allowed it long ago:

[eaton]

Just dropped in the latest dev build and I'm seeing the same issue: Even though I've given OpenSCAD full disk access, I get "OpenSCAD wants to access…" prompts dozens of times. I wonder if its thrashing of the Documents folder involves library access; I'll see if removing a bunch of the custom libraries I've installed helps.

[ChrisCoxArt]

And I still cannot reproduce that. I suspect something is very wrong with the permissions or security settings on your system.
Once you give an application access to a folder, MacOS should not prompt again for that application and location.

[DavidPhillipOster]

cannot reproduce

OpenSCAD version 2022.03.14 (git 9f68ea0). I removed any previous OpenSCAD, and in before first run removed OpenSCAD from SystemPreferences >Security&Privacy>Files&Folders After a restart, I opened, rendered, and edited a file that #included a BOSL2 file. Although on first launch, I did get the "OpenSCAD” cannot be opened because the developer cannot be verified. alert, I never got any complaints about access to any folders. macOS Monterery version 12.3, M1 Mac Mini.

[tcurdt]

I am seeing the same thing.

It seems a little suspicious that there are no entitlements at all

codesign --display --entitlements - /Applications/OpenSCAD.app

Some that could be relevant:

com.apple.security.app-sandbox
com.apple.security.files.user-selected.read-write
com.apple.security.app-protection
com.apple.security.documents.user-selected.read-write
com.apple.security.temporary-exception.files.home-relative-path.read-write

The strange thing is - even adding OpenSCAD to full disk access it keeps asking.

I still have a pending macOS upgrade and see if that makes a difference.

[eaton]

@tcurdt, are you by any chance storing your Desktop and Documents folders in iCloud? It just occurred to me that I'm doing that on both machines I tested with; by default, that also places OpenSCAD's Libraries folder in an iCloud controlled directory as well.

[tcurdt]

@eaton No, I am not using iCloud (more than I have to).
And my OpenSCAD library even resides outside of the Documents folder. (via OPENSCADPATH)
So that can't be it.

[tcurdt]

Just upgraded to the latest macOS 12.3 - still the same behaviour.

[tcurdt]

If OpenSCAD does not plan on releasing through the MAS, maybe the entitlement

<key>com.apple.security.app-sandbox</key>
<false/>

would save us from all the headaches?

Within the sandbox it probably also needs full disk permissions to make use of OPENSCADPATH.

[tcurdt]

Interesting - and weird! It happens only when the file is on the desktop (or a sub dir thereof). When I move it somewhere else everything just works. When I move it back to the desktop I again get the permission popups.

[thehans]

Just a shot in the dark, are any of the paths with problems containing symbolic links?

[tcurdt]

@thehans Na, the path to the desktop doesn't contain any links.

[eaton]

Just had a chance to set up a fresh new Mac and re-image the MacBook where I initially spotted the issue; it's definitely still present.

On both freshly-imaged machines, before and after enabling iCloud Desktop/Document sharing, I downloaded OpenSCAD-2022.04.15.dmg from the site and installed it.

• On launch, it requests access to the Documents folder.
• On saving a file to the Desktop, it requests access to the Desktop (predictably). Saving the file again doesn't re-trigger the prompt, but other operations — rendering, for example — do trigger requests to access both the Desktop and the Documents folder.
• Opening existing .scad files shows the same behavior, and the permission appear to pop up multiple times if the files use include, even when the included files are in folders that were previously 'prompted' for.
• Files that use the Customizer seem to do it more (I lost count after clicking to grant permissions to my Documents folder upwards of 30-40 times).
• Files stored on a NAS prompt for general 'Permission to access files on a network device' permissions.
• This behavior is present even when OpenSCAD is granted full disk access in System Preferences.

Other than this particular issue, the new dev builds are BLISTERINGLY fast on the M1. When I have a chance next week I'm going to dig in and do some more specific controlled tests around individual operations to see if there are any other patterns. As noted upthread, the Desktop folder (or any subfolders) seem to trigger it consistently, while other directories don't.

[tkircher]

I'm having this same issue. OpenSCAD version 2022.04.09 (git b13ec70), MacOS Monterey 12.3.1. It doesn't matter if I have a .scad file on the desktop, in a folder on the desktop, or in the documents folder. It asks me for permission every single time. When opening the documents folder, it sometimes asks thirty or forty times in a row. Clean system install. A mitigation strategy is to put files in your home directory only, which at least works for me. There does not appear to be a way to turn off privacy protections on MacOS anymore.

[tcurdt]

@tkircher Does it also ask for permission when in a subfolder of home?
As long as I stay away from the desktop it works OK. I haven't tried the documents folder though.

[tkircher]

@tcurdt A subdirectory of the home directory also works fine. So Desktop and Documents are basically unusable directories in MacOS.

[tcurdt]

@tkircher I just tried the documents folder. I can confirm the same.
So yes, Desktop and Documents are causing problems.

[fergu]

I can also confirm this bug. I can also confirm that moving the relevant *.scad files out of either Documents or Desktop does clear up the warnings when building the model, though you will still get asked for permissions every time you go through file->Open. Interestingly, I also note that I get asked for Desktop and Documents permissions twice each time (So 4x total), though sometimes I get asked for one of the two twice, and the other only once.

This bug does not appear when using the current release download (2021.01).

Maybe this might be related to code signing on Apple Silicon? https://developer.apple.com/forums/thread/125794

I don't know enough about OpenSCAD's internals, but maybe something isn't quite right with code signing and that's causing the security measures to freak out by thinking the binary is constantly changing? I wonder if this issue with the nightly build also exists on Intel Macs, and whether it can be cleared up by stripping the code signature if it does. Unfortunately unsigned ARM binaries will refuse to run, so I can't test that idea on an M1 directly.

[ChrisCoxArt]

The problem is: this only happens to small subset of users.
There is something different about your systems, or where/how you copied the application.

[tcurdt]

The problem is: this only happens to small subset of users. There is something different about your systems, or where/how you copied the application.

Probably - but for me it happened on a fresh system.
I got the new M1 laptop and during the setup also installed OpenSCAD.
So I am really wondering how the system could be different.

[fergu]

Mine isn't fresh, but I installed it to the normal /Applications/ directory. I've also tried deleting the permissions for OpenSCAD from Settings -> Privacy to force it to ask again with no luck.

I am using iCloud while @tcurdt (I assume based on earlier posts) is not, so it seems like it's likely not an iCloud issue.

The common thread between the two of us seems to be that we're both on M1 Macs, so I'm tempted to think this is something specific to that. The only thing I've found that's different is that MacOS running on M1's is more strict about code signing than on Intel (Edit: Though I'm admittedly unsure why that'd affect permissions requests)

Is there maybe a way to get an intel only build so we can see if running under Rosetta clears this up? That would at least narrow it down to an M1 issue.

[tkircher]

Clean system here, M1 Max, Monterey 12.3.1, official ARM build of OpenSCAD downloaded from the website, development snapshot 2022.04.09 (git b13ec70)

[tcurdt]

I am using iCloud while @tcurdt (I assume based on earlier posts) is not, so it seems like it's likely not an iCloud issue.

Not using iCloud. So that doesn't seem to be related.

The only thing I've found that's different is that MacOS running on M1's is more strict about code signing than on Intel (Edit: Though I'm admittedly unsure why that'd affect permissions requests)

Do you have more info about that? I am not aware of the "more strict" part.

(Was a) clean system, M1 Pro, Monterey 12.3.1, still on ARM build 2022.03.16 (git a6392b3)

[tkircher]

@tcurdt It is correct that M1 macs have a more tightly locked down system than Intel macs.

[fergu]

I've been testing on ARM (universal) 2022.05.09 (The "nightly" build available from the website). M1 Air, Monterey 12.3.1.

Do you have more info about that? I am not aware of the "more strict" part.

This Apple Developer release note mentions that Apple Silicon systems will refuse to run unsigned code, but that Xcode will sign the code as part of the linking process. That's enough to allow the code to run, but Gatekeeper will still flag it. (You'd need to go through the whole Apple Developer registration process thing to get around that which isn't necessary)

They also mention some caveats where the signing process may not work correctly. That said, I'd expect that kind of issue to prevent OpenSCAD from running, not to cause this weird permissions issue. So Code Signing itself might not be the problem, but maybe something adjacent to how M1 systems are more strict on security policies?

[ChrisCoxArt]

I also have an M1 iMac (in addition to a few Intel systems), and no such problems.
There is still something odd happening with a subset of systems and users.

[elxris]

@tcurdt If I change the Bundle Version I get ERROR: Parser error: file access denied while trying to open a file. I can't render it either.

Either way, if I don't modify anything, the last build (2022.10.31 (git 5944914)) I am only asked a few times after opening a file, but not while trying to render. So I see an improvement.

[tcurdt]

@elxris without more details of your situation it's hard say anything.

The workaround works fine for me on macOS 12.6 with a M1. 🤷‍♂️

[elxris]

@tcurdt I am sorry I was unable to provide more details, I really don't know how to debug these things as I am not a OSX developer.

I want to add that I did a quick Ecosia search and found this command to fix my problems on my M1 as the workaround Info.plist didn't work for me.
sudo codesign --force --deep --sign - /Applications/OpenSCAD.app

Source: alacritty/alacritty#5845

[tcurdt]

@elxris Things like processor architecture and macOS version would always be helpful :)

TBH I am surprised that changing the bundle version without a codesign works for me.

[elxris]

@tcurdt my bad! I forgot.
macOS 13.0 (22A380)
MacBook Air Apple M1

[DanielYWoo]

@DanielYWoo please re-read the issue.

The only work around I found is to manually change the Bundle version inside Info.plist. Really not sure why that is.

I just gave you an example of details, I can fix it with rolling the version but just curious why. And if you need some tests in different environments please let me know. I have a Macbook Pro M1 max 2021 with Monterey and a Macbook Air M1 with Monterey.

[thehans]

I am wondering if the issue with the bundle version is something to do with that fact that it is improperly formatted?
https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleversion

This key is a machine-readable string composed of one to three period-separated integers, such as 10.14.1. The string can only contain numeric characters (0-9) and periods.
...
You can include more integers but the system ignores them.

I would suggest:

YYYY.MMDD.BBBB

where BBBB represents some "build number".
I think the most appropriate value for this would be from an environment variable named GITHUB_RUN_NUMBER

GITHUB_RUN_NUMBER | A unique number for each run of a particular workflow in a repository. This number begins at 1 for the workflow's first run, and increments with each new run. This number does not change if you re-run the workflow run.

https://docs.github.com/en/actions/learn-github-actions/environment-variables#default-environment-variables

[tcurdt]

They have increased the strictness of the format - not entirely sure why.
The important bit now is that:

semversion(new) > semversion(old)

The current scheme YYYY.MM.DD follows this - as long as you don't install multiple different builds per day (which is a very niche use case) there is no difference over YYYY.MMDD.BBBB.

And given the latest findings the version does not seem to be the final piece of this puzzle.

[thehans]

@tcurdt Ah, my mistake, i was looking at one of your edited versions with 4 numbers. Though it is strange if adding a 4th number somehow helps, since the docs claim it should be ignored.

But also, I think it would be best to guarantee a unique build version, regardless of rarity of being built on the same day.
If nothing else than for the specific purpose of reliably testing an issue like this.

[thehans]

And given the latest findings the version does not seem to be the final piece of this puzzle.

I read through all the comments last evening, but I guess I didn't pick up on this.
Could you clarify what those latest findings are?

If you are talking about @elxris's issue:

@tcurdt If I change the Bundle Version I get ERROR: Parser error: file access denied while trying to open a file. I can't render it either.

This is the same issue @sroeper reported, and then said it was fixed:

The hooray was to early. Now I have another problem. I can open all files (all located under Documents/OpenSCAD) and never get the permission question. BUT when I press F5 (even in a new file with just a cube) I get ERROR: Parser error: file access denied ERROR: Compilation failed! (No top level object found)

Any ideas?

Ok, fixed. A simple reboot and everything seems to work now.

A last amendment, I also renamed my OpenSCAD folder in Documents and let OpenSCAD create a new one. After that I moved my libraries Folder an my other files to this new folder and deleted the old one (including the backups folder). Before that I still got file access errors when using my libraries.

Now everything is working like a charm.

[tcurdt]

@thehans A uniq bundle version would be nice - but it seems not to help this issue. Multiple builds per day is also more a developer concern and they are probably are less affected by this anyway. I guess this should be handled in a different issue as this isn't the cause for this issue.

FWIW: I used to use just the major version and as minor the total number of commits for the bundle version. That worked pretty well for me. Maybe for OpenSCAD it could be just YYYY.MM.#commits

I think the summary of the findings are as follows:

1. It seems that somehow the permissions are cached by macOS based on bundle version.
   Why I still had change the bundle version on a fresh build is still a mystery to me.
   I couldn't make sense of that yet. But it seems to work for me on 12.6.

2. This workaround(?) did not seem to work for @elxris on macOS 13 though.
   He had to re-sign the bundle.
   I am wondering how the signing is different from the official one.

[judy2k]

Hello! Sorry to add more conflicting info to this issue:

• MacOS 12.6 on an M2 MacBook Air

I've been seeing this issue with the various dev snapshots (2022.09.05 & 2022.11.21) I've downloaded since getting the Mac about 3 months ago. The latest was 2022.12.19. They've all suffered from the same repeated requests for access to the Documents folder.

I've just run the codesign command posted above sudo codesign --force --deep --sign - /Applications/OpenSCAD.app and it's fixed the problem. I don't know whether that's in combination with some of the changes that have been merged, but I'm just relieved to have a working OpenSCAD again.

[tcurdt]

I lately also had to codesign. It seems to be the final answer.

The question is how that codesign is different from what is done during the codesign at built time.

[chrishill-github]

Hallelujah! I've had the repeated permission request problem ever since I bought my M1 Macbook about a year ago. Today I decided to visit the forum again to see if there's a fix. Downloaded the latest snapshot build [2023.01.20] - no difference.

Tried the sudo codesign --force --deep --sign - /Applications/OpenSCAD.app command, and after one more permission request it seems to have gone.

Thanks for everyone's persistence on this.

[kintel]

Could someone who experiences this issue try these new binaries? These have been adhoc codesigned by the snapshot build system:
https://output.circle-artifacts.com/output/job/3283034f-9475-49d9-97ea-9e5c4ffe9d2d/artifacts/0/tmp/out/OpenSCAD-2023.10.08.dmg

[tcurdt]

@kintel unfortunately it even crashes (for me)

-------------------------------------
Translated Report (Full Report Below)
-------------------------------------

Incident Identifier: AE47AA23-1AE4-402C-861E-27BCE7501D9D
CrashReporter Key:   3ECE11CF-7E46-B58D-DC09-D101309B68B8
Hardware Model:      MacBookPro18,1
Process:             OpenSCAD [96335]
Path:                /Users/USER/Desktop/OpenSCAD.app/Contents/MacOS/OpenSCAD
Identifier:          org.openscad.OpenSCAD
Version:             2023.10 (2023.10.08)
Code Type:           ARM-64 (Native)
Role:                Background
Parent Process:      launchd [1]
Coalition:           org.openscad.OpenSCAD [40358]

Date/Time:           2023-10-08 21:20:39.7683 +0200
Launch Time:         2023-10-08 21:20:38.3004 +0200
OS Version:          macOS 14.0 (23A344)
Release Type:        User
Report Version:      104

Exception Type:  EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid))
Exception Subtype: UNKNOWN_0x32 at 0x000000010073c000
Exception Codes: 0x0000000000000032, 0x000000010073c000
VM Region Info: 0x10073c000 is in 0x10073c000-0x101394000;  bytes after start: 0  bytes before end: 12943359
      REGION TYPE                    START - END         [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      UNUSED SPACE AT START
--->  __TEXT                      10073c000-101394000    [ 12.3M] r-x/r-x SM=COW  
      __DATA_CONST                101394000-1013c0000    [  176K] rw-/rw- SM=COW  
Termination Reason: CODESIGNING 2 Invalid Page

Triggered by Thread:  0

Thread 0 Crashed:
0                                 	       0x101d62204 dyld3::MachOFile::forEachLoadCommand(Diagnostics&, void (load_command const*, bool&) block_pointer) const + 52
1                                 	       0x101d642ac dyld3::MachOFile::forEachSupportedPlatform(void (dyld3::Platform, unsigned int, unsigned int) block_pointer) const + 160
2                                 	       0x101db98dc dyld3::MachOFile::isBuiltForSimulator() const + 124
3                                 	       0x101d65b88 start + 992

[kintel]

Thanks, I'll keep investigating..

[kintel]

@tcurdt New try: https://output.circle-artifacts.com/output/job/367a9863-2b66-404c-8410-75b75d589a14/artifacts/0/tmp/out/OpenSCAD-2023.10.11.dmg

[tcurdt]

@kintel No longer crashes! After I removed the quarantine, I opened a few files but unfortunately it still forgets the permissions given.

Side note: During the lifetime of the ticket I have since upgraded to macOS 14 and are still seeing the exact same behaviour.

[kintel]

Thanks for testing! Next I'll try to manually sign the same bundle and see if that changes anything

[kintel]

@tcurdt One more time, this time manually re-signed the app bundle which was previously signed by macdeployqt: https://files.openscad.org/OpenSCAD-2023.10.11-signed.dmg

[DavidPhillipOster]

I'm on macOS Ventura 13.5.2, on an M1 Mini. When I launch the Openscad on OpenSCAD-2023.10.11-signed.dmg - on first launch the OS says in an alert box that it can't verify that it has no malware, so I <control>-click opened it, and on following launches it did not ask. The first time I opened a .scad file on auxiliary disk the OS asked in alert box if I should give OpenSCAD permission. It did not ask on following launches.

Even when I opened and previewed .scad files that used libraries (example: the first line of one file was use <threads_2.6.scad>; ) the OS did not ask for permission to access my ~/Documents directory.

But, that isn't surprising. Last year I was so annoyed by the repeating OS alert that I added a file: ~/Library/LaunchAgents/davids.environment.setup.plist containing:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>davids.environment.setup</string>
  <key>ProgramArguments</key>
  <array>
    <string>/bin/launchctl</string>
    <string>setenv</string>
    <string>OPENSCADPATH</string>
    <string>/Users/david/Library/Application Support/OpenSCAD/libraries</string>
  </array>
  <key>RunAtLoad</key>
  <true/>
</dict>
</plist>

to set the environment variable that ordinary double-clicked apps see to move my library directory somewhere that OpenSCAD is already allowed to see.

Edit to add: I tried launching OpenSCAD from the commandl ine via: /Applications/OpenSCAD.app/Contents/MacOS/OpenSCAD after verifying with printenv that the shell had an incorrect value for OPENSCADPATH - and that instance of OpenSCAD still saw the correct value from the LaunchAgent plist.

[tcurdt]

@kintel Holy smokes - the manually signed one works as expected!
It asks for permission only once. At least on my machine.
🎉

[ndevenish]

Tried the sudo codesign --force --deep --sign - /Applications/OpenSCAD.app command, and after one more permission request it seems to have gone.

This also worked for me. I opened stuff from Downloads without an issue before, but after adding a library to the OpenSCAD path in documents I just got this permissions-infinite-loop.

[gingerbeardman]

Still getting this on the latest dev nightly.

• M1 Pro 2021
• Sonoma 14.4.1

had to do the codesign.

[kintel]

We haven't set up codesign yet - I kind of lost steam after the automated signing failed.