Temurin-build: دعم وقت التشغيل المشدد لنظام التشغيل MacOS

عندما أحاول إضافة هذه العلامة أحصل على الخطأ التالي:
error: invalid or inappropriate API flag(s) specified

tkie هل لديك أي رؤى أخرى هنا؟

بالنظر إلى https://help.apple.com/xcode/mac/current/#/dev033e997ca ، فإنه يشير إلى أننا قد نحتاج إلى رمز رمز على نظام التشغيل macOS 10.13 أو أعلى ، اسمح لي باللعب هنا.

أستخدم XCode الإصدار 10.3 (10G8) على نظام التشغيل MacOS 10.14.6.
لا أعرف ما هو الحد الأدنى من إصدار XCode لدعم وقت التشغيل المتصلب ، لكنها ميزة جديدة نوعًا ما.

حسنًا ، لقد أحرزت بعض التقدم هنا ، يمكنني التوقيع على تمكين بناء jdk12. للتغلب على الخطأ:

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

تحتاج إلى إضافة استحقاقات في شكل 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>

ثم قم بإضافة --entitlements <path to entitlements.plist> كعلامة عند توقيع الرمز.

فحص الملف القابل للتنفيذ يمكنني الآن رؤية خيار وقت التشغيل:

➜  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 هل يمكنك تأكيد أن ما ورد أعلاه يناسبك أيضًا؟ إذا حدث ذلك ، فسأضيف هذا التغيير إلى البرامج النصية للبناء.

لقد تمكنت أيضًا من إجراء هذا العمل على jdk8 عن طريق إضافة هذا إلى ملف entitlements.plist:

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

اختبار توثيق تطبيق jdk11: تقرير (ناجح)

اختبار توثيق تطبيق jdk12: تقرير (ناجح)

gdams أنا آسف ، لم أقم مطلقًا ببناء JDK بنفسي. لقد قمت دائمًا بتنزيل التوزيعات الثنائية. ربما يمكنك جعل اختبار JDK 11 الخاص بك اليوم لنظام التشغيل MacOS متاحًا للتنزيل في مكان ما؟ بعد ذلك يمكنني محاولة الحصول على توثيق من Apple لتطبيقي الذي أود تجميع JDK فيه. لذلك يمكنني أن أؤكد ما إذا كان التغيير الخاص بك يعمل.

