I'm trying to send a Java application to the MacOS X App Store. All my code is correctly signed (jars, dylib, etc). Unfortunately, when sending the binary, I always get an "Invalid Binary" error with the following message:
Dear developer,
We have discovered one or more issues with your recent delivery for "tamaggo ibi desktop". To process your delivery, the following issues must be corrected:
App sandbox not enabled - The following executables must include the "com.apple.security.app-sandbox" entitlement with a Boolean value of true in the entitlements property list. Refer to the App Sandbox page for more information on sandboxing your app.
• tamaggo ibi.app/Contents/MacOS/JavaAppLauncher
Once these issues have been corrected, go to the Version Details page and click "Ready to Upload Binary." Continue through the submission process until the app status is "Waiting for Upload." You can then deliver the corrected binary.
Regards,
The App Store team
I Googled this for an entire day but didn't find anything. Does anybody have a clue how to sandbox the JavaAppLauncher in the .entitlements file ?
In order to give more informations, here is how I'm signing the code:
/usr/bin/codesign --resource-rules desktop-app/target/dist/myApp/Contents/ResourceRules.plist --verbose --force --sign "3rd Party Mac Developer Application: XXX" desktop-app/target/dist/myApp
find desktop-app/target/dist/myApp.app/Contents/ -type f \( -name "*.jnilib" -or -name "*.jar" -or -name "*.dylib" \) -exec codesign --resource-rules desktop-app/target/dist/myApp.app/Contents/ResourceRules.plist --verbose -f -s "3rd Party Mac Developer Application: XXX" --entitlements desktop-app/target/dist/myApp.app/Contents/myApp.entitlements {} \;
codesign --resource-rules desktop-app/target/dist/myApp.app/Contents/ResourceRules.plist --verbose --force --sign "3rd Party Mac Developer Application: XXX" desktop-app/target/dist/myApp.app/Contents/Resources/binaries/ffmpeg
codesign --resource-rules desktop-app/target/dist/myApp.app/Contents/ResourceRules.plist --verbose --force --sign "3rd Party Mac Developer Application: XXX" desktop-app/target/dist/myApp.app/Contents/MacOS/JavaAppLauncher
We've had a java app on the MAS since late summer 2012. I think we were the first java app on the store (more info at infinitekind.com).
I think one issue is how you are signing. To be accepted on the app store you'll need to bundle a JDK. This can be done using the appbundler ant task. We've created a fork of this with a few improvements since the official one seems to be stagnant and not accepting updates:
https://bitbucket.org/infinitekind/appbundler
We've also created a fork of the OpenJDK with a couple of minor fixes that were dealbreakers (menu item keyboard shortcut issues) for us. These may now have been incorporated into the mainline OpenJDK, but I don't think so.
https://bitbucket.org/infinitekind/openjdk7u-jdk
Anyway, the above two items may not be necessary in your case, but that's how we did it and it worked. I think the real problem is what you are signing and in which order. Here's what we do and it's been accepted for five update submissions now:
# sign all the jar and dylib files (signing jars is apparently not required by apple, but should be!)
find "Path/To/App/AppName.app/Contents" -type f \( -name "*.jar" -or -name "*.dylib" \) -exec codesign -f -s '3rd Party Mac Developer Application: YourCompanyName' --entitlements 'path/to/AppName.entitlements' {} \;
# Sign the JDK plugin
codesign --verbose -f -s '3rd Party Mac Developer Application: YourCompanyName' --entitlements 'path/to/AppName.entitlements' "Path/To/App/AppName.app/Contents/Plugins/jdk"
# sign the whole bundle
codesign --verbose -f -s '3rd Party Mac Developer Application: YourCompanyName' --entitlements 'path/to/AppName.entitlements' "Path/To/App/AppName.app"
Hope this isn't too late to be helpful!
Related
I tried to build the Android SDK Addon System Image of halogenOS 13 (AOSP 13, nothing was changed in the AOSP source code yet).
The steps to build are as usual:
source build/envsetup.sh
lunch aosp_sdk_phone_x86_64-eng
m sdk_addon
At 100%, the build fails with following error:
[100% 12483/12483] Packaging SDK Addon System-Image: out/host/linux-x86/sdk_addon/custom-eng.simao--
FAILED: out/host/linux-x86/sdk_addon/custom-eng.simao--img.zip
/bin/bash -c "(cp -R out/target/product/emulator_x86_64/data out/host/linux-x86/obj/SDK_ADDON/custom_intermediates/custom-eng.simao--img/images/x86_64/data ) && (out/host/linux-x86/bin/soong_zip -o out/host/linux-x86/sdk_addon/custom-eng.simao--img.zip -C out/host/linux-x86/obj/SDK_ADDON/custom_intermediates/custom-eng.simao--img/images/ -D out/host/linux-x86/obj/SDK_ADDON/custom_intermediates/custom-eng.simao--img/images/x86_64 )"
cp: bad 'out/target/product/emulator_x86_64/data': No such file or directory
13:17:13 ninja failed with: exit status 1
If I just mkdir out/target/product/emulator_x86_64/data, of course, that just solves the build error but the SDK addon does not actually boot in the emulator due to encryption issues with the userdata partition so I think this is related. This makes me guess that in the data directory there should be some files in there but for some reason the are not created.
EDIT:
What's really odd here is that the file device/generic/goldfish/vendor.mk explicitly adds some data files to PRODUCT_COPY_FILES, notably:
PRODUCT_COPY_FILES += \
device/generic/goldfish/data/etc/dtb.img:dtb.img \
device/generic/goldfish/emulator-info.txt:data/misc/emulator/version.txt \
device/generic/goldfish/data/etc/apns-conf.xml:data/misc/apns/apns-conf.xml \
device/generic/goldfish/radio/RadioConfig/radioconfig.xml:data/misc/emulator/config/radioconfig.xml \
device/generic/goldfish/data/etc/iccprofile_for_sim0.xml:data/misc/modem_simulator/iccprofile_for_sim0.xml \
If I manually build them using, for example, m out/target/product/emulator_x86_64/data/misc/emulator/version.txt, the file is created at the correct location, as expected. Which leads me to wonder when entries PRODUCT_COPY_FILES are considered targets to be built and when they aren't.
EDIT2:
I got the emulator to boot but the data directory is still not being created. (Creating manually or building one target in the data dir is a workaorund).
Yesterday I was having an issue to run my app after auto code signing. See the question I post here yesterday.
After spending some time to investigate the issue it turns out the framework certificate somehow corrupted.
The solution is to fix the invalid signature for the framework, and here is how to do so.
P.S. One thing we are certain is that we did tick the Sign On Copy checkbox.
NOTE: VideoBuilderLibrary is a custom framework we built.
To test the code sign state,
# Replace the framework to yours
codesign -v
frameworks/VideoBuilderLibrary.framework/Frameworks/libavutil.55.dylib
[no output]
If there is any invalid signature,
codesign -v
frameworks/VideoBuilderLibrary.framework/Frameworks/libavutil.55.dylib
frameworks/VideoBuilderLibrary.framework/Frameworks/libavutil.55.dylib:
invalid signature (code or signature have been modified)
In architecture: x86_64
To resigned all dylib files in a framewor and fix this, run command below with "YOUR CERTIFICATE NAME" replaced with your cert file name,
cd frameworks/VideoBuilderLibrary.framework/Frameworks
ls | xargs codesign -f -s "YOUR CERTIFICATE NAME"
To all,
I'm trying to run a makefile using the 'mex' command through Matlab. However,
when I try to run my test .m script using 'compile_mex;" I get the following error:
>> compile_mex
xcodebuild: error: SDK "macosx10.7" cannot be located.
xcrun: error: unable to find utility "clang++", not a developer tool or in PATH
mex: compile of ' "mex/perform_nlmeans_mex.cpp"' failed.
I've read through a couple of sources that a shell script may need to be written
to physically add the clang++ utility through a library that I need to import into
Matlab directly. Does anyone know how to fix/perform this? A sample or example shell
script and directions on how to use that script within or in coordination with
Matlab would be great if anyone can provide me this. Thanks!
A temporary workaround is given here. Effectively it amounts to getting MATLAB to use a different SDK (as the 10.7 SDK is removed in Mavericks). From the link:
Just for clarity in case someone else runs into the same issue, I
changed four lines in mexopts.sh:
# CC='xcrun -sdk macosx10.7 clang'
CC='xcrun -sdk macosx10.8 clang'
# MW_SDK_TEMP="find `xcode-select -print-path` -name MacOSX10.7.sdk"
MW_SDK_TEMP="find `xcode-select -print-path` -name MacOSX10.8.sdk"
# MACOSX_DEPLOYMENT_TARGET='10.7'
MACOSX_DEPLOYMENT_TARGET='10.8'
# CXX='xcrun -sdk macosx10.7 clang++'
CXX='xcrun -sdk macosx10.8 clang++'
I also had to do "mex -setup" from inside matlab in order to copy
mexopts.sh to my user directory.
When I did this change I directly edited ~/.matlab/R2013a/mexopts.sh rather than .matlab/R2013a/mexopts.sh – I felt this was slightly safer. It also removes the requirement to rerun mex -setup, but of course this means that the file can be overwritten.
For 10.9:
CC='xcrun -sdk macosx10.9 clang'
MW_SDK_TEMP="find `xcode-select -print-path` -name MacOSX10.9.sdk"
MACOSX_DEPLOYMENT_TARGET='10.9'
CXX='xcrun -sdk macosx10.9 clang++'
I have just learned about the possibility to use OTHER_CODE_SIGN_FLAGS to specify the keychain which includes the cert needed for building and signing an app. But unfortunately I cannot get it to work.
My script looks something like this:
#!/bin/bash
TARGET="MyProject"
CONFIGURATION="Release"
SDK="iphoneos"
IDENTITY="iPhone Developer: John Doe (XX22RR22O)"
KEYCHAIN="/Users/username/Library/Keychains/someKeyChain.keychain"
PASSWORD=""
security unlock-keychain -p ${PASSWORD} ${KEYCHAIN}
xcodebuild -target "${TARGET}" -configuration ${CONFIGURATION} -sdk $SDK CODE_SIGN_IDENTITY="${IDENTITY}" OTHER_CODE_SIGN_FLAGS="--keychain ${KEYCHAIN}"
But that fails:
Check dependencies
[BEROR]Code Sign error: The identity 'iPhone Developer: John Doe (XX22RR22O)' doesn't match any valid certificate/private key pair in the default keychain
But if I switch to the keychain first it works but that is not useable on a build server where multiple builds could happen simultaneously:
#!/bin/bash
TARGET="MyProject"
CONFIGURATION="Release"
SDK="iphoneos"
IDENTITY="iPhone Developer: John Doe (XX22RR22O)"
KEYCHAIN="/Users/username/Library/Keychains/someKeyChain.keychain"
PASSWORD=""
security unlock-keychain -p ${PASSWORD} ${KEYCHAIN}
security default-keychain -s ${KEYCHAIN}
xcodebuild -target "${TARGET}" -configuration ${CONFIGURATION} -sdk $SDK CODE_SIGN_IDENTITY="${IDENTITY}" OTHER_CODE_SIGN_FLAGS="--keychain ${KEYCHAIN}"
Hope you guys can help
-Morten
I found that if I didn't add the keychain to keychain search list, xcodebuild would not respect the OTHER_CODE_SIGN_FLAG --keychain setting. I had to add this code:
// Early in the script
ORIGINAL_KEYCHAINS=`security list-keychains -d user`
// After I create my keychain, add it to the list
security list-keychains -d user -s ${ORIGINAL_KEYCHAINS} "${KEYCHAIN_NAME}"
// On cleanup
security list-keychains -d user -s ${ORIGINAL_KEYCHAINS}
Needless to say, I lost hours figuring this out.
Also of help, making sure the keychain stays open for the length of your build. As advised here:
security -v set-keychain-settings -lut 7200 ${KEYCHAIN_NAME}
The answer is to upgrade: Xcode 4.3 respects the OTHER_CODE_SIGN_FLAGS flag during the Check dependencies build step.
I ran into the same problem while trying to set up CI for our iOS projects. I ended up updating the PackageApplication Perl script to support passing a keychain option. Location:
/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/PackageApplication
I'm still waiting for some licensing clarification from Apple so that I can publish my updated script to GitHub.
None of these really works unless you have the simplest of scripted builds going. Like #Tyler said, PackageApplication doesn't support specifying the keychain, and some versions of xcode will require there be no duplicate certificates across keychains when they check dependencies.
Don't waste your times, just call Apple and ask them to rename one of your certificates (they will actually rename your company --- by appending a suffix --- and you just have to regenerate your certificates and update your profiles).
CodeSign "build/Release-iphoneos/Nice Saying123.app"
cd "/Users/c28/Documents/Office Projects/Nice Saying123"
setenv PATH "/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
setenv _CODESIGN_ALLOCATE_ /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/codesign_allocate
/usr/bin/codesign -f -s "iPhone Developer: dipak kasabwala (29QJU3WV6X)" "--resource-rules=/Users/c28/Documents/Office Projects/Nice Saying123/build/Release-iphoneos/Nice Saying123.app/ResourceRules.plist" --entitlements "/Users/c28/Documents/Office Projects/Nice Saying123/build/Nice Saying123.build/Release-iphoneos/Nice Saying123.build/Nice Saying123.xcent" "/Users/c28/Documents/Office Projects/Nice Saying123/build/Release-iphoneos/Nice Saying123.app"
/Users/c28/Documents/Office Projects/Nice Saying123/build/Release-iphoneos/Nice Saying123.app: replacing invalid existing signature
/Users/c28/Documents/Office Projects/Nice Saying123/build/Release-iphoneos/Nice Saying123.app: CSSMERR_TP_NOT_TRUSTED
Command /usr/bin/codesign failed with exit code 1
I had the exact same error, and tried everything under the sun, including what was on the discussions.apple.com link above. What the problem was for me was that in Keychain Access, the actual Apple WWDR certificate was marked as "Always Trust". It needed to be "System Defaults". That goes for your Development and Distribution certificates, too. If any of them are incorrectly set to "Always Trust", that can apparently cause this problem.
So, in Keychain Access, click on the Apple Worldwide Developer Relations Certificate Authority certificate, select Get Info. Then, expand the Trust settings, and for the combo box for "When using this certificate:", choose "System Defaults".
It's very confusing that selecting "Always Trust" produces an error claiming that something is not trusted :( ... but that's the way it is apparently!
Hattip to #MariaZverina, whose comment/link provided help on this issue.
Edit: you may need to check both Login and System certificates, looking for this problem.
Even I had tried everything everywhere :) but what Nate says is true, it works :)
Just make sure you check both login and system certificates , mine had the System certificates set to Always Trust, making me overlook them.
Apple Code signing authority and Apple Worldwide Developer Relations Certificate Authority.
my error was :
/Users/XXXXXXXX/Library/Developer/Xcode/DerivedData/XXXXXXXXXX-fictlumohhjzjxcfmyfpwvrjakqa/Build/Products/Debug-iphoneos/XXXX XXX.app: object file format unrecognized, invalid, or unsuitable
Command /usr/bin/codesign failed with exit code 1
Try below.
Development system : OSX Lion, Xcode 4.1 iOS 4.3
if you have copied a successfully archived project and modified it for a new version, the copied version may run fine in simulator. But Distribution archive may get the above error. It took a day for me to sort this issue.
Right click Your_Project.xcodeproj> Show package contents & edit project.pbxproj file.
Solution :
- The Info.plist file may be having more than two copies in the project folders. As well wrong/multiple references in configuration sections inside the pbxproj file. o I have deleted those lines except referring them from Build configuration(Distribution). Set the info.plist reference in project settings as below.
Finally check the distribution settings should be like this..
8917E65D14244E5100B703F8 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ALWAYS_SEARCH_USER_PATHS = NO;
ARCHS = "$(ARCHS_UNIVERSAL_IPHONE_OS)";
CODE_SIGN_ENTITLEMENTS = "";
CODE_SIGN_IDENTITY = "iPhone Distribution: XXXXXXXX XXXXXXX";
"CODE_SIGN_IDENTITY[sdk=iphoneos*]" = "iPhone Distribution: XXXXXXXX XXXXXXX";
COPY_PHASE_STRIP = YES;
GCC_PRECOMPILE_PREFIX_HEADER = YES;
GCC_PREFIX_HEADER = XXXXX_Prefix.pch;
INFOPLIST_FILE = Info.plist;
IPHONEOS_DEPLOYMENT_TARGET = 4.3;
ONLY_ACTIVE_ARCH = NO;
PRODUCT_NAME = "Product Name";
PROVISIONING_PROFILE = "XXXXXXXX-XXXX-4ACA-A26E-XXXXXXXXXXXXX";
"PROVISIONING_PROFILE[sdk=iphoneos*]" = "XXXXXXXX-XXXX-4ACA-A26E-XXXXXXXXXXXXX";
SDKROOT = iphoneos4.3;
SEPARATE_STRIP = YES;
TARGETED_DEVICE_FAMILY = 2;
VALIDATE_PRODUCT = YES;
WRAPPER_EXTENSION = app;
};
name = Distribution;
};
In my case, it turned out to be because neither of the necessary intermediate certificates were installed (Apple WWDR and Developer ID). I just set up a new computer and exported my developer profile from my old machine, which bundles up all of the necessary certificates, keys, provisioning profiles, etc. into a single file, making a neat little package that can be backed up, or in my case, easily moved to a new machine. Unfortunately I had assumed that the intermediate certs would come along for the ride. They didn't. Downloading the intermediate certificates from the Apple developer site and installing those using Keychain Access did the trick.
Note there are two intermediate certificates: the Apple WWDR Intermediate Certificate (which covers both iOS and Mac App Store development and distribution), but there is also a separate Developer ID Intermediate Certificate (which covers Developer IDs, e.g. distributing outside of the App Store).
This occurred for me after another certificate was added to my keychain.
This is a senseless fix, but having tried everything, I unlocked/locked the login keychain and everything was fixed.
hmmmm.
In my case it was the "iPhone Developer" certificate which was marked as "Always Trust". After switching to "System Defaults" it works like a charm! :-)
I also was able to make it work by selecting "System Defaults"