macOS 10.15.5: microphone and camera privacy permissions don't work anymore with .app

[ra1nb0w]

I noticed the following problem with the latest macOS 10.15.5 (maybe with some others minor release):

using PortGroup app 1.0 and app.privacy_microphone yes the pop up that request the permission doesn't show up.

The problem seems related to the fact that the CFBundleExecutable is a symbolic link like in the following example:

/Applications/MacPorts/piHPSDR.app/Contents/MacOS/piHPSDR -> /opt/local/bin/pihpsdr.

Copying the binary into software.app/Contents/MacOS/ or making an hard link resolve the issue.

Someone else noticed the problem? How can we solve this issue? using hard link?

[ryandesign (Ryan Carsten Schmidt)]

Replying to ra1nb0w:

The problem seems related to the fact that the CFBundleExecutable is a symbolic link

It never crossed my mind that that might be a problem. Have you found any documentation stating that using a symlink as the executable is not supported? I found ​https://developer.apple.com/forums/thread/108024 which says codesigning will not work if the executable is a symlink. We don't codesign in MacPorts so that's not a problem, but maybe it points to a more general problem with trying to use symlinks.

If that's so, then we'll have to audit all portfiles that use the app 1.0 portgroup to find the ones that are using the feature of the portgroup that lets the executable be a symlink; modify those ports so that the executable is the real file and maybe put a symlink of it in ${prefix}/bin for example or maybe use hard links instead as you suggested; and change the app portgroup to no longer use or allow symlinks. It could be an opportunity to introduce a new app 1.1 portgroup, that way ports can switch to it gradually and we don't have to do everything at once. Other behaviors and defaults could change in 1.1 as well; for example retina mode could be enabled by default.

[ra1nb0w]

No, I didn't searched any document that proves this but it is a legitimate change thinking how it works.

I don't like the idea to have a symlink on ${prefix}/bin and this is why I proposed the hardlink that maintains the same inode of the binary.

During the weekend, I will try to change the app portgroup and open a PR.

[ryandesign (Ryan Carsten Schmidt)]

I'm not saying a symlink in ${prefix}/bin is the right choice, but why don't you like it?

I'm wary of hard links because they are at first glance indistinguishable from separate files. It may be possible to detect that a file is a hard link of another, but ​Time Machine for example doesn't attempt to do that so if we make a habit of hard linking things that will unnecessarily increase the size of users' backups.

Do consider introducing a new app 1.1 portgroup rather than modifying app 1.0. For example, app 1.0 has the app.executable option, and if that's set to a path within the destroot, it symlinks that into the app bundle as its executable. If you change that behavior in app 1.0, then you immediately have to revbump every port that uses that feature of app 1.0. That's a lot of work identifying all those ports, and a lot of builds for the buildbot to do all at once. So instead, you could introduce app 1.1 that makes app.executable either hardlink it or move the original and put a symlink in its place. Then ports can switch from app 1.0 to 1.1 when it's convenient, for example when they need to update their version anyway. We could enable retina mode by default so that ports don't all have to do it manually. And we could add the new CFBundleDisplayName key. If we can think of any other changes we should be making to app structure generally or to the keys that we add to the Info.plist this would be a good time to do it.

[ra1nb0w]

It is not a matter of taste about symlink it is only consistency: .app is an artifact that we are creating and therefore it should not be the main container of the binary. Obviously, this is my point of view and I generally don't like hardlinks because they complicate maintenance and backup tools (as you said), difficult to discinguish without stat() (as you said) and sometime in the past loops. Said that: the main binary should be not too big since it is linked therefore the backup increase is negligible (I think) and the management of the hardlink is done by macports and only few people investigate the nature of the file. But maybe I am only obstinate on my preliminary remarks :)

Sure for app 1.1.

[kencu (Ken)]

I find the launch script is the better idea 99% of the time, and I almost always use that instead of symlinks.

[ra1nb0w]

see ​https://github.com/macports/macports-ports/pull/7474

[ra1nb0w]

Any comment on the PR?

[ra1nb0w]

@kencu launch script fix the permission problems on maOS >= 10.15?

Any comment about the PR?