Temurin-build: Dukungan runtime yang diperkeras MacOS

ketika saya mencoba dan menambahkan bendera ini saya mendapatkan kesalahan berikut:
error: invalid or inappropriate API flag(s) specified

@tkie Apakah Anda memiliki wawasan lebih lanjut di sini?

melihat https://help.apple.com/xcode/mac/current/#/dev033e997ca itu menunjukkan bahwa kita mungkin perlu mendesain bersama pada macOS 10.13 atau lebih tinggi, izinkan saya bermain di sini.

Saya menggunakan XCode Versi 10.3 (10G8) di MacOS 10.14.6.
Saya tidak tahu yang merupakan versi XCode minimum untuk mendukung runtime yang diperkeras, tetapi ini adalah fitur yang agak baru.

oke jadi saya sudah membuat sedikit kemajuan di sini, saya bisa masuk mengaktifkan jdk12 build. Untuk mengatasi kesalahan:

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

anda perlu menambahkan hak dalam bentuk daftar:

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

dan kemudian tambahkan --entitlements <path to entitlements.plist> sebagai bendera saat Anda mendesain bersama.

memeriksa yang dapat dieksekusi, saya sekarang dapat melihat opsi runtime:

➜  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 dapatkah Anda mengonfirmasi bahwa hal di atas juga berfungsi untuk Anda? Jika ya, saya akan menambahkan perubahan itu ke skrip build.

Saya juga berhasil membuat ini berfungsi di jdk8 dengan menambahkan ini ke file entitlements.plist:

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

uji notaris aplikasi jdk11: laporan (berhasil)

uji notaris aplikasi jdk12: laporan (berhasil)

@gdams Maaf, saya tidak pernah membuat JDK sendiri. Saya selalu mengunduh distribusi biner. Mungkin Anda dapat membuat uji coba JDK 11 hari ini untuk MacOS tersedia untuk diunduh di suatu tempat? Kemudian saya bisa mencoba untuk mendapatkan notaris dari Apple untuk aplikasi saya di mana saya ingin menggabungkan JDK. Jadi saya bisa mengonfirmasi apakah perubahan Anda berhasil.

