How to suppress firewall warning when a (signed) networked app runs (from Xcode) - osx-mountain-lion

The Code Signing Identity in Xcode uses my iPhone Developer certificate.
Alas, I still must click Allow each time I try to test the .app in iOS Simulator. "It's just a click", but it gets old after a while.
Can this warning be suppressed? If so, how?
I've already tried (1) manually removing & adding the .app in Mountain Lion's Firewall Options, (2) manually signing the .app from Terminal with codesign, (3) few other things I don't remember.
Regarding the (2): signing the .app manually was "successful" ...
| 492 > codesign -vvv MyApp.app
MyApp.app: valid on disk
MyApp.app: satisfies its Designated Requirement
... but I guess it doesn't work because each xcodebuild replaces the old executable within the .app?
Vaguely related question: Firewall impeding Bonjour network debugging
Also related, later question: How do I get the Mac OS X Firewall to permanently allow my iOS app?

A solution using an automated mouse click:
Download CLIclick. (Thank you Carsten.)
Put it in a suitable location, say /usr/local/bin.
Get the Allow button's screen coordinates using ⌘⇧4. (In my example, these are x: 750, y: 600.)
Create a script with this content (the w: is the wait time in ms):
/usr/local/bin/cliclick c:750,600 w:1500 m:+0,+0 c:.
(I couldn't get CLIclick to work without "moving" it to the same location (the m:+0,+0 part) and clicking again at the same spot (c:.).)
Open Xcode's Preferences / Behaviors and add the above script.
Enjoy!
Of course, the solution of disabling the warning in the first place is still welcome.

Related

Verifying "Xcode" on every macOS boot

every time I start or restart my MacBook, macOS verifies Xcode.
This is not a picture from me I took it from another post but its basically the same just with "Xcode" (the app) instead of the image file.
It takes a while and for the time macOS is verifying Xcode the fan of the MacBook goes like to 100%. While its verifying I can't really use other applications because they freeze and will unfreeze when the verification is finished.
I tried to remove the quarantine xattr from the Xcode.app and recursively from all package components but there never was one set xattr: /Applications/Xcode.app/: No such xattr
I also tried to to reinstall Xcode. When booting into safe mode the same verification window appears.
This happened after I updated my mac to macOS Catalina. If you have any idea what I can try next, let me know.
Ok so apparently in my case there was something messed up with my system. I couldn't find any solution and besides the Xcode problem Reminders always wanted to access a keychain of mine. Not the login, the system or iCloud Keychain but a keychain I created myself just to store and organise some password. And when I clicked on "Deny" Reminders would ask again so I only could close this window and be able to do other things when I allow access.
Anyway after I completely reinstalled macOS (first erase the whole Macintosh HD and then reinstall Catalina) everything works fine.
So if any of you doesn't have that much of data on their Mac just a few files to back up I'd definitely try a reinstall. Took my 3-4 hours and now it works again.

After changing Document Parameters, NSCocoaErrorDomain 256 opening *new* docs

For the next version of a NSDocument-based app, I am revising the document parameters, that is, the values in Info.plist > CFBundleDocumentTypes and UTExportedTypeDeclarations. Specifically, I am changing from a flat NSPersistentDocument to a document package (with the help of BSManagedDocument).
The revised app can create new documents, but they appear in Finder with a generic icon, and when I close such a new document and try to re-open it, -[NSDocumentController openDocumentWithContentsOfURL:display:completionHandler:]fails, creating an error in NSCocoaErrorDomain with code 256, description “newDoc.myExtension” could not be handled because MyApp cannot open files of this type, and failure reason MyApp cannot open files of this type.
I understand that there are several significant parameters CFBundleDocumentTypes and UTExportedTypeDeclarations, and these must all be correct or you get this error. In this case, they are correct. I've confirmed this by comparing the Info.plist in my built product with the Info.plist of a different but similar app that works.
I've also tried calling LSRegisterURL() with inUpdate = true from main(), but that did not help.
What might be wrong? I'm running in macOS 10.12.6, building with macOS 10.13 SDK and Xcode 9.
Apparently the problem is in updating the Launch Services database. I copied the new application, with the revised Info.plist, into /Applications, replacing an old version, then launched this copy once. After these two steps, document icons are now correct when I reopened a Finder window, and upon relaunching my new app, it can now reopen its own new documents without error.
UPDATE: Today (macOS 10.13 Beta 8) I had the same problem, but installing the corrected app into /Applications did not work. However, this time, rebuilding the Launch Services database by running the following command in Terminal, and then relaunching my app, did work:
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -r -domain u -domain s -domain l -v
A side effect of the above is that some apps will have generic icons in the dock and cmd-tab application switcher until relaunched.
I think that either Launch Services much prefers apps in /Applications over apps in Xcode's DerivedData folder, even if the latter is the only one currently running, or running apps from Xcode's DerivedData do not register at all, or both.
It seems from the documentation that calling LSRegisterURL() should have had the same effect, but apparently not.

Gatekeeper quarantine issue with certificate

Our app has been code signed. Our Apple certificate is up to date. Previous versions of our app have run just fine.
However, when the DMG is downloaded by the users, on some Macs the application is quarantined, but for the majority of users, it's not. So some users can open the app and others get the "X.app can’t be opened because the identity of the developer cannot be confirmed."
Luckily I have 2 Macs here that have the quarantine problem, but we can't find a difference between these Macs and the others. Has anyone else run into this problem?
I think you may be a bit confused about how quarantine, code signing, and Gatekeeper work. The error you're seeing is from Gatekeeper, and indicates two different (and independent) things: 1) the app is quarantined (which has to do with how it was downloaded, not how it's signed) and 2) it is not signed in a way that complies with the Gatekeeper policy defined in Security & Privacy preferences. Let me explain these two things in more detail.
Quarantine is a result of the app (or the disk image it was in) being downloaded. When you download a file with a browser, the browser will attach a com.apple.quarantine attribute to it, indicating that it came from an untrusted network source. Other types of internet apps (email, chat, etc) should also attach this attribute to downloaded files.
But not all network download methods will apply the quarantine attribute. For example, copying a file over a file sharing connection (e.g. AFP or SMB) with the Finder will not mark it as being in quarantine. Also, command-line tools like curl and wget won't apply quarantine.
In your case, when you download the .dmg file, it gets marked as quarantined; when you open it, the attribute gets propagated to its contents, so the app is also marked as being in quarantine (and if you copy it to /Applications, the quarantine attribute gets copied along with everything else).
To check whether a file is quarantined, use ls -l# on it and look for the com.apple.quarantine attribute. It's entirely possible that the difference you're seeing between different computers has to do with how the disk image was downloaded and therefore whether the apps are quarantined.
When you open a quarantined app, Gatekeeper checks to see whether it complies with you computer's security policy subsystem. This is where code signing comes into it. You can view and change your policy in System Preferences -> Security & Privacy pane -> General tab -> "Allow apps downloaded from" or with the spctl command-line tool. The default policy is to allow quarantined apps that are from the Mac App Store (i.e. signed with Apple's app store keys) or from an identified developer (i.e. signed with a developer ID key issued by Apple to a registered developer).
When you try to open an app that's quarantined, and not signed in a way that complies with this policy, you get an error saying that "X.app cannot be opened because it is from an unidentified developer" or "... was not downloaded from the Mac App Store." If it's quarantined but does comply with the policy, you get a message that "X.app is an application downloaded from the internet. Are you sure you want to open it?" (with an Open button available). If it's not quarantined, the check is not performed, and the app opens directly.
You can get more information about the code signing and policy status of an application with spctl --assess -vv /path/to/X.app (which'll tell you whether it complies with the Gatekeeper policy) and codesign -dvv /path/to/X.app.
In summary, quarantine is normal and you should expect your users to experience it (and if you're not seeing it on one of your test computers, there's something wrong with how you're testing). Gatekeeper errors depend on both proper signing (check with codesign and spctl) and the Gatekeeper policy settings on the computer; check both to see what's going on.
Gordon Davissons answer is quite extensive and should help in most cases. In my case, it did not.
Besides the two gatekeeper error messages that he mentions, there is a third one and that is the one from your question:
".app can’t be opened because the identity of the developer cannot be confirmed."
In my case this message came up, when an embedded third party framework had a bad run path setting: LD_RUNPATH_SEARCH_PATHS in build settings did reference something that it was not allowed to.
Apple documents this here https://developer.apple.com/library/content/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG207
If an app uses #rpath or an absolute path to link to a dynamic library
outside of the app, the app will be rejected by Gatekeeper.
And they even state:
Neither the codesign nor the spctl tool will show the error. The error
will only appear in the system log.
The solution was to modify the third party framework to something standard like this:
$(inherited) #executable_path/../Frameworks #loader_path/Frameworks

Permission Denied when running Mac app after upgrading to XCode 4.4

I had a working Mac application until I updated to XCode 4.4 and Mountain Lion. Now the application still compiles, but when I try to run it I get an error message.
error: failed to launch '/Users/username/James/mac/Browser/trunk/Browser/DerivedData/Browser/Build/Products/Debug/Browser.app/Contents/MacOS/Browser' -- Permission denied*
Can anybody explain why I might be getting this?
I found this on an iPhone 5 (iOS 6.0) newly set up for development. I had to manually launch the app on the phone, and it said "Are you sure you want to launch this app signed by this devloper?" Once I approved that, the "permission denied" went away and it now launches from Xcode.
Unlock the Device
Try simply unlocking your device before running on it. I was stumped by this very same issue. Upon building and running with no changes to OS, environment, code, etc., I was receiving the error.
Similar questions have been asked here and here, but were not helpful in this situation.
This is caused by an entitlement (and, presumably, having the wrong kind of certificate for it).
If you have the sandbox enabled, and try to sign with a Developer ID certificate, your application will crash on launch (as of Lion—I haven't tried this on Mountain Lion).
If you have iCloud enabled, and try to sign with a Developer ID certificate, your application will not launch at all—in Xcode, you'll get the error message in the question, and in Finder, the application will launch ever so briefly and then get SIGKILLed.
Presumably, there is a right kind of certificate with which one can sign an app in order to be able to test with a sandbox and maybe even iCloud that you can obtain if you have a Mac Developer Program membership. A Developer ID certificate is not that kind of cert.
(That solves my problem, anyway. Dennis, what kind of cert were you trying to sign with?)
Open the organizer and make sure you're mac is in developer mode.
Also check your gatekeeper settings.
The device is seeing the app as an "unauthorized app downloaded from the web" for lack of a better description. Go into Settings > Security & Privacy, and at the bottom, allow applications downloaded from Anywhere.
Throwing a few thoughts on the wall:
Are you perhaps building on an external disk? Some drives get special permissions (like the "ignore permissions" checkbox), or maybe have ACLs set in a weird way. Tried building on internal startup disk?
Are you code signing? Have you tried just turning that off, to see if there's a bug in code signing or entitlements? Not the first time a new codesign tool has a bug.
Have you tried using xcode-select and updating any command line tools that are installed to make sure they all match the version of Xcode used?
Do you have any shell script build phases or the likes that might be editing the application after it's been signed, thus breaking the signature?
Have you checked if your hard disk is full or there's a (broken?) symlink somewhere in a path, or a volume name that has been unmounted?
i am sure this is long been figured out, but I have been getting the Permission denied and it turned out I had to add my laptop to the provisioning profile. I had recently reimaged my machine and in doing so the provisioning profile was no longer valid for that machine. It worked fine until i enabled iCloud. That's when the permission denied started.
Check the organizer in XCODE, click on the devices tab and click on your machine on the left. Check to see that the UDID it shows is listed in the devices section in your mac developer portal.
The short answer is when you get this error message, there is no valid development provisioning profile in the built application.
That alone won't solve your problem! There are a number of common causes of this:
You've moved to a new machine and haven't installed the provisioning profile in Xcode. Also see below
You've moved to a new machine and it's not in developer mode OR not added to the provisioning profile
For both of these, let Xcode regenerate it, or do it yourself in the Member centre... You can validate the causes is something to do with your provisioning profile by running Console and filtering on taskgated where you can see which provisioning profile it is trying to use (it will pull the one embedded in the application first, then try to pull from any installed on the Mac).
Make sure you check in your build settings that the right one is being used for Debug builds. Simple steps that normally resolve (XCode 5)
Go to member centre and create a new development profile
Select the app and certificate
Validate that the machine you are using is in the list of machines to be included in the profile, tick the box
Generate the certificate
Download it, and drag it over the Xcode icon in the doc
Go to the Build Settings tab in your target and set the provisioning profile to the one you've just downloaded
You haven't configured your iCloud/APN/GameCenter entitlements correctly.

How do I build apps to my jailbroken iPad?

I have XCode 3.2.2 and am trying to build an app to my jailbroken iPad. I have followed the tutorial to Fake Code Sign Apps here on Multi-Touch forums. On the iPad, I installed AppSync. Still, when I tried to build my app, I got
Error Starting Executable
No provisioned iPhone OS device is connected.
I think next, I'll try Cydia's tutorial....which probably woulda made sense to do first anyway. I'll post progress here. But in the meanwhile, any suggestions are welcome.
Thanks!
Thomas
OK so clearly, I'm just an idiot. I'm using XCode 3.2.2, which only supports iPad 3.2. My iPad has 3.2.1 installed. Updating my XCode will probably fix this (non) issue lol.
There are three ways to do this:
Self-Signing (from Xcode)
Pseudo-Signing (from device)
Disable Signing
All are detailed and explained here on Saurik's site.
I went with self-signing. Here's the process for those interested.
Self-Signing
Edit Info.plist file
Located at /Developer/Platforms/iPhoneOS.platform/.
Find three occurrences of "XCiPhoneOSCodeSignContext" and replace with "XCCodeSignContext"
Create certificate.
Open Keychain Access >> Click Keychain Access >> Certificate Assistant >> Create a Certificate
give it any name
Self-signed Root
Change type to "Code Signing"
Check "Override defaults"
Click "Continue" until done
Build the app in Xcode.
Edit Project Settings >> Set "Code Signing Identity" to the name of the certificate you just created.
Select the device you want to build to from the dropdown menu (not simulator)
Cmd + B to build
Copy to Device
Get the .app file from the build directory (/build/Debug-iphoneos/AppName.app)
SSH the file over to /Applications directory on the device
Respring/ reboot
In xcode's menu bar, go to windows->organizer. I don't remember exactly what it looks like, but once you plug in an ios device (aka the iPad) it should appear under devices on the left hand side. Click on it, and it will take you to a screen with 2 or so buttons on it, one of which will be 'use for development', or something like that. Clicking this will provision the iPad for development, and everything should work fine after that. Repeat for all other ipads/phones/touches.

Resources