Temurin-build: Prise en charge renforcée de l'environnement d'exécution MacOS

lorsque j'essaie d'ajouter ce drapeau, j'obtiens l'erreur suivante :
error: invalid or inappropriate API flag(s) specified

@tkie Avez-vous d'autres idées ici?

en regardant https://help.apple.com/xcode/mac/current/#/dev033e997ca , cela suggère que nous devrons peut-être coder sur macOS 10.13 ou supérieur, laissez-moi jouer ici.

J'utilise XCode Version 10.3 (10G8) sur MacOS 10.14.6.
Je ne sais pas quelle est la version minimale de XCode pour prendre en charge le runtime renforcé, mais c'est une fonctionnalité plutôt nouvelle.

ok donc j'ai fait un peu de progrès ici, je peux signer enable a jdk12 build. Pour contourner l'erreur :

Error occurred during initialization of VM
Could not reserve enough space in CodeHeap 'non-nmethods' (2496K)

vous devez ajouter des droits sous la forme d'un plist :

<?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.allow-dyld-environment-variables</key>
    <true/>
</dict>
</plist>

puis ajoutez --entitlements <path to entitlements.plist> comme indicateur lorsque vous codesignez.

en inspectant l'exécutable, je peux maintenant voir l'option d'exécution :

➜  Home codesign -dvvv ./bin/java
Executable=/Users/gdams/tmp/jdk-11.0.4+11/Contents/Home/bin/java
Identifier=net.java.openjdk.cmd
Format=Mach-O thin (x86_64)
CodeDirectory v=20500 size=832 flags=0x10000(runtime) hashes=17+5 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha1=89dde46e6d5094c92508bc3d95ecf04cbf2e5c6b
CandidateCDHash sha256=7504cd1dc13d553e9cb3d469a508900a34d3cbc7
Hash choices=sha1,sha256
CDHash=7504cd1dc13d553e9cb3d469a508900a34d3cbc7
Signature size=9037
Authority=Developer ID Application: London Jamocha Community CIC (VDX7B37674)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=30 Jul 2019 at 11:12:25
Info.plist entries=4
TeamIdentifier=VDX7B37674
Runtime Version=10.10.0
Sealed Resources=none
Internal requirements count=1 size=180

@tkie pouvez-vous confirmer que ce qui précède fonctionne également pour vous ? Si c'est le cas, j'ajouterai ce changement aux scripts de construction.

J'ai également réussi à faire fonctionner cela sur jdk8 en ajoutant ceci au fichier rights.plist :

<key>com.apple.security.cs.disable-library-validation</key>
<true/>

test de notarisation de l'application jdk11 : rapport (réussi)

test de notarisation de l'application jdk12 : rapport (réussi)

@gdams Je suis désolé, je n'ai jamais construit le JDK moi-même. J'ai toujours téléchargé des distributions binaires. Peut-être pourriez-vous rendre la version de test JDK 11 d'aujourd'hui pour MacOS disponible en téléchargement quelque part ? Ensuite, je pourrais essayer d'obtenir une notarisation d'Apple pour mon application dans laquelle je voudrais regrouper le JDK. Je pourrais donc confirmer si votre changement fonctionne.

@tkie J'ai trouvé un correctif qui corrige tout sur JDK11 +. Veuillez noter que ce changement ne sera pas perceptible avant notre prochaine version (je discuterai avec les gens d'Adopt de la possibilité d'une réédition afin que les gens puissent le consommer immédiatement.

Sur JDK8, nous avons toujours un problème :

The binary uses an SDK older than the 10.9 SDK

Ma suggestion serait que nous examinions l'envoi d'une version JDK8 optimisée pour le regroupement (c'est-à-dire construite sur une chaîne d'outils ultérieure), mais cela pourrait ne pas être une tâche simple car cela nécessite une charge de backports de JDK ultérieurs vers le référentiel JDK8u.

@tkie J'ai une version JDK12 que vous pouvez essayer ici: https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk12u/job/jdk12u-mac-x64-hotspot/

Version JDK11 :
https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk11u/job/jdk11u-mac-x64-hotspot/

@gdams Merci pour la version JDK12. Je peux confirmer que mon application, y compris le JRE de OpenJDK12U-jre_x64_mac_hotspot_2019-07-31-11-04.tar.gz, a été notariée par Apple.

@gdams j'ai également testé avec OpenJDK11U-jre_x64_mac_hotspot_2019-07-31-11-27.tar.gz. La notarisation avec elle a également été couronnée de succès.
De mon point de vue, le problème est résolu et il ne serait pas nécessaire d'enquêter sur Java 8.
Merci d'avoir résolu ce problème pour Java 11 et supérieur.

Nous obtenons également l'erreur "Le binaire utilise un SDK plus ancien que le SDK 10.9" lorsque nous tentons de légaliser notre application avec Java 1.8 Runtime inclus.

Nous devons actuellement rester avec Java 1.8, nous ne pouvons donc pas passer à un Java plus récent.

Y a-t-il une date à laquelle un runtime Java 1.8 mis à jour sera disponible et passera ce test de notarisation ?

Je peux également confirmer qu'il est corrigé avec https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk12u/job/jdk12u-mac-x64-hotspot/.

Quand pouvons-nous nous attendre à une version openjdk 8 qui passe la notarisation ?

Quand pouvons-nous nous attendre à une version OpenJDK 8 qui passe la notarisation ?

Cela peut faire un certain temps, actuellement, aucun fournisseur OpenJDK n'a ce support. Le défi est que jdk8u doit être construit sur Mac Os X 10.10 alors que la notarisation est un concept 10.14.

Salut les gens,
Je ne suis pas sûr que ce soit totalement fermé. Nous regroupons le dernier macOS OpenJDK 11 JRE (OpenJDK11U-jre_x64_mac_hotspot_11.0.5_10.tar.gz) avec notre application et pendant que le processus de notarisation réussit, nous recevons un certain nombre d'avertissements dans le journal JSON qui indiquent qu'il va (probablement) échouer à l'avenir. Par exemple:

{
  "severity": "warning",
  "code": null,
  "path": "XYZ.app.zip/XYZ.app/Contents/jdk-11/bin/java",
  "message": "The executable does not have the hardened runtime enabled.",
  "docUrl": null,
  "architecture": "x86_64"
},

Il semble que la notarisation réussie que d'autres ont signalée puisse être due au fait qu'Apple a temporairement assoupli les exigences de notarisation jusqu'en janvier 2020.

Je peux transmettre notre copie du journal si cela est utile.

Avez-vous ajouté le droit pour la capacité JIT ? Sans cela, la notarisation échoue. à peu près sûr que le JRE en a besoin.

https://developer.apple.com/documentation/security/hardened_runtime_entitlements

J'ai essayé ceci en utilisant l'exemple en amont de @gdams. Nous n'utilisons pas Xcode mais les outils de ligne de commande à la place. Il est possible que je doive changer, mais j'espère pouvoir éviter cela. Il peut s'agir simplement de réorganiser les étapes de signature; les choses étaient plus simples avant la notarisation...

Pour être clair, la notarisation réussit même sans elle, en raison des exigences assouplies actuelles d'Apple. Le souci est que les avertissements indiquent un échec dans le futur.

Si quelqu'un me dit où trouver le journal JSON mentionné par @davideby lors de l'utilisation de XCode, je ferai une autre notarisation de notre logiciel en utilisant XCode et vérifierai si je reçois également de tels avertissements.
Je peux seulement dire que la notarisation est réussie, mais je n'ai pas encore vérifié les avertissements dans un fichier journal.

Je travaille à partir de ce document . Voir notamment la rubrique « Vérifier le statut de votre demande ».