tkie لقد حصلت على إصلاح يعمل على إصلاح أي شيء على JDK11 +. يرجى ملاحظة أن هذا التغيير لن يكون ملحوظًا حتى إصدارنا التالي (سأناقش مع أعضاء التبني إمكانية إعادة الإصدار حتى يتمكن الأشخاص من استهلاك هذا على الفور.

في JDK8 لا تزال لدينا مشكلة:

The binary uses an SDK older than the 10.9 SDK

اقتراحي هو أن نحقق في شحن إصدار JDK8 الذي تم تحسينه للتجميع (على سبيل المثال ، مبني على سلسلة أدوات لاحقة) ولكن قد لا تكون هذه مهمة بسيطة لأنها تتطلب تحميلًا من backports من JDK لاحقًا إلى JDK8u repo.

tkie لدي بناء JDK12 يمكنك تجربته هنا: https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk12u/job/jdk12u-mac-x64-hotspot/

بناء JDK11:
https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk11u/job/jdk11u-mac-x64-hotspot/

gdams شكرا لك على بناء JDK12. أستطيع أن أؤكد أن طلبي بما في ذلك JRE من OpenJDK12U-jre_x64_mac_hotspot_2019-07-31-11-04.tar.gz قد تم توثيقه من قبل Apple.

gdams لقد اختبرت أيضًا مع OpenJDK11U-jre_x64_mac_hotspot_2019-07-31-11-27.tar.gz. كان التوثيق معها ناجحًا أيضًا.
من وجهة نظري ، تم حل المشكلة ولن يكون من الضروري التحقيق في Java 8.
شكرًا لك على حل هذه المشكلة لـ Java 11 وما فوق.

حصلنا أيضًا على الخطأ "يستخدم الثنائي SDK أقدم من 10.9 SDK" عندما نحاول توثيق تطبيقنا مع تضمين Java 1.8 Runtime.

نحتاج حاليًا إلى البقاء مع Java 1.8 ، لذا لا يمكننا الترقية إلى إصدار أحدث من Java.

هل هناك تاريخ يتوفر فيه وقت تشغيل Java 1.8 محدث يجتاز اختبار التوثيق هذا؟

يمكنني أيضًا أن أؤكد أنه تم إصلاحه باستخدام https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk12u/job/jdk12u-mac-x64-hotspot/.

متى نتوقع بناء Openjdk 8 يمر بالتوثيق؟

متى يمكن أن نتوقع بناء OpenJDK 8 يمر بالتوثيق؟

قد يكون هناك بعض الوقت ، في الوقت الحالي ، لا يوجد مزود OpenJDK لديه هذا الدعم. التحدي هو أن jdk8u يحتاج إلى أن يبنى على نظام التشغيل Mac OS X 10.10 بينما التوثيق هو مفهوم 10.14.

مرحبا يا رفاق،
لست متأكدًا من أن هذا مغلق تمامًا. نقوم بتجميع أحدث إصدار من macOS OpenJDK 11 JRE (OpenJDK11U-jre_x64_mac_hotspot_11.0.5_10.tar.gz) مع تطبيقنا ، وبينما تنجح عملية التوثيق ، نحصل على عدد من التحذيرات في سجل JSON والتي تشير إلى أنها (على الأرجح) ستفشل فى المستقبل. علي سبيل المثال:

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

يبدو أن التوثيق الناجح الذي أبلغ عنه الآخرون قد يكون بسبب قيام Apple بتخفيف متطلبات التوثيق مؤقتًا حتى يناير 2020.

يمكنني تمرير نسختنا من السجل إذا كانت مفيدة.

هل أضفت استحقاق قدرة JIT؟ بدونها يفشل التوثيق. متأكد من أن JRE يحتاج هذا.

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

لقد جربت هذا باستخدام مثال المنبع منgdams. نحن لا نستخدم Xcode ولكن أدوات سطر الأوامر بدلاً من ذلك. من الممكن أن أحتاج إلى التبديل ولكن آمل أن أتجنب ذلك. قد يكون الأمر مجرد تجديد لخطوات التوقيع ؛ كانت الأمور أبسط قبل التوثيق ...

لكي نكون واضحين ، فإن التوثيق ينجح حتى بدونه ، نظرًا لمتطلبات Apple الحالية المريحة. القلق هو أن التحذيرات تشير إلى فشل في المستقبل.

إذا أخبرني أي شخص بمكان العثور على سجل JSON الذي ذكره @ davideby عند استخدام XCode ، فسأقوم بتوثيق آخر لبرنامجنا باستخدام XCode وتحقق مما إذا تلقيت مثل هذه التحذيرات أيضًا.
لا يمكنني إلا أن أقول إن التوثيق قد نجح ، لكنني لم أتحقق من ملف السجل بحثًا عن التحذيرات حتى الآن.

أنا أعمل من هذا المستند . راجع قسم "التحقق من حالة طلبك" على وجه الخصوص.

gdams يبدو أن دعم وقت التشغيل hardenend قد اختفى مرة أخرى؟ إذا استخدمت jdk-11.0.4 + 11.4 ، فإن التوثيق يعمل. ولكن مع jdk-11.0.5 + 10 أحصل على خطأ مفاده أن دعم وقت التشغيل المتشدد غير ممكّن.

يبدو أنك توقع على الملفات التنفيذية بدون خيار وقت التشغيل المتصلب. حاول
أضف --option runtime إلى أمر codeign الخاص بك.

في الثلاثاء ، 5 نوفمبر 2019 ، 07:56 كتب David Eby [email protected] :

مرحبا يا رفاق،
لست متأكدًا من أن هذا مغلق تمامًا. نقوم بتجميع أحدث إصدار من macOS
OpenJDK 11 JRE (OpenJDK11U-jre_x64_mac_hotspot_11.0.5_10.tar.gz) من خلال موقعنا
التطبيق وأثناء نجاح عملية التوثيق ، نحصل على عدد من
التحذيرات الموجودة في سجل JSON والتي تشير إلى أنه سيفشل (على الأرجح) في ملف
مستقبل. علي سبيل المثال:

{
"الخطورة": "تحذير"،
"الكود": فارغ ،
"المسار": "XYZ.app.zip/XYZ.app/Contents/jdk-11/bin/java" ،
"message": "لم يتم تمكين وقت التشغيل المشدد للملف القابل للتنفيذ."،
"docUrl": فارغ ،
"العمارة": "x86_64"
} ،

يبدو أن التوثيق الناجح الذي أبلغ عنه الآخرون قد يكون مستحقًا
لشركة Apple تخفف مؤقتًا من متطلبات التوثيق
https://developer.apple.com/news/؟id=09032019a حتى يناير 2020.

يمكنني تمرير نسختنا من السجل إذا كانت مفيدة.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/AdoptOpenJDK/openjdk-build/issues/1130؟email_source=notifications&email_token=ALFWETDWY6UNPTKTOAOHGFLQSEDKHA5CNFSM4H3I6DJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDBV2EQ#issuecomment-549674258 ،
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/ALFWETGV56Q5HXDOMCPKBKTQSEDKHANCNFSM4H3I6DJQ
.

أصدرت Apple تحديثًا: https://developer.apple.com/news/؟
فهل أفهم بشكل صحيح أن استخدام JDK8 على OS X 10.15 سيبدأ في الفشل تمامًا بدءًا من 3 فبراير (خلال 4 أسابيع)؟
سيكون ذلك سيئًا جدًا ..

أصدرت Apple تحديثًا: https://developer.apple.com/news/؟
فهل أفهم بشكل صحيح أن استخدام JDK8 على OS X 10.15 سيبدأ في الفشل تمامًا بدءًا من 3 فبراير (خلال 4 أسابيع)؟
سيكون ذلك سيئًا جدًا ..

لا ، ليس هذا ما سيحدث. إنه أمر سيء ، لكن الأشياء التي تعمل الآن ستستمر في العمل. لتقديم تطبيق للتوثيق ، يجب أن يفي بمجموعة من المتطلبات ، أحدها هو توقيع الرمز ، والآخر هو تقوية وقت التشغيل. لكي يتم تثبيت تطبيقك الذي تم تنزيله من الإنترنت على نظام Catalina (10.15) ، سيتعين عليه تجاوز التحقق من البوابة للتحقق من أنه موثق بشكل صحيح. هذا يحدث الآن على كاتالينا.

ما يحدث في 3 شباط (فبراير) هو أنه لا يمكنك توثيق تطبيقك من قبل Apple إذا لم يقم بعمل الشريط فيما يتعلق بتوقيع الكود وتصلب وقت التشغيل.

كانت Apple في فترة سماح في الوقت الحالي ، بحيث يمكنك إرسال أي شيء ، وسيقومون بتوثيقه ، حتى لو لم يكن هناك متطلبات. بعد 3 شباط (فبراير) ، لن تتمكن من توثيق أحد التطبيقات ، لذلك لن تتمكن من توزيع تطبيق جديد دون أن يمر. بالطبع ، صرحت شركة Apple في يوليو أنه سيكون سبتمبر. في سبتمبر قالوا في يناير ، وفي ديسمبر قالوا الآن فبراير. لذا فهم يدركون أن الأمور ليست على ما يرام وسيؤذون الكثير من الناس من خلال القيام بذلك.

وهذه الحلول. إذا كان لدى العميل حق وصول المسؤول ، فيمكنه السماح بتثبيت أي شيء غير موثق على أي حال من خلال الانتقال إلى لوحة التحكم وتفويض التطبيق.

بالنسبة لأولئك الذين يكافحون مع تقوية وقت التشغيل ، أضف جميع استحقاقات plist الستة المتاحة ، وتأكد من أن وقت تشغيل java ، أيًا كان الإصدار الذي تستخدمه ، موجود في مجلد سيحصل على رمز عند استخدام الخيار -deep (الموجود في MacOS ، أو الأطر). إذا قمت بوضع JRE في المكونات الإضافية ، فإنه يفترض أنه تم توقيعه بواسطة الطرف الثالث ، ولن يقوم بتوقيع الرمز أو تقوية هذا الموقع. أي مواقع أخرى ، خارج MacOS و Frameworks ، يتجاهل رمز الترميز.

حتى لو كان التوقيع عليه بأنفسنا قد ينجح أو لا ، فأنا لا أرى كيف يمكن لأي شخص في الخارج إصلاح النوع التالي من تحذيرات التوثيق (والتي ستصبح أخطاء وتمنع جميع عمليات التوثيق المستقبلية في 3 فبراير):

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

وفقًا لـ https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution/resolving_common_notarization_issues ، هذا متوقع ويجب إنشاء الثنائيات بإصدار أحدث في المقام الأول.

لا يمكننا التوقف عن إصدار تحديثات لبرنامجنا لنظام التشغيل OS X 10.15+ بدءًا من 3 فبراير ، ولكن في الوقت الحالي يبدو أن هذا هو بالضبط ما سيحدث .. وإخبار بيئات الشركة بضرورة تعطيل بعض آليات الأمان بالنسبة لنا غالبًا ما يكون مستحيلًا وليس أبدًا طريق مقبول ..

لا يمكننا التوقف عن إصدار تحديثات لبرنامجنا لنظام التشغيل OS X 10.15+

FWIW كان حلنا هو أن نبنيها بأنفسنا باستخدام SDK أحدث عبر https://github.com/stooke/jdk8u-xcode10

يبدو منذ الأمس أن كل تحذيرات التوثيق قد تحولت أخيرًا إلى أخطاء. مما يعني أنه لا يمكننا توثيق تطبيقاتنا المستندة إلى Java بعد الآن :(

مرحبا يا رفاق. فقط أريد أن أذكر مشكلتي هنا مرة أخرى لأن مشكلتي المرتبطة كانت مغلقة بالإشارة إلى هذه المشكلة. ما زلت آمل أن يكون لدى شخص ما تلميح رائع حول كيفية الإصلاح.

منطق التطبيق الخاص بنا موجود في ملف جرة. يتم تجميع ملف jar هذا لاحقًا في حزمة تطبيق باستخدام الأمر packagebuild (http://s.sudre.free.fr/Software/Packages/about.html). تحتوي هذه الحزمة أيضًا على تبنّي OpenJDK JRE 11.0.4. هذا يعني أننا نشحن هذا الإصدار مع تطبيقنا للتأكد من بدء تطبيقنا دائمًا بالمطلوب.

ثم نوقع الرمز مثل هذا

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

بالطبع جميع الاستحقاقات الستة موجودة ويمكن رؤيتها أيضًا بعد تثبيت التطبيق.

كل شيء يعمل بشكل جيد حتى يتم تمكين وقت التشغيل المتصلب. يمر التوثيق ، لكن لا يمكن تشغيل التطبيق بإصدار جافا المشحون. انها تقول

حدث خطأ أثناء تهيئة الجهاز الظاهري تعذر حجز مساحة كافية في CodeHeap 'non-nmethods' (2496 كيلو بايت)

يبدو أن بدء تشغيل التطبيق بإصدار جافا مثبت مسبقًا يعمل بشكل جيد.

يبدو منذ الأمس أن كل تحذيرات التوثيق قد تحولت أخيرًا إلى أخطاء. مما يعني أنه لا يمكننا توثيق تطبيقاتنا المستندة إلى Java بعد الآن :(

لقد واجهت نفس المشكلة أمس. اليوم ، لا بأس. بالأمس ، أبلغت Apple أن مكتبات Java غير موقعة وخطأ. اليوم ، تم الإبلاغ عن عدم توقيعهم ولكن في تحذير. خلاصة القول ، قامت شركة Apple بتوثيق الحزمة الخاصة بي.

لقد واجهت نفس المشكلة أمس. اليوم ، لا بأس.

لقد رأيت هذا أيضًا ، ربما كانت شركة Apple هي التي تركت الإطارات وفقًا للقواعد الأكثر صرامة التي تم التخطيط لتطبيقها في 3 فبراير.

عند محاولة التوثيق باستخدام ملفات jdk-13.0.1+9 في .jmod ، يتم اكتشاف الملفات على أنها غير موقعة بواسطة خدمة التوثيق من Apple ، على سبيل المثال:

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

أرى أنه تمت إزالة توقيع jmod في 21 أغسطس https://github.com/AdoptOpenJDK/openjdk-build/commit/5cd5306b4e97437aa2129dffd7e83e2f7cfd9255#diff -9a6d9f1628b9075aa2e1b4c33e4b9cced تم إغلاق التذكرة المذكورة https://github.com/AdoptOpenJDK/TSC/issues/107 ، هل هناك خطط لإعادة هذا؟

حدث خطأ أثناء تهيئة الجهاز الظاهري تعذر حجز مساحة كافية في CodeHeap 'non-nmethods' (2496 كيلو بايت)

بعد إلقاء نظرة أخرى على هذا ، يبدو أن المشكلة كانت في البرنامج النصي الخاص بنا. تم تطويره تاريخيًا ، حيث قمنا أيضًا بالتوقيع على JRE. لقد قمت الآن بإزالة جزء البحث عن علامة JRE ويبدو أنه يعمل.

كما ذكر @ abauman-7signal ، فإن جميع الأخطاء هي تحذيرات مرة أخرى الآن ، ربما حتى 3 فبراير
هل لديك أي أفكار حول كيفية توثيق OpenJDK 13 وجعله يعمل بالفعل بعد ذلك؟

أي طريقة جيدة لإصلاح هذا الآن؟ على نظام macOS 10.15.2 ومحاولة استخدام openjdk8

أحاول تلخيص الوضع الحالي. قد يحتوي الملخص على أخطاء ، لأنني لست خبيرًا في هذا المجال. gdams هو من يقود الجهود للحصول على توثيقية تبنّي OpenJDK وتمكين دعم وقت التشغيل القوي ، لكنه مشغول بإنجاز ذلك. لذلك أعتبر مع حبة الملح…

اكتمل العمل على JDK 11 مع HotSpot مع JDK 11 مع OpenJ9 التالي قريبًا. من المفترض أن يعمل تجميع JDK دون مشاكل. من المتوقع أن يتم تضمين نتيجة هذا العمل في وحدة المعالجة المركزية ربع السنوية القادمة (أبريل 2020). لم يتم تحديد ما إذا كان سيتم إعادة بناء 11.0.6 التي ستكون متاحة قريبًا مع التوثيق الكامل ودعم وقت التشغيل القوي. الثنائيات الحالية موثقة بالفعل ويجب أن تستمر إلى ما بعد 3 فبراير دون مشاكل:

$ 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 لا يزال قيد العمل وليس هناك وقت محدد للوصول. تكمن المشكلة الرئيسية هنا في أن JDK 8 يدعم فقط البناء باستخدام أكواد X القديمة والتي بدورها لا تدعم التوثيق ووقت التشغيل القوي. هناك محاولة جارية لاستخدام إصدارات Xcode الأحدث ولكن الثنائيات الناتجة لا تجتاز مجموعة الاختبار حتى الآن. يبحث gdams في الأمر مع Apple. الملفات التنفيذية الحالية موثقة ويجب أن تستمر إلى ما بعد 3 فبراير:

$ 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 الذي سيتم إصداره في مارس بنفس الإمكانات مثل JDK 11. يجب أن تتوفر الإنشاءات الليلية لـ JDK 14 مع التوثيق ودعم وقت التشغيل القوي قريبًا. مطلوب على الأقل https://github.com/AdoptOpenJDK/openjdk-build/pull/1517 لهذا الغرض.

لقد وصلت جميع JDKs الأخرى (9 ، 10 ، 12 ، 13) إلى نهاية عمرها الافتراضي ، وبالتالي فهي خارج النطاق.

شكرًا لك على هذا التحديث وعلى عملك في حل هذه المشكلة.

يرجى إتاحة إعادة بناء 11.0.6 في أقرب وقت ممكن. كما هو الحال ، أعتقد أن المطورين مثلنا الذين يشحنون التطبيقات بوقت تشغيل Java مدمج لن يتمكنوا من شحن بنية جديدة تعمل على Catalina بعد 3 فبراير حتى يتم إصدار 11.0.7 بعد شهرين من الآن. (ما لم تتمكن من الاستيلاء على 11.0.4 + 11.2 قبل إزالته ، وهو ما فعلناه.)

سأكون سعيدًا باختباره باستخدام نظام إنشاء التطبيقات والتوثيق الخاص بنا قبل إصدار أكثر عمومية إذا كان ذلك مفيدًا.

سأكون سعيدًا باختباره باستخدام نظام إنشاء التطبيقات والتوثيق الخاص بنا قبل إصدار أكثر عمومية إذا كان ذلك مفيدًا.

mdgood ، يمكنك بالفعل الحصول على أحد إصدارات JDK11 الليلية التي تحتوي على أحدث تحديثات التوثيق المحدثة. يرجى مراجعة https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk11u/job/jdk11u-mac-x64-hotspot.

سأكون مهتمًا بمعرفة كيفية تقدمك؟ اسمحوا لي أن أعرف!

gdams شكرًا على المؤشر - هذه أخبار رائعة! سألتقط هذا وأبلغ عن نتائجنا.

يجب أن يكون JDK 14 الذي سيتم إصداره في مارس بنفس الإمكانات مثل JDK 11. يجب أن تتوفر الإنشاءات الليلية لـ JDK 14 مع التوثيق ودعم وقت التشغيل القوي قريبًا. مطلوب على الأقل # 1517 لهذا الغرض.

لقد وصلت جميع JDKs الأخرى (9 ، 10 ، 12 ، 13) إلى نهاية عمرها الافتراضي ، وبالتالي فهي خارج النطاق.

لاحظ أن JDK 13 ليس في نهاية العمر الافتراضي. سيصل إلى نهاية العمر الافتراضي فقط عندما يتم إصدار JDK 14 في مارس. يرجى إعادة النظر وإصدار إصدار آخر من JDK 13 موثق ، بحيث يمكن الحصول على نسخة موثقة من JDK الأحدث.

gadams يعمل الإصدار 11.0.7 الليلي في 30 يناير بشكل جيد بالنسبة لنا. تم إنشاء تطبيقنا الموثق بدون تحذيرات ، ويتم تثبيته ويعمل بشكل جيد على نظام Catalina. سأحاول إنشاء طلبنا وتوثيقه مرة أخرى الأسبوع المقبل بعد بدء القيود الجديدة لمجرد التحقق مرة أخرى.

عمل البناء والتوثيق بشكل جيد أمس أيضًا.

اعتبارًا من 2020-02-06 06:01:30 +0000 تظهر لي أخطاء في التوثيق مثل:

شدة | "خطأ"
المسار | ".... / المحتويات / المكونات الإضافية / Java.Runtime / المحتويات / الصفحة الرئيسية / jre / bin / java"
رسالة | "يستخدم الثنائي SDK أقدم من 10.9 SDK."
الهندسة المعمارية | "x86_64"

لذلك أفترض أنك سترى نفس المشكلة في المستقبل القريب.

هل هناك أي تقدم أو جدول زمني لـ Java 8 JRE المبني مقابل 10.9 أو أحدث؟ ما زلنا بحاجة إلى التجميع مع Java 8 بسبب تغييرات RMI.

سيكون موضع تقدير أي معلومات. إذا كانت لا تزال هناك عقبات كبيرة ، فيمكننا النظر في بنائها بأنفسنا من خلال هذا الريبو المذكور سابقًا:
https://github.com/stooke/jdk8u-xcode10

ومع ذلك ، إذا كان هناك Java 8 JRE متاحًا في غضون الأيام القليلة المقبلة ، فإنني أفضل انتظار ذلك.

addsomebass لا يوجد شيء وشيك. وإذا كنت أتذكر بشكل صحيح ، فقد لعب أحد أعضاء فريقنا مع التصحيحات التي ترتبط بها والثنائيات الناتجة لم تجتاز مجموعة الاختبار. لذلك ستجمع JDK مع العيوب المعروفة.

addsomebass لقد كنت أعمل مع Apple لحل إخفاقات الاختبار التي ذكرهاaahlenst. سأكرر أن التصحيحات الموجودة في https://github.com/stooke/jdk8u-xcode10 ليست جاهزة للإنتاج ولديها إخفاقات في الاختبار.

هدفي الحالي هو الحصول على ملف ثنائي jdk8 موثق جاهزًا بنهاية الشهر.

شكرًا لك على التحديث gdams ، أنا حقًا أقدر عملك على هذا.

شكرًا على عمل الجميع في هذا - على الرغم من أنه لا يزال لدي مشكلة.

أنا أستخدم jpackage من أحدث EA لـ JDK14 لإنشاء ملف .app. يحتوي الملف على هذه البنية:

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

المشكلة هي أنه يمكنني إما:

• أنشئ تطبيقًا موثقًا ، لكنه لن يعمل ، أو
• أنشئ تطبيقًا قابلاً للتشغيل ، لكنه لن يتم توثيقه

لوضع شيء واحد جانبًا - تم تعطيل توقيع تطبيقات Mac في jpackage حاليًا لذا لا يمكنني استخدام ذلك. لقد كان يعمل عندما لم يتم التوقيع على وقت التشغيل ، ولكن من الواضح الآن أنني بحاجة للقيام بالتوقيع بنفسي.

يبدو لي أنني أسيء فهم شيء ما حول كيفية دمج وقت التشغيل (JRE) ومتطلبات توقيعه.

أولاً أقوم بتسجيل جميع الملفات التي ليست في وقت التشغيل والتي ليست قاذفات:

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

لقد أدركت أنه إذا تم توقيع وقت التشغيل بالفعل ، فلن يحتاج إلى إعادة التوقيع.

في هذه المرحلة ، يتم تشغيل تطبيقي. ومع ذلك:

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

لست متأكدًا حقًا مما يعنيه هذا - الشيء الوحيد الذي يمكنني العثور عليه عبر الإنترنت هو أنه قد يعني أن التطبيق تالف. هذا ليس الكثير من المعلومات التي يجب أن تحدث.

لذلك أحاول:

% 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

لست متأكدًا مما إذا كان هذا يعني أن وقت التشغيل هو مصدر المشكلة. إذا قمت بإجراء نفس الفحص على مصدر JRE الأصلي (قبل أن يتم تعبئته بواسطة jpackage) أحصل على نفس النتيجة.

% 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

حتى الآن أقوم بالتوقيع على التطبيق:

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

لا بد لي من استخدام --options=runtime وإلا سأحصل على خطأ _ لم يتم تمكين وقت التشغيل المشدد للملف التنفيذي.

تحقق مرة اخرى:

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

الصيحة! ولكن إذا أجريت نفس الفحص على المجلد runtime مع JRE بداخله ، ما زلت أحصل على نفس الرسالة.

هذا يعطي نتيجة التوثيق:

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

أيضًا ، لم يعد التطبيق يعمل:

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

ثم أدركت أن هذا الملف لم يتم توقيعه (فلماذا يسمح spctl بهذا ؟؟؟) ولذا قمت بالتوقيع عليه:

% 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

يتعين علي بعد ذلك إعادة تسجيل التطبيق ، وإلا فإنه يعطي خطأ حول الملفات التي يتم تعديلها.

لكنها ما زالت لا تعمل ، هذه المرة بسبب مشكلة في 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

الآن إذا وقّعت وقت التشغيل ، لمعالجة مشكلة التوثيق أيضًا:

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

وأعد تسجيل التطبيق مرة أخرى ، لأن التطبيق قد تغير. أحصل الآن على هذا الجمال عند الجري:

% 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

ومع ذلك ، لا يزال هذا غير موثق:

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

متأكد بما فيه الكفاية:

% 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

آه - أتذكر - لقد وقعت على runtime/Contents/Home/lib/jli/libjli.dylib لذا أحتاج إلى التوقيع على حزمة runtime مرة أخرى ، ثم حزمة تطبيق الالتفاف.

لذا فإن أسئلتي هي:

• هل من المفترض أن أعيد التوقيع على وقت التشغيل؟
• هل أستخدم وقت التشغيل الصحيح؟
• هل يمكن لأي شخص مشاركة هياكل تطبيقاته الناجحة؟

أهلا!

لقد تمكنت من تشغيله باستخدام JDK 14 و jpackage وتوقيع جميع dylibs والجرار بنفسي. هل وضعت هذه السطور في ملف استحقاقاتك؟

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

هل هذه استحقاقات وقت التشغيل أم للتطبيق الذي يجمع وقت التشغيل؟

لقد استخدمته لجميع أوامر الرمز ، على سبيل المثال لـ dmg ولكن أيضًا لجميع الملفات الأخرى (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 شكرا - سأحاول ذلك. لم أكتب أي استحقاقات من قبل الآن ، ولكن منذ 3 فبراير يبدو أن كل شيء قد تعطل ؛ ربما كنت أعتمد على التقصير الذي اعتاد أن يكون مقبولًا ، لكنه الآن غير مقبول (من الواضح أن هذا ينطبق على وقت التشغيل القوي والبناء ضد حزم SDK القديمة ؛ وهذا هو السبب في أنني أحاول اعتماد هذا الإصدار).

يبدو أن هذا العمل ، شكرا! لذلك ، لتوثيق الحل النهائي الخاص بي:

% 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

جميع الاختبارات تعمل:

% 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

هل تعمل؟

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

نعم!

هل هو موثق؟

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

يا هلا!

ملخص لأولئك الذين يقومون بتجميع JRE:

• توقيع jpackage معطل الآن ، إذا كنت تريد الحصول على شيء موثق
• يجب عليك التوقيع على الرمز الخاص بك.
• يجب عليك إعادة التوقيع على JRE. استخدم -f لفرض التوقيع.
• يجب عليك تحديد الاستحقاقات في جميع مكالمات التوقيع

مرحبًا ، هل يمكنني أن أسأل فقط هل لدينا حاليًا إصدار Mac لـ Java 8 أو Java 9 يسمح بالتوثيق وفقًا للقواعد الجديدة أم لا؟

ijabz إذا كنت أفهم سؤالك بشكل صحيح ، فأنت تريد تجميع ملف jvm داخل أحد التطبيقات ، ثم توثيق ذلك. حاليًا ، لا يمكنك ذلك. تم إنشاء أحدث إصدار من تبنّي OpenJDK بإصدار أقدم من Mac OS SDK ولا يمكن إعادة تجميعه وإعادة توثيقه.

إذا كنت ترغب فقط في تثبيت java ، فستعمل أحدث مثبتات .pkg على OSX Catalina ، ويمكنني تثبيت Java وتنفيذها على ما يرام. تم توثيق أدوات التثبيت هذه ، ويمكنها تثبيت Java على جهازك دون مشكلة.

تعمل gadams على الحصول على نسخة موثقة من Java 8 ، وتأمل أن يتم ذلك في نهاية الشهر. أتمنى له ولجميع التوفيق.

إذا كنت أفهم سؤالك بشكل صحيح ، فأنت تريد تجميع ملف jvm داخل أحد التطبيقات ، ثم توثيق ذلك. حاليًا ، لا يمكنك ذلك

نعم صحيح ، حسنًا ، سيتطلب هذا إجراء تغييرات في التعليمات البرمجية من جانبي ، لكن هل يعمل تطبيق Java 11 BuildOpenJDK؟

أو إذا قمت بتثبيت Oracle builds فسوف يعمل ذلك ، فأنا أستخدم حاليًا Oracle Java 8 على MacOS وقد نجح ذلك حتى 3 فبراير ، فهل هذا ما تقصده ببناء .pkg؟

أنا أبحث فقط عن حل يمكنني استخدامه الآن ، فأنا غير واضح تمامًا بشأن الخيارات المتاحة حاليًا.

ijabz آسف لا أستطيع التحدث إلى Java 11 أو ما بعده ، لأنني لم أعمل معها شخصيًا. بالحكم على التعليقات هنا ، يبدو أن هناك طريقة للحصول على حزمة عمل. يمكنني التحدث فقط عن العمل مع Java 8 builds.

تعد حزم أداة تثبيت mac أو ملفات .pkg أدوات تثبيت للبرامج. يوجد حاليًا بعض أدوات تثبيت .pkg المتاحة لإصدارات تبنّي OpenJDK الموثقة وسيتم تثبيت Java بشكل صحيح ، مثل هذا الموجود هنا:
https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u242-b08/OpenJDK8U-jdk_x64_mac_hotspot_8u242b08.pkg

أشعر أنني غبية لكنني لا أفهم أنه من جهة واحدة ، تعمل شركة تبنّي أوبن جيه دي كيه على بناء جافا 8 موثق ولكن لن يكون جاهزًا حتى نهاية الشهر ، ولكن على العكس من ذلك ، يوجد بالفعل برنامج تثبيت جافا 8 من تبنّي OpenJDk والذي سيقوم بالفعل بتثبيت نسخة مصدقة جافا 8؟

ijabz أعتقد أن السبب هو أنه إذا تم توثيق شيء ما قبل 3 فبراير 2020 ، فلا يزال ساريًا ولا يزال يعمل على macOS Catalina. ومع ذلك ، لن يكون من الممكن توثيقه مرة أخرى الآن ، لأن القواعد أكثر صرامة الآن. لذلك ربما تم توثيق برنامج تثبيت جافا 8 تبنّي أبن جيه دي كيه قبل الثالث من فبراير وبالتالي لا يزال من الممكن استخدامه.

لكن لا يمكنك حزمه بعد الآن لأنه منذ 3 فبراير ، تطلب Apple أن تكون التطبيقات "أكثر صلابة" ، الأمر الذي يتطلب XCode 10. ولم يتم تجميع Java 8 باستخدام XCode 10 ، لذلك لا يمكن تقويتها (حتى الآن).

لذلك يمكنك تثبيت تبنّي جافا 8 على الرغم من عدم تقويته لمجرد أنه تم توثيقه قبل 3 فبراير. ولكن الآن لم يعد من الممكن إنشاء نسخة جديدة منه أو حزم برنامج به ، لأنه لا يمكن تقويته وبالتالي لا يمكن توثيقه.

مما قرأته ، يبدو أن JDK 11.0.7 و JDK 14 يعملان بشكل جيد ، وقد تم تجميعهما باستخدام XCode 10 ، وهما "مقوىان" ويمكن استخدام JDK 14 على الأقل لحزم البرامج.

حسنًا ، شكرًا ، فهمت بشكل أفضل الآن.
هناك شيء آخر عندما تشير إلى JDK 11.0.7 و JDK 14 أفترض أنك تقصد تبني أبنية JDK ، فهل الوضع الخاص بـ تبني OpenJDk هو نفسه بالنسبة للتنزيلات المتاحة على موقع أوراكل؟

اسف لا اعرف. لقد جربته فقط مع OpenJDK (ليس تبنّي OpenJDK ولكن توزيع مختلف لكن أعتقد أنه هو نفسه لجميع توزيعات OpenJDK). ومع ذلك ، نظرًا لأنه يبدو أنه يتطلب تغييرات في JDK 8 لجعله متوافقًا مع XCode 10 ، وبقدر ما أعرف ، تقوم Oracle بإجراء نفس التغييرات في OpenJDK وتوزيعها الخاص ، أعتقد أن JDK 8 الخاصة بهم لم يتم تقويتها أيضًا ( أو بخلاف ذلك كانوا سيصدرون إصدار OpenJDK من Java 8 والذي سيتم تقويته أيضًا). لكن كما قلت لم أجربها.

حسنا، شكرا. أنا أسأل لأنني لست متأكدًا تمامًا من ميزة استخدام بُنيَتُ تبنِّي عوضاً عن مجرد تنزيل من أوراكل.

ijabz Oracle JDK مجاني للاستخدام فقط لمجموعة محدودة من حالات الاستخدام (راجع الأسئلة الشائعة حول ترخيص Oracle Java SE ). تتوفر إصدارات OpenJDK من Oracle أيضًا ، ولا تزال مجانية للاستخدام دون قيود ، ولكن عدد المنصات والإصدارات المدعومة أقل بكثير مما نقدمه هنا في تبنّي أوبن جي دي كيه. كما يوحي الاسم ، فإن تبنّي OpenJDK عبارة عن نسخ من OpenJDK. أحد أهدافنا الرئيسية هو توجيه جميع التغييرات. البائعون الآخرون لـ OpenJDK (وهناك العديد منهم: Amazon ، Azul ، BellSoft ، SAP ، ...) قد يكون لديهم سياسات مختلفة.

حسنًا ، وأرى أنهم يقدمون فقط إصدار MacOS لأحدث الإصدارات الآن ، حسنًا ، شكرًا.

gdams ، هل ما زلت تتوقع أن يكون لديك ثنائي jdk8 موثق جاهزًا بنهاية الشهر؟ أيضا ، هل سيشمل ذلك J9 JVM؟

gdams ، هل ما زلت تتوقع أن يكون لديك ثنائي jdk8 موثق جاهزًا بنهاية الشهر؟ أيضا ، هل سيشمل ذلك J9 JVM؟

هل يمكنك تجربة توزيع BellSoft JDK8 (https://bell-sw.com/pages/java-8u242/). لقد استبدلتُ اعتمادُ OpenJDK J8 بـ BellSoft J8 ، تخلصت من "The binary uses an SDK older than the 10.9 SDK." وتم توثيقها نهائيًا.

يبدو أن BellSoft J8 جاهز بالفعل.

كما أفهم ، فإن BellSoft JDK ليس مجانيًا ..

كما أفهم ، فإن BellSoft JDK ليس مجانيًا ..

رخصة جنو العمومية العامة (GPL) مع "CLASSPATH" باستثناء رخصة GPL
لنظام Liberica Java SE 8u242 JDK أو JRE نفس ترخيص OpenJDK.

أنها توفر الدعم التجاري إذا كنت بحاجة.

شكرا للتوضيح !

يبدو أن هذا العمل ، شكرا! لذلك ، لتوثيق الحل النهائي الخاص بي:

% 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

جميع الاختبارات تعمل:

% 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

هل تعمل؟

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

نعم!

هل هو موثق؟

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

يا هلا!

ملخص لأولئك الذين يقومون بتجميع JRE:

• توقيع jpackage معطل الآن ، إذا كنت تريد الحصول على شيء موثق
• يجب عليك التوقيع على الرمز الخاص بك.
• يجب عليك إعادة التوقيع على JRE. استخدم -f لفرض التوقيع.
• يجب عليك تحديد الاستحقاقات في جميع مكالمات التوقيع

تمكنت من اتباع خطواتك ولكن لدي مكتبة وحتى معها
<key>com.apple.security.cs.disable-library-validation</key> <true/>

لقد تلقيت هذا الخطأ:

استثناء في الخيط "JavaFX Application Thread" java.lang.UnsatisfiedLinkError: /private/var/folders/0f/trlp6tp95qjbzm99ds8pt8zm0000gp/T/JxBrowser/7.5/libbrowsercore_toolkit.dylib: dlopen / 0 JxBrowser / 7.5 / libbrowsercore_toolkit.dylib، 1): لم يتم العثور على صورة مناسبة. هل وجدت:
/private/var/folders/0f/trlp6tp95qjbzm99ds8pt8zm0000gp/T/JxBrowser/7.5/libbrowsercore_toolkit.dylib: توقيع الكود في (/private/var/folders/0f/trlp6tp95qjbzm99ds8ptowsToolz) قيد التشغيل باستخدام "التحقق من صحة المكتبة": عملية التعيين والملف المعين (غير النظام الأساسي) لهما معرفات فريق مختلفة

هل هذا يعني أن المكتبة التي أملكها تحتاج أيضًا إلى هذا الاستحقاق للعمل أم أنها شيء من جانبي؟

الجزء الأكثر إحباطًا في عملية التوثيق هو أنني اضطررت إلى ربط عملية الإصدار هذه في خط أنابيب CI / CD الخاص بي. أتمنى أن تقدم Apple نقطة نهاية اختبار. لا أحتاجه موثقًا ، أريد فقط معرفة ما إذا كان موثقًا. من المسلم به أن الفارق ضئيل ، لكن هناك أمران يجعلانه غير مريح.

1. إذا استهلكت تحديثًا لطرف ثالث ، فأنا بحاجة إلى عملية استيعاب تؤكد أن التحديث غير قابل للتوثيق. من خلال إرسال هذا الطرف الثالث للتحقق ، لقد قمت الآن بتوثيق ذلك الطرف الثالث باستخدام أرصدة شركتي ، ويعتقد أفراد الأمن لدي أن هذا ليس رائعًا.
2. أقوم بتقديم أشياء للتوثيق كل يوم لا أنوي على الإطلاق تقديمها للعميل ، ولا بد لي من استخدام بيانات الاعتماد المصرح لها بإجراء أكثر من مجرد اختبار. نظرًا لأن هذه الاعتمادات أصبحت الآن جزءًا من خط الأنابيب الخاص بي ، فإن مساحة سطح الأمان الخاصة بي لخرق بيانات الاعتماد أكبر. لذلك أريد نقطة نهاية اختبار لا تستخدم أرصدة ، أو تستخدم أرصدة لأغراض الاختبار فقط.

هل يواجه أي شخص آخر المشكلة التي أواجههاgravelld @ dg76 لقد حاولت إنشاء استحقاق ولكن لا يبدو أن هذا يؤدي إلى تعطيل التحقق من صحة المكتبة

@ dcboy95 أنا آسف - لا أعرف كيف تعمل استحقاقات معينة فيما يتعلق بالتغطية على الحزمة بأكملها. لقد وجدت ، مع توقيع الرمز ، اضطررت إلى الاستقالة من المكتبة بأكملها التي قمت بشحنها ، لذلك ربما يعني ذلك أن قاعدة الشفرة بالكامل التي تشحن بها يجب أن تتمتع أيضًا بالاستحقاق؟ آسف.

@ dcboy95 أعتقد أنه يجب عليك فقط الاستقالة من ملف "libbrowsercore_toolkit.dylib" باستخدام الرمز المميز والشهادة الخاصة بك. (اعتقدت أنني قمت بالفعل بنشر هذا الاقتراح هنا ولكن لا يمكنني العثور على أي رد مني.) يبدو أن الخطأ يشير فقط إلى أن المكتبة لها توقيع مختلف عن باقي التطبيق. وأعتقد أن كل شيء يجب أن يكون له نفس التوقيع لضمان عدم قيام أي شخص آخر بوضع أي شيء فيه. لذا فقط حاول تشغيل علامة الرمز على "libbrowsercore_toolkit.dylib". هل هذا يصلح؟

@ dg76 للأسف هذا لم ينجح. مع مكتبة الطرف الثالث ، تعيد تثبيت نفسها إذا كان هناك إصدار مختلف. لذلك عندما أقوم بتوقيع هذا الملف ، فإنه يراه كملف قديم ويقوم بتنزيل ملف جديد ، ليحل محل الملف المعدل. مما أدى إلى نفس الخطأ. اعتقدت أن الاستحقاق com.apple.security.cs.disable-library-validation سيصلح هذه المشكلة ولكن لا يبدو كذلك.

@ dcboy95 أعتقد أن هذا لن ينجح. أعتقد أن الغرض من نظام التوثيق من Apple هو التأكد من أن المطور قد أكد أن جميع أجزاء تطبيقه قد تم اختبارها وأنها جيدة. ربما لا يُسمح بتحميل أجزاء من مطورين آخرين أثناء وقت التشغيل ، والتي لم يتم اختبارها وتأكيدها من قبل المطور. ألا يمكنك فقط تعطيل وظيفة التنزيل التلقائي؟

@ dg76 شكرًا على المعلومات ، سأضطر إلى البحث في وثائقهم لمعرفة ما إذا كان هذا ممكنًا. شكرا لك مرة أخرى

تم إصدار OpenJDK 14 + 36 وهو موثق بالكامل. يرجى الإبلاغ مرة أخرى في حالة حدوث مشاكل.

لا يزال JDK 8 موثق بالكامل في الأعمال. نأمل أن يتم تضمين هذا في وحدة المعالجة المركزية ربع السنوية القادمة (أقرب يوم ثلاثاء إلى 17 أبريل).

اجتازت التصحيحات المطلوبة بعض عمليات التشغيل الاختبارية (بما في ذلك TCK) ، ولكن المزيد من التحقق من الصحة ضروري. تخطط gdams لنشر الحالة الحالية حتى نتمكن من توفير تصميمات للاختبار في المستقبل غير البعيد.

aahlenst هل هناك أي خطط لـ JDK 11؟

@ dcboy95 سيتم نشر JDK 11 موثقة بالكامل كجزء من وحدة المعالجة المركزية ربع السنوية التالية (بعد فترة وجيزة من أقرب يوم ثلاثاء إلى 17 أبريل إذا كنت أتذكر قاعدة Oracle بشكل صحيح). في غضون ذلك ، يمكنك الحصول على إصدار ليلي من JDK 11 على https://adoptopenjdk.net/nightly.html؟variant=openjdk11&jvmVariant=hotspot والإبلاغ إذا لم يعمل.

مرحبًا ، لقد حاولت استخدام jdk-11.0.7 + 7 للمثبت ولكن لا يزال [1] يفشل مع الخطأ "توقيع الثنائي غير صالح"

[1] /Contents/MacOS/libjli.dylib

NishikaDeSilva حاول تشغيل هذا:

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

gdams لقد جربت الحل الخاص بك.

الأمر: codeign --verbose = 4 --deep --force -s "تطبيق معرف المطور: abc (xxxxx)" jdk-11.0.7 + 7

انتاج:
jdk-11.0.7 + 7: استبدال التوقيع الحالي
jdk-11.0.7 + 7: لا يُسمح بتفرع الموارد أو معلومات الباحث أو المخلفات المماثلة

لكنها تشير إلى الخطأ التالي ...
jdk-11.0.7 + 7: الكود ليس له موارد ولكن التوقيع يشير إلى وجوب وجودها.

أفعل شيئا خاطئا ؟

حاولت 11.0.7 + 7 من البناء الليلي. يمر التوثيق ويظهر التطبيق بنجاح. ومع ذلك ، يبدو أن الثنائيات (dylib) يتم البحث عنها الآن في حزمة البرطمان المنفذة فقط من خلال أي حمل أصلي يستخدمه JNA. نتيجة لذلك ، يتلقى تطبيقنا الآن UnsatisfiedLinkErrors عند محاولة الوصول إلى dylib المثبت على النظام. كان هذا يعمل من قبل.

MoxxiManagarm هل تم التوقيع على dylibs؟ تحقق مع codesign -v -v /path/to/dylib .

aahlenst أشك ، هذه dylibs (برامج تشغيل الأجهزة) التابعة لجهات خارجية مثبتة على النظام ، فهي ليست جزءًا من تطبيقنا. لدي أيضًا الاستحقاق نشطًا com.apple.security.cs.disable-library-validation ، لا ينبغي أن تكون هذه مشكلة.

يوجد lib داخل الدليل /usr/local/lib/

باستخدام الإصدار الليلي لـ JDK 11's JRE ، لدي نفس المشكلة مثل NishikaDeSilva. لقد اختبرت نسختين من JRE 13 و 14 ليلاً من أجل قياس جيد.

لا أعرف ما إذا كان أي من هذا سيكون مفيدًا ، ولكن هذه ملاحظاتي.

تشغيل codesign -dvvv libjli.dylib للتحقق من نتائج التوقيع في هذا.

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

التحقق من التوقيع باستخدام spctl -a -vv libjli.dylib يؤدي إلى ما يلي:
libjli.dylib: code has no resources but signature indicates they must be present

لا يمكنني العثور على أي توثيق جيد لهذا الخطأ ، ولكن يبدو أن له علاقة بـ "الموارد المختومة" ، والتي يقول التوقيع أعلاه أنها none . لا معنى له.

تؤدي محاولة ترميز الملف بنفسي إلى ما يلي:
resource fork, Finder information, or similar detritus not allowed

تشير جميع الوثائق الموجودة حول هذا الخطأ إلى أنه ناتج عن السمات الموسعة في الملف. على وجه التحديد ، com.apple.FinderInfo و com.apple.ResourceFork . لكن ls -l@ libjli.dylib و xattr -l libjli.dylib لا يدرجان أي سمات x.

من الغريب أن نقل الملف إلى موقع آخر (في أي مكان خارج المجلد Contents/MacOS ) أو تغيير امتداد الملف إلى شيء آخر غير .dylib سيجعل التوقيع بالرمز والتحقق من التوقيع يمر بشكل طبيعي ، دون أي مما سبق غير منطقي أخطاء. يجب أن تأخذ آلية رمز الرمز في الاعتبار أيضًا موقع الملف ، مما يجعله يختلف عن نتائج الملف عند Contents/Home/lib/jli/libjli.dylib .

أي تحديث لبرنامج التشغيل dylib الذي لم يتم العثور عليه في /usr/local/lib/ بعد التوثيق (الإصدار الليلي)؟

التحقق من التوقيع باستخدام spctl -a -vv libjli.dylib ينتج عنه:
libjli.dylib: الكود ليس له موارد لكن التوقيع يشير إلى وجوب وجودها

@ justin-espedal حاول تشغيل هذا في دليل المستوى الأعلى:

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

انتاج:
jdk-11.0.7 + 7: استبدال التوقيع الحالي
jdk-11.0.7 + 7: لا يُسمح بتفرع الموارد أو معلومات الباحث أو المخلفات المماثلة

NishikaDeSilva قم بتشغيل هذا في الدليل قبل تشغيل الأمر codeign:

xattr -cr .

هذا يعمل. لا حاجة للتكرار -cr ، يكفي فقط إزالة com.apple.FinderInfo من مجلد المستوى الأعلى. من المنطقي أن تكون سمة FinderInfo في مجلد المستوى الأعلى هي التي تتداخل مع رمز الحزمة بأكملها.

بغض النظر عما إذا كان هذا xattr موجودًا أم لا ، فإن libjli.dylib لا يزال غير قادر على تعيين رمز بمفرده. هل تتطلب آلية الرمز المميز وجود dylib في هذا الموقع المحدد للتحقق من شيء ما باستخدام توقيع كود الحزم المحتوي؟ إذا كان الأمر كذلك (أو ربما بغض النظر عن ذلك) ، فلماذا لا يتم ببساطة تعيين رموز الحزمة بأكملها افتراضيًا؟

أنا بالتأكيد أفضل عدم التوقيع على كود JRE بالكامل إذا لم يكن علي ذلك.

gadamsaahlenst أي تحديث على JDK 1.8 الموثق ؟ هل نصدره في 17 أبريل؟ هل هناك مجموعة سابقة لتجربتها؟

الأسبوع المقبل ، سيكون هناك 8u252 بدون توثيق ووقت تشغيل محسّن أولاً. بعد ذلك ، سنقلب المفاتيح ونبني واحدة مع التوثيق ووقت التشغيل المشدد. ستتبع معلومات إضافية. لا أعرف ما إذا كان هناك بالفعل ثنائي جاهز للاختبار من قبل الآخرين.

هل سيتضمن 8u252 libAppleScriptEngine.dylib الذي تم إنشاؤه مقابل sdk لاحقًا ، لذلك لا يفشل مع "يستخدم الثنائي SDK أقدم من 10.9 SDK" ، سيكون هذا مفيدًا للغاية ، https://stackoverflow.com/questions/61208189/java-notarization -من- libapplescriptengine-dylib-failing-with-the-binary-الاستخدامات- an

لقد انتهى الإصدار 8u252 الذي طال انتظاره ، ولكن اتضح أن جميع الثنائيات الموجودة فيه تقريبًا لا تزال مبنية باستخدام sdk 10.8 ، مما يمنع التوثيق الناجح.
احتوى JRE من https://ci.adoptopenjdk.net/view/work٪20in٪20progress/job/jdk8u-mac-x64-hotspot-notarized/10/ على 10.14 ثنائيات لذلك كنا نأمل أن 8u252 الرسمية سوف تفعل ذلك أيضًا.

الأسبوع المقبل ، سيكون هناك 8u252 بدون توثيق ووقت تشغيل محسّن أولاً. بعد ذلك ، سنقلب المفاتيح ونبني واحدة مع التوثيق ووقت التشغيل المشدد.

هل لديكم جدول لهذا يمكنكم مشاركته من فضلكم؟

meshcow يصعب تقديره. لهذا السبب لم أعطي أي تقدير في المقام الأول. لا تزال خطوط الأنابيب مع الإصدارات العادية قيد التشغيل (على سبيل المثال ، 14.0.1 مع HotSpot و 11.0.7 مع OpenJ9). الإصدار مع وقت تشغيل صارم سيتم بناؤه بعد ذلك.

meshcow - سنقوم ببناء 8u252.1 لاختبار تصحيح التوثيق لنظام التشغيل Mac OS الخاص بنا ، يجب أن يكون هنا في غضون يوم أو يومين.

لمعلوماتك ، استخدمت BellSoft 8u252 لمحاولة الحصول على libAppleScriptEngine.dylib الذي تم إنشاؤه مقابل sdk لاحقًا للسماح بالتوثيق ، ويمكن تأكيد نجاحه.

يمكنني أيضًا تأكيد أنني جمعت اعتماد JDk 11.0.7 JRE في تطبيقي وقمت بتوثيق طلبي بنجاح.

لمعلوماتك ، استخدمت BellSoft 8u252 لمحاولة الحصول على libAppleScriptEngine.dylib الذي تم إنشاؤه مقابل sdk لاحقًا للسماح بالتوثيق ، ويمكن تأكيد نجاحه.

هل يمكنك أن تخبر ، من فضلك ، ما الذي تستخدمه لربط jre بتطبيقك؟ عندما أستخدم javapackager ، فإنه يقول fxbundlerpath/Contents/MacOS/libpackager.dylib: is already signed .
وكيف يمكنك فعل ذلك باستخدام تطبيق JDK 11؟

لقد استخدمت Appbundler (InfinityKind fork) - https://github.com/TheInfiniteKind/appbundler/
سأحاول نشر إجابة تفصيلية كاملة على stackoveflow غدًا

@ as1an تمت إضافة إجابة لسؤالي الخاص على https://stackoverflow.com/questions/58548736/notarize-existing-java-application-for-macos-catalina

هل لدى أي شخص بنية موثقة J9 JVM 1.8 لنا لاختبارها؟

meshcow يصعب تقديره. لهذا السبب لم أعطي أي تقدير في المقام الأول. لا تزال خطوط الأنابيب مع الإصدارات العادية قيد التشغيل (على سبيل المثال ، 14.0.1 مع HotSpot و 11.0.7 مع OpenJ9). الإصدار مع وقت تشغيل صارم سيتم بناؤه بعد ذلك.

aahlenst هل سيشمل هذا الإصدار J9 من 1.8 JVM أيضًا؟

إنه قادم هذا الأسبوع.

شكرا جزيلا!

تم إصدار ثنائي JDK8u Hotspot موثق اليوم jdk8u252-b09.1

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

جربه وأخبرنا إذا كانت لديك أية مشكلات!

سيتم طرح OpenJ9 أيضًا قريبًا

تمكنا من توثيق تطبيقنا بنقطة الاتصال المجمعة 8u252-b09.1 JRE بنجاح.
شكرا جزيلا يا رفاق!

meshcow هل يقوم تطبيقك بتضمين JVM أم أنه يستخدمه خارجيًا؟ نشهد مشكلة في وقت التشغيل تفيد بأن التوقيع مختلف في JVM عن توقيع التطبيق لدينا.

meshcow هل يقوم تطبيقك بتضمين JVM أم أنه يستخدمه خارجيًا؟ نشهد مشكلة في وقت التشغيل تفيد بأن التوقيع مختلف في JVM عن توقيع التطبيق لدينا.

JVM مضمن (JNI) ، يتم توقيع التطبيق من خلال الشهادة الخاصة بنا. لم نوقع أي شيء داخل JRE ، حيث تبين أنه تم توقيع كل شيء فيه بالفعل.
لا توجد قضايا حتى الآن.

meshcow أعلم أن هذا ليس له علاقة ، وأعتذر إذا لم يكن هذا هو المنتدى المناسب لذلك ، لكنني كنت أعاني من أجل جعل JNI يعمل في تطبيق مجمع ، وكنت أتساءل عما إذا كان بإمكانك مشاركة أي موارد ساعدتك في الوصول إلى هناك . جميع حِزم تطبيقات جافا الحالية التي يمكنني العثور عليها تنتج ملفًا تنفيذيًا غير مقوى يمنع التوثيق ، حتى عندما يكون JRE قابلاً للتوثيق.

أي مساعدة لتجاوز هذه العقبة الأخيرة سيكون موضع تقدير كبير.

addsomebass - نحن نستخدم نهجًا قياسيًا حسب الكتاب: قاذفة صغيرة مكتوبة في Objective C والتي تستخدم Java Invocation API لتحميل JVM وبدء تطبيق Java [الخالص] معها. يتم وضع المشغل في دليل تطبيق OSX ضمن / المحتويات / MacOs. يتم وضع JRE هناك في مجلد تطبيق java ضمن / المحتويات / [اسم التطبيق] / jre.
يتم توقيع تطبيق OSX ، ثم يصبح جاهزًا لإرساله للتسجيل. نستخدم أرغس سطر cmd التالية لـ codeign: --strict --timestamp --entitlements entitlements.plist --force --deep --options runtime ، ومحتويات entitlemenst.plist كما في هذه الإجابة: https://stackoverflow.com/a/58553559.

لذا فإن الشيء الوحيد الذي يمكنني أن أنصح به هو إنشاء المشغل الخاص بك. لا ينبغي أن يكون الأمر بهذه الصعوبة ، فهناك الكثير من الأمثلة التي يمكنك العثور عليها ، على سبيل المثال https://github.com/search؟l=Objective-C&q=JNI_createJavaVM&type=Code

addsomebass أعتقد أنك لست بحاجة إلى قاذفة خاصة. أنا أستخدم JNI في برنامج Java عادي تم تجميعه باستخدام Java packager jpackage من Java 14. يمكنك العثور على خطواتي هنا: https://blog.dgunia.de/2020/02/12/signed-macos-programs- with-java-14 / يصف التوقيع فقط وليس جزء JNI. لكنني قمت بإنشاء ملف JNI dylib عادي تم توقيعه أيضًا أثناء هذه العملية. إنه يعمل بشكل جيد حتى الآن ، كان من الممكن توثيقه.

addsomebass @ dg76 جافا 8 هي حالتنا وليس 14

meshcow @ dg76 شكرا للنصائح. نحتاج إلى استخدام Java 8 أيضًا بسبب تغييرات RMI.

شكرا لدعم التوثيق الآن. ولكن أين هو javapackager في الحزمة؟ يمكنني أن أجد فقط بناء jdk8 "العادي" بدون javapackager. هل هناك jdk كامل مع javapackager مدمج؟

تضمين التغريدة
استخدمنا الإصدار المقوى من Open J9 الذي تم إصداره الأسبوع الماضي وحصلنا على هذا الخطأ من Apple أثناء التوثيق:

{"الخطورة": "خطأ" ، "رمز": فارغ ، "المسار": "/jre/Contents/MacOS/libjli.dylib "،" message ":" توقيع الثنائي غير صالح. "،" docUrl ": null،" architecture ":" x86_64 "}

تقول أن libjli.dylib ليس له توقيع ، لكنني أعتقد أنه ملف ارتباط؟

لقد جربنا هذا الأمر أيضًا

تم تنزيل الملف - OpenJDK8U-jre_x64_mac_openj9_macosXL_8u252b09_openj9-0.20.0.tar.gz * فك ضغطه في المجلد jdk8u252-b09-jre-j9 ثم فحص التوقيع -

codeign -vvvv jdk8u252-b09-jre-j9jdk8u252-b09-jre-j9 /: الكود لا يحتوي على موارد ولكن التوقيع يشير إلى وجوب وجودها

لست متأكدا ما إذا كان كلاهما مرتبطين. هل هناك إصلاح لهذه؟

شكرا لك.

إذا كنت بحاجة إلى مساعدة ، فيرجى فتح المشكلات في https://github.com/adoptopenjdk/openjdk-support/.