Trying to run an executable linking to a dynamic library, I get the following error:
Library not loaded:
[...]
Reason: tried:
<lib> not valid for use in process: mapped file has no
cdhash, completely unsigned? Code has to be at least ad-hoc signed.
How can I ad-hoc sign my lib?
First, you can confirm that your library is not signed with:
% codesign -d -v <lib>
Which should say:
<lib>: code object is not signed at all
Ad-hoc sign it with:
% codesign -s - <lib>
Although not advised for a production system, you can bypass the checks with these two build flags.
See Xcode project target settings, Signing and Capabilities,
then clean and rebuild
Related
I am trying to build a Xamarin iOS app using xbuild on Jenkins. Sometimes the build fails during the codesigning process with an unknown error -1=ffffffffffffffff and sometimes the build succeeds. The provisioning profile is stored in a separate keychain jenkins.keychain (not the system or login keychain) that is referenced by Jenkins through the Keychains and Provisioning Profiles Plugin.
This is the console log of Jenkins:
Target _CodesignAppBundle:
Codesign Task
CodesignAllocate: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate
DisableTimestamp: False
Entitlements: obj/iPhone/In-House/Entitlements.xcent
Keychain: <null>
Resources:
bin/iPhone/In-House/MyApp.app
ResourceRules: <null>
SigningKey: 123
ExtraArgs: <null>
IsAppExtension: False
Tool /usr/bin/codesign execution started with arguments: -v --force --sign 123 --entitlements /private/var/lib/jenkins/workspace/Master/Apps/iOS/obj/iPhone/In-House/Entitlements.xcent /private/var/lib/jenkins/workspace/Master/Apps/iOS/bin/iPhone/In-House/MyApp.app
bin/iPhone/In-House/MyApp.app: error : /private/var/lib/jenkins/workspace/Master/Apps/iOS/bin/iPhone/In-House/MyApp.app: replacing existing signature
/private/var/lib/jenkins/workspace/Master/Apps/iOS/bin/iPhone/In-House/MyApp.app: unknown error -1=ffffffffffffffff
Task "Codesign" execution -- FAILED
Done building target "_CodesignAppBundle" in project "/private/var/lib/jenkins/workspace/Master/Apps/iOS/MyApp.csproj".-- FAILED
As suggested in Codesign returned unknown error -1=ffffffffffffffff I added set-key-partition-list -S apple-tool:,apple:,codesign: -s -k ${KEYCHAIN_PW} ${KEYCHAIN_PATH} to my build script but it did not fix the issue.
Do you have any idea how to address this issue? Why is there an existing signature to be replaced?
Update 1 - We keep getting the error after:
switching from xbuild to msbuild version 15.3.0.0
setting jenkins keychain to "Allow all applications to access this item"
deleting the derived data folder
not using relative paths for security commands
A similar problem is described in the Apple forum.
What fixed the issue:
The keychain filename extension changed from *.keychain to *.keychain-db on macOS Sierra. The code signing error was caused by referencing the old keychain file while we were editing in fact the jenkins.keychain-db file containing updated certificates. Keychains with the new extension are rejected from the upload with Jenkins' keychain plugin. So we do not use the keychain plugin any longer and store the signing certificates inside the login.keychain-db. With this we can successfully build the app without the unknown error.
My resolution to this problem was ensuring that the Mac had proper permissions to use the new certificate. I was getting this code signing issue when trying to run a Jenkins job, but things ran properly on my local machine. When I tried manually code signing one of the Swift libraries (e.g. libswiftos.dylib), the Mac then asked for a password to be able to use the new certificate. Once I did that, the Jenkins job ran successfully.
Restarting the Mac could Fix the issue
Xcode 6.1.1
We are trying to sign our app for distribution (or even just to test on physical device). We have a referenced framework in our project. We were under the impression that we should only sign our app itself (and we have all code signing identities, provisioning profiles, etc. set up), but we should not sign this external framework, since we didn't write it. It should be getting its code signing credentials from the parent project.
However every time we try to run on physical device, this referenced framework throws a build error: "CodeSign error: code signing is required for product type 'Framework' in SDK 'iOS 8.1'".
Does this mean we actually have to code sign this?
Specifically, the framework we're trying to use is Alamofire.
I think it depends on where those frameworks come from:
If they're yours (i.e. internal library you're bundling with your project), you need to sign them.
If they come from an open source project that you're building from source (i.e. a pod from Cocoapods) you'll have to sign them.
If they come from a 3rd-party developer they should already be signed.
There's a a step called "Embed Frameworks" under "Build Phases" of the target where you can specify which framework to embed in your bundle and what to code sign:
It doesn't matter if they already have a signature: yours will replace whatever was there.
You can always check the certificate status of a framework with the codesign command line tool:
xcrun codesign --verify --verbose [MYFramework.framework/MYFramework]
and print the singing entity with:
xcrun codesign --display --verbose [MYFramework.framework/MYFramework]
We have an iOS automated build system that is randomly failing the codesign for certain projects.
The build system uses xcodebuild (followed by xcrun) to build and package the application. We use this process across multiple apps. The build machines we run this on have multiple distribution signing certificates, and are running Xcode 5.1.1 (5B1008) and 10.9.4. We've been using the system for about two years now, and builds work fine. When they don't work, there's usually a clear xcodebuild error message. But right now we are getting random failures of the codesign call on xcodebuild for two of our apps.
The xcodebuild command is as follows:
xcodebuild -verbose -project ./src_dir/TechApp.xcodeproj ONLY_ACTIVE_ARCH=NO ARCHS="armv7 armv7s arm64" -scheme ${SCHEME} QA PROVISIONING_PROFILE=${PROFILE} CODE_SIGN_IDENTITY=${IDENTITY} CONFIGURATION_BUILD_DIR=./bld_dir/builds/QA build
And, after lots and lots of xcodebuild compile statements, it fails with the following:
CodeSign /Users/bldUser/buildScripts/archive_dir/1404933111/bld/bld_dir/builds/QA/Tech\ App.app
cd /Users/bldUser/buildScripts/archive_dir/1404933111/bld/src_dir
export CODESIGN_ALLOCATE=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate
export PATH="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/git/bin"
Using code signing identity "iPhone Distribution: Build Certificate" and provisioning profile "BuildWildcard" (C137C14D-630F-4D67-BD2B-2FD4AB4F2BA4)
/usr/bin/codesign --force --sign 637514541007B62BCEA94ACC41A98A0E1391C3D4 --resource-rules=/Users/bldUser/buildScripts/archive_dir/1404933111/bld/bld_dir/builds/QA/Tech\ App.app/ResourceRules.plist --entitlements /Users/bldUser/buildScripts/archive_dir/1404933111/bld/build/TechApp.build/Debug-iphoneos/TechApp\ QA.build/Tech\ App.xcent /Users/bldUser/buildScripts/archive_dir/1404933111/bld/bld_dir/builds/QA/Tech\ App.app
** BUILD FAILED **
The projects in which this are failing are big apps... and they have multiple dependent projects attached to them (and I think that it might be the dependent projects that are contributing to the random failure of the codesign, but I'm not sure).
The thing is that this randomly fails at this statement. If I run it again, it will work fine. So it's the randomness that confuses me. And there really is not any error message. It just says "BUILD FAILED". Some things I've tried to get this to work:
I've passed in additional parameters into xcodebuild OTHER_CODE_SIGN_FLAGS=--verbose=4 --continue --deep in order to see if any combination of these parameters "help." This was based on the problem described in this link, as it seemed to match the failure conditions for our particular projects that are failing. This post had me the most interested, as it seems like this issue may be related to the OS + build environment + the fact that the projects this is failing on have lots of sub-projects attached.
We currently have all our certificates in the login.keychain... but, as per this link (amongst others) there's a suggestion to run certificates off of a build-specific keychain. This is great, and a much cleaner way to do things-- but, after trying this, this had no impact for the issue above.
I thought maybe this might have to do with confusion on certificates-- so I've removed all iPhone Distribution certificates except the the one I need for these apps, and it still comes back with this error.
I've gone in to each of the targets for the projects, including the sub-projects, and put in code signing identity just to make sure there wasn't a possibility that there was some project or sub-project setting that would pick the wrong certificate. In addition, on the xcodebuild command above, I've put in the explicit scheme name and provisioning profile id-- so this is not an issue where it can't find the provisioning profile/certificate combination (or at least I don't think it is-- there's no indicator that it can't find the provisioning profile or certificate)
Given that it's random, I suspect it's either (1) a case where there is some unset code signing value, and it therefore randomly picks one; or (2) some issue with xcode or the os that was only recently introduced.
Any thoughts or ideas on what to try would be much appreciated.
One update:
This works just fine when run through Xcode. So this is something specific to xcodebuild for these projects. When compiled through Xcode: it works 100% of the time. When compiled through xcodebuild: it works like 25-50% of the time. So I'm really hoping there's something I"m missing on the xcodebuild command and this does not require an actual project change (since it works when compiled directly through Xcode).
Update on trojanfoe's question:
There may very well be an issue with spaces. This is the actual xcodebuild call on one of the projects:
xcodebuild -verbose -project /Users/bldUser/buildScripts/archive_dir/1404904225/bld/src_dir/MyTechApp.xcodeproj ONLY_ACTIVE_ARCH="NO" ARCHS="armv7 armv7s arm64" -scheme "TechApp Dev" PROVISIONING_PROFILE="" CODE_SIGN_IDENTITY="iPhone Distribution: Build Certificate" CONFIGURATION_BUILD_DIR="/Users/bldUser/buildScripts/archive_dir/1404897462/bld/bld_dir/builds/Dev" build
After running the command above, there is (lots) of build commands (there are lots and lots of warnings, but no errors). It finally stops at the following:
CodeSign /Users/bldUser/buildScripts/archive_dir/1404897462/bld/bld_dir/builds/Dev/Tech\ App.app
cd /Users/bldUser/buildScripts/archive_dir/1404904225/bld/src_dir
export CODESIGN_ALLOCATE=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate
export PATH="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/git/bin"
Using code signing identity "iPhone Distribution: Build Certificate" and provisioning profile "BuildWildcard" (C137C14D-630F-4D67-BD2B-2FD4AB4F2BA4)
/usr/bin/codesign --force --sign 637514541007B62BCEA94ACC41A98A0E1391C3D4 --resource-rules=/Users/bldUser/buildScripts/archive_dir/1404897462/bld/bld_dir/builds/Dev/Tech\ App.app/ResourceRules.plist --entitlements /Users/bldUser/buildScripts/archive_dir/1404904225/bld/build/MyTechApp.build/Debug-iphoneos/TechApp\ Dev.build/Tech\ App.xcent /Users/bldUser/buildScripts/archive_dir/1404897462/bld/bld_dir/builds/Dev/Tech\ App.app
** BUILD FAILED **
All of the "cd" commands and the "export" commands are run as part of the codesign command. In terms of the xcodebuild statement, we're leaving the provisioning profile blank so it picks up a default-- although even if I specify the specific provisioning profile, it will still fail (and from the code sign above, it IS picking up the correct provisioning profile). The above also specifies the scheme. This is normally run from a bash script where it will loop through an array of schemes and generate builds via xcodebuild for each scheme. As you can see above, there are spaces in the scheme and the project and the product name, so I would not be at all surprised if that were an issue in some way. I'm not sure why it would work one time and not another, but I'm going to try out removing spaces. The src_dir and the funky archive_dir numeric is a directory created by our build system, so the files are all checked out to the src_dir location.
When you specify an entitlement and a code signing identity in build settings (Xcode 4.2.1), you have the following output when you build from Xcode:
ProcessProductPackaging "myAppName.entitlements" "/path/to/myAppName.xcent"
cd /path/to/myAppName/SourceCode
builtin-productPackagingUtility "/path/to/myAppName/SourceCode/myAppName.entitlements" -entitlements -format xml -o "/path/to/myAppName.xcent"
CodeSign "/path/to/Garfields Comic Boom 1.0.app"
cd /path/to/myAppName/SourceCode
setenv CODESIGN_ALLOCATE /Developer/usr/bin/codesign_allocate
/usr/bin/codesign --force --sign "myCertificate" --entitlements "/path/to/myAppName.xcent" "/path/to/myAppName.app"
I would like to sign my app folder at the end of the build, and not during the Xcode build.
My problem is I don't know how to generate the xcent file in the command line.
Question : How do you generate xcent files in command line? I did a find from the root, there is nothing called productPackagingUtility...
I would like to sign my app folder at the end of the build, not during the Xcode build.
IIRC recent versions of Xcode complain if you disable code signing for a device build.
The easiest way around this is to let Xcode sign it and then re-sign it later. Steps are approximately
Dump the original entitlements with codesign -d --entitlements=MyApp.xcent MyApp.app
If you're changing provisioning profiles, copy the new one to MyApp.app/embedded.mobileprovision and modify the entitlements accordingly (IIRC the file format has a 4-byte magic and a 4-byte length; remember to update the length!).
Re-sign with your desired certificate.
Using the codesign utility does not require an xcent file. You can simply create a plist file and use that for entitlements. Make sure it is an XML plist, not binary.
The format of the .entitlements and the ${APPNAME}.xcent is the same so it can just be copied across.
We are enrolled in the iOS Enterprise Program. The provisioning profile used for our released apps is about to expire, so I got a new certificate and provisioning profile.
I need to re-distribute some of our apps with the new provisioning profile, without building them anew. How?
(I vaguely remember seeing a utility program that did exactly this: You choose an IPA and a provisioning profile, and it would create a new IPA using the new profile and certificate. What was the tool’s name, and where can I get it?)
In theory whoever built the last IPA in XCode should have used Archive - this creates a build you can sign to create an IPA (using XCode).
You could also try using the command line signing tool XCRun to re-sign the App bundled in your existing IPA:
http://skabber.com/package-your-ios-application-with-xcrun
OK, turns out when you know what term to google, there‘s lots of excellent resources…
They all point to xcrun. I made it work with this shell snippet, adapted from this promising build script:
APP_FILENAME=MyApp.app
BUILD_DIRECTORY=/Path/To/Target/Dir
IPA_FILENAME=MyApp.ipa
DISTRIBUTION_CERTIFICATE='iPhone Distribution'
PROVISIONING_PROFILE_PATH='/Path/To/Profile.mobileprovision'
/usr/bin/xcrun -sdk iphoneos PackageApplication -v "$APP_FILENAME" -o "$BUILD_DIRECTORY/$IPA_FILENAME" --sign "$DISTRIBUTION_CERTIFICATE" --embed "$PROVISIONING_PROFILE_PATH"
The codesign command-line utility, included with the iOS SDK tools, will allow adding/changing the certificate and provision with which a developer built app is signed.
As hotpaw2's anwaswer states. You can also resign using the codesign tool.
The way I do it (this may not be the most efficient, but it works)
Rename the .ipa to a .zip and extract
Run The following:
/usr/bin/codesign -f -s "iPhone Distribution: Company Name" "Payload/MyApp.app"
Re-zip the Payload folder and rename to .ipa
Note: You can also use this method to edit the embedded.mobileprovisioning file! Just remember to remove the .DS_Store (rm Payload/.DS_Store) if you are using finder.
You can do manual way if you just resigning app from same account with following steps.
All this is using shell script and super easy provided you know how to use shell commands.
Rename IPA to zip
unzip this file to temp folder
Remove the old _CodeSignature folder from all targets (if you have multiple targets like main,watch, watch extn, siri, widget, message, etc)
bring all the targets prov-profiles in one folder and replace all the embedded.provisioningprofile files for each target with the new ones
remove the archived....xccent file as this is old one (optional)
code sign with the entitlements.plist created for all the entitlements if any used by the app.
Zip the folder back after code sign all okay with no errors
Rename the zip to IPA
Note: To validate the IPA before upload to apple you can just use the altool from inbuild XCode App Loader to check the new IPA.
Reference: The steps for commands is also explained here:
http://www.enterpriseios.com/forum/topic/Resigning_3rd_party_apps
If you want to get rid of manual sign use the fastlane tool as its quite simple and easy to configure.https://fastlane.tools/