@gdams Il semble que le support d'exécution hardenend ait à nouveau disparu? Si j'utilise jdk-11.0.4 + 11.4, la notarisation fonctionne. Mais avec jdk-11.0.5+10, j'obtiens l'erreur indiquant que la prise en charge renforcée de l'exécution n'est pas activée.

Il semble que vous signiez des exécutables sans option d'exécution renforcée. Essayez de
ajoutez --option runtime à votre commande de codesign.

Le mar. 5 novembre 2019, 07h56, David Eby [email protected] a écrit :

Salut les gens,
Je ne suis pas sûr que ce soit totalement fermé. Nous regroupons le dernier macOS
OpenJDK 11 JRE (OpenJDK11U-jre_x64_mac_hotspot_11.0.5_10.tar.gz) avec notre
app et tandis que le processus de notarisation réussit, nous obtenons un certain nombre de
avertissements dans le journal JSON qui indiquent qu'il échouera (probablement) dans le
avenir. Par exemple:

{
"gravité": "avertissement",
"code": nul,
"chemin": "XYZ.app.zip/XYZ.app/Contents/jdk-11/bin/java",
"message": "L'exécutable n'a pas le runtime renforcé activé.",
"docUrl": nul,
"architecture": "x86_64"
},

Il semble que la notarisation réussie que d'autres ont signalée soit peut-être due
à Apple assouplissant temporairement les exigences de notarisation
https://developer.apple.com/news/?id=09032019a jusqu'en janvier 2020.

Je peux transmettre notre copie du journal si cela est utile.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/AdoptOpenJDK/openjdk-build/issues/1130?email_source=notifications&email_token=ALFWETDWY6UNPTKTOAOHGFLQSEDKHA5CNFSM4H3I6DJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDBV2EQ#5
ou désabonnez-vous
https://github.com/notifications/unsubscribe-auth/ALFWETGV56Q5HXDOMCPKBKTQSEDKHANCNFSM4H3I6DJQ
.

Apple a publié une mise à jour : https://developer.apple.com/news/?id=12232019a
Alors, ai-je bien compris que l'utilisation de JDK8 sur OS X 10.15 commencera à échouer complètement à partir du 3 février (dans 4 semaines) ?
Ce serait plutôt pas mal..

Apple a publié une mise à jour : https://developer.apple.com/news/?id=12232019a
Alors, ai-je bien compris que l'utilisation de JDK8 sur OS X 10.15 commencera à échouer complètement à partir du 3 février (dans 4 semaines) ?
Ce serait plutôt pas mal..

Non, ce n'est pas ce qui va se passer. C'est mauvais, mais les choses qui fonctionnent maintenant continueront de fonctionner. Pour soumettre une application pour notarisation, elle doit répondre à un tas d'exigences, l'une d'entre elles est la signature de code, une autre est le renforcement de l'exécution. Pour que votre application téléchargée à partir d'Internet soit installée sur Catalina (10.15), elle devra passer le contrôle d'accès pour s'assurer qu'elle est correctement notariée. Cela se produit en ce moment sur Catalina.

Ce qui se passe le 3 février, c'est que vous ne pouvez pas faire notarier votre application par Apple si elle ne fait pas la barre en ce qui concerne la signature de code et le renforcement de l'exécution.

Apple a été dans une période de grâce en ce moment, de sorte que vous pouvez soumettre N'IMPORTE QUOI, et ils le notifieront, même s'ils ne remplissent pas les conditions. Après le 3 février, vous ne pourrez plus faire notarier une application, vous ne pourrez donc pas distribuer une nouvelle application sans qu'elle passe. Bien sûr, en juillet, Apple a annoncé que ce serait en septembre. En septembre, ils ont dit janvier, et en décembre, ils ont maintenant dit février. Ils reconnaissent donc que les choses ne vont pas et qu'ils vont blesser beaucoup de gens en le faisant.

Et leurs sont des solutions de contournement. Si un client dispose d'un accès administrateur, il peut autoriser l'installation de tout ce qui n'est pas notarié en accédant au panneau de configuration et en autorisant l'application.

pour ceux qui luttent contre le durcissement de l'exécution, ajoutez les six droits plist disponibles et assurez-vous que votre environnement d'exécution Java, quelle que soit la version que vous utilisez, se trouve dans un dossier qui sera codé lorsque vous utilisez l'option -deep (qui est dans MacOS , ou Cadres). Si vous avez mis votre JRE dans des plugins, il suppose qu'il a été codé par le tiers, et ne code pas ou ne durcit pas cet emplacement. Tous les autres emplacements, en dehors de MacOS et des frameworks, sont ignorés par la conception de code.

Même si le signer nous-mêmes peut ou non fonctionner, je ne vois pas comment quelqu'un de l'extérieur peut corriger le type d'avertissements de notarisation suivant (qui deviendra une erreur et bloquera toutes les futures notarisations le 3 février):

"severity": "warning",
"code": null,
"path": "mydmg.dmg/MyApp.app/Contents/Helpers/jre_1.8.0_XX.jre/Contents/Home/lib/libzip.dylib",
"message": "The binary uses an SDK older than the 10.9 SDK.",
"docUrl": null,
"architecture": "x86_64"

Selon https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution/resolve_common_notarization_issues , cela est attendu et les fichiers binaires doivent être créés avec une version plus récente en premier lieu.

Nous ne pouvons pas simplement arrêter de publier des mises à jour de notre logiciel pour OS X 10.15+ à partir du 3 février, mais actuellement, il semble que c'est exactement ce qui va se passer. Et dire aux environnements d'entreprise qu'ils doivent simplement désactiver certains mécanismes de sécurité pour nous est souvent impossible et jamais un chemin acceptable..

Nous ne pouvons pas simplement arrêter de publier des mises à jour de notre logiciel pour OS X 10.15+

FWIW notre solution était de le construire nous-mêmes avec un SDK plus récent via https://github.com/stooke/jdk8u-xcode10

