Ok. I know. This has been covered 100^1000 times here and everywhere, but I have been trying to create my .ipa for submission for the past week (not kidding, thats how much I spent working on just this) and I keep getting this warning. BTW - not sure it makes a difference, but thats an iPad app.
I am getting this warning:
warning: Application failed codesign verification. The signature was invalid, or it was not signed with an iPhone Distribution Certificate. (-19011)
Executable=/Users/username/Library/Developer/Xcode/DerivedData/JudgeIt-ebfrsivdbrxukqhbupfnzzqgoftd/ArchiveIntermediates/JudgeIt/IntermediateBuildFilesPath/UninstalledProducts/JudgeIt.app/JudgeIt
codesign_wrapper-0.7.10: using Apple CA for profile evaluation
Illegal entitlement key/value pair: com.apple.developer.ubiquity-kvstore-identifier, 6366MSW2TK.com.JudgeIt.JudgeIt
Illegal entitlement key/value pair: com.apple.developer.ubiquity-container-identifiers, {type = mutable-small, count = 1, values = (
0 : {contents = "6366MSW2TK.com.JudgeIt.JudgeIt"}
)}
AssertMacros: filter_entitlements(entitlements_whitelist, entitlements_requested, allowable_entitlements), file: codesign_wrapper.c, line: 932
- (null)
I tried:
Delete all the certificates and keys and start all over again
Unistall Xcode
Restarting my computer
Deleting build library
Cleaning project
Also attaching a screenshot of the Code Signing setting of my project - looks ok to me.
UPDATES:
- I am using Xcode 4.2
- All certificates on Keychain are valid and I have one of each (developer, distribution, AWDR)
This might sound totally stupid, but that was the failure message when I wanted to validate my archive yesterday while submitting an app. I had used a "+" sign in the bundle name, and that was the problem source!! Renaming the required fields, I didn't get the code sign error anymore!!
Related
We are developing a document-based Objective-C project, using NSPersistentDocument and NSPersistentStore to save a unique binary file on disk. No autosave.
One customer has a recurring saving issue
The document "something.extension" could not be saved
that we cannot reproduce in our development setup. They can load their saved file without issue, but after a few changes the error pops up when trying to save. In our own setup, using the same build, the file opens and saves without issue.
The error is too vague for us to pinpoint the exact reason why their document would not save, but based on the very basic error message, we have realised the error raised is NSFileWriteUnknownError = 512.
In which situation would that error be raised? In which situation wouldn't the other, more specific error codes be applicable?
We build using SDK 10.14 and both us and the customer run on macOS Monterey 12.3.1
EDITED ON 09/08/22 - Added details based on Willeke's comments.
EDITED ON 17/08/22 - Underlying error
The error's userInfo comes with an underlying error message, which our customer could display. It states "No known persistent store for URL"
Disclaimer: I posted this originally on Code Review but as the code does not currently work I was suggested to post at SO instead.
I have converted the official AWS SDK iOS (v 2.5.0) framework (focusing on S3) to macOS and everything is working as expected with uploads and downloads. However, I wanted to also enable Transfer Acceleration for S3 using AWSTransferManager. I know that you can enable Transfer Acceleration (TA) using the AWSTransferUtility, but that utility uses pre-signed requests that are valid for only 50 minutes (useful for iOS but not macOS). I would like to be able to transfer files that are large and can take hours even when using Transfer Acceleration.
I have edited the original code from AWS to enable TA for AWSTransferManager, however, I still can not get this to work properly as the final signing of the upload/download request fails. The error message is:
Message=The request signature we calculated does not match the signature you provided. Check your key and signing method.}]
For the most part, I have edited the files AWSSignature, AWSS3TransferManager, and AWSService (AWSServiceConfiguration). I think that the signing error occurs because I am editing a path, or URL without correctly code signing the change (probably in AWSSignature.m). As I am uncertain as to where my code breaks, I have created a repository with all of the AWS SKD macOS files required to compile the framework including a unit test. If I run the test initializing the call to AWSServiceConfiguration with:
AWSServiceConfiguration *configuration = [[AWSServiceConfiguration alloc]initWithRegion:[region aws_regionTypeValue] credentialsProvider:credentialsProvider
accelerateModeEnabled:#(NO)
bucketName:self.testBucketName];
Then everything works as expected and the test file uploads and downloads correctly. However, if I try to turn transfer acceleration on (I have already made sure that my bucket has acceleration enabled), then it fails with the code signing error above.
AWSServiceConfiguration *configuration = [[AWSServiceConfiguration alloc]initWithRegion:[region aws_regionTypeValue] credentialsProvider:credentialsProvider
accelerateModeEnabled:#(YES)
bucketName:self.testBucketName];
In fact it seems like the test script is trying to upload a file much larger than what the testfile (3 Mb) really is. I assume my error is related to the signing of the URL body in some way as the size of the file seems wrong.
I know that finding this error requires a bigger effort than what is usually expected at SO and it is not something many will throw themselves at (but hopefully some) as it involves very complex code and it is time-consuming. However, I do believe that if we could make this work then many can find the framework for AWS SKD for macOS + Transfer Acceleration very useful.
I hope you will take a look at try to identify what may be my problem breaking the code signing.
All code for the framework+test example is available here: https://github.com/trondkr/aws-sdk-macos-TA. To run the unit test you need to provide the secret key and access id to your AWS S3 and the name of a bucket that has transfer acceleration enabled.
Thanks. Cheers, Trond
The debug build of some code utilizing SFHFKeychainUtils that is working without complaint on the mac which I'm developing on is triggering an error on another mac:
The code makes use of the following methods provided by SFHFKeychainUtils:
+[SFHFKeychainUtils getPasswordForUsername:andServiceName:accessGroup:error:]
+[SFHFKeychainUtils storeUsername:andPassword:forServiceName:accessGroup:updateExisting:updateExisting:error:]
A password is added for a username using +[SFHFKeychainUtils storeUsername:andPassword:forServiceName:accessGroup:updateExisting:updateExisting:error:]. Some time later, an attempt is made to retrieve the password using +[SFHFKeychainUtils getPasswordForUsername:andServiceName:accessGroup:error:]. However, this method is returning the error; its domain is SFHFKeychainUtilsErrorDomain and its code is -25293 (so it is errSecAuthFailed). This error is only returned when a password is in fact stored in the keychain (or at least when it is visible from Keychain Access).
Why is this taking place?
The problem is a lack of code signing. Code signing is required in order for the second machine to access the keychain. The fix was to enable code signing for the debug build.
This question already has answers here:
How to obtain codesigned application certificate info
(2 answers)
Closed 8 years ago.
I have app signed. I created an identity and used codesign to sign my app as per Apple's Code Signing Guide.
Now, how do I check the signature from within my application?
I need to verify this on Cocoa apps (Objective-C) and apps written in C.
You could use NSTask and run "codesign --verify" and check the exit status. Of corse if the program was altered it could be altered to remove the check, so I'm not sure what that buys you.
If you are not worried about directed tampering (like the kind that might remove your check of the signature) you can use the codesign "kill" option, if you do merely executing means the signature is valid (at least for all pages that have been executed so far...but if a not-yet-resident page has been tampered with you will get killed when that one is read in anyway).
Maybe if you could explain a little more about why you want to verify the signature a better answer could be formed.
Note: Currently MacOS X does not verify signed code prior to execution. This may be different for sandboxed code, and it would seem sensible that it is otherwise anybody could edit the entitlements.
To check an applications signature from within the application itself you use the Code Signing Services. In particular look at SecCodeCheckValidity. The code to do the checking is not long, but there is quite a bit to understand so I won't give a code sample - you need to read and understand the documentation.
Checking the signature allows your application to detect changes to its code & resources and report it is "damaged" (it may well be, not all changes are malicious) and refuse to run. Adding such code does not of course guarantee your code is not damaged, but certainly it does raise the barrier higher against intentional damage (and if MacOS X starts doing the check itself then there will be a big win).
The way signiture verification is implemented on iOS is that when an application is being launched, the launchd daemon decrypts the binary using that device's specific private key (this is why you can't just decompile apps or copy-paste them from one device to another), if the decryption fails, the application fails to launch.
The native tools that do this are not available within applications due to the iOS sandboxing.
If you're simply attempting to track if someone has modified your binary, you can perform an MD5 or SHA1 hash of it, store it in NSUserDefaults and compare it at each app start. If the hash changes between executions you know it has been modified (possibly by a legitimate application update or possibly nefariously.)
Here's an example on how to get the hash of an NSData.
The binary file you're looking for is: AppName.app/AppName
But it clearly does not fail on my system. The Verification test in XCode during the submission should (I assume) test this. And running codesign on the command line of the archived app results in:
/Users/iac/Library/Application Support/Developer/Shared/Archived Applications/272860A0-961E-47E7-B62F-0F7D373D938A.apparchive/Kiwi.app: valid on disk
/Users/iac/Library/Application Support/Developer/Shared/Archived Applications/272860A0-961E-47E7-B62F-0F7D373D938A.apparchive/Kiwi.app: satisfies its Designated Requirement
Anyone run into something like this before?
Thanks,
Isaiah
After a bit of back and forth the app was placed back "In Review" (without any change to the binary). It was then rejected again for another odd reason (No non-apple installers allowed) after which it was again placed back "In Review," (again without any changes to the binary).
After a few more emails it finally received a rejection that made sense: a few files in my resource folder had overly restrictive permissions.
So the answer is: double-check your file permissions or be doomed to weeks of confusion.
Isaiah