I'm new to compiling AIR iOS apps with the command line. My current command looks like this:
./adt -package -target ipa-app-store -storetype pkcs12 -keystore iOS7.p12 -provisioning-profile Africa_DragDrop_iPad.mobileprovision Africa_iPad.ipa Africa_iPad-app.xml Africa_iPad.swf AfricaIcon29.png AfricaIcon40.png AfricaIcon48.png AfricaIcon50.png AfricaIcon57.png AfricaIcon58.png AfricaIcon72.png AfricaIcon76.png AfricaIcon80.png AfricaIcon100.png AfricaIcon114.png AfricaIcon120.png AfricaIcon128.png AfricaIcon144.png AfricaIcon152.png AfricaIcon512.png AfricaIcon1024.png Default-Landscape.png
What is the correct way to add an .ane (AIR Native Extension) to it?
You'll need to add the extension directory to your options:
adt -package
-target ipa-app-store
-provisioning-profile Africa_DragDrop_iPad.mobileprovision
-storetype pkcs12
-keystore iOS7.p12
Africa_iPad.ipa Africa_iPad-app.xml Africa_iPad.swf AfricaIcon29.png AfricaIcon40.png AfricaIcon48.png AfricaIcon50.png AfricaIcon57.png AfricaIcon58.png AfricaIcon72.png AfricaIcon76.png AfricaIcon80.png AfricaIcon100.png AfricaIcon114.png AfricaIcon120.png AfricaIcon128.png AfricaIcon144.png AfricaIcon152.png AfricaIcon512.png AfricaIcon1024.png Default-Landscape.png
-extdir DIRECTORY_CONTAINING_ANES
And also, make sure that you have specified the extensions in the application descriptor node.
More information on the adt directories here: http://help.adobe.com/en_US/air/build/WS901d38e593cd1bac1e63e3d128fc240122-7ff2.html
Related
I am using facebook login integration in my react-native app. Getting invalid hash key error with release key but debug key hash is working fine.
Environment :
"react": "16.0.0"
"react-native": "0.50.4"
"react-native-fbsdk": "^0.7.0"
You have to copy the Hash key of the error, than go to facebook for developer page, select your app, than go to Settings > General and enter the Hask key on the Hash key section. If you test it your Android emulator run this command: keytool -exportcert -alias androiddebugkey -keystore ~/.android/debug.keystore | openssl sha1 -binary | openssl base64, copy the hash key and paste it also on your settings.
Have you tried add new key to FB app ? ( https://developers.facebook.com/apps/ )
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"
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!
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).
How can I find out where my OpenSSL installation is looking for installed (trusted) certificates?
It is sometimes /etc/ssl/cert, but I have a new system and it is not working with this path.
The default path where certificates are looked up might be different on each platform. You can lookup your system configuration using the following command:
$ openssl version -d
OPENSSLDIR: "/etc/pki/tls"
This C snippet, compiled against OpenSSL, will tell you:
#include <stdlib.h>
#include <stdio.h>
#include <openssl/x509.h>
int main()
{
const char *dir;
dir = getenv(X509_get_default_cert_dir_env());
if (!dir)
dir = X509_get_default_cert_dir();
puts(dir);
return 0;
}
The path you are looking for is the "Directory for OpenSSL files". As #tnbt answered, openssl version -d (or -a) gives you the path to this directory. OpenSSL looks here for a file named cert.pem and a subdirectory certs/. Certificates it finds there are treated as trusted by openssl s_client and openssl verify (source: the article, What certificate authorities does OpenSSL recognize?).
% openssl version -d
OPENSSLDIR: "/opt/local/etc/openssl"
% ls -l /opt/local/etc/openssl/cert*
lrwxr-xr-x 1 root admin 40 29 Nov 02:05 /opt/local/etc/openssl/cert.pem -> /opt/local/share/curl/curl-ca-bundle.crt
% head -10 /opt/local/etc/openssl/cert.pem
##
## Bundle of CA Root Certificates
##
## Certificate data from Mozilla as of: Fri Nov 24 08:00:26 2017 GMT
##
## This is a bundle of X.509 certificates of public Certificate Authorities
## (CA). These were automatically extracted from Mozilla's root certificates
## file (certdata.txt). This file can be found in the mozilla source tree:
## https://hg.mozilla.org/releases/mozilla-release/raw-file/default/security/nss/lib/ckfw/builtins/certdata.txt
##
...[rest of file omitted]...
It turns out that the installer which installed OpenSSL on my system also installed cert.pem as a symlink to a bundle of Certificate Authority certificates from the tool cUrl . Those in turn came from Mozilla.
You might have nothing installed in this file or directory, or you might have a different set of certificates. This will affect which server certificates OpenSSL verifies.
OpenSSL commands like s_client support, I think since version 1.1, options -no-CAfile and -no-CApath. These let you ignore the certificates in this file and directory respectively, for the duration of one command. (I can't reproduce this because I am still using version 1.0.2, and it lacks those options.)
How can I find out, where my openssl installed is looking for installed certificates (trusted)?
You can't. OpenSSL trusts nothing by default, and it does not go looking for certs. You have to instruct it what to trust. There's even a FAQ topic covering it: Why does <SSL program> fail with a certificate verify error?:
This problem is usually indicated by log messages saying something
like "unable to get local issuer certificate" or "self signed
certificate". When a certificate is verified its root CA must be
"trusted" by OpenSSL this typically means that the CA certificate must
be placed in a directory or file and the relevant program configured
to read it. The OpenSSL program 'verify' behaves in a similar way and
issues similar error messages: check the verify(1) program manual page
for more information.
Caf's answer is kind of correct, but OpenSSL does not use it and there's nothing there...
$ grep -R X509_get_default_cert_dir *
...
crypto/x509/x509_def.c:const char *X509_get_default_cert_dir(void)
...
In the above, notice it does not hit on anything in the apps/ directory. apps/ is where all the OpenSSL samples and utilities are, like openssl req, openssl rsa, openssl dsa, openssl x509, openssl sign, openssl verify, etc.
Then:
$ cat crypto/x509/x509_def.c
...
const char *X509_get_default_cert_dir(void)
{ return(X509_CERT_DIR); }
...
$ grep -R X509_CERT_DIR *
crypto/cryptlib.h:#define X509_CERT_DIR OPENSSLDIR "/certs"
And finally:
$ ls /usr/local/ssl/certs/
$
Like I said, its not used and there's nothing there.