Hello,
We have a macOS App Store app that uses network extension. One of the users is not able to install it since the App Store says "Requires a Mac running macOS 10.15 or later with an Intel 64-bit processor or additional software not available in your country or region"
That user has a Macbook Pro with Apple M1 Max chip and is on Monterey (12.2.1).
However, our app is supported and has been working with M1 chips. We checked with two other users - one with Macbook Air and Apple M1 chip and another one with Macbook Pro/ Apple M1 Max chip / 12.2.1 (same as the problematic user). Both these users are able to install it.
So, we have inconsistency where one user is able to install it and is working fine while for the other user, we get an incompatibility warning.
Does anyone have any idea how to go about this? Also, do we need to collect some logs like Console logs or something?
Post
Replies
Boosts
Views
Activity
Hello again. We have a sandboxed app in macOS App Store.
It has to load dylib files using dlopen(). The dylib files are signed by our vendor. When the app tries to load them, we see this error similar to "mapping process and mapped file have different Team IDs".
We tried adding disable-library-validation but when we do so, the app refuses even to start.
Is there a way to achieve loading of dylibs signed by another team?
Also, this issue happens with only a few users. I don't see this issue on my development machines.
Hello,
I have a sandboxed app distributed through macOS AppStore. It downloads some 'dylib' files from a server(internet) and later loads using dlopen(). But the downloaded files have quarantine flag set and thus Gatekeeper shows a warning when the app loads them.
Added LSFileQuarantineEnabled in info.plist and set to false but it didn't help.
Tried to run a shell command "xattr -d filename" from the app itself but that doesn't work too due to "operation not permitted" error.
Tried [file1 setResourceValue:nil forKey:NSURLQuarantinePropertiesKey error:nil] but even this doesn't make any difference. Although the return value of the call is "YES", the quarantine flag is still there. Note : when i run this method from a non-sandboxed app, it works.
Now I don't have any more options. Is there any way a sandboxed app can download a file and remove the quarantine attribute?
Hello.
We have a VPN app distributed via App Store and it uses Network Extensions (tunnel provider). App Store app works fine.
We have a list of Mac devices added in our profile for testing. Their hardware UUIDs are in the developer profile. When I build the app and run it on one of these Macs, Network Extension refuses to start. The GUI app itself opens fine but when it's time to start VPN, the extension won't start. I get the following error messages :
Signature check failed: code failed to satisfy specified code requirement(s)
NEVPNTunnelPlugin(com.XYZ.XYZ[inactive]): Validation of the extension failed
This happens on Catalina and Big Sur but runs fine on Mojave even though we see the same messages on Console. Do we have to notarise our debug builds also, to run debug builds on test devices? Or do we have to provide another entitlement?
Even if it was an issue with notarisation, I got a popup saying "Cannot check for malicious softwares etc etc" and I went to security preferences and explicitly allowed the app.
Also, it runs fine on the machine it was built on. It just won't run on other test machines.
Hello,
We have a sandboxed app in App Store. It does scans at some point and one of them is checking if a browser is running. e.g. check if "Google Chrome" is running. We use a third party library to do the scan. Apparently, the library calls process-info-listpids and it is denied access. That's why the scan to check if Chrome is running fails.
Here are some of the Console logs (replaced the app name/signing info etc with placeholders) :
Sandbox: APPNAME(40905) deny(1) process-info-listpids
Violation: deny(1) process-info-listpids
Parent Process: debugserver [40906]
MetaData: {"flags":5,"responsible-process-user-uuid":"UUIDNUMBER","hardware":"Mac","pid":40905,"errno":1,"profile-flags":0,"responsible-process-path":"PATHTOPROCESS","summary":"deny(1) process-info-listpids","profile-in-collection":false,"uid":501,"responsible-process-uid":501,"platform-binary":false,"operation":"process-info-listpids","signing-id":"SIGNINGID","team-id":"TEAMID","apple-internal":false,"container":"CONTAINERPATH","build":"Mac OS X 10.15.4 (19E287)","action":"deny","process-path":"PROCESSPATH","platformbinary":"no","process":"PROCESSNAME","platform-policy":false}
The app has access to root directory as we ask for it from user using NSOpenPanel; so no problem with access to folders.
Is there an entitlement to solve this issue?
We have an app company.app and it is loading dynamic library from a thirdparty vendor - let's call it vendor.dylib.company.app is signed by our organisation's developer ID certificate. We have notarized company.app with hardened runtime enabled.vendor.dylib is signed and notarised by vendor's certificate.Now, when company.app tries to load the dylib using dlopen, we get an error "not valid for use in process using Library Validation: mapping process and mapped file (non-platform) have different Team IDs"I read about disabling library validation entitlement https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_disable-library-validation?language=objc and https://forums.developer.apple.com/thread/126895I added this in the info.plist file <key>com.apple.security.cs.disable-library-validation</key> <true/>After building the app and notarising it, i can still see the value com.apple.security.cs.disable-library-validation set to true in the final app's Info.plist.Yet, i get the same error "not valid for use....... mapped file have different Team IDs". It's as if 'disabling library validation entitlement' didn't take effect.Any pointers how to go about this?Note : I cannot opt for a solution where we take vendor.dylib and sign it with our certificate because even though it does seem to solve the loading problem, the vendor's code itself is doing some checksum verification which breaks if vendor.dylib is re-signed with our cert.