Autenticare l'applicazione Java esistente per macOS Catalina

Modifica 12/2/2020 - ci sono stati un sacco di cambiamenti perché Apple hanno lentamente inasprito i requisiti per l'autenticazione notarile. Dal 3 febbraio sembrano aver raggiunto la fase finale, il che significa che la tua app deve soddisfare requisiti molto più elevati, incluso un JRE che è costruito contro l'ultimo SDK e con supporto "runtime indurito".

Così ho spogliato gran parte della vecchia discussione.

Il mio primo problema è stato l'impostazione: è necessario un account Developer Program attivo con ID Apple (che è facile) ma poi, quando si seguono le istruzioni per aggiungere una password al portachiavi, utilizzare il App specifica password. Devi anche abilitare l'autenticazione a due fattori per il tuo account ID Apple.

Una volta elaborate le chiamate da riga di comando, è abbastanza facile automatizzare in uno script di compilazione. Ho usato jpackage per creare l'app e il DMG ma attenzione - attualmente il suo approccio alla firma dell'app non funziona.

In termini di scripting, ecco cosa sto facendo per firmare il codice l'applicazione adatta per l'autenticazione notarile (questo presuppone un .app è già stato creato):

% 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

I diritti dovrebbero essere:

<?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>

Tutti i test funzionano:

% 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

A questo punto dovresti anche provare a eseguire la tua app: il processo di firma del codice può rompere le cose.

Da qui, è possibile creare un DMG (di nuovo, io uso jpackage) e questo dovrebbe passare notarile.

In sintesi:

1. Crea l'app nella struttura corretta
2. Creare un diritto file
3. Codice firma il tuo codice
4. Firma il codice dei file all'interno del runtime in bundle, forzando la firma
5. Firma il codice del runtime in bundle stesso
6. Codice firma il file dell'app
7. Pacchetto in un DMG
8. Autenticarlo
9. Spedirlo

• AFAIK, hai bisogno di Java 11 (vedi JDK-8223671), tuttavia, recentemente mi è stato detto che Java 8 potrebbe anche funzionare. Non ci ho provato.

• JDK-8223671 contiene alcune informazioni utili. In particolare, è necessario aggiungere diritti alla chiamata del segno di codice:

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

Un file di esempio java.entitlements funzionante potrebbe essere simile a questo:

<?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> 

• Raggruppare un runtime generato da jlink è un problema, perché contiene collegamenti sym (che non sono consentiti durante la firma) e anche una cartella legale che contiene nomi di cartelle come java.xml (con un .). codesign è sfortunatamente un po ' stupido e crede che tali cartelle siano bundle e interruzioni non riconosciuti. Pertanto è necessario rinominare tali file / cartelle e risolvere eventuali collegamenti sim prima di jlinking.

• Se si utilizza jlink, assicurarsi di aggiungere i fornitori di servizi necessari, ad esempio jdk.crypto.ec per HTTPS. Si noti inoltre che AFAIK, in Java 11 TLSv1.3 è almeno parzialmente rotto (caricamento di file di grandi dimensioni) e dovresti disabilitarlo, ad esempio con -Dhttps.protocols=TLSv1.1,TLSv1.2.

• Se si utilizza il fork AppBundler, è necessario assicurarsi che aderisca anche alle linee guida di Apple, ovvero che sia collegato a macOS 10.9. Credo che per impostazione predefinita i collegamenti AppBundler contro 10.7, ma cambiarlo è semplice.

• Se si utilizza Java 11 o versione successiva, assicurarsi di raggruppare libjli.dylib in /Contents/PlugIns/JAVA_PLUGIN_NAME/Contents/Home/lib/jli/libjli.dylib. Apparentemente questo è necessario al launcher e potrebbe non esserlo in bundle per impostazione predefinita.

• Alcune delle tue altre domande trovano risposta nelle linee guida di Apple:

L'autenticazione notarile richiede Xcode 10 o versione successiva. La creazione di una nuova app per l'autenticazione notarile richiede macOS 10.13.6 o versione successiva. La pinzatura di un'app richiede macOS 10.12 o versione successiva.

Per autenticare richiede Xcode 10 e per pinzare richiede almeno Sierra.

"L'autenticazione notarile richiede Xcode 10 o versione successiva. La creazione di una nuova app per l'autenticazione notarile richiede macOS 10.13.6 o versione successiva. La pinzatura di un'app richiede macOS 10.12 o versione successiva."https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution

Per quanto riguarda il trasferimento di certificati dev, lascia che Xcode gestisca questa attività esportando il tuo profilo sulla vecchia macchina e importandolo sul nuovo.