Il semble que depuis hier, tous ces avertissements de notarisation se soient finalement transformés en erreurs. Ce qui signifie que nous ne pouvons plus légaliser nos applications basées sur Java :(

Salut les gens. Je veux juste mentionner à nouveau mon problème ici puisque mon problème lié a été fermé en référence à celui-ci. J'espère toujours que quelqu'un a un bon indice sur la façon de réparer.

Notre logique d'application est contenue dans un fichier jar. Ce fichier jar est ensuite regroupé dans un package d'application avec la commande packagesbuild (http://s.sudre.free.fr/Software/Packages/about.html). Ce bundle contient également AdoptOpenJDK JRE 11.0.4. Cela signifie que nous expédions cette version avec notre application pour nous assurer que notre application est toujours démarrée avec le requis.

Nous signons ensuite le code comme ceci

# signing the main application
    codesign --deep --force --timestamp --strict --entitlements "${ENTITLEMENTS_DIR}" \
      --options runtime --sign "${CERT_DEV_ID_APPLICATION}" "${DIR_TO_OUR_APP_JAR}"

    # signing the java binaries
    find ${DIR_TO_JRE} -type f -exec \
      codesign --deep --force --timestamp --strict --entitlements "${ENTITLEMENTS_DIR}" \
      --options runtime --sign "${CERT_DEV_ID_APPLICATION}" '{}' \;

Bien sûr, les 6 droits sont là et sont également visibles après avoir installé l'application.

Tout fonctionne correctement jusqu'à ce que le runtime renforcé soit activé. La notarisation réussit, mais l'application ne peut pas être lancée avec la version Java fournie. Ça dit

Une erreur s'est produite lors de l'initialisation de la machine virtuelle Impossible de réserver suffisamment d'espace dans CodeHeap 'non-nmethods' (2496K)

Le démarrage de l'application avec une version Java préinstallée semble bien fonctionner.

Il semble que depuis hier, tous ces avertissements de notarisation se soient finalement transformés en erreurs. Ce qui signifie que nous ne pouvons plus légaliser nos applications basées sur Java :(

J'ai rencontré le même problème hier. Aujourd'hui, ça va. Hier, Apple a signalé que les bibliothèques Java étaient non signées et erronées. Aujourd'hui, ils sont signalés comme non signés mais en avertissement. En bout de ligne, Apple a notarié mon colis.

J'ai rencontré le même problème hier. Aujourd'hui, ça va.

J'ai vu cela aussi, peut-être que c'était Apple qui frappait les pneus sur les règles plus strictes qui devraient être appliquées le 3 février.

Lors d'une tentative de notarisation avec des fichiers jdk-13.0.1+9 dans .jmod , les fichiers sont détectés comme n'étant pas signés par le service de notarisation d'Apple, par exemple :

    {
      "severity": "warning",
      "code": null,
      "path": "[...]/Contents/Home/jmods/jdk.jartool.jmod/bin/jarsigner",
      "message": "The binary is not signed.",
      "docUrl": null,
      "architecture": "x86_64"
    },

Je vois que la signature jmod a été supprimée le 21 août dans https://github.com/AdoptOpenJDK/openjdk-build/commit/5cd5306b4e97437aa2129dffd7e83e2f7cfd9255#diff -9a6d9f1628b9075aa2e1b4c33e4b9cc8 et est toujours commentée. Le ticket mentionné https://github.com/AdoptOpenJDK/TSC/issues/107 a été fermé, est-il prévu de le ramener ?

Une erreur s'est produite lors de l'initialisation de la machine virtuelle Impossible de réserver suffisamment d'espace dans CodeHeap 'non-nmethods' (2496K)

Après avoir jeté un autre coup d'œil à ce sujet, il semble que le problème se trouve dans notre script. C'était historiquement développé, que nous signons en outre le JRE. J'ai maintenant simplement supprimé la partie find-sign pour JRE et cela semble si bien fonctionner.

Comme @abauman-7signal l'a mentionné en effet, toutes les erreurs sont à nouveau des avertissements maintenant, peut-être jusqu'au 3 février
Des idées sur la façon de notariser OpenJDK 13 et de le faire fonctionner par la suite?

Un bon moyen de résoudre ce problème maintenant ? Sur macOS 10.15.2 et essayant d'utiliser openjdk8

J'essaie de résumer l'état actuel. Le résumé peut contenir des erreurs, car je ne suis pas un expert dans ce domaine. @gdams est celui qui dirige les efforts pour faire notarier AdoptOpenJDK et activer le support d'exécution renforcé, mais il est occupé à le faire. Alors prenez-le avec un grain de sel…

Le travail sur JDK 11 avec HotSpot est terminé avec JDK 11 avec OpenJ9 qui suivra bientôt. Le regroupement du JDK est censé fonctionner sans problème. Le résultat de ce travail devrait être inclus dans le prochain CPU trimestriel (avril 2020). La question de savoir s'il y aura des reconstructions de 11.0.6 qui seraient disponibles plus tôt avec une notarisation complète et un support d'exécution renforcé n'a pas encore été décidée. Les fichiers binaires existants sont déjà notariés et devraient continuer à fonctionner au-delà du 3 février sans problème :

$ codesign -dvv ~/Downloads/jdk-11.0.6+10/Contents/Home/bin/java  
Executable=/Users/andreas/Downloads/jdk-11.0.6+10/Contents/Home/bin/java
Identifier=net.java.openjdk.cmd
Format=Mach-O thin (x86_64)
CodeDirectory v=20200 size=276 flags=0x0(none) hashes=4+2 location=embedded
Signature size=9038
Authority=Developer ID Application: London Jamocha Community CIC (VDX7B37674)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=15 Jan 2020 at 13:14:22
Info.plist entries=4
TeamIdentifier=VDX7B37674
Sealed Resources=none
Internal requirements count=1 size=180

JDK 8 est toujours en cours de développement et il n'y a pas d'ETA. Le principal problème ici est que JDK 8 ne prend en charge que la construction avec des Xcodes plus anciens qui, à leur tour, ne prennent pas en charge la notarisation et l'exécution renforcée. Un effort pour utiliser les nouvelles versions de Xcode est en cours, mais les binaires résultants ne passent pas encore la suite de tests. @gdams étudie la question avec Apple. Les exécutables existants sont notariés et devraient continuer à fonctionner au-delà du 3 février :

$ codesign -dvv ~/Downloads/jdk8u242-b08/Contents/Home/bin/java
Executable=/Users/andreas/Downloads/jdk8u242-b08/Contents/Home/bin/java
Identifier=net.java.openjdk.cmd
Format=Mach-O thin (x86_64)
CodeDirectory v=20200 size=884 flags=0x0(none) hashes=23+2 location=embedded
Library validation warning=OS X SDK version before 10.9 does not support Library Validation
Signature size=9038
Authority=Developer ID Application: London Jamocha Community CIC (VDX7B37674)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=19 Jan 2020 at 16:38:24
Info.plist entries=4
TeamIdentifier=VDX7B37674
Sealed Resources=none
Internal requirements count=1 size=180

Le JDK 14, qui sortira en mars, devrait avoir les mêmes capacités que le JDK 11. Des versions nocturnes du JDK 14 avec notarisation et un support d'exécution renforcé devraient être bientôt disponibles. Au moins https://github.com/AdoptOpenJDK/openjdk-build/pull/1517 est requis pour cela.

Tous les autres JDK (9, 10, 12, 13) ont atteint leur fin de vie et sont donc hors champ.

Merci pour cette mise à jour et votre travail pour résoudre ce problème.

Veuillez faire une reconstruction de 11.0.6 disponible dès que possible. Dans l'état actuel des choses, je pense que les développeurs comme nous qui livrent des applications avec un environnement d'exécution Java intégré ne pourraient pas livrer une nouvelle version qui fonctionne sur Catalina après le 3 février jusqu'à ce que la version 11.0.7 soit publiée dans deux mois. (À moins que vous n'ayez réussi à saisir 11.0.4 + 11.2 avant qu'il ne soit supprimé, ce que nous avons fait.)

Je serais heureux de le tester avec notre système de construction d'application et de notarisation avant une version plus générale si cela peut aider.

Je serais heureux de le tester avec notre système de construction d'application et de notarisation avant une version plus générale si cela peut aider.

@mdgood , vous pouvez déjà récupérer l'une de nos versions nocturnes de JDK11 qui contient les dernières mises à jour de notarisation mises à jour. Veuillez consulter https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk11u/job/jdk11u-mac-x64-hotspot.

Je serais intéressé de voir comment tu t'en sors ? Fais-moi savoir!

@gdams Merci pour le pointeur - c'est une excellente nouvelle ! Je vais saisir cela et rendre compte de nos résultats.

Le JDK 14, qui sortira en mars, devrait avoir les mêmes capacités que le JDK 11. Des versions nocturnes du JDK 14 avec notarisation et un support d'exécution renforcé devraient être bientôt disponibles. Au moins #1517 est requis pour cela.

Tous les autres JDK (9, 10, 12, 13) ont atteint leur fin de vie et sont donc hors champ.

Notez que JDK 13 n'est pas en fin de vie. Il n'atteindra sa fin de vie que lorsque le JDK 14 sortira en mars. Veuillez reconsidérer et émettre une autre version de JDK 13 qui est notariée, afin qu'il soit possible d'avoir une version notariée du dernier JDK.

@gadams La version nocturne de 11.0.7 du 30 janvier fonctionne bien pour nous. Notre application est notariée sans avertissements, s'installe et fonctionne correctement sur Catalina. J'essaierai à nouveau de créer et de légaliser notre application la semaine prochaine après l'entrée en vigueur des nouvelles restrictions, juste pour vérifier.

La construction et la notarisation ont bien fonctionné hier également.

Au 2020-02-06 06:01:30 +0000, je reçois des erreurs de notarisation telles que :

sévérité | "Erreur"
chemin | "..../Contents/Plugins/Java.Runtime/Contents/Home/jre/bin/java"
message | "Le binaire utilise un SDK plus ancien que le SDK 10.9."
architecture | "x86_64"

donc je suppose que vous verrez le même problème dans un proche avenir.

Y a-t-il des progrès ou un calendrier pour un JRE Java 8 construit avec 10.9 ou une version ultérieure ? Nous devons encore regrouper Java 8 en raison des modifications apportées à RMI.

Toute information serait appréciée. S'il y a encore des obstacles importants, nous pouvons envisager de le construire nous-mêmes avec ce référentiel mentionné précédemment :
https://github.com/stooke/jdk8u-xcode10

Cependant, s'il y aura un JRE Java 8 disponible dans les prochains jours, je préférerais de loin attendre cela.

@addsomebass Il n'y a rien d'imminent. Et si je me souviens bien, l'un des membres de notre équipe a joué avec les correctifs auxquels vous vous connectez et les binaires résultants n'ont pas réussi la suite de tests. Vous regrouperiez donc un JDK avec des défauts connus.

@addsomebass J'ai travaillé avec Apple pour résoudre les échecs de test mentionnés par @aahlenst. Je répéterai que les correctifs dans https://github.com/stooke/jdk8u-xcode10 ne sont pas prêts pour la production et ont des échecs de test.

Mon objectif actuel est d'avoir un binaire jdk8 notarié prêt d'ici la fin du mois.

Merci pour la mise à jour @gdams , j'apprécie vraiment votre travail à ce sujet.

Merci pour le travail de chacun sur ce sujet - même si j'ai toujours un problème.

J'utilise jpackage du dernier EA de JDK14 pour créer un fichier .app. Le fichier a cette structure :

MyApp.app/
  Contents/
    MacOS/ <- the launcher
    Resources/
    PkgInfo
    Info.plist
    app/ <- the libs for the app
    runtime/ <- contents of jdk-11.0.7+2-jre

Le problème c'est que je peux soit :

• Créer une application notariée, mais elle ne fonctionnera pas, ou
• Créez une application exécutable, mais elle ne sera pas notariée

Pour mettre une chose de côté - la signature d'applications pour Mac dans jpackage est actuellement cassée , je ne peux donc pas l'utiliser. Cela fonctionnait lorsque le runtime n'était pas signé, mais maintenant il est clair que je dois faire la signature moi-même.

Il me semble que je comprends mal quelque chose sur la façon dont le runtime (le JRE) est incorporé et les exigences pour sa signature.

Je signe d'abord tous les fichiers qui ne sont pas dans le runtime et qui ne sont pas des lanceurs :

% find my-app.app -type f -not -path "*/Contents/runtime/*" \
  -not -path "*/Contents/MacOS/my-app" \
  -not -path "*libapplauncher.dylib" \
  -exec codesign -v -s "my key" --prefix com.myapp. --keychain /Users/myuser/Library/Keychains/codesigning.keychain {} \;

J'ai pensé que si le runtime est déjà signé, il n'aura pas besoin d'être re-signé.

À ce stade, mon application s'exécute. Toutefois:

% spctl -a -t exec -vv my-app.app
my-app.app: code has no resources but signature indicates they must be present

Je ne sais pas vraiment ce que cela signifie - la seule chose que je peux trouver en ligne est que cela pourrait signifier que l'application est corrompue. Ce n'est pas vraiment beaucoup d'informations à se passer.

Alors j'essaie :

% spctl -a -t exec -vv my-app.app/Contents/runtime 
my-app.app/Contents/runtime: code has no resources but signature indicates they must be present

Je ne sais pas si cela signifie que c'est le runtime qui est la source du problème. Si j'exécute la même vérification par rapport à la source JRE d'origine (avant qu'elle ne soit empaquetée par jpackage), j'obtiens le même résultat.

% codesign -vvv --deep --strict /path/to/jdk-11.0.7+2-jre 
/path/to/jdk-11.0.7+2-jre: code has no resources but signature indicates they must be present
% codesign -dv --deep --strict /path/to/osx/jdk-11.0.7+2-jre 
Executable=/path/to/jdk-11.0.7+2-jre/Contents/MacOS/libjli.dylib
Identifier=libjli
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20500 size=786 flags=0x10000(runtime) hashes=16+5 location=embedded
Signature size=9038
Timestamp=8 Feb 2020 at 19:20:05
Info.plist=not bound
TeamIdentifier=VDX7B37674
Runtime Version=10.14.0
Sealed Resources=none
Internal requirements count=1 size=168

Alors maintenant, je signe l'application :

codesign -f -s "my key" --options=runtime --prefix com.myapp. --keychain /Users/myuser/Library/Keychains/codesigning.keychain my-app.app

Je dois utiliser --options=runtime sinon j'obtiens une erreur _L'exécutable n'a pas le runtime renforcé activé_.

Revérifier:

% spctl -a -t exec -vv my-app.app
bliss-5.app: accepted
source=Developer ID
origin=Developer ID Application: D Gravell (366TU22RYQ)

Hourra ! Mais si je fais la même vérification sur le dossier runtime contenant le JRE, je reçois toujours le même message.

Cela donne le résultat de la notarisation :

      "path": "my-app.dmg/my-app.app/Contents/runtime/Contents/MacOS/libjli.dylib",
      "message": "The signature of the binary is invalid.",

De plus, l'application ne fonctionne plus :

% my-app.app/Contents/MacOS/my-app
2020-02-12 14:39:08.685 bliss[2909:61940] /private/tmp/my-app.app/Contents/MacOS/libapplauncher.dylib not found.

Alors j'ai réalisé que ce fichier n'était pas signé (alors pourquoi spctl permet-il cela ???) et je l'ai donc signé :

% codesign -f -s "My key" --options=runtime --prefix com.myapp. -vv --keychain /Users/gravelld/Library/Keychains/codesigning.keychain my-app.app/Contents/MacOS/libapplauncher.dylib
% codesign -vvv --deep --strict my-app/Contents/MacOS/libapplauncher.dylib
my-app.app/Contents/MacOS/libapplauncher.dylib: valid on disk
my-app.app/Contents/MacOS/libapplauncher.dylib: satisfies its Designated Requirement

Je dois alors re-signer l'application, sinon cela donne une erreur sur les fichiers en cours de modification.

Mais il ne fonctionnera toujours pas, cette fois en raison d'un problème avec le JRE :

% my-app.app/Contents/MacOS/my-app
2020-02-12 14:45:51.846 my-app[2919:63060] Failed to find library.:/private/tmp/my-app.app/Contents/runtime/Contents/Home/lib/jli/libjli.dylib
2020-02-12 14:45:51.847 my-app[2919:63060] my-app:Failed to locate JLI_Launch
2020-02-12 14:45:51.847 my-app[2919:63060] my-app:Failed to launch JVM

Maintenant, si je signe le runtime, pour résoudre également le problème de notarisation :

% codesign -f -s "my key" --options=runtime --prefix com.myapp. -v --keychain /Users/gravelld/Library/Keychains/codesigning.keychain  my-app.app/Contents/runtime/Contents/Home/lib/jli/libjli.dylib
my-app.app/Contents/runtime/: replacing existing signature
my-app.app/Contents/runtime/: signed bundle with Mach-O thin (x86_64) [com.oracle.java.com.myapp]

Et signez à nouveau l'application, car l'application a changé. J'obtiens maintenant cette beauté en courant:

% my-app.app/Contents/MacOS/my-app
Error: dl failure on line 542
Error: failed /private/tmp/my-app.app/Contents/runtime/Contents/Home//lib/server/libjvm.dylib, because dlopen(/private/tmp/my-app.app/Contents/runtime/Contents/Home//lib/server/libjvm.dylib, 10): no suitable image found.  Did find:
    /private/tmp/my-app.app/Contents/runtime/Contents/Home//lib/server/libjvm.dylib: code signature in (/private/tmp/my-app.app/Contents/runtime/Contents/Home//lib/server/libjvm.dylib) not valid for use in process using Library Validation: mapping process and mapped file (non-platform) have different Team IDs
2020-02-12 14:53:03.153 my-app[2942:64467] my-app:Failed to launch JVM

Cependant, cela n'est toujours pas notarié :

      "path": "my-app.dmg/my-app.app/Contents/runtime/Contents/MacOS/libjli.dylib",
      "message": "The signature of the binary is invalid.",

Assez sur:

% codesign -vvv --deep --strict my-app.app/Contents/runtime/Contents/MacOS/libjli.dylib 
my-app.app/Contents/runtime/Contents/MacOS/libjli.dylib: a sealed resource is missing or invalid
file modified: /private/tmp/my-app.app/Contents/runtime/Contents/Home/lib/jli/libjli.dylib

Ah - je me souviens - j'ai signé runtime/Contents/Home/lib/jli/libjli.dylib donc je dois signer à nouveau le paquet runtime , puis le paquet d'applications d'emballage.

Donc mes questions sont :

• Suis-je censé re-signer le runtime ?
• Est-ce que j'utilise le bon runtime ?
• Quelqu'un pourrait-il partager ses structures d'applications réussies ?

Salut!

J'ai réussi à le faire fonctionner avec JDK 14, jpackage et en signant moi-même tous les dylibs et jars. Avez-vous défini ces lignes dans votre fichier de droits ?

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

S'agit-il des droits pour l'environnement d'exécution ou pour l'application qui regroupe l'environnement d'exécution ?

Je l'ai utilisé pour toutes les commandes de codesign, par exemple pour le dmg mais aussi pour tous les autres fichiers (dylib, jar, .app):

codesign --timestamp --entitlements src/main/deploy/package/macosx/MyApp.entitlements --options runtime --deep -vvv -f --sign "Developer ID Application: John Public (XXXXXXXXXX)" MyApp-1.0.dmg

@ dg76 merci - je vais essayer ça. Je n'ai écrit aucun droit avant maintenant, mais depuis le 3 février, tout semble s'être cassé; peut-être que je comptais sur des valeurs par défaut qui étaient acceptables, mais qui ne le sont plus (évidemment, cela s'applique à l'environnement d'exécution renforcé et aux versions avec les anciens SDK ; c'est pourquoi j'essaie d'adopter cette version).

Cela semble fonctionner, merci ! Donc, pour documenter ma solution finale:

% 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

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

Fonctionne-t-il ?

% my-app.app/Contents/MacOS/my-app 

Oui!

Est-ce notarié?

Status: success
Status Code: 0
Status Message: Package Approved

Hourra!

Résumé pour ceux qui regroupent un JRE :

• La signature jpackage est cassée en ce moment, si vous voulez obtenir quelque chose de notarié
• Vous devez signer votre propre code.
• Vous devez signer à nouveau le JRE. Utilisez -f pour forcer la signature.
• Vous devez spécifier les droits dans tous les appels de signature

Salut, puis-je simplement demander si nous avons actuellement une version Mac pour Java 8 ou Java 9 qui lui permet d'être notarié selon les nouvelles règles ou non ?

@ijabz si je comprends bien votre question, vous souhaitez regrouper une jvm dans une application, puis notarier cela. Actuellement, vous ne pouvez pas. La dernière version d'AdoptOpenJDK est construite avec une ancienne version du SDK Mac OS et ne peut pas être reconditionnée et notariée.

Si vous souhaitez simplement installer Java, les derniers programmes d'installation .pkg fonctionneront sur OSX Catalina, et je peux très bien installer et exécuter Java. Ces installateurs ont été notariés et peuvent installer Java sur votre machine sans problème.

gadams travaille à l'obtention d'une version notariable de Java 8 et espère que cela sera fait à la fin du mois. Je lui souhaite bonne chance ainsi qu'à tous les autres.

si je comprends bien votre question, vous souhaitez regrouper une jvm dans une application, puis notarier cela. Actuellement, vous ne pouvez pas

Oui correct, d'accord, cela nécessitera des modifications de code de ma part, mais la version AdoptOpenJDK Java 11 fonctionne-t-elle?

Ou si j'installe des versions Oracle, cela fonctionnera-t-il, j'utilise actuellement Oracle Java 8 sur MacOS et cela a fonctionné jusqu'au 3 février, est-ce ce que vous entendez par une version .pkg ?

Je cherche juste une solution que je peux utiliser maintenant, je ne sais pas très bien quelles sont les options actuellement.

@ijabz Désolé, je ne peux pas parler de Java 11 ou version ultérieure, car je n'ai pas travaillé avec lui personnellement. À en juger par les commentaires ici, il semble qu'il existe un moyen d'obtenir un ensemble fonctionnel. Je ne peux parler que du travail avec les versions Java 8.

Les packages d'installation mac, ou fichiers .pkg, sont des programmes d'installation de logiciels. Actuellement, il existe des programmes d'installation .pkg disponibles pour les builds AdoptOpenJDK qui sont notariés et installeront Java correctement, comme celui-ci ici :
https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u242-b08/OpenJDK8U-jdk_x64_mac_hotspot_8u242b08.pkg

Je me sens stupide mais je ne comprends pas que d'un côté AdoptOpenJDk travaille sur une version Java 8 notariée mais qui ne sera pas prête avant la fin du mois, mais à l'inverse il existe déjà un installateur AdoptOpenJDk Java 8 qui installera déjà un version notariée Java 8 ?

@ijabz Je pense que la raison en est que si quelque chose a été notarié avant le 3 février 2020, il est toujours valide et fonctionne toujours sur macOS Catalina. Cependant, il ne serait plus possible de le notarier à nouveau maintenant, car les règles sont plus strictes maintenant. Ainsi, le programme d'installation d'AdoptOpenJDK Java 8 a probablement été notarié avant le 3 février et peut donc toujours être utilisé.

Mais vous ne pouvez plus l'empaqueter car depuis le 3 février, Apple exige que les applications soient "durcies", ce qui nécessite XCode 10. Et Java 8 n'a pas été compilé avec XCode 10, donc il ne peut pas (encore) être durci.

Vous pouvez donc installer AdoptOpenJDK Java 8 bien qu'il ne soit pas renforcé simplement parce qu'il a été notarié avant le 3 février. Mais maintenant, il ne serait plus possible d'en créer une nouvelle version ou d'empaqueter un programme avec, car il ne peut pas être durci et donc ne peut pas être notarié.

D'après ce que j'ai lu, au moins JDK 11.0.7 et JDK 14 semblent fonctionner correctement, sont compilés à l'aide de XCode 10, sont "renforcés" et au moins JDK 14 peut être utilisé pour empaqueter des programmes.

D'accord merci je comprends mieux maintenant.
Une dernière chose lorsque vous faites référence à JDK 11.0.7 et JDK 14, je suppose que vous voulez dire les builds AdoptOpenJDk, est-ce que la situation pour les builds AdoptOpenJDk est la même que pour les téléchargements disponibles sur le site Oracle ?

Désolé, je ne sais pas. Je l'ai essayé uniquement avec OpenJDK (pas AdoptOpenJDK mais une distribution différente mais je suppose que c'est la même chose pour toutes les distributions OpenJDK). Cependant, comme il semble nécessiter des modifications dans JDK 8 pour le rendre compatible avec XCode 10 et, pour autant que je sache, Oracle apporte les mêmes modifications dans OpenJDK et leur propre distribution, je pense que leur JDK 8 n'est pas non plus renforcé ( ou sinon ils auraient publié une version OpenJDK de Java 8 qui serait également renforcée). Mais comme je l'ai dit, je n'ai pas essayé.

d'accord merci. Je demande parce que je ne suis pas tout à fait sûr de l'avantage d'utiliser la version AdoptOpenJdk plutôt que de simplement télécharger à partir d'Oracle.

@ijabz Oracle JDK n'est gratuit que pour un ensemble limité de cas d'utilisation (voir FAQ sur les licences Oracle Java SE ). Les versions OpenJDK d'Oracle sont également disponibles et peuvent toujours être utilisées sans restrictions, mais le nombre de plates-formes et de versions prises en charge est nettement inférieur à ce que nous proposons ici chez AdoptOpenJDK. Comme son nom l'indique, AdoptOpenJDK sont des versions d'OpenJDK. Un de nos principaux objectifs est d'accompagner en amont tous les changements. D'autres fournisseurs d'OpenJDK (et ils sont nombreux : Amazon, Azul, BellSoft, SAP, ...) peuvent avoir des politiques différentes.

D'accord, et je vois qu'ils ne semblent proposer que la version MacOS pour les dernières versions maintenant, d'accord merci.

@gdams , pensez-vous toujours avoir un binaire jdk8 notarié prêt d'ici la fin du mois ? Cela inclurait-il également la JVM J9 ?

@gdams , pensez-vous toujours avoir un binaire jdk8 notarié prêt d'ici la fin du mois ? Cela inclurait-il également la JVM J9 ?

Pouvez-vous essayer la distribution BellSoft JDK8 (https://bell-sw.com/pages/java-8u242/). J'ai remplacé AdoptOpenJDK J8 par BellSoft J8, je me suis débarrassé de "The binary uses an SDK older than the 10.9 SDK." et j'ai finalement été notarié.

On dirait que BellSoft J8 est déjà notarié prêt.

Si j'ai bien compris, BellSoft JDK n'est pas gratuit.

Si j'ai bien compris, BellSoft JDK n'est pas gratuit.

La licence publique générale GNU (GPL) avec EXCEPTION "CLASSPATH" À LA GPL
pour Regular Liberica Java SE 8u242 JDK ou JRE la même licence que OpenJDK.

Ils offrent un soutien commercial si vous en avez besoin.

Merci pour la clarification !

Cela semble fonctionner, merci ! Donc, pour documenter ma solution finale:

% 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

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

Fonctionne-t-il ?

% my-app.app/Contents/MacOS/my-app 

Oui!

Est-ce notarié?

Status: success
Status Code: 0
Status Message: Package Approved

Hourra!

Résumé pour ceux qui regroupent un JRE :

• La signature jpackage est cassée en ce moment, si vous voulez obtenir quelque chose de notarié
• Vous devez signer votre propre code.
• Vous devez signer à nouveau le JRE. Utilisez -f pour forcer la signature.
• Vous devez spécifier les droits dans tous les appels de signature

J'ai pu suivre vos démarches cependant j'ai une bibliothèque et même avec
<key>com.apple.security.cs.disable-library-validation</key> <true/>

J'obtiens cette erreur :

Exception dans le fil "Thread d'application JavaFX" java.lang.UnsatisfiedLinkError : /private/var/folders/0f/trlp6tp95qjbzm99ds8pt8zm0000gp/T/JxBrowser/7.5/libbrowsercore_toolkit.dylib : dlopen(/private/var/folders/0f/trlp6tp95qjbzm99ds8pt8zm000gzm0 JxBrowser/7.5/libbrowsercore_toolkit.dylib, 1) : aucune image appropriée trouvée. A trouvé :
/private/var/folders/0f/trlp6tp95qjbzm99ds8pt8zm0000gp/T/JxBrowser/7.5/libbrowsercore_toolkit.dylib : signature de code dans (/private/var/folders/0f/trlp6tp95qjbzm99ds8pt8zm0000gp/T/Jxlibrowsercore_toolkit.dylib) en cours à l'aide de la validation de la bibliothèque : le processus de mappage et le fichier mappé (hors plate-forme) ont des ID d'équipe différents

Cela signifie-t-il que la bibliothèque que j'ai a également besoin de ce droit pour fonctionner ou est-ce quelque chose de mon côté ?

La partie la plus frustrante du processus de notarisation est que j'ai dû intégrer ce processus de publication dans mon pipeline CI/CD. J'aimerais qu'Apple fournisse un point final de test. Je n'ai pas besoin qu'il soit notarié, j'ai juste besoin de savoir s'il est notariable. Certes, la différence est faible, mais quelques éléments la rendent inconfortable.

1. Si je consomme une mise à jour vers un tiers, j'ai besoin d'un processus d'admission qui valide que la mise à jour est notariable. En soumettant cette tierce partie pour validation, j'ai maintenant notarié cette tierce partie en utilisant les références de mon entreprise, et mes responsables de la sécurité pensent que ce n'est pas génial.
2. Je soumets tous les jours des choses à notarisation que je n'ai absolument pas l'intention de fournir à un client, et je dois utiliser des informations d'identification qui sont autorisées à faire plus que de simples tests. Étant donné que ces informations d'identification font désormais partie de mon pipeline, ma surface de sécurité pour une violation des informations d'identification est plus grande. Je veux donc un point de terminaison de test qui n'utilise pas de creds, ou utilise des creds uniquement à des fins de test.

Est-ce que quelqu'un d'autre rencontre le problème que j'ai @gravelld @dg76 J'ai essayé de créer un droit mais cela ne semble pas désactiver la validation de la bibliothèque

@ dcboy95 Je suis désolé - je ne sais pas comment fonctionnent les droits particuliers en ce qui concerne la couverture de l'ensemble du forfait. J'ai découvert qu'avec la signature de code, je devais démissionner de toute la bibliothèque avec laquelle j'étais expédiée, alors peut-être que cela signifie que toute la base de code avec laquelle vous expédiez doit également avoir le droit? Pardon.

@ dcboy95 Je penserais qu'il vous suffit de démissionner du fichier "libbrowsercore_toolkit.dylib" en utilisant codesign et votre propre certificat. (Je pensais avoir déjà posté cette suggestion ici mais je ne trouve aucune réponse de ma part.) L'erreur semble simplement indiquer que la bibliothèque a une signature différente du reste de l'application. Et je pense que tout doit avoir la même signature pour s'assurer que personne d'autre n'y met quoi que ce soit. Essayez donc simplement d'exécuter codesign sur "libbrowsercore_toolkit.dylib". Est-ce que ça résout le problème ?

@ dg76 Malheureusement, cela n'a pas fonctionné. Avec la bibliothèque tierce, il se réinstalle s'il existe une version différente. Ainsi, lorsque je code ce fichier, il le considère comme un ancien fichier et en télécharge un nouveau, remplaçant celui modifié. Résultant de la même erreur. Je pensais que le droit com.apple.security.cs.disable-library-validation résoudrait ce problème, mais cela ne semble pas le cas.

@ dcboy95 Je pense que cela ne fonctionnera pas. Je pense que le but du système de notarisation d'Apple est de s'assurer que le développeur a confirmé que toutes les parties de son application ont été testées et sont correctes. Le chargement de pièces d'autres développeurs pendant l'exécution, qui n'ont pas été testées et confirmées par le développeur, n'est probablement pas autorisé. Ne pouvez-vous pas simplement désactiver la fonction de téléchargement automatique ?

@ dg76 Merci pour l'information, je vais devoir rechercher leur documentation pour voir si c'est une possibilité. Merci encore

AdoptOpenJDK 14+36 est sorti et est entièrement notarié. Merci de revenir en cas de problème.

Un JDK 8 entièrement notarié est toujours en préparation. Nous espérons que cela sera inclus dans le prochain CPU trimestriel (le mardi le plus proche du 17 avril).

Les correctifs requis ont réussi certains tests (y compris le TCK), mais une validation supplémentaire est nécessaire. @gdams prévoit de publier l'état actuel afin que nous puissions fournir des versions à tester dans un avenir pas si lointain.

@aahlenst y a-t-il des projets pour JDK 11 ?

@ dcboy95 Un JDK 11 entièrement notarié sera publié dans le cadre du prochain CPU trimestriel (peu après le mardi le plus proche du 17 avril si je me souviens bien de la règle d'Oracle). En attendant, vous pouvez récupérer une version nocturne de JDK 11 sur https://adoptopenjdk.net/nightly.html?variant=openjdk11&jvmVariant=hotspot et signaler si cela ne fonctionne pas.

Salut, j'ai essayé d'utiliser jdk-11.0.7 + 7 pour le programme d'installation mais [1] échoue toujours avec l'erreur "La signature du binaire n'est pas valide"

[1] /Contents/MacOS/libjli.dylib

@NishikaDeSilva essayez d'exécuter ceci :

codesign --verbose=4 --deep --force -s "Developer ID Application: MyTeam (XXXX)" installer.jdk

@gdams j'ai essayé votre solution.

commande : codesign --verbose=4 --deep --force -s "Application ID développeur : abc (xxxxx)" jdk-11.0.7+7

sortir:
jdk-11.0.7+7 : remplacement de la signature existante
jdk-11.0.7+7 : fourchette de ressources, informations du Finder ou détritus similaires non autorisés

Mais cela indique l'erreur suivante...
jdk-11.0.7+7 : le code n'a pas de ressources mais la signature indique qu'elles doivent être présentes.

Est-ce que je fais quelque chose de mal ?

J'ai essayé 11.0.7 + 7 à partir de la version nocturne. La notarisation passe et l'application se présente avec succès. Cependant, il semble que les fichiers binaires (dylib) ne soient désormais recherchés dans le bundle jar exécuté que par toute charge native utilisée par JNA. En conséquence, notre application reçoit désormais des erreurs de lien insatisfaites lorsqu'elle tente d'accéder à dylib installé sur le système. Cela fonctionnait avant.

@MoxxiManagarm Les dylibs sont-ils signés ? Vérifiez avec codesign -v -v /path/to/dylib .

@aahlenst Je doute, ce sont des dylibs tiers (pilotes de périphériques) installés sur le système, ils ne font pas partie de notre application. J'ai également le droit actif com.apple.security.cs.disable-library-validation , cela ne devrait pas être un problème.

La bibliothèque existe dans le répertoire /usr/local/lib/

En utilisant la version nocturne du JRE de JDK 11, j'ai le même problème que NishikaDeSilva. J'ai également testé des versions nocturnes de JRE 13 et 14 pour faire bonne mesure.

Je ne sais pas si tout cela sera utile, mais voici mes notes.

Exécuter codesign -dvvv libjli.dylib pour vérifier les résultats de la signature.

Executable=[...]/Contents/MacOS/libjli.dylib
Identifier=libjli
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20500 size=786 flags=0x10000(runtime) hashes=16+5 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha1=512c6006363d2928665d9d135f360f974fe66d27
CandidateCDHashFull sha1=512c6006363d2928665d9d135f360f974fe66d27
CandidateCDHash sha256=1157d57e9849eb161251e3a4bca6e2ab7200eaa1
CandidateCDHashFull sha256=1157d57e9849eb161251e3a4bca6e2ab7200eaa11cf4d1f13ae558f0a8ae207e
Hash choices=sha1,sha256
CMSDigest=2727b2d669fee540fd5848fffba07d583d737065d4f28c205530b29f44dfb347
CMSDigestType=2
CDHash=1157d57e9849eb161251e3a4bca6e2ab7200eaa1
Signature size=9037
Authority=Developer ID Application: London Jamocha Community CIC (VDX7B37674)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Mar 31, 2020 at 8:44:15 AM
Info.plist=not bound
TeamIdentifier=VDX7B37674
Runtime Version=10.14.0
Sealed Resources=none
Internal requirements count=1 size=168

La vérification de la signature avec spctl -a -vv libjli.dylib donne ceci :
libjli.dylib: code has no resources but signature indicates they must be present

Je ne trouve aucune bonne documentation sur cette erreur, mais cela semble avoir quelque chose à voir avec les "ressources scellées", dont la signature ci-dessus indique qu'elle est none . Cela n'a pas beaucoup de sens.

Tenter de codésigner le fichier moi-même donne ceci :
resource fork, Finder information, or similar detritus not allowed

Toute la documentation existante sur cette erreur indique qu'elle est causée par des attributs étendus sur le fichier. Plus précisément, com.apple.FinderInfo et com.apple.ResourceFork . Mais ls -l@ libjli.dylib et xattr -l libjli.dylib ne listent aucun attribut x.

Curieusement, déplacer le fichier vers un autre emplacement (n'importe où en dehors du dossier Contents/MacOS ) ou changer l'extension du fichier en quelque chose d'autre que .dylib fera passer la signature de code et la vérification de signature normalement, sans l'un ou l'autre des absurdités ci-dessus les erreurs. Le mécanisme de conception codée doit également tenir compte de l'emplacement du fichier, ce qui le fait différer des résultats du fichier à Contents/Home/lib/jli/libjli.dylib .

Une mise à jour sur le pilote dylib qui n'est pas trouvée dans /usr/local/lib/ après la notarisation (construction nocturne) ?

La vérification de la signature avec spctl -a -vv libjli.dylib donne ceci :
libjli.dylib : le code n'a pas de ressources mais la signature indique qu'elles doivent être présentes

@justin-espedal essayez d'exécuter ceci sur le répertoire de niveau supérieur :

xattr -cr .
codesign --verbose=4 --deep --force -s "Developer ID Application: MyTeam (XXXX)" adoptopenjdk-11.jdk 

sortir:
jdk-11.0.7+7 : remplacement de la signature existante
jdk-11.0.7+7 : fourchette de ressources, informations du Finder ou détritus similaires non autorisés

@NishikaDeSilva exécutez ceci sur le répertoire avant d'exécuter la commande codesign :

xattr -cr .

Cela fonctionne. Pas besoin du récursif -cr , il suffit de supprimer com.apple.FinderInfo du dossier de niveau supérieur. Il est logique que l'attribut FinderInfo du dossier de niveau supérieur interfère avec la conception codée de l'ensemble du package.

Que xattr soit présent ou non, le libjli.dylib ne peut toujours pas être codé par lui-même. Le mécanisme de codesign nécessite-t-il des dylib à cet emplacement spécifique pour vérifier quelque chose avec la signature de code des packages contenant? Si tel est le cas (ou peut-être indépendamment de cela), pourquoi l'ensemble du package n'est-il pas simplement codé par défaut ?

Je préférerais certainement ne pas coder l'intégralité du code JRE si je n'y suis pas obligé.

@gadams @aahlenst Une mise à jour sur le JDK 1.8 notarié ? Le publions-nous le 17 avril ? Y a-t-il un kit antérieur à essayer ?

La semaine prochaine, il y aura d'abord un 8u252 sans notarisation et un temps d'exécution renforcé. Ensuite, nous allons inverser les commutateurs et en construire un avec une notarisation et une exécution renforcée. Des informations complémentaires suivront. Je ne sais pas s'il existe déjà un binaire prêt à être testé par d'autres.

8u252 inclura-t-il libAppleScriptEngine.dylib qui est construit avec un SDK plus récent donc n'échoue pas avec 'Le binaire utilise un SDK plus ancien que le SDK 10.9', ce serait très utile, https://stackoverflow.com/questions/61208189/java-notarization -de-libapplescriptengine-dylib-échouant-avec-le-binaire-utilise-un

Le 8u252 tant attendu est sorti, mais il s'est avéré que presque tous les binaires qu'il contient étaient encore construits avec le sdk 10.8, ce qui empêche une notarisation réussie.
Le JRE de https://ci.adoptopenjdk.net/view/work%20in%20progress/job/jdk8u-mac-x64-hotspot-notarized/10/ contenait 10.14 binaires, nous espérions donc que le 8u252 officiel le sera également.

La semaine prochaine, il y aura d'abord un 8u252 sans notarisation et un temps d'exécution renforcé. Ensuite, nous allons inverser les commutateurs et en construire un avec une notarisation et une exécution renforcée.

Avez-vous un programme pour cela que vous pouvez partager, s'il vous plaît ?

@meshcow Difficile à estimer. C'est pourquoi je n'ai donné aucune estimation au départ. Les pipelines avec les versions régulières sont toujours en cours d'exécution (par exemple, 14.0.1 avec HotSpot et 11.0.7 avec OpenJ9). La version avec runtime renforcé sera compilée par la suite.

@meshcow - nous allons construire un 8u252.1 pour tester notre correctif de notarisation Mac Os, devrait être là dans un jour ou deux.

Pour info, j'ai utilisé BellSoft 8u252 pour essayer d'obtenir un libAppleScriptEngine.dylib qui est construit avec un sdk ultérieur pour permettre la notarisation, et je peux confirmer que cela a fonctionné.

Je peux également confirmer que j'ai intégré AdoptJDk 11.0.7 JRE build et dans mon application et que j'ai réussi à notarier mon application.

Pour info, j'ai utilisé BellSoft 8u252 pour essayer d'obtenir un libAppleScriptEngine.dylib qui est construit avec un sdk ultérieur pour permettre la notarisation, et je peux confirmer que cela a fonctionné.

Pourriez-vous dire, s'il vous plaît, ce que vous utilisez pour regrouper jre avec votre application ? Lorsque j'utilise javapackager, il indique fxbundlerpath/Contents/MacOS/libpackager.dylib: is already signed .
Et comment faites-vous cela avec AdoptJDK 11 ?

J'ai utilisé Appbundler (fork InfinityKind) - https://github.com/TheInfiniteKind/appbundler/
Je vais essayer de poster une réponse complète et détaillée sur stackoveflow demain

@ as1an Réponse ajoutée à ma propre question sur https://stackoverflow.com/questions/58548736/notarize-existing-java-application-for-macos-catalina

Quelqu'un a-t-il une version notariée J9 JVM 1.8 à tester ?

@meshcow Difficile à estimer. C'est pourquoi je n'ai donné aucune estimation au départ. Les pipelines avec les versions régulières sont toujours en cours d'exécution (par exemple, 14.0.1 avec HotSpot et 11.0.7 avec OpenJ9). La version avec runtime renforcé sera compilée par la suite.

@aahlenst Cela inclura-t-il également la version J9 de 1.8 JVM?

Il arrive cette semaine.

Grand merci!

Un binaire notarié JDK8u Hotspot a été publié aujourd'hui jdk8u252-b09.1

https://adoptopenjdk.net/archive.html?variant=openjdk8&jvmVariant=hotspot

Essayez-le et faites-nous savoir si vous avez des problèmes!

OpenJ9 sortira également sous peu

Nous avons réussi à légaliser notre application avec le hotspot 8u252-b09.1 JRE fourni avec succès.
Merci beaucoup les gars!

@meshcow Votre application intègre-t-elle la JVM ou l'utilise-t-elle en externe ? Nous constatons un problème d'exécution indiquant que la signature est différente dans la JVM de notre signature d'application.

@meshcow Votre application intègre-t-elle la JVM ou l'utilise-t-elle en externe ? Nous constatons un problème d'exécution indiquant que la signature est différente dans la JVM de notre signature d'application.

La JVM est embarquée (JNI), l'application est signée par notre cert. Nous n'avons rien signé dans JRE, car il s'est avéré que tout était déjà signé.
Aucun problème jusqu'à présent.

@meshcow Je sais que ce n'est pas lié, et je m'excuse si ce n'est pas le bon forum pour cela, mais j'ai eu du mal à faire fonctionner JNI dans une application groupée, et je me demandais si vous pouviez partager des ressources qui vous ont aidé à y arriver . Tous les bundlers d'applications Java actuels que je peux trouver produisent un exécutable non renforcé qui empêche la notarisation, même lorsque le JRE est notariable.

Toute aide pour surmonter ce dernier obstacle serait très appréciée.

@addsomebass - Nous utilisons une approche standard à la lettre : un petit lanceur écrit en Objective C qui utilise l'API Java Invocation pour charger la JVM et démarrer notre application Java [pure] avec. Le lanceur est placé dans le répertoire de l'application OSX sous /Contents/MacOs. Le JRE y est placé dans le dossier de l'application Java sous /Contents/[app-name]/jre.
L'application OSX est signée, puis elle est prête à être envoyée pour notification. Nous utilisons les arguments de ligne cmd suivants pour la conception de code : --strict --timestamp --entitlements entitlements.plist --force --deep --options runtime , et le contenu entitlemenst.plist est comme dans cette réponse : https://stackoverflow.com/a/58553559.

Donc, la seule chose que je pourrais vous conseiller est de créer votre propre lanceur. Cela ne devrait pas être si difficile, vous pouvez trouver de nombreux exemples, par exemple https://github.com/search?l=Objective-C&q=JNI_createJavaVM&type=Code

@addsomebass Je pense que vous n'avez pas besoin de votre propre lanceur. J'utilise JNI dans un programme Java normal qui est fourni à l'aide du packager Java jpackage de Java 14. Vous pouvez trouver mes étapes ici : https://blog.dgunia.de/2020/02/12/signed-macos-programs- with-java-14/ Il décrit uniquement la signature, pas la partie JNI. Mais j'ai créé un fichier JNI dylib normal qui est également signé au cours de ce processus. Cela fonctionne bien jusqu'à présent, il était possible de le notarier.

@addsomebass @dg76 Java 8 est notre cas, pas 14

@meshcow @dg76 merci pour les conseils. Nous devons également utiliser Java 8 en raison des modifications apportées à RMI.

Merci de soutenir la notarisation maintenant. Mais où est javapackager dans le paquet ? Je ne peux trouver que la version "normale" de jdk8 sans javapackager. Existe-t-il un jdk complet avec javapackager intégré ?

@gdams @aahlenst
Nous avons utilisé la version renforcée d'Open J9 publiée la semaine dernière et nous avons eu cette erreur d'Apple lors de la notarisation :

{ "gravité": "erreur", "code": null, "chemin": "/jre/Contents/MacOS/libjli.dylib", "message": "La signature du binaire est invalide.", "docUrl": null, "architecture": "x86_64" }

Il dit que libjli.dylib n'a pas de signature, mais je crois que c'est un fichier de lien ?

Nous avons également essayé cette commande

Fichier téléchargé - OpenJDK8U-jre_x64_mac_openj9_macosXL_8u252b09_openj9-0.20.0.tar.gz* l'a décompressé dans le dossier jdk8u252-b09-jre-j9 puis a vérifié la signature -

codesign -vvvv jdk8u252-b09-jre-j9jdk8u252-b09-jre-j9/ : le code n'a pas de ressources mais la signature indique qu'elles doivent être présentes

Je ne sais pas si les deux sont liés. Existe-t-il un correctif pour cela?

Merci.

Si vous avez besoin d'aide, veuillez ouvrir les problèmes dans https://github.com/adoptopenjdk/openjdk-support/.