Notarier l'application Java existante pour macOS Catalina

Edit 12/2/2020 - il y a eu beaucoup de changements car Apple a lentement resserré les exigences en matière de notarisation. À partir du 3 février, ils semblent avoir atteint la dernière étape, ce qui signifie que votre application doit répondre à des exigences beaucoup plus élevées, y compris un JRE construit sur le dernier SDK et avec un support "durci runtime".

J'ai donc dépouillé une grande partie de l'ancienne discussion.

Mon premier problème était la configuration-vous avez besoin d'un compte de programme Développeur actif avec un identifiant Apple (qui est facile) mais ensuite, lorsque vous suivez les instructions pour ajouter un mot de passe au trousseau, utilisez le Mot de passe spécifique à l'application. Vous devez également activer l'authentification à deux facteurs pour votre compte Apple ID.

Une fois que vous travaillez sur les appels de ligne de commande, il est assez facile d'automatiser dans un script de construction. J'ai utilisé jpackage pour créer l'application et le DMG, mais méfiez - vous - actuellement son approche de la signature de l'app ne fonctionne pas.

En termes de script, voici ce que je fais pour coder sign l'application adaptée à la notarisation (cela suppose qu'un .app est déjà créé):

% security unlock-keychain -p passwordhere codesigning.keychain
% find my-app.app -type f \
  -not -path "*/Contents/runtime/*" \
  -not -path "*/Contents/MacOS/my-app" \
  -not -path "*libapplauncher.dylib" \
  -exec codesign --timestamp --entitlements /tmp/bliss.entitlements -s "XXX" --prefix com.myapp. --options runtime -v --keychain /path/to/codesigning.keychain {} \;

% find my-app.app/Contents/runtime -type f \
  -not -path "*/legal/*" \
  -not -path "*/man/*" \
  -exec codesign -f --timestamp --entitlements /tmp/bliss.entitlements -s "XXX" --prefix com.myapp. --options runtime -v --keychain /path/to/codesigning.keychain {} \;

% codesign -f --timestamp --entitlements /tmp/bliss.entitlements -s "XXX" --prefix com.myapp. --options runtime -v --keychain /path/to/codesigning.keychain my-app.app/Contents/runtime

% codesign -f --timestamp --entitlements /tmp/bliss.entitlements -s "XXX" --prefix com.myapp. --options runtime -v --keychain /path/to/codesigning.keychain my-app.app

Les droits devraient être:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.security.cs.allow-jit</key>
    <true/>
    <key>com.apple.security.cs.allow-unsigned-executable-memory</key>
    <true/>
    <key>com.apple.security.cs.disable-executable-page-protection</key>
    <true/>
    <key>com.apple.security.cs.disable-library-validation</key>
    <true/>
    <key>com.apple.security.cs.allow-dyld-environment-variables</key>
    <true/>
</dict>
</plist>

Tous les tests fonctionnent:

% codesign -vvv --deep --strict my-app.app/Contents/runtime 
my-app.app/Contents/runtime: valid on disk
my-app.app/Contents/runtime: satisfies its Designated Requirement
% codesign -vvv --deep --strict my-app.app/                
--prepared:/private/tmp/my-app.app/Contents/MacOS/libapplauncher.dylib
--validated:/private/tmp/my-app.app/Contents/MacOS/libapplauncher.dylib
my-app.app/: valid on disk
my-app.app/: satisfies its Designated Requirement
% spctl -a -t exec -vv my-app.app          
my-app.app: accepted
source=Developer ID
origin=XXX

À ce stade, vous devriez également essayer d'exécuter votre application - le processus de signature de code peut casser des choses.

À partir de là, vous pouvez créer un DMG (encore une fois, j'utilise jpackage) et cela devrait passer la notarisation.

En résumé:

1. Construire l'application dans la structure correcte
2. Créer un droit fichier
3. Code signez votre code
4. Le code signe les fichiers à l'intérieur de l'exécution groupée, forçant la signature
5. Code signe le runtime fourni lui-même
6. Code signez votre fichier d'application
7. Paquet dans un DMG
8. Légaliser
9. Expédiez-le

• AFAIK, vous avez besoin de Java 11 (voir JDK-8223671), cependant, récemment on m'a dit que Java 8 pouvait également fonctionner. Je n'ai pas essayé ce.

• JDK-8223671 contient quelques informations utiles. Plus précisément, vous devez ajouter des droits à votre appel de signe de code:

codesign --entitlements java.entitlements --options runtime --deep -vvv -f --sign "Developer ID Application: Bla Bla (XXXX)" YourApp.app

Un exemple de travail java.entitlements fichier pourrait ressembler à ceci:

<?xml version="1.0" encoding="UTF-8"?> 
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> 
<plist version="1.0"> 
<dict> 
    <key>com.apple.security.cs.allow-jit</key> 
    <true/> 
    <key>com.apple.security.cs.allow-unsigned-executable-memory</key> 
    <true/> 
    <key>com.apple.security.cs.disable-executable-page-protection</key> 
    <true/> 
    <key>com.apple.security.cs.disable-library-validation</key> 
    <true/> 
    <key>com.apple.security.cs.allow-dyld-environment-variables</key> 
    <true/> 
</dict> 
</plist> 

• Regrouper un runtime généré par jlink est une douleur, car il contient des liens sym (qui ne sont pas autorisés lors de la signature) et aussi un dossier légal qui contient des noms de dossiers comme java.xml (avec un .). codesign est malheureusement un peu stupide et croit que de tels dossiers sont des paquets non reconnus et des abandons. Par conséquent, vous devez renommer ces fichiers / dossiers et résoudre tous les liens sim avant jlinking.

• Si vous utilisez jlink , assurez-vous d'ajouter les fournisseurs de services nécessaires, par exemple jdk.crypto.ec pour HTTPS. Notez également que AFAIK, en Java 11 TLSv1. 3 est au moins partiellement cassé (téléchargement de fichiers volumineux) et vous devez le désactiver, par exemple avec -Dhttps.protocols=TLSv1.1,TLSv1.2.

• Si vous utilisez le fork AppBundler, vous devrez vous assurer qu'il adhère également aux directives d'Apple, c'est-à-dire qu'il est lié à macOS 10.9. Je crois que par défaut AppBundler lie contre 10.7, mais le changer est simple.

• Si vous utilisez Java 11 ou une version ultérieure, assurez-vous que vous bundle libjli.dylib dans /Contents/PlugIns/JAVA_PLUGIN_NAME/Contents/Home/lib/jli/libjli.dylib. Apparemment cela est nécessaire par le lanceur et peut ne pas être livré par défaut.

• Certaines de vos autres questions sont répondues dans les lignes directrices d'Apple :

La notarisation nécessite Xcode 10 ou une version ultérieure. La création d'une nouvelle application pour la notarisation nécessite macOS 10.13.6 ou version ultérieure. L'agrafage d'une application nécessite macOS 10.12 ou version ultérieure.

Pour notarier nécessite Xcode 10, et pour agrafer nécessite au moins Sierra.

"La notarisation nécessite Xcode 10 ou une version ultérieure. La création d'une nouvelle application pour la notarisation nécessite macOS 10.13.6 ou version ultérieure. L'agrafage d'une application nécessite macOS 10.12 ou version ultérieure."https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution

En ce qui concerne le transfert de certificats de développement, laissez Xcode gérer cette tâche en exportant votre profil sur l'ancienne machine et en l'important sur le nouveau.