I want to notarize an existing Qt app for Mac OSX.
I do not have an Apple Developer ID which makes things a bit harder, nevertheless, according to Apple's workflow description, this should be possible.
I created a so called app-specific password (why is it app-specific? nobody asked me for the app's name when I created that password???)
This password I pass along with my apple-id into altool.
I started by "hardening" my app with
codesign --deep -s "XXXXXXXXXXXXX" --options runtime --timestamp "my-app.app/"
Then I build my package as usual and put everything into a dmg.
XXXXXXXXXXXXX is a long number that I found next to my developer certificate (see below).
My problem: whenever I call
xcrun altool --notarize-app -t osx -f my-app.dmg --primary-bundle-id="com.bundle.app" -u "my-apple#id.net" -p "xxxx-xxxx-xxxx-xxxx"
I get:
The username my-apple#id.net is not a member of the provider
According to this source, this error means that the TeamID is not correct - but where does the TeamID come in anyhow? I found my Organization-ID in the certificate I identified with security find-identity -v -p codesigning. But where does this ID go to? Into the Info.plist? But which key?
If I put my local username or the app-specific-passwords user name behind -u instead of my apple id, I get
*** Error: Unable to validate your application. This person is not active.
EDIT: Calling iTMSTransporter -m provider -u my-apple#id.net -p #file:password.txt gives
Neither an encoding house user nor an iTunesConnect user was found.
The error code is: 1080
So it looks as if -u apple-id is wrong, but what other user can I pass?
Related
I want to set and get a password in MacOS Keychain Access that is only accessible by a specific golang binary without confirmation prompt.
Any other apps trying to access should require the password before being able to get the password.
It works for a specific binary. But if I build a new binary it starts requiring the password.
Already tried signing the binary with a self signed certificate but does not seem to work.
codesign --force --verify --verbose=4 --deep --timestamp --options=runtime \
--sign "My Self Signed Key" \
ssh-agent
Any ideas? What can I be doing wrong?
I'm trying to codesign + notarize from the command line a small executable file generated out of a javascript file without success. This file is a very simple CLI tool, aimed to be used through the mac's terminal.
downloading the file and attempting to run it results in the error:
"testBinaryFile can’t be opened because the identity of the developer
cannot be confirmed."
(and running it from the terminal, as it should be, results in a "killed" status on the process").
These are the steps that I did:
0. bundling the code into an executable (named testBinaryFile)
Codesigning the executable with:
codesign -s CERTIFICATE_UUID --timestamp -o runtime -v testBinaryFile --force
zipping the executable (so it can be uploaded for notarization):
ditto -c -k testBinaryFile testBinaryFile.zip
sending the zip for notarization:
xcrun altool --notarize-app \
--primary-bundle-id io.test.bundled \
--username <OUR_APPLE_ID> \
--password <OUR_APPLE_APP_SPECIFIC_PASS> \
--file testBinaryFile.zip
polling service until we get back a success notarization message with:
xcrun altool --notarization-info REQUEST_ID -u <OUR_APPLE_ID> -p <OUR_APPLE_APP_SPECIFIC_PASS>
Uploading the zip file to our hosting in Github (also tried on Google's hosting services)
Downloading the zip file, extracting it, and trying to run it -> results in the error attached above.
other notes:
*I have an "Apple Developer ID certificate" that allows distributing the bundled executable outside of the AppStore.
*I use the same bundled executable inside a notarized .dmg installer containing ".app” application (and the bundle inside its /resources), and there I manage to use it without any issues at all
Any clues on how to make it work also just for the bundle?
It is not possible to use certificates from third-party providers (eg Comodo, DigiCert) because such certificates will not pass Gatekeeper which requires an Apple developer issued certificate.
Your gatekeeper security settings is disallowing this because it is not even an app. It may have been quarantined as a result, meaning you would have to run xattr -d com.apple.quarantine /path/to/file to get it to run.
The less preferred method is to lower your security settings.
Also note that because the notarization ticket cannot be stapled to the binary executable, the user would require internet to access the ticket in order to enable code execution.
I am trying to upload our existing app to apple for notarization.
According to the document https://help.apple.com/xcode/mac/current/#/dev88332a81e
I have to open the app the xcode archive organizer.
We have a dmg file generated from our jenkins build server.
How do I open the dmg file in xcode to upload?
Also, is there some command line tool that I can use for the notarization?
You can do it from the command line.
First you will need to extract the .app from your .dmg and resign it, removing the com.apple.security.get-task-allow entitlement in the process (this is added automatically by the build to support debugging and normally gets removed by archiving - the notarization service won't accept a package with that entitlement, however, so you must remove it).
The .entitlements file you use can just be an empty one.
Xcode 10.2 and higher lets you set a build setting "Code Signing Inject Base Entitlements" that will prevent the com.apple.security.get-task-allow entitlement from being added in the first place. You can use this option on e.g. release builds where debugging is not required, and skip this whole dance of resigning and repackaging with an empty entitlements file.
Note also the use of the --options runtime, which specifies your app was built with the hardened runtime, and is also required.
codesign -f -s "Developer ID Application: Name (ID)" --entitlements my-entitlments.entitlements --options runtime MyApp.app
Now you need to repackage your .app back inside a .dmg, and resign that:
(I use the --options runtime flag here too, though not sure if it's necessary)
codesign -s "Developer ID Application: Name (ID)" MyApp.dmg --options runtime
Then use altool to submit your .dmg:
(Username and password must be someone on the macOS team in the developer portal)
xcrun altool --notarize-app -f MyApp.dmg --primary-bundle-id my-app.myapp -u username -p password
If it upload successfully, you will get back a token:
RequestUUID = 28fad4c5-68b3-4dbf-a0d4-fbde8e6a078f
Then you can check the status with altool, using that token:
xcrun altool --notarization-info 28fad4c5-68b3-4dbf-a0d4-fbde8e6a078f -u username -p password
Eventually, it will either succeed or fail. Just keep checking. Check the "Status" field of the response, which should be "success". The response will also include a log file that you can use to troubleshoot errors.
Assuming it succeeds, you need to staple the notarization to the app:
xcrun stapler staple MyApp.dmg
And then validate:
xcrun stapler validate MyApp.dmg
The validate action worked!
You can also apply the quarantine flag to your .app and try to launch it, you will see the new Gatekeeper dialog:
xattr -w com.apple.quarantine MyApp.app
With Xcode 13 and later, notarization via command-line has come down to these 2 basically:
xcrun notarytool store-credentials "<key>" --apple-id "<your apple id>" --team-id <your teamid> --password "<app specific password>"
and
xcrun notarytool submit <your file>.dmg --keychain-profile "<key>" --wait
At the time of writing this answer, the apple documentation is confusing as they have mentioned using the secret 2FA password instead of the app specific password. You can go through these steps to create an app specific password.
Slightly longer version here: https://blog.rampatra.com/how-to-notarize-a-dmg-or-zip-file-with-the-help-of-xcode-s-notary-tool
I have an OS X app which uses a custom built flow outside of XCode. Therefore, I have to use the codesign tool in command line mode to sign everything within the app. The command line I used is:
codesign -f -s "Developer ID Application: MyCompany Inc" -i com.mycompany.myapp -v $Path_To_App
I first signed every binary, framework and plugins within the app by passing the path of each one of them as $Path_To_App. Then I signed the whole app by passing the path of the app folder MyApp.app.
After that, I used the following command to build a dmg file:
hdiutil create -format UDBZ -srcfolder path_to_app_folder myapp.dmg
If I install this dmg file locally, everything is fine. I believe OS X doesn't even check the certificates in this case. But after I upload the dmg file to the web server, download it with a browser and extract the app into the Applications folder, the OS rejects the app as damaged. The message is:
"MyApp" is damaged and can't be opened. You should move it to the trash.
If I check the signature like this, it is fine:
codesign --verify --verbose /Applications/MyApp.app
/Applications/MyApp.app: valid on disk
/Applications/MyApp.app: satisfies its Designated Requirement
However, if I check it with spctl, it does complain:
spctl -a -v /Applications/MyApp.app
/Applications/MyApp.app: a sealed resource is missing or invalid
I am not sure where I do wrong here. Here is the url of the signed dmg file on the web: http://www.slimjet.com/test/slimjet1.dmg .
Thanks a lot for helping!
Here is an update. The damage warning only shows up when I extract the app into the /Applications folder and run it from there. If I drop it into any other folder and run, or directly run it from mounted dmg archive, it is able to run just fine.
It turned out the gatekeeper keeps cached information about previous failures. Even if you fix the problem by applying all the correct signatures later on, spctl command still reports the same error without actually checking it again. The codesign command doesn't use cache but spctl does. I had to reset the system policy database by the following command:
sudo cp /var/db/.SystemPolicy-default /var/db/SystemPolicy
After that, I restart the OS. Then my app runs just fine. Although spctl has a "--ignore-cache" switch, it doesn't have any effect in this case.
You forgot to also codesign:
FlashPeak Slimjet.app/Contents/Versions/13.0.6.0/FlashPeak Slimjet Helper.app
FlashPeak Slimjet.app/Contents/Versions/13.0.6.0/FlashPeak Slimjet Framework.framework/Resources/app_mode_loader.app
Since they not codesigned this is probably the issue; there could be others, but check these first.
This arose from How to install gdb (debugger) in Mac OSX El Capitan?.
I have macports working under el capitan no problem and have installed the gdb port but I can't get the codesigning to work. It all seems to have worked. The certificate is there and "Always Trust" is set. The binary shows:
$ codesign -d -v -v /opt/local/bin/ggdb
Executable=/opt/local/bin/ggdb
Identifier=org.gnu.gdb
Format=Mach-O thin (x86_64)
CodeDirectory v=20100 size=25320 flags=0x0(none) hashes=1261+2 location=embedded
Signature size=1392
Authority=gdb-cert
Signed Time=23 Oct 2015, 07:56:53
Info.plist entries=4
TeamIdentifier=not set
Sealed Resources=none
Internal requirements count=1 size=88
but I get
(gdb) r
Starting program: /Users/sal/Katiss/ecodriving
Unable to find Mach task port for process-id 39278: (os/kern) failure (0x5).
(please check gdb is codesigned - see taskgated(8))
when I try to start debugging something.
Any ideas?
I just settled this problem by using the following command.
sudo dseditgroup -o edit -a yourusername -t user procmod
Which adds you to group procmod.
It's just because only users in procmod can use function task_for_pid, and you can find that the own group of /opt/local/bin/ggdb is procmod.
I installed MacPorts gcc9 (gcc-9.2.0) on an older iMac (10.11.6 El Capitan), and recently needed to install the gdb port (gdb-9.1.0); predictably encountering the same code-signing / permission issue.
There's a list of instructions on github that worked perfectly for me, simply replacing: /usr/local/bin/gdb with: /opt/local/bin/ggdb. Since such snippets on github may be ephemeral, so I'll paste it here:
Open Keychain Access
In the menu, open Keychain Access > Certificate Assistant > Create a certificate
Give it a name (e.g. gdbc)
Identity type: Self Signed Root
Certificate type: Code Signing
Check: let me override defaults
Continue until it prompts you for: "specify a location for..."
Set Keychain location to System
Create a certificate and close assistant.
Find the certificate in System keychains, right click it > get info (or just double click it)
Expand Trust, set Code signing to always trust
Restart taskgated in terminal: killall taskgated
Enable root account:
Open System Preferences
Go to User & Groups > Unlock
Login Options > "Join" (next to Network Account Server)
Click "Open Directory Utility"
Go up to Edit > Enable Root User
Run codesign -fs gdbc /usr/local/bin/gdb in terminal: this asks for the root password
Disable root account (see #10)
Done!