I am using Sparkle for the first time, and having troubles getting things off the ground. When I check for updates, it correctly detects a newer version, downloads it, unarchives it, and then gives the following error:
Update Error!
An error occurred while extracting the archive. Please try again later.
The output log shows the following detail:
Sparkle: The appcast item for the update has no DSA signature.
The update will be rejected, because both DSA and Apple Code
Signing verification failed.
My archive is named "MyApp.pkg.zip", and contains only "MyApp.pkg". It has an apple ID digital signature. I verified this by downloading the zip manually, extracting it, running the PKG, and clicking the lock icon on the first install page.
The PKG has been created using Packages.
My appcast has the following:
<enclosure url="http://thedomain/MyApp.pkg.zip" sparkle:version="1.0.0.990" length="5752133" type="application/octet-stream" />
My .app also has the same Apple ID signature as the .pkg, though I don't think it matters at this point of the auto-update process.
So my question is: What am I doing wrong? How is Sparkle concluding that the digital signature is not sufficient, when the PKG is clearly digitally signed?
Do you have different certificates for signing the .app and the .pkg? When you go to create the certificate on Apple's Certificates site, you have to choose one or the other type.
You need to have two certificates, one for signing the .app and one for signing the .pkg.
Related
VS2022
I have succesfully built and archived my Xamarin.Forms app. I've used ad hoc distribution many times in this project, successfully.
With my last archive, it failed to sign the package, quoting the error Signing Packages Failed. 'Keystore was tampered with, or password was incorrect.'
I used this process after successfully archiving:
I click Distribute => Ad Hoc.
I select my signing Identity, and select a save location.
I am prompted for my password, which contains only 6 lower case letters.
I get an error:
Signing Packages Failed.
Keystore was tampered with, or password was incorrect.
Following other SO threads I have:
I've rebooted.
I've rebuilt and re-archived.
I have since deleted the keystore.
I've reinstalled xamarin forms after deleting the 'mono for android' folder.
Still, even with a brand new key (taking care for no special characters), the package signing fails.
I'm absolutely tearing my hair out - can anyone advise how to fix this ridiculous problem?
I had successfully uploaded an app for TestFlight but after archiving and uploading now it is giving me this error I can't explain. Just to make sure I unchecked all entitlements in the capabilities target tab but that doesn't seem to matter.
I looked over all the app id's, certificates and provisioning profiles but there's nothing that looks abnormal. I would look in the actual .plist file generated by Xcode but I don't see where it is or if it even exists. Where should I even check to verify what's going on? Xcode is a buggy mess so I don't even trust this isn't some random bug (I cleaned the target of course just to make sure).
Automatic signing is unable to resolve an issue with the "..."
target's entitlements. Switch to manual signing and resolve the issue
by downloading a matching provisioning profile from the developer
website. Alternatively, to continue using automatic signing, remove
these entitlements from your entitlements file and their associated
functionality from your code. Then rebuild your archive and try again.
Provisioning profile failed qualification Profile doesn't match the
entitlements file's value for the application-identifier entitlement.
I had a terrible time with some old projects where I had to use manual signing because I couldn't get automatic provisioning to work. Then I discovered the following solution, which has worked for me 100%:
Switch to automatic provisioning if you haven't already.
Edit the target build settings and search for Sign. You should see four Code Signing Identity entries and they should all say iOS Developer. (If one of them says iOS Distribution, that's the kiss of death.)
Still editing the target build settings, search for Provision. Scroll down to the bottom and see if there is an explicit extra provisioning profile setting giving a profile number. If so, delete it.
Edit the target capabilities. Turn Game Center and iCloud and In-App Purchase on. Now turn them off again. This will give you an empty entitlements file (you can confirm this in the project navigator).
You will now be able to build to a device, archive, and export to the App Store, using automatic signing throughout.
I have had a very similar issue with Xcode 9.4, the only difference being that the error referred to issues with both the application identifier and keychain access groups entitlements.
I switched from automatic Xcode signing to manual signing to try to fix the problem. After some mucking about that did not help (and that I don't think contributed to fixing the problem) I ended up re-enabling the Xcode automatic signing. This appears to have fixed the problem. I was able to clean, archive and upload without any issues.
Not a particularly satisfying answer, but it worked for me.
I am trying to publish my app on the app store but I get this error. I have no idea where it is coming from. My certifications and signing are managed automaticaly by XCode. (Select is empty because I erased it on the screenshot)
Invalid Signature - A sealed resource is missing or invalid. The file
at path [AlphaBane.app/AlphaBane] is not properly signed. Make sure
you have signed your application with a distribution certificate, not
an ad hoc certificate or a development certificate. Verify that the
code signing settings in Xcode are correct at the target level (which
override any values at the project level). Additionally, make sure the
bundle you are uploading was built using a Release target in Xcode,
not a Simulator target. If you are certain your code signing settings
are correct, choose "Clean All" in Xcode, delete the "build" directory
in the Finder, and rebuild your release target. For more information,
please consult
https://developer.apple.com/library/ios/documentation/Security/Conceptual/CodeSigningGuide/Introduction/Introduction.html
https://developer.apple.com/library/ios/documentation/Security/Conceptual/CodeSigningGuide/Introduction/Introduction.html
I started a brand new project with Cordova, and I am still facing this error. As Always, Apple error are self-explained (irony). What do I have to do to fix this error ?
Thanks
I'm seeing the same thing in a project (on Xcode 9.2) with multiple targets (different version of a single app framework) - all targets pass except one. One of my apps continued to get this error. Perfect situation to look into why this is happening. I first thought it was the signature profile (development vs distribution certificate). Check that first.
But in my case, I had a few files that were not being used by the code that I had excluded from the build. When I added these resources my build passed. Check to see that all needed resources are included in the File Inspector panel. This includes code and media resources.
I have an electron app that originally was distributed with a certificate for an individual developer.
I'd like to now sign the next update to that app with a certificate from my organization, but when I do so, existing installations (upon auto update) throw an error that the code requirements aren't met.
Is there a way to properly sign an electron app with both the old and new certificate? I'd like to prevent my existing users from being interrupted.
Any help appreciated!
Thanks
We had a similar situation, with an Electron application for MacOS using auto-update, and we needed to switch to a new certificate without making everyone download and re-install the application manually. The auto-update process needs to recognize the new certificate. Rightfully so, the old version will refuse to update if the new certificate is not recognized.
Our strategy was:
look at the designated requirement (or DR) of the application, when signed with the old certificate, using codesign -d -v -r - <path-to-app>
look at the designated requirement of the application when signed with the new certificate
place the combined designated requirement, that includes both certificates, into an electron-builder-requirements.txt file
make sure that you do not include the identifier in the combined designated requirement string
make a reference to the electron-builder-requirements.txt in the electron-builder.yaml file (add a line under mac: like this requirements: electron-builder-requirements.txt)
publish a new version of the app, signed with the old certificate, but with the DR that contains information about both certificates
wait until nearly everyone has the version running on their desktop that includes mention of both certificates in the DR
update the build so that it uses the new certificate instead, and remove the electron-builder-requirements.txt file
release a new version of the app signed with the new certificate (no requirements file is needed, and it will list only its own cert in the DR)
An older version of the application that has a DR that includes information about both certificates will allow an auto-update to a new version that uses either certificate.
I found this document about signing code manually helpful in understanding the "designated requirement".
Update: here's an example of the electron-builder-requirements.txt file (I've modified some of the letters/numbers for privacy purposes):
designated => certificate leaf = H"2323ce6b0XXXXXXXX39f2064be999999997272b1" or anchor apple generic and certificate 1[field.1.2.840.199995.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.199995.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "6ZXXXXXXUY"
I'm trying to submit an update to my app. I had messed up some files, so had to generate from scratch all of my the certificates, keys, and provisioning files. Would that be a problem for updating? I read someone saying that updates to the app HAVE to be done using the same provisioning file... that can't be true, can it? Otherwise, I'm in major trouble.
Anyhow, my archive builds keep failing validation. I have triple checked that I'm using the Store Distribution certificate for my release. I also ran codesign command and it came through fine. I have also checked the contents of MYAPP.app bundle and the "embedded.mobileprovision" is there. Why does it say "Failed to load"?
Below is the output I get in my log. Any ideas?
(using XCode 4.0.2)
warning: Application failed codesign verification. The signature was invalid, or it was not signed with an Apple submission certificate. (-19011)
Executable=/Users/anna/Library/Developer/Xcode/DerivedData/MYAPP-fjmzhplryhwnsrgcsoyuivpwrojd/Build/Products/Release-iphoneos/MYAPP.app/MYAPP
codesign_wrapper-0.7.10: using Apple CA for profile evaluation
AssertMacros: signer, file: codesign_wrapper.c, line: 610
AssertMacros: profile, file: codesign_wrapper.c, line: 914
codesign_wrapper-0.7.10: Failed to load provision profile from: /Users/anna/Library/Developer/Xcode/DerivedData/MYAPP-fjmzhplryhwnsrgcsoyuivpwrojd/Build/Products/Release-iphoneos/MYAPP.app/embedded.mobileprovision
- (null)
You should remove your distribution certificate from your system. Revoke that certificate from developer portal, create a new one. delete the old provision profile and create a new provision profile for app store and use that.
I ended up resolving my issue by moving over to a different machine that had a clean install of all the dev tools. My original install got corrupted because I foolishly installed beta version over it and then tried to revert back, at which point codesign didn't want to play along anymore. I know that wasn't the smartest thing.. but sometimes you do things for the first time and learn the hard way :)
Anyhow, the good news is that new keys and certificates don't really mess things up and life can go on but watch where you install beta versions!
In dev center you can read that it is critical to store your private key somewhere save. It also says that this private key cannot be reproduced if lost.
Therefore I think you are in trouble.