@tkie Saya telah mendapatkan perbaikan yang memperbaiki apa pun di JDK11+. Harap dicatat bahwa perubahan ini tidak akan terlihat sampai rilis berikutnya (saya akan mendiskusikan dengan orang-orang Adopt kemungkinan rilis ulang sehingga orang dapat segera mengkonsumsi ini.

Di JDK8 kami masih memiliki masalah:

The binary uses an SDK older than the 10.9 SDK

Saran saya adalah kami menyelidiki pengiriman build JDK8 yang dioptimalkan untuk bundling (yaitu dibangun di atas toolchain yang lebih baru) tetapi ini mungkin bukan tugas yang sederhana karena memerlukan beban backport dari JDK yang lebih baru ke repo JDK8u.

@tkie Saya memiliki build JDK12 yang dapat Anda coba di sini: https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk12u/job/jdk12u-mac-x64-hotspot/

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

@gdams Terima kasih atas pembuatan JDK12. Saya dapat mengonfirmasi bahwa aplikasi saya termasuk JRE dari OpenJDK12U-jre_x64_mac_hotspot_2019-07-31-11-04.tar.gz diaktakan oleh Apple.

@gdams Saya juga telah menguji dengan OpenJDK11U-jre_x64_mac_hotspot_2019-07-31-11-27.tar.gz. Notaris dengan itu juga berhasil.
Dari sudut pandang saya, masalah ini terpecahkan dan tidak perlu menyelidiki Java 8.
Terima kasih telah memecahkan masalah ini untuk Java 11 dan di atasnya.

Kami juga mendapatkan kesalahan "The binary using an SDK old than the 10.9 SDK" ketika kami mencoba untuk membuat notaris aplikasi kami dengan Java 1.8 Runtime yang disertakan .

Saat ini kami harus tetap menggunakan Java 1.8 sehingga tidak dapat meningkatkan ke Java yang lebih baru.

Apakah ada tanggal kapan runtime Java 1.8 yang diperbarui akan tersedia yang akan lulus uji notaris ini?

Saya juga dapat mengonfirmasi bahwa itu diperbaiki dengan https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk12u/job/jdk12u-mac-x64-hotspot/.

Kapan kita bisa mengharapkan build openjdk 8 yang lolos notaris?

Kapan kita bisa mengharapkan build OpenJDK 8 yang lolos notaris?

Mungkin beberapa waktu, saat ini, tidak ada penyedia OpenJDK yang memiliki dukungan ini. Tantangannya adalah jdk8u perlu dibangun di Mac Os X 10.10 sedangkan notaris adalah konsep 10.14.

Hai teman-teman,
Saya tidak yakin ini benar-benar tertutup. Kami memaketkan macOS OpenJDK 11 JRE terbaru (OpenJDK11U-jre_x64_mac_hotspot_11.0.5_10.tar.gz) dengan aplikasi kami dan saat proses notaris berhasil, kami mendapatkan sejumlah peringatan di log JSON yang menunjukkan bahwa itu (mungkin) akan gagal di masa depan. Sebagai contoh:

{
  "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"
},

Sepertinya notaris yang berhasil yang dilaporkan orang lain mungkin karena Apple untuk sementara melonggarkan persyaratan notaris hingga Januari 2020.

Saya dapat memberikan salinan log kami jika itu membantu.

Apakah Anda menambahkan hak untuk kemampuan JIT? Tanpa itu notaris gagal. cukup yakin JRE membutuhkan ini.

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

Saya mencoba ini menggunakan contoh upstream dari @gdams. Kami tidak menggunakan Xcode tetapi alat baris perintah sebagai gantinya. Mungkin saya perlu beralih tetapi mudah-mudahan bisa menghindarinya. Ini mungkin hanya masalah pembenahan langkah-langkah penandatanganan; hal-hal yang lebih sederhana sebelum notaris...

Untuk lebih jelasnya, notaris berhasil bahkan tanpa itu, karena persyaratan santai Apple saat ini. Kekhawatirannya adalah bahwa peringatan menunjukkan kegagalan di masa depan.

Jika ada yang memberi tahu saya di mana menemukan log JSON yang disebutkan oleh @davideby saat menggunakan XCode, saya akan melakukan notaris lain dari perangkat lunak kami menggunakan XCode dan memeriksa apakah saya juga mendapatkan peringatan seperti itu.
Saya hanya dapat mengatakan bahwa notaris berhasil, tetapi saya belum memeriksa file log untuk peringatan.

Saya bekerja dari dokumen ini . Lihat bagian "Periksa Status Permintaan Anda" secara khusus.

@gdams Tampaknya dukungan runtime hardenend telah menghilang lagi? Jika saya menggunakan jdk-11.0.4+11.4 maka notaris berfungsi. Tetapi dengan jdk-11.0.5+10 saya mendapatkan kesalahan bahwa dukungan runtime yang dikeraskan tidak diaktifkan.

Sepertinya Anda menandatangani executable tanpa opsi runtime yang diperkeras. Mencoba untuk
tambahkan --option runtime ke perintah codesign Anda.

Pada Selasa, 5 November 2019, 07:56 David Eby [email protected] menulis:

Hai teman-teman,
Saya tidak yakin ini benar-benar tertutup. Kami menggabungkan macOS terbaru
OpenJDK 11 JRE (OpenJDK11U-jre_x64_mac_hotspot_11.0.5_10.tar.gz) dengan
aplikasi dan saat proses notaris berhasil, kami mendapatkan sejumlah
peringatan di log JSON yang mengindikasikan akan (mungkin) gagal di
masa depan. Sebagai contoh:

{
"keparahan": "peringatan",
"kode": nol,
"path": "XYZ.app.zip/XYZ.app/Contents/jdk-11/bin/java",
"message": "Executable tidak mengaktifkan hardened runtime.",
"docUrl": nol,
"arsitektur": "x86_64"
},

Sepertinya notaris sukses yang dilaporkan orang lain mungkin sudah jatuh tempo
ke Apple untuk sementara melonggarkan persyaratan notaris
https://developer.apple.com/news/?id=09032019a hingga Januari 2020.

Saya dapat memberikan salinan log kami jika itu membantu.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/AdoptOpenJDK/openjdk-build/issues/1130?email_source=notifications&email_token=ALFWETDWY6UNPTKTOAOHGFLQSEDKHA5CNFSM4H3I6DJ2YY3PNVWWK3TUL52HS4DFVREXG43VMXVBWQ67
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/ALFWETGV56Q5HXDOMCPKBKTQSEDKHANCNFSM4H3I6DJQ
.

Apple telah merilis pembaruan: https://developer.apple.com/news/?id=12232019a
Jadi, apakah saya memahaminya dengan benar bahwa menggunakan JDK8 pada OS X 10.15 akan mulai gagal sepenuhnya mulai 3 Februari (dalam 4 minggu)?
Itu akan sangat buruk..

Apple telah merilis pembaruan: https://developer.apple.com/news/?id=12232019a
Jadi, apakah saya memahaminya dengan benar bahwa menggunakan JDK8 pada OS X 10.15 akan mulai gagal sepenuhnya mulai 3 Februari (dalam 4 minggu)?
Itu akan sangat buruk..

Tidak, bukan itu yang akan terjadi. Itu buruk, tetapi hal-hal yang bekerja sekarang akan terus bekerja. Untuk mengajukan aplikasi ke notaris, aplikasi tersebut harus memenuhi banyak persyaratan, salah satunya adalah penandatanganan kode, yang lainnya adalah pengerasan waktu proses. Agar aplikasi Anda yang diunduh dari internet dapat diinstal di Catalina (10.15), aplikasi tersebut harus melewati pemeriksaan penjaga gerbang bahwa aplikasi tersebut diaktakan dengan benar. Itu terjadi sekarang di Catalina.

Apa yang terjadi pada 3 Februari adalah Anda tidak dapat membuat aplikasi Anda diaktakan oleh Apple jika itu tidak memenuhi standar sehubungan dengan penandatanganan kode dan pengerasan runtime.

Apple telah dalam masa tenggang sekarang, sehingga Anda dapat mengirimkan APA SAJA, dan mereka akan mensahkannya, bahkan jika itu tidak memenuhi persyaratan. Setelah 3 Februari, Anda tidak akan bisa mendapatkan aplikasi yang diaktakan, jadi Anda tidak akan bisa mendistribusikan aplikasi baru tanpa melewatinya. Tentu saja, Pada bulan Juli Apple mengatakan bahwa itu akan menjadi bulan September. Pada bulan September mereka mengatakan Januari, dan pada bulan Desember mereka sekarang mengatakan Februari. Jadi mereka menyadari bahwa ada hal yang tidak benar dan mereka akan menyakiti banyak orang dengan melakukannya.

Dan mereka adalah solusi. Jika pelanggan memiliki akses admin, mereka dapat mengizinkan apa pun yang tidak disahkan untuk dipasang dengan membuka panel kontrol dan mengotorisasi aplikasi.

bagi mereka yang berjuang dengan pengerasan runtime, tambahkan semua enam hak plist yang tersedia, dan pastikan runtime Java Anda, versi mana pun yang Anda gunakan, ada di folder yang akan dirancang bersama saat Anda menggunakan opsi -deep (yang ada di MacOS , atau Kerangka). Jika Anda telah memasukkan JRE Anda ke dalam plugin, itu mengasumsikan bahwa itu dirancang bersama oleh pihak ke-3, dan tidak akan mendesain bersama atau mengeraskan lokasi itu. Lokasi lain mana pun, di luar MacOS dan Kerangka, pengabaian desain bersama.

Bahkan jika menandatanganinya sendiri mungkin berhasil atau tidak, saya tidak melihat bagaimana orang di luar dapat memperbaiki jenis peringatan notaris berikut (yang akan menjadi kesalahan dan memblokir semua notaris di masa mendatang 3 Februari):

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

Menurut https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution/resolving_common_notarization_issues , ini diharapkan dan binari perlu dibuat dengan versi yang lebih baru di tempat pertama.

Kami tidak bisa berhenti merilis pembaruan perangkat lunak kami untuk OS X 10.15+ mulai 3 Februari, tetapi saat ini sepertinya itulah yang akan terjadi.. Dan memberi tahu lingkungan perusahaan bahwa mereka harus menonaktifkan beberapa mekanisme keamanan bagi kami seringkali tidak mungkin dan tidak pernah jalan yang bisa diterima..

Kami tidak bisa berhenti merilis pembaruan perangkat lunak kami untuk OS X 10.15+

FWIW solusi kami adalah membangunnya sendiri dengan SDK yang lebih baru melalui https://github.com/stooke/jdk8u-xcode10

Sepertinya sejak kemarin semua peringatan notaris itu akhirnya berubah menjadi kesalahan. Yang berarti kami tidak dapat lagi mensahkan aplikasi berbasis Java kami :(

Hai teman-teman. Hanya ingin menyebutkan masalah saya di sini lagi karena masalah tertaut saya ditutup dengan merujuk ke yang ini. Saya masih berharap seseorang memiliki petunjuk yang bagus bagaimana cara memperbaikinya.

Logika aplikasi kami terkandung dalam file jar. File jar ini kemudian dibundel ke dalam paket aplikasi dengan perintah packagebuild (http://s.sudre.free.fr/Software/Packages/about.html). Bundel ini juga berisi AdoptOpenJDK JRE 11.0.4. Ini berarti kami mengirimkan versi ini dengan aplikasi kami untuk memastikan aplikasi kami selalu dimulai dengan yang diperlukan.

Kami kemudian menandatangani kode seperti ini

# 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}" '{}' \;

Tentu saja semua 6 hak ada dan juga terlihat setelah aplikasi diinstal.

Semuanya berfungsi dengan baik sampai runtime yang diperkeras diaktifkan. Notaris lolos, tetapi aplikasi tidak dapat diluncurkan dengan versi java yang dikirimkan. Ia mengatakan

Terjadi kesalahan selama inisialisasi VM Tidak dapat memesan cukup ruang di 'non-nmethods' CodeHeap (2496K)

Memulai aplikasi dengan versi Java yang sudah diinstal sebelumnya tampaknya berfungsi dengan baik.

Sepertinya sejak kemarin semua peringatan notaris itu akhirnya berubah menjadi kesalahan. Yang berarti kami tidak dapat lagi mensahkan aplikasi berbasis Java kami :(

Saya mengalami masalah yang sama kemarin. Hari ini, baik-baik saja. Kemarin, Apple melaporkan perpustakaan Java sebagai tidak ditandatangani dan dalam kesalahan. Hari ini, mereka dilaporkan tidak ditandatangani tetapi dalam peringatan. Intinya, Apple mengesahkan paket saya.

Saya mengalami masalah yang sama kemarin. Hari ini, baik-baik saja.

Saya juga melihat ini, mungkin Apple menendang ban pada aturan ketat yang direncanakan akan diberlakukan pada 3 Februari.

Saat mencoba notaris dengan file jdk-13.0.1+9 di .jmod file terdeteksi tidak ditandatangani oleh layanan notaris Apple, misalnya:

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

Saya melihat penandatanganan jmod telah dihapus pada 21 Agustus di https://github.com/AdoptOpenJDK/openjdk-build/commit/5cd5306b4e97437aa2129dffd7e83e2f7cfd9255#diff -9a6d9f1628b9075aa2e1b4c33e4b9cc8 dan masih dikomentari. Tiket yang disebutkan https://github.com/AdoptOpenJDK/TSC/issues/107 telah ditutup, apakah ada rencana untuk mengembalikannya?

Terjadi kesalahan selama inisialisasi VM Tidak dapat memesan cukup ruang di 'non-nmethods' CodeHeap (2496K)

Setelah melihat ini lagi, sepertinya masalahnya ada di skrip kami. Itu tumbuh secara historis, bahwa kami juga menandatangani JRE. Saya sekarang cukup menghapus bagian find-sign untuk JRE dan sepertinya berhasil.

Seperti yang disebutkan @abauman-7signal memang semua kesalahan adalah peringatan lagi sekarang, mungkin hingga 3 Februari
Adakah ide bagaimana membuat notaris OpenJDK 13 dan membuatnya benar-benar berfungsi setelahnya?

Adakah cara yang baik untuk memperbaikinya sekarang? Di macOS 10.15.2 dan mencoba menggunakan openjdk8

Saya mencoba merangkum keadaan saat ini. Ringkasan mungkin mengandung kesalahan, karena saya bukan ahli di bidang ini. @gdams adalah yang memimpin upaya agar AdoptOpenJDK diaktakan dan mengaktifkan dukungan runtime yang diperkeras, tetapi dia sibuk menyelesaikannya. Jadi ambil dengan sebutir garam ...

Bekerja pada JDK 11 dengan HotSpot telah selesai dengan JDK 11 dengan OpenJ9 segera menyusul. Bundling JDK seharusnya bekerja tanpa masalah. Hasil pekerjaan ini diharapkan dapat dimasukkan dalam CPU triwulanan berikutnya (April 2020). Apakah akan ada pembangunan kembali 11.0.6 yang akan tersedia lebih cepat dengan notaris lengkap dan dukungan runtime yang diperkeras belum diputuskan. Biner yang ada sudah diaktakan dan akan terus berjalan setelah 3 Februari tanpa masalah:

$ 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 masih dalam proses dan tidak ada ETA. Masalah utama di sini adalah bahwa JDK 8 hanya mendukung pembangunan dengan Xcode lama yang pada gilirannya tidak mendukung notaris dan runtime yang diperkeras. Upaya untuk menggunakan versi Xcode yang lebih baru sedang berlangsung tetapi binari yang dihasilkan belum lulus rangkaian pengujian. @gdams sedang menyelidikinya bersama dengan Apple. Eksekusi yang ada diaktakan dan harus terus berjalan setelah 3 Februari:

$ 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

JDK 14 yang akan dirilis pada bulan Maret harus memiliki kemampuan yang sama dengan JDK 11. Build malam JDK 14 dengan notaris dan dukungan runtime yang diperkeras akan segera tersedia. Setidaknya https://github.com/AdoptOpenJDK/openjdk-build/pull/1517 diperlukan untuk ini.

Semua JDK lainnya (9, 10, 12, 13) telah mencapai akhir masa pakainya dan oleh karena itu di luar cakupan.

Terima kasih atas pembaruan ini dan pekerjaan Anda dalam menyelesaikan ini.

Harap membuat pembangunan kembali 11.0.6 tersedia sesegera mungkin. Saat ini, saya percaya bahwa pengembang seperti kami yang mengirimkan aplikasi dengan runtime Java tertanam tidak akan dapat mengirimkan build baru yang berfungsi di Catalina setelah 3 Februari hingga 11.0.7 dirilis dua bulan dari sekarang. (Kecuali Anda berhasil mengambil 11.0.4+11.2 sebelum dihapus, yang kami lakukan.)

Saya akan dengan senang hati mengujinya dengan pembuatan aplikasi dan sistem notaris kami sebelum rilis yang lebih umum jika itu membantu.

Saya akan dengan senang hati mengujinya dengan pembuatan aplikasi dan sistem notaris kami sebelum rilis yang lebih umum jika itu membantu.

@mdgood Anda sudah dapat mengambil salah satu build malam JDK11 kami yang memiliki pembaruan notaris yang lebih baru. Silakan lihat https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk11u/job/jdk11u-mac-x64-hotspot.

Saya akan tertarik untuk melihat bagaimana Anda mendapatkan? Biarkan aku tahu!

@gdams Terima kasih atas petunjuknya - itu berita bagus! Saya akan mengambil ini dan melaporkan kembali hasil kami.

JDK 14 yang akan dirilis pada bulan Maret harus memiliki kemampuan yang sama dengan JDK 11. Build malam JDK 14 dengan notaris dan dukungan runtime yang diperkeras akan segera tersedia. Setidaknya #1517 diperlukan untuk ini.

Semua JDK lainnya (9, 10, 12, 13) telah mencapai akhir masa pakainya dan oleh karena itu di luar cakupan.

Perhatikan bahwa JDK 13 belum berakhir. Itu hanya akan mencapai akhir hidup ketika JDK 14 dirilis pada bulan Maret. Harap pertimbangkan kembali dan terbitkan versi lain dari JDK 13 yang diaktakan, sehingga dimungkinkan untuk memiliki versi yang disahkan dari JDK terbaru.

@gadams Build 11,0.7 malam 30 Januari berfungsi dengan baik untuk kami. Pembuatan aplikasi kami diaktakan tanpa peringatan, dan dipasang serta berfungsi dengan baik di Catalina. Saya akan mencoba membangun dan membuat notaris aplikasi kami lagi minggu depan setelah pembatasan baru berlaku hanya untuk memeriksa ulang.

Bangunan dan notaris bekerja dengan baik kemarin juga.

Pada 06-02-2020 06:01:30 +0000 Saya mendapatkan kesalahan notaris seperti:

keparahan | "kesalahan"
jalan | "..../Contents/Plugins/Java.Runtime/Contents/Home/jre/bin/java"
pesan | "Binary menggunakan SDK yang lebih lama dari SDK 10.9."
arsitektur | "x86_64"

jadi saya berasumsi bahwa Anda akan melihat masalah yang sama dalam waktu dekat.

Apakah ada kemajuan atau garis waktu untuk Java 8 JRE yang dibuat dengan versi 10.9 atau lebih baru? Kami masih perlu membundel dengan Java 8 karena perubahan RMI.

Setiap info akan dihargai. Jika masih ada kendala yang signifikan, kita dapat melihat ke dalam membangunnya sendiri dengan repo ini yang disebutkan sebelumnya:
https://github.com/stooke/jdk8u-xcode10

Namun, jika Java 8 JRE akan tersedia dalam beberapa hari ke depan, saya lebih suka menunggu.

@addsomebass Tidak ada yang dekat. Dan jika saya ingat dengan benar, salah satu anggota tim kami bermain-main dengan patch yang Anda tautkan dan binari yang dihasilkan tidak lulus test suite. Jadi, Anda akan menggabungkan JDK dengan cacat yang diketahui.

@addsomebass Saya telah bekerja dengan Apple untuk menyelesaikan kegagalan pengujian yang disebutkan oleh @aahlenst. Saya akan menegaskan kembali bahwa tambalan di https://github.com/stooke/jdk8u-xcode10 belum siap produksi dan mengalami kegagalan pengujian.

Tujuan saya saat ini adalah menyiapkan biner jdk8 yang diaktakan pada akhir bulan.

Terima kasih atas pembaruannya @gdams , saya sangat menghargai pekerjaan Anda dalam hal ini.

Terima kasih atas kerja semua orang dalam hal ini - meskipun saya masih memiliki masalah.

Saya menggunakan jpackage dari EA terbaru JDK14 untuk membuat file .app. File memiliki struktur ini:

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

Masalahnya adalah, saya dapat:

• Buat aplikasi yang disahkan, tetapi tidak dapat dijalankan, atau
• Buat aplikasi yang dapat dijalankan, tetapi tidak akan diaktakan

Untuk mengesampingkan satu hal - menandatangani aplikasi untuk Mac di jpackage saat ini rusak jadi saya tidak bisa menggunakannya. Itu _was_ berfungsi ketika runtime tidak ditandatangani, tetapi sekarang jelas saya harus melakukan penandatanganan sendiri.

Sepertinya saya salah memahami sesuatu tentang bagaimana runtime (JRE) dimasukkan, dan persyaratan untuk penandatanganannya.

Pertama saya menandatangani semua file yang tidak ada dalam runtime dan itu bukan peluncur:

% 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 {} \;

Saya pikir jika runtime sudah ditandatangani, itu tidak perlu ditandatangani ulang.

Pada titik ini, aplikasi saya berjalan. Namun:

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

Saya tidak begitu yakin apa artinya ini - satu-satunya hal yang dapat saya temukan online adalah bahwa itu mungkin berarti aplikasinya rusak. Itu tidak benar-benar banyak info yang akan terjadi.

Jadi saya mencoba:

% 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

Saya tidak yakin apakah itu berarti runtime yang menjadi sumber masalahnya. Jika saya menjalankan pemeriksaan yang sama terhadap sumber JRE asli (sebelum dikemas oleh jpackage) saya mendapatkan hasil yang sama.

% 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

Jadi sekarang saya menandatangani aplikasi:

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

Saya harus menggunakan --options=runtime jika tidak, saya mendapatkan kesalahan _ Eksekusi tidak mengaktifkan hardened runtime_.

Periksa lagi:

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

Hore! Tetapi jika saya melakukan pemeriksaan yang sama pada folder runtime dengan JRE di dalamnya, saya masih mendapatkan pesan yang sama.

Ini memberikan hasil notaris:

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

Selain itu, aplikasi tidak lagi berjalan:

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

Jadi saya menyadari file ini tidak ditandatangani (jadi mengapa spctl mengizinkan ini???) dan saya menandatanganinya:

% 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

Saya kemudian harus menandatangani ulang aplikasi, jika tidak maka akan memberikan kesalahan tentang file yang sedang dimodifikasi.

Tapi tetap tidak bisa berjalan, kali ini karena masalah dengan 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

Sekarang jika saya menandatangani runtime, untuk juga mengatasi masalah notaris:

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

Dan menandatangani ulang aplikasi lagi, karena aplikasi telah berubah. Saya sekarang mendapatkan keindahan ini saat berlari:

% 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

Namun, ini masih belum disahkan:

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

Tentu saja:

% 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 - saya ingat - saya menandatangani runtime/Contents/Home/lib/jli/libjli.dylib jadi saya perlu menandatangani bundel runtime lagi, dan kemudian bundel aplikasi pembungkus.

Jadi pertanyaan saya adalah:

• Apakah saya harus menandatangani ulang runtime?
• Apakah saya menggunakan runtime yang benar?
• Adakah yang bisa membagikan struktur aplikasi mereka yang sukses?

Hai!

Saya telah berhasil menjalankannya dengan JDK 14, jpackage dan dengan menandatangani semua dylib dan toples sendiri. Apakah Anda mengatur baris ini di file hak Anda?

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

Apakah itu hak untuk runtime atau untuk aplikasi yang menggabungkan runtime?

Saya telah menggunakannya untuk semua perintah codesign, misalnya untuk dmg tetapi juga untuk semua file lain (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 terima kasih - saya akan mencobanya. Saya belum pernah menulis hak apa pun sebelumnya, tetapi sejak 3 Februari semuanya tampaknya telah rusak; mungkin saya mengandalkan default yang dulunya dapat diterima, tetapi sekarang tidak (jelas itu berlaku untuk runtime yang diperkeras dan build terhadap SDK lama; itulah sebabnya saya mencoba mengadopsi build ini).

Itu tampaknya berhasil, terima kasih! Jadi, untuk mendokumentasikan solusi akhir saya:

% 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

Semua tes berfungsi:

% 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

Apakah itu berjalan?

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

Ya!

Apakah itu notaris?

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

Hore!

Ringkasan untuk mereka yang menggabungkan JRE:

• Penandatanganan jpackage rusak sekarang, jika Anda ingin mendapatkan sesuatu yang diaktakan
• Anda harus menandatangani kode Anda sendiri.
• Anda harus menandatangani ulang JRE. Gunakan -f untuk memaksa tanda tangan.
• Anda harus menentukan hak dalam semua panggilan penandatanganan

Hai, bolehkah saya bertanya apakah saat ini kami memiliki Mac build untuk Java 8 atau Java 9 yang memungkinkan untuk diaktakan sesuai dengan aturan baru atau tidak?

@ijabz jika saya memahami pertanyaan Anda dengan benar, Anda ingin menggabungkan jvm di dalam aplikasi, dan kemudian membuat notaris. Saat ini, Anda tidak bisa. Versi AdoptOpenJDK terbaru dibuat dengan versi Mac OS SDK yang lebih lama dan tidak dapat dikemas ulang dan diaktakan ulang.

Jika Anda hanya ingin menginstal java, penginstal .pkg terbaru akan bekerja pada OSX Catalina, dan saya dapat menginstal dan menjalankan Java dengan baik. Pemasang ini telah disahkan, dan dapat menginstal Java ke mesin Anda tanpa masalah.

gadams sedang bekerja untuk mendapatkan build Java 8 yang terkenal, dan berharap bisa menyelesaikannya pada akhir bulan. Saya berharap dia dan semua orang beruntung.

jika saya memahami pertanyaan Anda dengan benar, Anda ingin menggabungkan jvm di dalam aplikasi, dan kemudian membuat notaris itu. Saat ini, Anda tidak bisa

Ya benar, oke ini akan memerlukan perubahan kode di pihak saya, tetapi apakah versi AdoptOpenJDK Java 11 berfungsi?

Atau jika saya menginstal Oracle build, apakah itu akan berfungsi, saya saat ini menggunakan Oracle Java 8 di MacOS dan itu berhasil hingga 3 Februari, apakah ini yang Anda maksud dengan .pkg build ?

Saya hanya mencari solusi yang dapat saya gunakan sekarang, saya sangat tidak jelas tentang opsi apa yang ada saat ini.

@ijabz Maaf saya tidak dapat berbicara dengan Java 11 atau yang lebih baru, karena saya belum bekerja dengannya secara pribadi. Dilihat dari komentar di sini sepertinya ada cara untuk mendapatkan bundel yang berfungsi. Saya hanya dapat berbicara untuk bekerja dengan Java 8 build.

Paket penginstal mac, atau file .pkg, adalah penginstal untuk perangkat lunak. Saat ini ada beberapa penginstal .pkg yang tersedia untuk versi AdoptOpenJDK yang diaktakan dan akan menginstal Java dengan benar, seperti ini di sini:
https://github.com/AdoptOpenJDK/openjdk8-binary/releases/download/jdk8u242-b08/OpenJDK8U-jdk_x64_mac_hotspot_8u242b08.pkg

Saya merasa saya bodoh tetapi saya tidak mengerti bahwa di satu sisi AdoptOpenJDk sedang mengerjakan Java 8 build yang diaktakan tetapi itu tidak akan siap hingga akhir bulan, tetapi sebaliknya sudah ada penginstal AdoptOpenJDk Java 8 yang sudah akan menginstal a versi notaris Java 8 ?

@ijabz Saya pikir alasannya adalah bahwa jika sesuatu telah diaktakan sebelum 3 Februari 2020, itu masih valid dan masih berfungsi di macOS Catalina. Namun sekarang tidak bisa di notariskan lagi, karena aturannya sekarang lebih ketat. Jadi penginstal AdoptOpenJDK Java 8 mungkin baru saja disahkan sebelum 3 Februari dan dengan demikian masih dapat digunakan.

Tetapi Anda tidak dapat mengemasnya lagi karena sejak 3 Februari Apple mengharuskan aplikasi untuk "dikeraskan", yang membutuhkan XCode 10. Dan Java 8 belum dikompilasi dengan XCode 10, sehingga belum dapat dikeraskan (belum).

Jadi Anda dapat menginstal AdoptOpenJDK Java 8 meskipun tidak dikeraskan hanya karena disahkan sebelum 3 Februari. Tetapi sekarang tidak mungkin lagi untuk membuat versi baru atau mengemas program dengannya, karena tidak dapat dikeraskan dan dengan demikian tidak dapat diaktakan.

Dari apa yang saya baca setidaknya JDK 11.0.7 dan JDK 14 tampaknya berfungsi dengan baik, dikompilasi menggunakan XCode 10, "dikeraskan" dan setidaknya JDK 14 dapat digunakan untuk mengemas program.

Oke terima kasih saya mengerti lebih baik sekarang.
Satu hal lagi ketika Anda merujuk ke JDK 11.0.7 dan JDK 14 Saya berasumsi maksud Anda AdoptOpenJDk build, apakah situasi untuk AdoptOpenJDk build sama dengan unduhan yang tersedia di situs Oracle?

Maaf, saya tidak tahu. Saya telah mencobanya hanya dengan OpenJDK (bukan AdoptOpenJDK tetapi distribusi yang berbeda tetapi saya kira itu sama untuk semua distribusi OpenJDK). Namun karena tampaknya memerlukan perubahan dalam JDK 8 agar kompatibel dengan XCode 10 dan, sejauh yang saya tahu, Oracle membuat perubahan yang sama di OpenJDK dan distribusi mereka sendiri, saya akan berpikir bahwa JDK 8 mereka juga tidak dikeraskan ( atau jika tidak, mereka akan merilis versi OpenJDK dari Java 8 yang juga akan dikeraskan). Tapi seperti yang saya katakan saya belum mencobanya.

Ok terima kasih. Saya bertanya karena saya tidak sepenuhnya yakin apa keuntungan menggunakan AdoptOpenJdk build daripada hanya mengunduh dari Oracle.

@ijabz Oracle JDK hanya gratis digunakan untuk kasus penggunaan terbatas (lihat FAQ Perizinan Oracle Java SE ). Build OpenJDK oleh Oracle juga tersedia, dan masih gratis untuk digunakan tanpa batasan, tetapi jumlah platform dan versi yang didukung jauh lebih rendah daripada yang kami tawarkan di sini di AdoptOpenJDK. Sesuai dengan namanya, AdoptOpenJDK adalah build dari OpenJDK. Salah satu tujuan utama kami adalah untuk hulu semua perubahan. Vendor OpenJDK lainnya (dan ada banyak: Amazon, Azul, BellSoft, SAP, ...) mungkin memiliki kebijakan yang berbeda.

Benar, dan saya melihat mereka sepertinya hanya menawarkan build MacOS untuk build terbaru sekarang, oke terima kasih.

@gdams , apakah Anda masih mengharapkan biner jdk8 yang diaktakan siap pada akhir bulan? Juga, apakah itu termasuk J9 JVM?

@gdams , apakah Anda masih mengharapkan biner jdk8 yang diaktakan siap pada akhir bulan? Juga, apakah itu termasuk J9 JVM?

Bisakah Anda mencoba distribusi BellSoft JDK8 (https://bell-sw.com/pages/java-8u242/). Saya mengganti AdoptOpenJDK J8 dengan BellSoft J8, menyingkirkan "The binary uses an SDK older than the 10.9 SDK." dan akhirnya diaktakan.

Sepertinya BellSoft J8 sudah siap diaktakan.

Seperti yang saya pahami, BellSoft JDK tidak gratis..

Seperti yang saya pahami, BellSoft JDK tidak gratis..

Lisensi Publik Umum GNU (GPL) dengan "CLASSPATH" PENGECUALIAN UNTUK GPL
untuk Regular Liberica Java SE 8u242 JDK atau JRE dengan lisensi yang sama dengan OpenJDK.

Mereka menawarkan dukungan komersial jika Anda membutuhkannya.

Terima kasih untuk klarifikasi!

Itu tampaknya berhasil, terima kasih! Jadi, untuk mendokumentasikan solusi akhir saya:

% 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

Semua tes berfungsi:

% 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

Apakah itu berjalan?

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

Ya!

Apakah itu notaris?

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

Hore!

Ringkasan untuk mereka yang menggabungkan JRE:

• Penandatanganan jpackage rusak sekarang, jika Anda ingin mendapatkan sesuatu yang diaktakan
• Anda harus menandatangani kode Anda sendiri.
• Anda harus menandatangani ulang JRE. Gunakan -f untuk memaksa tanda tangan.
• Anda harus menentukan hak dalam semua panggilan penandatanganan

Saya dapat mengikuti langkah Anda namun saya memiliki perpustakaan dan bahkan dengan
<key>com.apple.security.cs.disable-library-validation</key> <true/>

Saya mendapatkan kesalahan ini:

Pengecualian di utas "Utas Aplikasi JavaFX" java.lang.UnsatisfiedLinkError: /private/var/folders/0f/trlp6tp95qjbzm99ds8pt8zm0000gp/T/JxBrowser/7.5/libbrowsercore_toolkit.dylib: dlopen(/private/var/folder/0mzdqjsbpt/0990000/trlp6zt JxBrowser/7.5/libbrowsercore_toolkit.dylib, 1): tidak ditemukan gambar yang sesuai. Apakah menemukan:
/private/var/folders/0f/trlp6tp95qjbzm99ds8pt8zm0000gp/T/JxBrowser/7.5/libbrowsercore_toolkit.dylib: tanda tangan kode di (/private/var/folder/0f/trlp6tp95qjbzm99ds8pt8_toolkitbBrowser/T/notkitlibbBrowser/T8_ToolbBrowser/T dalam proses menggunakan Validasi Pustaka: proses pemetaan dan file yang dipetakan (non-platform) memiliki ID Tim yang berbeda

Apakah ini berarti perpustakaan yang saya miliki juga memerlukan hak itu agar dapat berfungsi atau apakah itu sesuatu yang merugikan saya?

Bagian yang paling membuat frustrasi dari proses notaris adalah bahwa saya harus memasukkan proses rilis ini ke dalam pipa CI/CD saya. Saya berharap apel akan menyediakan titik akhir tes. Saya tidak membutuhkannya diaktakan, saya hanya perlu tahu apakah itu dapat diaktakan. Memang perbedaannya kecil, tetapi beberapa hal membuatnya tidak nyaman.

1. Jika saya menggunakan pembaruan ke pihak ke-3, saya memerlukan proses pemasukan yang memvalidasi bahwa pembaruan tersebut dapat disahkan. Dengan mengirimkan pihak ke-3 untuk validasi, saya sekarang telah membuat notaris pihak ke-3 tersebut menggunakan kredensial perusahaan saya, dan orang-orang keamanan saya berpikir itu tidak luar biasa.
2. Saya mengirimkan hal-hal untuk notaris setiap hari yang sama sekali tidak ingin saya berikan kepada pelanggan, dan saya harus menggunakan kredensial yang diizinkan untuk melakukan lebih dari sekadar pengujian. Karena kredensial itu sekarang menjadi bagian dari saluran saya, area permukaan keamanan saya untuk pelanggaran kredensial lebih besar. Jadi saya ingin titik akhir pengujian yang tidak menggunakan kredit, atau menggunakan kredit yang hanya untuk tujuan pengujian.

Apakah ada orang lain yang mengalami masalah yang saya alami @gravelld @dg76 Saya telah mencoba membuat hak tetapi sepertinya itu tidak menonaktifkan validasi perpustakaan

@dcboy95 Maaf - saya tidak tahu bagaimana hak tertentu bekerja sehubungan dengan cakupan seluruh bundel. Saya menemukan, dengan penandatanganan kode, saya harus mengundurkan diri dari seluruh perpustakaan yang saya kirimkan, jadi mungkin itu berarti seluruh basis kode yang Anda kirimkan juga harus memiliki hak? Maaf.

@dcboy95 Saya akan berpikir bahwa Anda hanya perlu mengundurkan diri dari file "libbrowsercore_toolkit.dylib" menggunakan codesign dan sertifikat Anda sendiri. (Saya pikir saya sudah memposting saran ini di sini tetapi saya tidak dapat menemukan tanggapan dari saya.) Kesalahan sepertinya menunjukkan bahwa perpustakaan memiliki tanda tangan yang berbeda dari aplikasi lainnya. Dan saya pikir semuanya harus memiliki tanda tangan yang sama untuk memastikan bahwa tidak ada orang lain yang memasukkan apa pun ke dalamnya. Jadi coba jalankan codesign di "libbrowsercore_toolkit.dylib". Apakah itu memperbaikinya?

@dg76 Sayangnya itu tidak berhasil. Dengan perpustakaan pihak ketiga itu menginstal ulang sendiri jika ada versi yang berbeda. Jadi ketika saya mendesain ulang file itu, itu melihatnya sebagai file lama dan mengunduh yang baru, menggantikan yang dimodifikasi. Menghasilkan kesalahan yang sama. Saya pikir hak com.apple.security.cs.disable-library-validation akan memperbaiki masalah ini namun tampaknya tidak.

@ dcboy95 Saya pikir ini tidak akan berhasil. Saya pikir tujuan dari sistem notaris Apple adalah untuk memastikan bahwa pengembang telah mengkonfirmasi bahwa semua bagian dari aplikasinya telah diuji dan baik-baik saja. Memuat bagian dari pengembang lain selama runtime, yang belum diuji dan dikonfirmasi oleh pengembang, mungkin tidak diperbolehkan. Tidak bisakah Anda menonaktifkan fungsi unduh otomatis?

@dg76 Terima kasih atas informasinya, saya harus meneliti dokumentasi mereka untuk melihat apakah ini suatu kemungkinan. Terima kasih lagi

AdoptOpenJDK 14+36 keluar yang sepenuhnya diaktakan. Silakan laporkan kembali jika ada masalah.

JDK 8 yang sepenuhnya diaktakan masih dalam pengerjaan. Kami berharap untuk memasukkan ini ke dalam CPU triwulanan berikutnya (hari Selasa terdekat hingga 17 April).

Tambalan yang diperlukan lulus beberapa uji coba (termasuk TCK), tetapi diperlukan lebih banyak validasi. @gdams berencana untuk memublikasikan status saat ini sehingga kami dapat menyediakan build untuk pengujian dalam waktu dekat.

@aahlenst apakah ada rencana untuk JDK 11?

@ dcboy95 JDK 11 yang sepenuhnya diaktakan akan diterbitkan sebagai bagian dari CPU triwulanan berikutnya (tak lama setelah Selasa terdekat hingga 17 April jika saya mengingat aturan Oracle dengan benar). Sementara itu, Anda dapat mengambil build malam JDK 11 di https://adoptopenjdk.net/nightly.html?variant=openjdk11&jvmVariant=hotspot dan melaporkan kembali jika tidak berhasil.

Hai, saya mencoba menggunakan jdk-11.0.7+7 untuk penginstal tetapi masih [1] gagal dengan kesalahan "Tanda tangan biner tidak valid"

[1] /Contents/MacOS/libjli.dylib

@NishikaDeSilva coba jalankan ini:

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

@gdams saya mencoba solusi Anda.

perintah: codesign --verbose=4 --deep --force -s "Aplikasi ID Pengembang: abc (xxxxx)" jdk-11.0.7+7

keluaran:
jdk-11.0.7+7: mengganti tanda tangan yang ada
jdk-11.0.7+7: garpu sumber daya, informasi Finder, atau detritus serupa tidak diizinkan

Tapi itu menunjukkan kesalahan berikut ...
jdk-11.0.7+7: kode tidak memiliki sumber daya tetapi tanda tangan menunjukkan bahwa mereka harus ada.

Apakah saya melakukan sesuatu yang salah?

Saya mencoba 11.0.7+7 dari build malam. Notaris berlalu dan aplikasi berhasil muncul. Namun, tampaknya binari (dylib) sekarang dicari di bundel jar yang dieksekusi hanya oleh beban asli apa pun yang digunakan oleh JNA. Akibatnya aplikasi kita sekarang menerima UnsatisfiedLinkErrors ketika mencoba mengakses dylib yang diinstal pada sistem. Ini bekerja sebelumnya.

@MoxxiManagar Apakah dylib ditandatangani? Periksa dengan codesign -v -v /path/to/dylib .

@aahlenst Saya ragu, itu adalah dylib pihak ke-3 (driver perangkat) yang diinstal pada sistem, mereka bukan bagian dari aplikasi kami. Saya juga memiliki hak aktif com.apple.security.cs.disable-library-validation , yang seharusnya tidak menjadi masalah.

Lib ada di dalam direktori /usr/local/lib/

Menggunakan build malam JDK 11's JRE, saya memiliki masalah yang sama dengan NishikaDeSilva. Saya telah menguji build malam JRE 13 dan 14 juga untuk ukuran yang baik.

Saya tidak tahu apakah semua ini akan membantu, tetapi inilah catatan saya.

Menjalankan codesign -dvvv libjli.dylib untuk memeriksa hasil tanda tangan dalam hal ini.

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

Memverifikasi tanda tangan dengan spctl -a -vv libjli.dylib menghasilkan ini:
libjli.dylib: code has no resources but signature indicates they must be present

Saya tidak dapat menemukan dokumentasi yang bagus tentang kesalahan itu, tetapi tampaknya ada hubungannya dengan "sumber daya yang disegel", yang menurut tanda tangan di atas adalah none . Tidak masuk akal.

Mencoba untuk mendesain sendiri file tersebut menghasilkan ini:
resource fork, Finder information, or similar detritus not allowed

Semua dokumentasi yang ada tentang kesalahan itu mengatakan bahwa itu disebabkan oleh atribut yang diperluas pada file. Khususnya, com.apple.FinderInfo dan com.apple.ResourceFork . Tetapi ls -l@ libjli.dylib dan xattr -l libjli.dylib tidak mencantumkan atribut x.

Anehnya, memindahkan file ke lokasi lain (di mana pun di luar folder Contents/MacOS ) atau mengubah ekstensi file ke sesuatu selain .dylib akan membuat desain bersama dan verifikasi tanda tangan lulus secara normal, tanpa salah satu dari yang tidak masuk akal di atas kesalahan. Mekanisme codesign harus mempertimbangkan lokasi file juga, menyebabkannya berbeda dari hasil file di Contents/Home/lib/jli/libjli.dylib .

Adakah pembaruan pada driver dylib yang tidak ditemukan dalam /usr/local/lib/ setelah notaris (pembuatan malam)?

Memverifikasi tanda tangan dengan spctl -a -vv libjli.dylib menghasilkan ini:
libjli.dylib: kode tidak memiliki sumber daya tetapi tanda tangan menunjukkan bahwa mereka harus ada

@justin-espedal coba jalankan ini di direktori tingkat atas:

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

keluaran:
jdk-11.0.7+7: mengganti tanda tangan yang ada
jdk-11.0.7+7: garpu sumber daya, informasi Finder, atau detritus serupa tidak diizinkan

@NishikaDeSilva jalankan ini di direktori sebelum menjalankan perintah codesign:

xattr -cr .

Itu berhasil. Tidak perlu -cr rekursif, cukup menghapus com.apple.FinderInfo dari folder tingkat atas sudah cukup. Masuk akal bahwa atribut FinderInfo pada folder tingkat atas adalah yang mengganggu desain bersama seluruh paket.

Terlepas dari apakah xattr itu ada atau tidak, libjli.dylib masih tidak dapat dirancang sendiri. Apakah mekanisme desain bersama memerlukan dylib di lokasi spesifik itu untuk memverifikasi sesuatu dengan tanda tangan kode paket yang berisi? Jika itu masalahnya (atau mungkin terlepas dari itu), mengapa seluruh paket tidak dirancang bersama secara default?

Saya tentu lebih suka untuk tidak mendesain bersama seluruh kode JRE jika saya tidak perlu.

@gadams @aahlenst Adakah pembaruan pada JDK 1.8 yang diaktakan? Apakah kami akan merilisnya pada 17 April? Apakah ada kit sebelumnya untuk dicoba?

Minggu depan, akan ada 8u252 tanpa notaris dan hardened runtime terlebih dahulu. Setelah itu, kita akan membalik sakelar dan membuatnya dengan notaris dan runtime yang diperkeras. Informasi tambahan akan menyusul. Saya tidak tahu apakah sudah ada biner yang siap diuji oleh orang lain.

Akankah 8u252 menyertakan libAppleScriptEngine.dylib yang dibangun dengan SDK yang lebih baru sehingga tidak gagal dengan 'Biner menggunakan SDK yang lebih lama dari SDK 10.9', ini akan sangat membantu, https://stackoverflow.com/questions/61208189/java-notarization -of-libapplescriptengine-dylib-failing-with-the-binary-uses-an

8u252 yang telah lama ditunggu-tunggu keluar, tetapi ternyata hampir semua binari di dalamnya masih dibangun dengan sdk 10.8, yang mencegah notaris yang berhasil.
JRE dari https://ci.adoptopenjdk.net/view/work%20in%20progress/job/jdk8u-mac-x64-hotspot-notarized/10/ berisi 10,14 binari jadi kami berharap 8u252 resmi juga demikian.

Minggu depan, akan ada 8u252 tanpa notaris dan hardened runtime terlebih dahulu. Setelah itu, kita akan membalik sakelar dan membuatnya dengan notaris dan runtime yang diperkeras.

Apakah kalian punya jadwal untuk ini, tolong bagikan?

@meshcow Sulit diperkirakan. Itu sebabnya saya tidak memberikan perkiraan di tempat pertama. Pipeline dengan build reguler masih berjalan (misalnya, 14.0.1 dengan HotSpot dan 11.0.7 dengan OpenJ9). Versi dengan runtime yang diperkeras akan dibuat setelahnya.

@meshcow - kami akan membangun 8u252.1 untuk menguji patch notaris Mac Os kami, akan ada di sini dalam satu atau dua hari.

FYI Saya menggunakan BellSoft 8u252 untuk mencoba dan mendapatkan libAppleScriptEngine.dylib yang dibangun untuk SDK yang lebih baru untuk memungkinkan notaris, dan dapat mengonfirmasi bahwa itu berhasil.

Juga dapat mengonfirmasi bahwa saya menggabungkan AdoptJDk 11.0.7 JRE build dan ke dalam aplikasi saya dan berhasil menotariskan aplikasi saya.

FYI Saya menggunakan BellSoft 8u252 untuk mencoba dan mendapatkan libAppleScriptEngine.dylib yang dibangun untuk SDK yang lebih baru untuk memungkinkan notaris, dan dapat mengonfirmasi bahwa itu berhasil.

Bisakah Anda memberi tahu, tolong, apa yang Anda gunakan untuk menggabungkan jre dengan aplikasi Anda? Ketika saya menggunakan javapackager dikatakan fxbundlerpath/Contents/MacOS/libpackager.dylib: is already signed .
Dan bagaimana Anda melakukannya dengan AdoptJDK 11?

Saya menggunakan Appbundler (garpu InfinityKind) - https://github.com/TheInfiniteKind/appbundler/
Saya akan mencoba dan memposting jawaban terperinci lengkap di stackoveflow besok

@as1an Menambahkan jawaban untuk pertanyaan saya sendiri di https://stackoverflow.com/questions/58548736/notarize-existing-Java-application-for-macos-catalina

Adakah yang memiliki build J9 JVM 1.8 yang diaktakan untuk kami uji?

@meshcow Sulit diperkirakan. Itu sebabnya saya tidak memberikan perkiraan di tempat pertama. Pipeline dengan build reguler masih berjalan (misalnya, 14.0.1 dengan HotSpot dan 11.0.7 dengan OpenJ9). Versi dengan runtime yang diperkeras akan dibuat setelahnya.

@aahlenst Apakah ini termasuk versi J9 dari 1.8 JVM juga?

Itu akan datang minggu ini.

Terima kasih banyak!

Biner Hotspot JDK8u Notaris telah dirilis hari ini jdk8u252-b09.1

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

Cobalah dan beri tahu kami jika Anda memiliki masalah!

OpenJ9 juga akan segera keluar

Kami berhasil membuat notaris aplikasi kami dengan hotspot yang dibundel 8u252-b09.1 JRE.
Terima kasih banyak!

@meshcow Apakah aplikasi Anda menyematkan JVM atau menggunakannya secara eksternal? Kami melihat masalah runtime yang mengatakan tanda tangan berbeda di JVM dari tanda tangan aplikasi kami.

@meshcow Apakah aplikasi Anda menyematkan JVM atau menggunakannya secara eksternal? Kami melihat masalah runtime yang mengatakan tanda tangan berbeda di JVM dari tanda tangan aplikasi kami.

JVM tertanam (JNI), aplikasi ditandatangani oleh sertifikat kami. Kami tidak menandatangani apa pun di dalam JRE, karena ternyata semua yang ada di dalamnya sudah ditandatangani.
Tidak ada masalah sejauh ini.

@meshcow Saya tahu ini tidak terkait, dan saya minta maaf jika ini bukan forum yang tepat untuk ini, tetapi saya telah berjuang untuk membuat JNI berfungsi dalam aplikasi yang dibundel, dan saya ingin tahu apakah Anda dapat membagikan sumber daya apa pun yang membantu Anda sampai di sana . Semua bundel aplikasi Java saat ini yang dapat saya temukan menghasilkan executable yang tidak dikeraskan yang mencegah notaris, bahkan ketika JRE tidak dapat dinotariskan.

Bantuan apa pun untuk mengatasi rintangan terakhir ini akan sangat dihargai.

@addsomebass - Kami menggunakan pendekatan standar berdasarkan buku: peluncur kecil yang ditulis dalam Objective C yang menggunakan Java Invocation API untuk memuat JVM dan memulai aplikasi Java [murni] kami dengannya. Peluncur dimasukkan ke dalam direktori aplikasi OSX di bawah /Contents/MacOs. JRE diletakkan di sana ke folder aplikasi Java di bawah /Contents/[app-name]/jre.
Aplikasi OSX ditandatangani, dan kemudian siap dikirim untuk notrisasi. Kami menggunakan argumen baris cmd berikut untuk desain bersama: --strict --timestamp --entitlements entitlements.plist --force --deep --options runtime , dan konten entitlemenst.plist seperti dalam jawaban ini: https://stackoverflow.com/a/58553559.

Jadi satu-satunya saran yang bisa saya berikan adalah membuat peluncur Anda sendiri. Seharusnya tidak terlalu sulit, ada banyak contoh yang dapat Anda temukan, misalnya https://github.com/search?l=Objective-C&q=JNI_createJavaVM&type=Code

@addsomebass Saya pikir Anda tidak memerlukan peluncur sendiri. Saya menggunakan JNI dalam program Java normal yang dibundel menggunakan Java packager jpackage Java 14. Anda dapat menemukan langkah-langkah saya di sini: https://blog.dgunia.de/2020/02/12/signed-macos-programs- with-java-14/ Ini hanya menjelaskan penandatanganan, bukan bagian JNI. Tetapi saya telah membuat file dylib JNI normal yang juga ditandatangani selama proses itu. Ini berfungsi dengan baik sejauh ini, itu mungkin untuk diaktakan.

@addsomebass @dg76 Java 8 adalah kasus kami, bukan 14

@meshcow @dg76 terima kasih atas tipsnya. Kita perlu menggunakan Java 8 juga karena perubahan RMI.

Terima kasih telah mendukung notaris sekarang. Tapi di mana javapackager dalam paket? Saya hanya dapat menemukan build jdk8 "normal" tanpa javapackager. Apakah ada jdk lengkap dengan javapackager bawaan?

@gdams @aahlenst
Kami menggunakan versi hardened Open J9 yang dirilis minggu lalu dan kami mendapatkan kesalahan ini dari Apple selama notaris:

{ "severity": "error", "code": null, "path": "/jre/Contents/MacOS/libjli.dylib", "message": "Tanda tangan biner tidak valid.", "docUrl": null, "architecture": "x86_64" }

Dikatakan libjli.dylib tidak memiliki tanda tangan, tetapi saya yakin ini adalah file tautan?

Kami juga mencoba perintah ini

File diunduh - OpenJDK8U-jre_x64_mac_openj9_macosXL_8u252b09_openj9-0.20.0.tar.gz* membuka ritsletingnya ke folder jdk8u252-b09-jre-j9 dan kemudian memeriksa tanda tangan -

codesign -vvvv jdk8u252-b09-jre-j9jdk8u252-b09-jre-j9/: kode tidak memiliki sumber daya tetapi tanda tangan menunjukkan bahwa mereka harus ada

Tidak yakin apakah keduanya terkait. Apakah ada perbaikan untuk ini?

Terima kasih.

Jika Anda memerlukan bantuan, silakan buka masalah di https://github.com/adoptopenjdk/openjdk-support/.