Temurin-build: MacOS कठोर रनटाइम समर्थन

जब मैं कोशिश करता हूं और इस ध्वज को जोड़ता हूं तो मुझे निम्न त्रुटि मिलती है:
error: invalid or inappropriate API flag(s) specified

@tkie क्या आपके पास यहां कोई और अंतर्दृष्टि है?

https://help.apple.com/xcode/mac/current/#/dev033e997ca को देखते हुए यह सुझाव देता है कि हमें macOS 10.13 या इसके बाद के संस्करण पर कोड साइन करने की आवश्यकता हो सकती है, मुझे यहां एक नाटक करने दें।

मैं MacOS 10.14.6 पर XCode संस्करण 10.3 (10G8) का उपयोग करता हूं।
मुझे नहीं पता कि कठोर रनटाइम का समर्थन करने के लिए न्यूनतम एक्सकोड संस्करण कौन सा है, लेकिन यह एक नई सुविधा है।

ठीक है, इसलिए मैंने यहां थोड़ी प्रगति की है, मैं एक jdk12 बिल्ड को सक्षम करने पर हस्ताक्षर कर सकता हूं। त्रुटि के आसपास काम करने के लिए:

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

आपको एक प्लिस्ट के रूप में एंटाइटेलमेंट जोड़ने की आवश्यकता है:

<?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 पर यह काम करने में भी कामयाबी हासिल की है:

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

परीक्षण jdk11 ऐप नोटरीकरण: रिपोर्ट (सफल)

परीक्षण jdk12 ऐप नोटरीकरण: रिपोर्ट (सफल)

@gdams मुझे खेद है, मैंने खुद कभी JDK नहीं बनाया है। मैंने हमेशा बाइनरी वितरण डाउनलोड किया है। हो सकता है कि आप अपने आज के JDK 11 टेस्ट बिल्ड को MacOS के लिए कहीं डाउनलोड के लिए उपलब्ध करा सकें? तब मैं अपने आवेदन के लिए ऐप्पल से नोटरीकरण प्राप्त करने का प्रयास कर सकता था जिसमें मैं जेडीके को बंडल करना चाहता था। इसलिए मैं पुष्टि कर सकता हूं कि आपका परिवर्तन काम करता है या नहीं।

@tkie मैं एक फिक्स उतरा हूं जो JDK11 + पर कुछ भी ठीक करता है। कृपया ध्यान दें कि यह परिवर्तन हमारी अगली रिलीज़ तक ध्यान देने योग्य नहीं होगा (मैं एडॉप्ट लोगों के साथ फिर से रिलीज़ की संभावना पर चर्चा करूँगा ताकि लोग इसका तुरंत उपभोग कर सकें।

JDK8 पर हमें अभी भी एक समस्या है:

The binary uses an SDK older than the 10.9 SDK

मेरा सुझाव यह होगा कि हम एक JDK8 बिल्ड की शिपिंग की जांच करें जो बंडलिंग के लिए अनुकूलित है (यानी बाद के टूलचेन पर बनाया गया है) लेकिन यह एक आसान काम नहीं हो सकता है क्योंकि इसके लिए बाद के JDK से JDK8u रेपो में बैकपोर्ट के भार की आवश्यकता होती है।

@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 बिल्ड के लिए धन्यवाद। मैं पुष्टि कर सकता हूं कि OpenJDK12U-jre_x64_mac_hotspot_2019-07-31-11-04.tar.gz से JRE सहित मेरे आवेदन को Apple द्वारा नोटरीकृत किया गया था।

@gdams मैंने OpenJDK11U-jre_x64_mac_hotspot_2019-07-31-11-27.tar.gz के साथ भी परीक्षण किया है। इसके साथ नोटरीकरण भी सफल रहा।
मेरे दृष्टिकोण से समस्या हल हो गई है और जावा 8 की जांच करना आवश्यक नहीं होगा।
Java 11 और इसके बाद के संस्करण के लिए इस समस्या को हल करने के लिए धन्यवाद।

जब हम जावा 1.8 रनटाइम के साथ अपने एप्लिकेशन को नोटराइज करने का प्रयास करते हैं तो हमें "बाइनरी 10.9 एसडीके से पुराने एसडीके का उपयोग करता है" त्रुटि भी मिलती है।

वर्तमान में हमें जावा 1.8 के साथ बने रहने की आवश्यकता है ताकि अधिक हाल के जावा में अपग्रेड नहीं किया जा सके।

क्या कोई तारीख है जब एक अद्यतन जावा 1.8 रनटाइम उपलब्ध होगा जो इस नोटरीकरण परीक्षण को पास करेगा?

मैं यह भी पुष्टि कर सकता हूं कि यह https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk12u/job/jdk12u-mac-x64-hotspot/ के साथ तय किया गया है।

हम एक ओपनजेडके 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 क्षमता के लिए पात्रता जोड़ी? इसके बिना नोटरीकरण विफल हो जाता है। यकीन है कि जेआरई को इसकी जरूरत है।

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

मैंने @gdams से अपस्ट्रीम उदाहरण का उपयोग करके यह कोशिश की। हम एक्सकोड का उपयोग नहीं कर रहे हैं बल्कि इसके बजाय कमांड लाइन टूल्स का उपयोग कर रहे हैं। यह संभव है कि मुझे स्विच करना होगा लेकिन उम्मीद है कि इससे बच सकते हैं। यह सिर्फ हस्ताक्षर करने के चरणों में सुधार करने की बात हो सकती है; नोटरीकरण से पहले चीजें आसान थीं...

स्पष्ट होने के लिए, Apple की वर्तमान शिथिल आवश्यकताओं के कारण, नोटरीकरण इसके बिना भी सफल होता है। चिंता की बात यह है कि चेतावनी भविष्य में विफलता का संकेत देती है।

यदि कोई मुझे बताता है कि XCode का उपयोग करते समय @davidby द्वारा उल्लिखित JSON लॉग कहां मिलेगा, तो मैं XCode का उपयोग करके अपने सॉफ़्टवेयर का एक और नोटरीकरण करूंगा और जांच करूंगा कि क्या मुझे ऐसी चेतावनियां भी मिलती हैं।
मैं केवल यह बता सकता हूं कि नोटरीकरण सफल है, लेकिन मैंने अभी तक चेतावनियों के लिए लॉग फ़ाइल की जांच नहीं की है।

मैं इस दस्तावेज़ से काम कर रहा हूँ। विशेष रूप से "अपने अनुरोध की स्थिति की जांच करें" अनुभाग देखें।

@gdams ऐसा लगता है कि हार्डेंड रनटाइम सपोर्ट फिर से गायब हो गया है? अगर मैं jdk-11.0.4+11.4 का उपयोग करता हूं तो नोटरीकरण काम करता है। लेकिन jdk-11.0.5+10 के साथ मुझे त्रुटि मिलती है कि कठोर रनटाइम समर्थन सक्षम नहीं है।

ऐसा लगता है कि आप कठोर रनटाइम विकल्प के बिना निष्पादन योग्य पर हस्ताक्षर करते हैं। की कोशिश
अपने कोडसाइन कमांड में --option runtime जोड़ें।

मंगल पर, 5 नवंबर, 2019, 07:56 डेविड एबी नोटिफिकेशन @github.com ने लिखा:

हाय दोस्तों,
मुझे यकीन नहीं है कि यह पूरी तरह से बंद है। हम नवीनतम 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/notifications/unsubscribe-auth/ALFWETGV56Q5HXDOMCPKBKTQSEDKHANCNFSM4H3I6DJQ
.

Apple ने एक अपडेट जारी किया है: https://developer.apple.com/news/?id=12232019a
तो क्या मैं इसे सही ढंग से समझता हूं कि ओएस एक्स 10.15 पर जेडीके 8 का उपयोग करना 03 फरवरी (4 सप्ताह में) से पूरी तरह विफल होना शुरू हो जाएगा?
यह बहुत बुरा होगा..

Apple ने एक अपडेट जारी किया है: https://developer.apple.com/news/?id=12232019a
तो क्या मैं इसे सही ढंग से समझता हूं कि ओएस एक्स 10.15 पर जेडीके 8 का उपयोग करना 03 फरवरी (4 सप्ताह में) से पूरी तरह विफल होना शुरू हो जाएगा?
यह बहुत बुरा होगा..

नहीं, ऐसा नहीं होगा। यह बुरा है, लेकिन जो चीजें अभी काम कर रही हैं, वे काम करती रहेंगी। नोटरीकरण के लिए एक ऐप सबमिट करने के लिए, इसे आवश्यकताओं के एक समूह को पूरा करना होगा, उनमें से एक कोड साइनिंग है, दूसरा रनटाइम हार्डनिंग है। कैटालिना (10.15) पर इंटरनेट से डाउनलोड किए गए आपके ऐप को इंस्टॉल करने के लिए, उसे गेटकीपर की जांच से गुजरना होगा कि यह ठीक से नोटरीकृत है। कैटालिना पर अभी यही होता है।

03 फरवरी को क्या होता है कि यदि आप कोड साइनिंग और रनटाइम सख्त करने के संबंध में बार नहीं बनाते हैं तो आप ऐप्पल द्वारा अपने ऐप को नोटरीकृत नहीं कर सकते हैं।

Apple अभी ग्रेस पीरियड में है, ताकि आप कुछ भी सबमिट कर सकें, और वे इसे नोटराइज़ कर देंगे, भले ही यह आवश्यकताओं को पूरा न करे। 3 फरवरी के बाद, आप किसी ऐप को नोटरीकृत नहीं करवा पाएंगे, इसलिए आप एक नए ऐप को पास किए बिना वितरित नहीं कर पाएंगे। बेशक, जुलाई में Apple ने कहा कि यह सितंबर होगा। सितंबर में उन्होंने जनवरी कहा, और दिसंबर में उन्होंने अब फरवरी कहा। इसलिए वे पहचान रहे हैं कि चीजें सही नहीं हैं और वे ऐसा करके बहुत से लोगों को चोट पहुँचाने वाले हैं।

और उनके उपाय हैं। यदि किसी ग्राहक के पास व्यवस्थापक पहुंच है, तो वे नियंत्रण कक्ष में जाकर और ऐप को अधिकृत करके किसी भी चीज़ को स्थापित करने की अनुमति दे सकते हैं जो नोटरीकृत नहीं है।

रनटाइम हार्डनिंग के साथ संघर्ष करने वालों के लिए, उपलब्ध सभी छह प्लिस्ट एंटाइटेलमेंट जोड़ें, और सुनिश्चित करें कि आपका जावा रनटाइम, जो भी संस्करण आप उपयोग कर रहे हैं, एक फ़ोल्डर में है, जो -डीप विकल्प (जो मैकओएस में है) का उपयोग करने पर कोडसाइन हो जाएगा। , या फ्रेमवर्क)। यदि आपने अपने जेआरई को प्लगइन्स में रखा है, तो यह मानता है कि यह तीसरे पक्ष द्वारा कोडित किया गया था, और उस स्थान को कोडन या कठोर नहीं करेगा। मैकोज़ और फ्रेमवर्क के बाहर कोई अन्य स्थान, कोडिंग को अनदेखा करता है।

भले ही खुद इस पर हस्ताक्षर करने से काम हो या न हो, मैं यह नहीं देखता कि बाहर का कोई भी व्यक्ति निम्नलिखित प्रकार की नोटरीकरण चेतावनियों को कैसे ठीक कर सकता है (जो एक त्रुटि बन जाएगी और भविष्य के सभी नोटरीकरण 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 के अनुसार, यह अपेक्षित है और बायनेरिज़ को पहले स्थान पर एक नए संस्करण के साथ बनाने की आवश्यकता है।

हम 3 फरवरी से ओएस एक्स 10.15+ के लिए अपने सॉफ़्टवेयर में अपडेट जारी करना बंद नहीं कर सकते हैं, लेकिन वर्तमान में ऐसा लग रहा है कि वास्तव में ऐसा ही होगा .. और कॉर्पोरेट वातावरण को बताना कि उन्हें हमारे लिए कुछ सुरक्षा तंत्र को अक्षम करना चाहिए अक्सर असंभव है और कभी नहीं एक स्वीकार्य पथ ..

हम OS X 10.15+ . के लिए अपने सॉफ़्टवेयर में अपडेट जारी करना बंद नहीं कर सकते

एफडब्ल्यूआईडब्ल्यू हमारा समाधान https://github.com/stooke/jdk8u-xcode10 के माध्यम से इसे एक नए एसडीके के साथ स्वयं बनाना था

ऐसा लगता है कि कल से नोटरीकरण की वे सभी चेतावनियाँ अंततः त्रुटियों में बदल गई हैं। जिसका अर्थ है कि हम अपने जावा-आधारित अनुप्रयोगों को और अधिक नोटरीकृत नहीं कर सकते :(

हाय दोस्तों। मैं यहाँ फिर से अपनी समस्या का उल्लेख करना चाहता हूँ क्योंकि मेरा जुड़ा हुआ मुद्दा इसी के सन्दर्भ में बंद कर दिया गया था। मुझे अभी भी उम्मीद है कि किसी के पास एक अच्छा संकेत है कि कैसे ठीक किया जाए।

हमारा एप्लिकेशन तर्क एक जार फ़ाइल के भीतर समाहित है। इस जार फ़ाइल को बाद में पैकेजबिल्ड कमांड (http://s.sudre.free.fr/Software/Packages/about.html) के साथ एक एप्लिकेशन पैकेज में बंडल किया जाता है। इस बंडल में एडॉप्टओपेनजेडीके जेआरई 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}" '{}' \;

बेशक सभी 6 पात्रताएं हैं और एप्लिकेशन इंस्टॉल होने के बाद भी दिखाई दे सकती हैं।

कठोर रनटाइम सक्षम होने तक सब कुछ ठीक काम करता है। नोटराइजेशन पास हो जाता है, लेकिन एप्लिकेशन को शिप किए गए जावा संस्करण के साथ लॉन्च नहीं किया जा सकता है। इसे कहते हैं

VM के आरंभीकरण के दौरान त्रुटि हुई कोडहेप 'गैर-nमेथड्स' (2496K) में पर्याप्त स्थान आरक्षित नहीं कर सका

प्रीइंस्टॉल्ड जावा संस्करण के साथ एप्लिकेशन शुरू करना ठीक काम करता प्रतीत होता है।

ऐसा लगता है कि कल से नोटरीकरण की वे सभी चेतावनियाँ अंततः त्रुटियों में बदल गई हैं। जिसका अर्थ है कि हम अपने जावा-आधारित अनुप्रयोगों को और अधिक नोटरीकृत नहीं कर सकते :(

मैंने कल भी इसी मुद्दे का अनुभव किया था। आज, यह ठीक है। कल, ऐप्पल ने जावा पुस्तकालयों को हस्ताक्षरित और त्रुटि के रूप में रिपोर्ट किया। आज, उन्हें हस्ताक्षरित नहीं बल्कि चेतावनी के रूप में सूचित किया जाता है। निचला रेखा, Apple ने मेरे पैकेज को नोटरीकृत किया।

मैंने कल भी इसी मुद्दे का अनुभव किया था। आज, यह ठीक है।

मैंने इसे भी देखा, शायद यह Apple था जो सख्त नियमों पर टायरों को लात मार रहा था जिन्हें 3 फरवरी को लागू करने की योजना है।

jdk-13.0.1+9 फाइलों के साथ नोटरीकरण का प्रयास करते समय .jmod फाइलों में एप्पल की नोटराइजेशन सेवा द्वारा हस्ताक्षरित नहीं होने का पता लगाया जा रहा है, उदाहरण के लिए:

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

मैं देख रहा हूं कि 21 अगस्त को https://github.com/AdoptOpenJDK/openjdk-build/commit/5cd5306b4e97437aa2129dffd7e83e2f7cfd9255#diff -9a6d9f1628b9075aa2e1b4c33e4b9cc8 में हस्ताक्षर हटा दिया गया था और अभी भी टिप्पणी की गई है। उल्लिखित टिकट https://github.com/AdoptOpenJDK/TSC/issues/107 बंद कर दिया गया है, क्या इसे वापस लाने की कोई योजना है?

VM के आरंभीकरण के दौरान त्रुटि हुई कोडहेप 'गैर-nमेथड्स' (2496K) में पर्याप्त स्थान आरक्षित नहीं कर सका

इस पर एक और नज़र डालने के बाद ऐसा लगता है कि यह मुद्दा हमारी लिपि में था। यह ऐतिहासिक रूप से उगाया गया था, कि हम जेआरई पर भी हस्ताक्षर करते हैं। मैंने अब जेआरई के लिए खोज-चिह्न भाग को हटा दिया है और ऐसा लगता है कि यह बहुत काम करता है।

जैसा कि @ abauman-7signal ने उल्लेख किया है कि वास्तव में सभी त्रुटियां अब फिर से चेतावनियां हैं, शायद 3 फरवरी तक
ओपनजेडीके 13 को नोटराइज करने और इसे वास्तव में बाद में काम करने के बारे में कोई विचार?

इसे अभी ठीक करने का कोई अच्छा तरीका? MacOS 10.15.2 पर और openjdk8 . का उपयोग करने का प्रयास कर रहा है

मैं वर्तमान स्थिति को संक्षेप में प्रस्तुत करने का प्रयास करता हूं। सारांश में त्रुटियां हो सकती हैं, क्योंकि मैं इस क्षेत्र का विशेषज्ञ नहीं हूं। @gdams वह है जो एडॉप्टओपेनजेडीके को नोटरीकृत करने और कठोर रनटाइम समर्थन को सक्षम करने के प्रयास का नेतृत्व कर रहा है, लेकिन वह इसे पूरा करने में व्यस्त है। तो इसे नमक के दाने के साथ लें...

हॉटस्पॉट के साथ JDK 11 पर काम जल्द ही JDK 11 के साथ OpenJ9 के साथ पूरा हो गया है। JDK को बंडल करना बिना किसी समस्या के काम करना चाहिए। इस कार्य का परिणाम अगली तिमाही सीपीयू (अप्रैल 2020) में शामिल होने की उम्मीद है। क्या 11.0.6 के पुनर्निर्माण होने जा रहे हैं जो जल्द ही पूर्ण नोटरीकरण के साथ उपलब्ध होंगे और कठोर रनटाइम समर्थन अभी तक तय नहीं किया गया है। मौजूदा बायनेरिज़ पहले से ही नोटरीकृत हैं और बिना किसी समस्या के फरवरी 3rd से आगे चलते रहना चाहिए:

$ 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 अभी भी प्रगति पर है और कोई ETA नहीं है। यहां मुख्य समस्या यह है कि जेडीके 8 केवल पुराने एक्सकोड के साथ निर्माण का समर्थन करता है जो बदले में नोटरीकरण और कठोर रनटाइम का समर्थन नहीं करता है। नए 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 जरूरी है।

अन्य सभी JDK (9, 10, 12, 13) अपने जीवन के अंत तक पहुँच चुके हैं और इसलिए दायरे से बाहर हैं।

इस अद्यतन और इसे हल करने में आपके कार्य के लिए धन्यवाद।

कृपया 11.0.6 का पुनर्निर्माण यथाशीघ्र उपलब्ध कराएं। जैसा कि यह खड़ा है, मेरा मानना ​​​​है कि हमारे जैसे डेवलपर्स जो एक एम्बेडेड जावा रनटाइम के साथ एप्लिकेशन शिप करते हैं, वे एक नया बिल्ड शिप नहीं कर पाएंगे जो कि कैटालिना पर 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 की जरूरत है।

अन्य सभी JDK (9, 10, 12, 13) अपने जीवन के अंत तक पहुँच चुके हैं और इसलिए दायरे से बाहर हैं।

ध्यान दें कि JDK 13 जीवन के अंत में नहीं है। यह जीवन के अंत तक तभी पहुंचेगा जब JDK 14 मार्च में रिलीज़ होगी। कृपया पुनर्विचार करें और JDK 13 का एक और निर्माण जारी करें जो नोटरीकृत हो, ताकि नवीनतम JDK का नोटरीकृत निर्माण संभव हो सके।

@gadams 30 जनवरी की रात 11.0.7 की बिल्ड हमारे लिए ठीक काम कर रही है। हमारा एप्लिकेशन चेतावनियों के बिना नोटरीकृत बनाता है, और कैटालिना पर स्थापित और ठीक काम करता है। नए प्रतिबंधों के लागू होने के बाद मैं अगले सप्ताह फिर से अपने आवेदन को बनाने और नोटरीकृत करने का प्रयास करूंगा।

बिल्डिंग और नोटराइजिंग ने कल भी ठीक काम किया।

2020-02-06 06:01:30 +000 तक मुझे नोटरीकरण त्रुटियाँ मिल रही हैं जैसे:

गंभीरता | "त्रुटि"
पथ | ".../सामग्री/प्लगइन्स/जावा.रनटाइम/सामग्री/होम/जेआर/बिन/जावा"
संदेश | "बाइनरी 10.9 एसडीके से पुराने एसडीके का उपयोग करता है।"
वास्तुकला | "x86_64"

इसलिए मुझे लगता है कि निकट भविष्य में आपको वही समस्या दिखाई देगी।

क्या जावा 8 जेआरई के लिए 10.9 या बाद के संस्करण के लिए कोई प्रगति या समयरेखा है? RMI परिवर्तनों के कारण हमें अभी भी Java 8 के साथ बंडल करने की आवश्यकता है।

किसी भी जानकारी की सराहना की जाएगी। यदि अभी भी महत्वपूर्ण बाधाएं हैं, तो हम पहले बताए गए इस रेपो के साथ इसे स्वयं बनाने पर विचार कर सकते हैं:
https://github.com/stook/jdk8u-xcode10

हालांकि, अगर अगले कुछ दिनों में जावा 8 जेआरई उपलब्ध होगा तो मैं उसके लिए इंतजार करना पसंद करूंगा।

@addsomebass आसन्न कुछ भी नहीं है। और अगर मुझे ठीक से याद है, तो हमारी टीम के सदस्यों में से एक ने आपके द्वारा लिंक किए जा रहे पैच के साथ खेला और परिणामी बायनेरिज़ ने परीक्षण सूट पास नहीं किया। तो आप ज्ञात दोषों के साथ एक JDK को बंडल करेंगे।

@addsomebass मैं @aahlenst द्वारा उल्लिखित परीक्षण विफलताओं को हल करने के लिए Apple के साथ काम कर रहा हूं। मैं दोहराना चाहूँगा कि https://github.com/stoke/jdk8u-xcode10 में पैच उत्पादन के लिए तैयार नहीं हैं और परीक्षण विफल हो गए हैं।

मेरा वर्तमान लक्ष्य महीने के अंत तक एक नोटरीकृत jdk8 बाइनरी तैयार करना है।

अपडेट @gdams के लिए धन्यवाद, मैं वास्तव में इस पर आपके काम की सराहना करता हूं।

इस पर सभी के काम के लिए धन्यवाद - हालांकि मुझे अभी भी एक समस्या है।

मैं एक .app फ़ाइल बनाने के लिए JDK14 के नवीनतम ईए से jpackage का उपयोग कर रहा हूँ। फ़ाइल में यह संरचना है:

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

समस्या यह है, मैं या तो कर सकता हूँ:

• नोटरीकृत ऐप बनाएं, लेकिन यह नहीं चलेगा, या
• एक रन करने योग्य ऐप बनाएं, लेकिन यह नोटरीकृत नहीं होगा

एक बात को अलग रखने के लिए - मैक के लिए jpackage में ऐप्स पर हस्ताक्षर करना वर्तमान में टूटा हुआ है इसलिए मैं इसका उपयोग नहीं कर सकता। यह _was_ काम कर रहा था जब रनटाइम पर हस्ताक्षर नहीं किया गया था, लेकिन अब यह स्पष्ट है कि मुझे स्वयं हस्ताक्षर करने की आवश्यकता है।

ऐसा लगता है कि मैं इस बारे में कुछ गलत समझ रहा हूं कि रनटाइम (जेआरई) कैसे शामिल किया गया है, और इसके हस्ताक्षर के लिए आवश्यकताएं।

सबसे पहले मैं उन सभी फाइलों पर हस्ताक्षर करता हूं जो रनटाइम में नहीं हैं और जो लॉन्चर नहीं हैं:

% 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

मुझे यकीन नहीं है कि इसका मतलब है कि यह रनटाइम है जो इस मुद्दे का स्रोत है। यदि मैं मूल जेआरई स्रोत (जेपैकेज द्वारा पैक किए जाने से पहले) के खिलाफ एक ही चेक चलाता हूं तो मुझे वही परिणाम मिलता है।

% 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 फ़ोल्डर पर वही चेक करता हूं, तो भी मुझे वही संदेश मिलता है।

यह नोटरीकरण परिणाम देता है:

      "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 और jars को स्वयं साइन करके प्राप्त करने में कामयाबी हासिल की है। क्या आपने इन पंक्तियों को अपनी एंटाइटेलमेंट फ़ाइल में सेट किया था?

<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 फरवरी के बाद से सब कुछ टूट गया लगता है; शायद मैं डिफ़ॉल्ट पर भरोसा कर रहा था जो स्वीकार्य हुआ करता था, लेकिन अब नहीं है (जाहिर है कि कठोर रनटाइम पर लागू होता है और पुराने एसडीके के खिलाफ बनाता है, यही कारण है कि मैं इस निर्माण को अपनाने की कोशिश कर रहा हूं)।

यह काम करता प्रतीत होता है, धन्यवाद! तो, मेरे अंतिम समाधान का दस्तावेजीकरण करने के लिए:

% 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 हस्ताक्षर अभी टूटा हुआ है, अगर आप कुछ नोटरीकृत करना चाहते हैं
• आपको अपने कोड पर हस्ताक्षर करने होंगे।
• आपको जेआरई पर फिर से हस्ताक्षर करने होंगे। हस्ताक्षर करने के लिए बाध्य करने के लिए -f का उपयोग करें।
• आपको सभी साइनिंग कॉल में एंटाइटेलमेंट निर्दिष्ट करना होगा

नमस्ते, क्या मैं सिर्फ यह पूछ सकता हूं कि क्या हमारे पास जावा 8 या जावा 9 के लिए मैक बिल्ड है जो इसे नए नियमों के अनुसार नोटरीकृत करने की अनुमति देता है या नहीं?

@ijabz अगर मैं आपके प्रश्न को सही ढंग से समझ रहा हूं, तो आप एक आवेदन के भीतर एक जेवीएम को बंडल करना चाहते हैं, और फिर उसे नोटराइज करना चाहते हैं। वर्तमान में, आप नहीं कर सकते। नवीनतम एडॉप्टओपेनजेडीके बिल्ड मैक ओएस एसडीके के पुराने संस्करण के साथ बनाया गया है और इसे फिर से पैक और फिर से नोटरीकृत नहीं किया जा सकता है।

यदि आप सिर्फ जावा स्थापित करना चाहते हैं, तो नवीनतम .pkg इंस्टालर OSX Catalina पर काम करेंगे, और मैं जावा को ठीक से स्थापित और निष्पादित कर सकता हूं। इन इंस्टालरों को नोटरीकृत कर दिया गया है, और बिना किसी समस्या के आपकी मशीन पर जावा स्थापित कर सकते हैं।

gadams Java 8 का नोटराइज़ेबल बिल्ड प्राप्त करने पर काम कर रहा है, और उम्मीद कर रहा है कि महीने के अंत में ऐसा हो जाएगा। मैं उसे और बाकी सभी को शुभकामनाएं देता हूं।

अगर मैं आपके प्रश्न को सही ढंग से समझ रहा हूं, तो आप एक आवेदन के भीतर एक जेवीएम को बंडल करना चाहते हैं, और फिर उसे नोटराइज करना चाहते हैं। वर्तमान में, आप नहीं कर सकते

हाँ सही है, ठीक है, इसके लिए मेरी ओर से कोड परिवर्तन की आवश्यकता होगी, लेकिन क्या एडॉप्टओपेनजेडीके जावा 11 निर्माण कार्य करता है?

या अगर मैं ओरेकल बिल्ड स्थापित करता हूं तो वह काम करेगा, मैं वर्तमान में मैकोज़ पर ओरेकल जावा 8 का उपयोग कर रहा हूं और यह 3 फरवरी तक काम करता है, क्या आपका मतलब .pkg बिल्ड से है?

मैं सिर्फ एक समाधान की तलाश में हूं जिसका मैं अभी उपयोग कर सकता हूं, मैं इस बारे में बहुत अस्पष्ट हूं कि वर्तमान में विकल्प क्या हैं।

@ijabz क्षमा करें, मैं जावा 11 या उसके बाद के संस्करण से बात नहीं कर सकता, क्योंकि मैंने व्यक्तिगत रूप से इसके साथ काम नहीं किया है। यहां टिप्पणियों को देखते हुए ऐसा लगता है कि एक काम करने वाला बंडल पाने का एक तरीका है। मैं केवल जावा 8 बिल्ड के साथ काम करने के लिए बोल सकता हूं।

मैक इंस्टालर पैकेज, या .pkg फाइलें, सॉफ्टवेयर के लिए इंस्टॉलर हैं। वर्तमान में एडॉप्टओपेनजेडीके बिल्ड के लिए कुछ .pkg इंस्टालर उपलब्ध हैं जो नोटरीकृत हैं और जावा को सही तरीके से स्थापित करेंगे, जैसे यह यहाँ है:
https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u242-b08/OpenJDK8U-jdk_x64_mac_hotspot_8u242b08.pkg

मुझे लगता है कि मैं गूंगा हूं लेकिन मुझे समझ में नहीं आता कि एक तरफ एडॉप्टओपेनजेडीके जावा 8 बिल्ड पर काम कर रहे हैं जो नोटरीकृत है लेकिन यह महीने के अंत तक तैयार नहीं होगा, लेकिन इसके विपरीत पहले से ही एक एडॉप्टओपेनजेडीके जावा 8 इंस्टॉलर है जो पहले से ही एक स्थापित करेगा नोटरीकृत संस्करण जावा 8 ?

@ijabz मुझे लगता है कि इसका कारण यह है कि अगर 3 फरवरी 2020 से पहले कुछ नोटरीकृत किया गया है, तो यह अभी भी मान्य है और अभी भी macOS कैटालिना पर काम करता है। हालाँकि अब इसे फिर से नोटरी करना संभव नहीं होगा, क्योंकि नियम अब और सख्त हो गए हैं। तो एडॉप्टओपेनजेडीके जावा 8 इंस्टालर शायद 3 फरवरी से पहले नोटरीकृत किया गया था और इस प्रकार अभी भी इसका उपयोग किया जा सकता है।

लेकिन आप इसे और पैकेज नहीं कर सकते क्योंकि 3 फरवरी से ऐप्पल को ऐप्स को "हार्डेन" करने की आवश्यकता है, जिसके लिए एक्सकोड 10 की आवश्यकता है। और जावा 8 को एक्सकोड 10 के साथ संकलित नहीं किया गया है, इसलिए इसे कठोर (अभी तक) नहीं किया जा सकता है।

तो आप एडॉप्टओपेनजेडीके जावा 8 को स्थापित कर सकते हैं, इसके बावजूद कि यह सख्त नहीं है क्योंकि इसे 3 फरवरी से पहले नोटरीकृत किया गया था। लेकिन अब इसका नया संस्करण बनाना या इसके साथ किसी प्रोग्राम को पैकेज करना संभव नहीं होगा, क्योंकि इसे कठोर नहीं किया जा सकता है और इस प्रकार नोटरीकृत नहीं किया जा सकता है।

मैंने जो पढ़ा है उससे कम से कम JDK 11.0.7 और JDK 14 ठीक काम करने लगते हैं, XCode 10 का उपयोग करके संकलित किए जाते हैं, "कठोर" होते हैं और कम से कम JDK 14 का उपयोग कार्यक्रमों को पैकेज करने के लिए किया जा सकता है।

ठीक है धन्यवाद मैं अब बेहतर समझता हूं।
एक और बात जब आप JDK 11.0.7 और JDK 14 का संदर्भ देते हैं, तो मुझे लगता है कि आपका मतलब है एडॉप्टओपेनजेडीके बनाता है, क्या एडॉप्टओपेनजेडीके की स्थिति ओरेकल साइट पर उपलब्ध डाउनलोड के समान है?

क्षमा करें, मुझे नहीं पता। मैंने इसे केवल ओपनजेडीके के साथ आजमाया है (एडॉप्टओपेनजेडीके नहीं बल्कि एक अलग वितरण लेकिन मुझे लगता है कि यह सभी ओपनजेडीके वितरणों के लिए समान है)। हालाँकि, क्योंकि ऐसा लगता है कि इसे XCode 10 के साथ संगत बनाने के लिए JDK 8 में बदलाव की आवश्यकता है और जहाँ तक मुझे पता है, Oracle OpenJDK और अपने स्वयं के वितरण में समान परिवर्तन करता है, मुझे लगता है कि उनका JDK 8 या तो कठोर नहीं है ( या अन्यथा वे जावा 8 का एक ओपनजेडीके संस्करण जारी कर देते थे जो भी कठोर हो जाएगा)। लेकिन जैसा कि मैंने कहा, मैंने इसकी कोशिश नहीं की है।

ठीक है धन्यवाद। मैं पूछता हूं क्योंकि मुझे पूरी तरह से यकीन नहीं है कि केवल ओरेकल से डाउनलोड करने के बजाय एडॉप्टओपेनजेडीके बिल्ड का उपयोग करने का क्या फायदा है।

@ijabz Oracle JDK केवल उपयोग के मामलों के सीमित सेट के लिए उपयोग करने के लिए स्वतंत्र है ( Oracle Java SE लाइसेंसिंग FAQ देखें)। Oracle द्वारा निर्मित OpenJDK उपलब्ध हैं, और अभी भी प्रतिबंधों के बिना उपयोग करने के लिए स्वतंत्र हैं, लेकिन समर्थित प्लेटफॉर्म और संस्करणों की संख्या हमारे द्वारा यहां दी गई एडप्टोपेनजेडीके की तुलना में काफी कम है। जैसा कि नाम का तात्पर्य है, एडॉप्टओपेनजेडीके ओपनजेडीके का निर्माण करता है। हमारा एक मुख्य उद्देश्य सभी परिवर्तनों को अपस्ट्रीम करना है। OpenJDK के अन्य विक्रेता (और कई हैं: Amazon, Azul, BellSoft, SAP,…) की अलग-अलग नीतियां हो सकती हैं।

ठीक है, और मुझे लगता है कि वे केवल नवीनतम बिल्ड के लिए मैकोज़ बिल्ड की पेशकश करते हैं, ठीक है धन्यवाद।

@gdams , क्या आप अभी भी महीने के अंत तक एक नोटरीकृत jdk8 बाइनरी तैयार होने की उम्मीद करते हैं? साथ ही, क्या इसमें J9 JVM शामिल होगा?

@gdams , क्या आप अभी भी महीने के अंत तक एक नोटरीकृत jdk8 बाइनरी तैयार होने की उम्मीद करते हैं? साथ ही, क्या इसमें J9 JVM शामिल होगा?

क्या आप BellSoft JDK8 वितरण (https://bell-sw.com/pages/java-8u242/) आज़मा सकते हैं। मैंने एडॉप्टओपेनजेडीके जे8 को बेलसॉफ्ट जे8 से बदल दिया, "The binary uses an SDK older than the 10.9 SDK." से छुटकारा पाया और फाइनली नोटरीकृत हो गया।

ऐसा लगता है कि BellSoft J8 पहले से ही नोटरीकृत तैयार है।

जैसा कि मैं समझता हूं, बेलसॉफ्ट जेडीके मुक्त नहीं है ..

जैसा कि मैं समझता हूं, बेलसॉफ्ट जेडीके मुक्त नहीं है ..

GPL . के अलावा "क्लासस्पैट" के साथ GNU जनरल पब्लिक लाइसेंस (GPL)
नियमित लाइबेरिका जावा एसई 8u242 जेडीके या जेआरई के लिए ओपनजेडीके के समान लाइसेंस।

जरूरत पड़ने पर वे व्यावसायिक सहायता प्रदान करते हैं।

स्पष्टीकरण के लिए धन्यवाद !

यह काम करता प्रतीत होता है, धन्यवाद! तो, मेरे अंतिम समाधान का दस्तावेजीकरण करने के लिए:

% 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 हस्ताक्षर अभी टूटा हुआ है, अगर आप कुछ नोटरीकृत करना चाहते हैं
• आपको अपने कोड पर हस्ताक्षर करने होंगे।
• आपको जेआरई पर फिर से हस्ताक्षर करने होंगे। हस्ताक्षर करने के लिए बाध्य करने के लिए -f का उपयोग करें।
• आपको सभी साइनिंग कॉल में एंटाइटेलमेंट निर्दिष्ट करना होगा

मैं आपके चरणों का पालन करने में सक्षम था, हालांकि मेरे पास एक पुस्तकालय है और यहां तक ​​​​कि
<key>com.apple.security.cs.disable-library-validation</key> <true/>

मुझे यह त्रुटि मिलती है:

थ्रेड में अपवाद "जावाएफएक्स एप्लीकेशन थ्रेड" JxBrowser/7.5/libbrowsercore_toolkit.dylib, 1): कोई उपयुक्त छवि नहीं मिली। पाया:
/private/var/folders/0f/trlp6tp95qjbzm99ds8pt8zm0000gp/T/JxBrowser/7.5/libbrowsercore_toolkit.dylib: कोड सिग्नेचर (/private/var/folders/0f/trlp6tp95qjbzm99ds8pt8zm0000p/7.5kit) में कोड सिग्नेचर मान्य नहीं है। पुस्तकालय सत्यापन का उपयोग कर प्रक्रिया में: मैपिंग प्रक्रिया और मैप की गई फ़ाइल (गैर-प्लेटफ़ॉर्म) में अलग-अलग टीम आईडी हैं

क्या इसका मतलब यह है कि मेरे पास जो पुस्तकालय है, उसे भी काम करने के लिए उस अधिकार की आवश्यकता है या यह मेरी ओर से कुछ है?

नोटरीकरण प्रक्रिया का सबसे निराशाजनक हिस्सा यह है कि मुझे इस रिलीज प्रक्रिया को अपनी सीआई/सीडी पाइपलाइन में डालना पड़ा है। काश सेब एक परीक्षण समापन बिंदु की आपूर्ति करता। मुझे इसे नोटरीकृत करने की आवश्यकता नहीं है, मुझे केवल यह जानने की आवश्यकता है कि क्या यह नोटराइज़ करने योग्य है। माना कि अंतर छोटा है, लेकिन कुछ चीजें इसे असहज कर देती हैं।

1. यदि मैं किसी तृतीय पक्ष के लिए एक अद्यतन का उपभोग करता हूं, तो मुझे एक सेवन प्रक्रिया की आवश्यकता होती है जो यह पुष्टि करती है कि अद्यतन नोटराइज़ करने योग्य है। उस तृतीय पक्ष को सत्यापन के लिए सबमिट करके, मैंने अब उस तृतीय पक्ष को मेरी कंपनियों के क्रेडिट का उपयोग करके नोटरीकृत कर दिया है, और मेरे सुरक्षा लोगों को लगता है कि यह बहुत बढ़िया नहीं है।
2. मैं हर दिन नोटरीकरण के लिए चीजें जमा कर रहा हूं कि मैं बिल्कुल ग्राहक को प्रदान करने का इरादा नहीं रखता हूं, और मुझे ऐसे प्रमाण-पत्रों का उपयोग करना है जो केवल परीक्षण से अधिक करने के लिए अधिकृत हैं। क्योंकि वे क्रेडिट अब मेरी पाइपलाइन का हिस्सा हैं, क्रेडेंशियल्स में उल्लंघन के लिए मेरा सुरक्षा सतह क्षेत्र बड़ा है। तो मैं एक परीक्षण समापन बिंदु चाहता हूं जो बिना किसी क्रेडिट का उपयोग करता है, या केवल परीक्षण उद्देश्यों के लिए क्रेडिट का उपयोग करता है।

क्या कोई और इस मुद्दे में चल रहा है कि मेरे पास @ बजरी @ dg76 है , मैंने एक एंटाइटेलमेंट बनाने की कोशिश की है, लेकिन यह पुस्तकालय सत्यापन को अक्षम नहीं करता है

@ dcboy95 मुझे क्षमा करें - मुझे नहीं पता कि संपूर्ण बंडल पर कवरेज के संबंध में विशेष पात्रताएं कैसे काम करती हैं। मैंने पाया, कोड साइनिंग के साथ, मुझे मेरे द्वारा शिप की गई पूरी लाइब्रेरी से इस्तीफा देना पड़ा, तो हो सकता है कि इसका मतलब है कि आपके द्वारा शिप किए जाने वाले पूरे कोडबेस के पास भी पात्रता होनी चाहिए? माफ़ करना।

@ dcboy95 मुझे लगता है कि आपको कोडसाइन और अपने स्वयं के प्रमाणपत्र का उपयोग करके "libbrowsercore_toolkit.dylib" फ़ाइल से इस्तीफा देना होगा। (मैंने सोचा था कि मैंने पहले ही इस सुझाव को यहां पोस्ट कर दिया था लेकिन मुझे मुझसे कोई प्रतिक्रिया नहीं मिल रही है।) त्रुटि सिर्फ यह इंगित करती है कि पुस्तकालय में शेष एप्लिकेशन की तुलना में एक अलग हस्ताक्षर है। और मुझे लगता है कि हर चीज पर एक जैसा हस्ताक्षर होना चाहिए ताकि यह सुनिश्चित हो सके कि कोई और उसमें कुछ भी न डाले। तो बस "libbrowsercore_toolkit.dylib" पर कोडसाइन चलाने का प्रयास करें। क्या यह ठीक करता है?

@ dg76 दुर्भाग्य से यह काम नहीं किया। तीसरे पक्ष के पुस्तकालय के साथ यदि कोई भिन्न संस्करण है तो यह स्वयं को पुनः स्थापित करता है। इसलिए जब मैं उस फ़ाइल को कोडसाइन करता हूं, तो वह इसे पुरानी फ़ाइल के रूप में देखती है और संशोधित फ़ाइल की जगह एक नई फ़ाइल डाउनलोड करती है। एक ही त्रुटि के परिणामस्वरूप। मैंने सोचा था कि पात्रता com.apple.security.cs.disable-library-validation इस मुद्दे को ठीक कर देगी हालांकि ऐसा प्रतीत नहीं होता है।

@ dcboy95 मुझे लगता है कि यह काम नहीं करेगा। मुझे लगता है कि ऐप्पल के नोटराइजेशन सिस्टम का उद्देश्य यह सुनिश्चित करना है कि डेवलपर ने पुष्टि की है कि उसके ऐप के सभी हिस्सों का परीक्षण किया गया है और ठीक है। रनटाइम के दौरान अन्य डेवलपर्स से भागों को लोड करना, जिन्हें डेवलपर द्वारा परीक्षण और पुष्टि नहीं किया गया है, शायद अनुमति नहीं है। क्या आप स्वचालित डाउनलोड फ़ंक्शन को अक्षम नहीं कर सकते?

@ dg76 जानकारी के लिए धन्यवाद, मुझे यह देखने के लिए उनके दस्तावेज़ीकरण पर शोध करना होगा कि क्या यह एक संभावना है। एक बार फिर धन्यवाद

एडॉप्टओपेनजेडीके 14+36 बाहर है जो पूरी तरह से नोटरीकृत है। कृपया परेशानी के मामले में वापस रिपोर्ट करें।

पूरी तरह से नोटरीकृत JDK 8 अभी भी काम कर रहा है। हम इसे अगली तिमाही सीपीयू (निकटतम मंगलवार से 17 अप्रैल) में शामिल करने की उम्मीद करते हैं।

आवश्यक पैच कुछ टेस्ट रन (टीसीके सहित) पास कर चुके हैं, लेकिन अधिक सत्यापन आवश्यक है। @gdams वर्तमान स्थिति को प्रकाशित करने की योजना बना रहा है ताकि हम इतने दूर के भविष्य में परीक्षण के लिए बिल्ड प्रदान कर सकें।

@aahlenst क्या JDK 11 के लिए कोई योजना है?

@ dcboy95 एक पूरी तरह से नोटरीकृत JDK 11 अगले तिमाही सीपीयू के हिस्से के रूप में प्रकाशित किया जाएगा (यदि मैं Oracle के नियम को सही ढंग से याद करता हूं तो 17 अप्रैल को निकटतम मंगलवार के तुरंत बाद)। इस बीच, आप https://adoptopenjdk.net/nightly.html?variant=openjdk11&jvmVariant=hotspot पर JDK 11 का रात्रिकालीन निर्माण प्राप्त कर सकते हैं और यदि यह काम नहीं करता है तो वापस रिपोर्ट करें।

नमस्ते मैंने इंस्टॉलर के लिए jdk-11.0.7+7 का उपयोग करने की कोशिश की लेकिन फिर भी [1] वें त्रुटि के साथ विफल रहता है "बाइनरी का हस्ताक्षर अमान्य है"

[1] /सामग्री/मैकोज़/libjli.dylib

@NishikaDeSilva इसे चलाने का प्रयास करें:

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

@gdams मैंने आपके समाधान की कोशिश की।

कमांड: codesign --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 तक पहुंचने का प्रयास करते समय हमारा एप्लिकेशन अब असंतुष्ट लिंक्स त्रुटि प्राप्त करता है। यह पहले काम कर रहा था।

@MoxxiManagarm क्या डिलिब्स पर हस्ताक्षर किए गए हैं? codesign -v -v /path/to/dylib से जांचें।

@aahlenst मुझे संदेह है, वे सिस्टम पर स्थापित तृतीय पक्ष डाइलिब (डिवाइस ड्राइवर) हैं, वे हमारे आवेदन का हिस्सा नहीं हैं। मेरे पास सक्रिय com.apple.security.cs.disable-library-validation एंटाइटेलमेंट भी है, यह कोई समस्या नहीं होनी चाहिए।

निर्देशिका /usr/local/lib/ . के भीतर मौजूद है

JDK 11 के JRE के रात्रि निर्माण का उपयोग करते हुए, मेरे पास NishikaDeSilva जैसी ही समस्या है। मैंने अच्छे उपाय के लिए जेआरई 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 में कोई xattributes सूचीबद्ध नहीं है।

उत्सुकता से, फ़ाइल को किसी अन्य स्थान पर ले जाना ( Contents/MacOS फ़ोल्डर के बाहर कहीं भी) या फ़ाइल एक्सटेंशन को .dylib के अलावा किसी अन्य चीज़ में बदलने से कोडिंग और हस्ताक्षर सत्यापन सामान्य रूप से पारित हो जाएगा, बिना उपरोक्त में से किसी भी बकवास के त्रुटियाँ। कोडसाइन तंत्र को फ़ाइल के स्थान को भी ध्यान में रखना चाहिए, जिससे यह फ़ाइल के परिणामों से Contents/Home/lib/jli/libjli.dylib पर भिन्न हो।

ड्राइवर डाइलिब पर कोई अपडेट जो नोटरीकरण (रात के निर्माण) के बाद /usr/local/lib/ के भीतर नहीं मिला है?

Spctl -a -vv libjli.dylib के साथ हस्ताक्षर को सत्यापित करने से यह परिणाम मिलता है:
libjli.dylib: कोड में कोई संसाधन नहीं है लेकिन हस्ताक्षर इंगित करता है कि उन्हें उपस्थित होना चाहिए

@ जस्टिन-एस्पेडल इसे शीर्ष-स्तरीय निर्देशिका पर चलाने का प्रयास करें:

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 इसे डायरेक्टरी पर चलाएं:

xattr -cr .

यह काम करता है। पुनरावर्ती -cr की कोई आवश्यकता नहीं है, केवल शीर्ष-स्तरीय फ़ोल्डर से com.apple.FinderInfo को हटाना पर्याप्त है। यह समझ में आता है कि शीर्ष-स्तरीय फ़ोल्डर पर FinderInfo विशेषता पूरे पैकेज की कोडिंग के साथ हस्तक्षेप करती है।

भले ही वह xattr मौजूद हो या नहीं, फिर भी libjli.dylib को अपने आप कोड-हस्ताक्षरित नहीं किया जा सकता है। क्या कोडसाइन तंत्र को उस विशिष्ट स्थान पर dylib की आवश्यकता होती है ताकि युक्त पैकेज कोड हस्ताक्षर के साथ कुछ सत्यापित किया जा सके? यदि ऐसा है (या शायद उस पर ध्यान दिए बिना), तो पूरे पैकेज को डिफ़ॉल्ट रूप से कोडित क्यों नहीं किया जाता है?

यदि आवश्यक न हो तो मैं निश्चित रूप से संपूर्ण जेआरई के कोड को कोड-साइन नहीं करना पसंद करूंगा।

@gadams @aahlenst नोटरीकृत JDK 1.8 पर कोई अपडेट? क्या हम इसे 17 अप्रैल को रिलीज कर रहे हैं? क्या कोशिश करने के लिए पहले की कोई किट है?

अगले सप्ताह, पहले नोटरीकरण और कठोर रनटाइम के बिना 8u252 होगा। बाद में, हम स्विच को फ्लिप करने जा रहे हैं और नोटरीकरण और कठोर रनटाइम के साथ एक का निर्माण करेंगे। अतिरिक्त जानकारी का पालन करेंगे। मुझे नहीं पता कि क्या पहले से ही एक बाइनरी है जो दूसरों द्वारा परीक्षण के लिए तैयार है।

8u252 में libAppleScriptEngine.dylib शामिल होगा जो बाद के sdk के विरुद्ध बनाया गया है, इसलिए 'बाइनरी 10.9 SDK से पुराने SDK का उपयोग करता है' के साथ विफल नहीं होता है, यह सबसे अधिक मददगार होगा, https://stackoverflow.com/questions/61208189/java-notarization -of-libapplescriptengine-dylib-failing-with-the-binary-uses-an

लंबे समय से प्रतीक्षित 8u252 बाहर है, लेकिन यह पता चला कि इसमें लगभग सभी बायनेरिज़ अभी भी एसडीके 10.8 के साथ बनाए गए थे, जो सफल नोटरीकरण को रोकता है।
https://ci.adoptopenjdk.net/view/work%20in%20progress/job/jdk8u-mac-x64-hotspot-notarized/10/ के JRE में 10.14 बायनेरिज़ थे, इसलिए हमें उम्मीद थी कि आधिकारिक 8u252 भी ऐसा करेगा।

अगले सप्ताह, पहले नोटरीकरण और कठोर रनटाइम के बिना 8u252 होगा। बाद में, हम स्विच को फ्लिप करने जा रहे हैं और नोटरीकरण और कठोर रनटाइम के साथ एक का निर्माण करेंगे।

क्या आप लोगों के पास इसके लिए कोई शेड्यूल है जिसे आप साझा कर सकते हैं, कृपया?

@meshcow अनुमान लगाना मुश्किल है। इसलिए मैंने पहली बार में कोई अनुमान नहीं दिया। नियमित बिल्ड वाली पाइपलाइन अभी भी चल रही हैं (उदाहरण के लिए, हॉटस्पॉट के साथ 14.0.1 और OpenJ9 के साथ 11.0.7)। कठोर रनटाइम वाला संस्करण बाद में बनाया जाएगा।

@meshcow - हम अपने मैक ओएस नोटराइजेशन पैच का परीक्षण करने के लिए 8u252.1 का निर्माण करेंगे, यहां एक या दो दिन में होना चाहिए।

एफवाईआई मैंने एक libAppleScriptEngine.dylib को आजमाने और प्राप्त करने के लिए BellSoft 8u252 का उपयोग किया जो नोटरीकरण की अनुमति देने के लिए बाद में एसडीके के खिलाफ बनाया गया है, और पुष्टि कर सकता है कि काम किया।

यह भी पुष्टि कर सकता हूं कि मैंने एडॉप्टजेडीके 11.0.7 जेआरई बिल्ड और अपने ऐप में बंडल किया है और मेरे आवेदन को सफलतापूर्वक नोटरीकृत किया है।

एफवाईआई मैंने एक libAppleScriptEngine.dylib को आजमाने और प्राप्त करने के लिए BellSoft 8u252 का उपयोग किया जो नोटरीकरण की अनुमति देने के लिए बाद में एसडीके के खिलाफ बनाया गया है, और पुष्टि कर सकता है कि काम किया।

क्या आप बता सकते हैं, कृपया, आप अपने ऐप के साथ jre को बंडल करने के लिए क्या उपयोग कर रहे हैं? जब मैं javapackager का उपयोग करता हूं तो यह fxbundlerpath/Contents/MacOS/libpackager.dylib: is already signed कहता है।
और आप इसे कैसे एडॉप्टजेडीके 11 के साथ करते हैं?

मैंने ऐपबंडलर (इन्फिनिटीकिंड कांटा) का इस्तेमाल किया - https://github.com/TheInfiniteKind/appbundler/
मैं कल स्टैकोवफ्लो पर एक पूर्ण विस्तृत उत्तर देने का प्रयास करूंगा और पोस्ट करूंगा

@as1an https://stackoverflow.com/questions/58548736/notarize- मौजूदा-जावा-application-for-macos-catalina पर मेरे अपने प्रश्न का उत्तर जोड़ा गया

परीक्षण करने के लिए किसी के पास जे9 जेवीएम 1.8 नोटरीकृत बिल्ड है?

@meshcow अनुमान लगाना मुश्किल है। इसलिए मैंने पहली बार में कोई अनुमान नहीं दिया। नियमित बिल्ड वाली पाइपलाइन अभी भी चल रही हैं (उदाहरण के लिए, हॉटस्पॉट के साथ 14.0.1 और OpenJ9 के साथ 11.0.7)। कठोर रनटाइम वाला संस्करण बाद में बनाया जाएगा।

@aahlenst क्या इसमें 1.8 JVM का J9 संस्करण भी शामिल होगा?

यह इस सप्ताह आ रहा है।

बहुत बहुत शुक्रिया!

एक नोटरीकृत JDK8u हॉटस्पॉट बाइनरी आज जारी की गई है 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) है, ऐप हमारे सर्टिफिकेट द्वारा हस्ताक्षरित है। हमने जेआरई के भीतर कुछ भी हस्ताक्षर नहीं किया, क्योंकि यह पता चला कि इसमें सब कुछ पहले से ही हस्ताक्षरित था।
अब तक कोई समस्या नहीं है।

@meshcow मुझे पता है कि यह असंबंधित है, और मैं क्षमा चाहता हूं अगर यह इसके लिए सही मंच नहीं है, लेकिन मैं जेएनआई को एक बंडल ऐप में काम करने के लिए संघर्ष कर रहा हूं, और मैं सोच रहा था कि क्या आप कोई संसाधन साझा कर सकते हैं जिससे आपको वहां पहुंचने में मदद मिली। . सभी मौजूदा जावा ऐप बंडलर मैं एक कठोर निष्पादन योग्य उत्पादन कर सकता हूं जो नोटराइजेशन को रोकता है, तब भी जब जेआरई नोटराइज करने योग्य हो।

इस आखिरी बाधा को दूर करने में किसी भी मदद की बहुत सराहना की जाएगी।

@addsomebass - हम मानक बाय-द-बुक दृष्टिकोण का उपयोग करते हैं: ऑब्जेक्टिव सी में लिखा गया एक छोटा लॉन्चर जो जेवीएम लोड करने के लिए जावा इनवोकेशन एपीआई का उपयोग करता है और इसके साथ हमारा [शुद्ध] जावा ऐप शुरू करता है। लॉन्चर को /Contents/MacOs के तहत OSX ऐप की डायरेक्टरी में डाल दिया जाता है। JRE वहां /Contents/[app-name]/jre के अंतर्गत जावा ऐप फ़ोल्डर में डाल दिया जाता है।
OSX ऐप पर हस्ताक्षर हो जाते हैं, और फिर यह नोट्रीकरण के लिए भेजे जाने के लिए तैयार है। हम कोडसाइन के लिए निम्नलिखित cmd-line args का उपयोग करते हैं: --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 मुझे लगता है कि आपको अपने लॉन्चर की आवश्यकता नहीं है। मैं एक सामान्य जावा प्रोग्राम में जेएनआई का उपयोग कर रहा हूं जो जावा 14 के जावा पैकेजर जेपैकेज का उपयोग करके बंडल किया गया है। आप मेरे कदम यहां पा सकते हैं: https://blog.dgunia.de/2020/02/12/signed-macos-programs- with-java-14/ यह केवल हस्ताक्षर का वर्णन करता है, जेएनआई भाग का नहीं। लेकिन मैंने एक सामान्य जेएनआई डाइलिब फ़ाइल बनाई है जो उस प्रक्रिया के दौरान भी हस्ताक्षरित है। यह अब तक ठीक काम करता है, इसे नोटरीकृत करना संभव था।

@addsomebass @dg76 Java 8 हमारा मामला है, 14 नहीं

@ meshcow @dg76 सुझावों के लिए धन्यवाद। RMI परिवर्तनों के कारण हमें Java 8 का भी उपयोग करने की आवश्यकता है।

अब नोटरीकरण का समर्थन करने के लिए धन्यवाद। लेकिन पैकेज में javapackager कहां है? मैं javapackager के बिना केवल "सामान्य" jdk8 बिल्ड ढूंढ सकता हूं। क्या जावापैकर के साथ एक पूर्ण जेडीके बनाया गया है?

@gdams @aahlenst
हमने पिछले सप्ताह जारी किए गए ओपन J9 के कठोर संस्करण का उपयोग किया और नोटरीकरण के दौरान हमें Apple से यह त्रुटि मिली:

{ "गंभीरता": "त्रुटि", "कोड": शून्य, "पथ": "/jre/Contents/MacOS/libjli.dylib", "message": "बाइनरी का हस्ताक्षर अमान्य है।", "docUrl": नल, "आर्किटेक्चर": "x86_64" }

यह कहता है कि libjli.dylib का कोई हस्ताक्षर नहीं है, लेकिन मेरा मानना ​​है कि यह एक लिंक फ़ाइल है?

हमने इस कमांड को भी आजमाया

फ़ाइल डाउनलोड की गई - OpenJDK8U-jre_x64_mac_openj9_macosXL_8u252b09_openj9-0.20.0.tar.gz* ने इसे jdk8u252-b09-jre-j9 फ़ोल्डर में अनज़िप किया और फिर हस्ताक्षर की जाँच की -

कोडसाइन -vvvv jdk8u252-b09-jre-j9jdk8u252-b09-jre-j9/: कोड में कोई संसाधन नहीं है लेकिन हस्ताक्षर इंगित करता है कि उन्हें मौजूद होना चाहिए

सुनिश्चित नहीं है कि दोनों संबंधित हैं। क्या इसे ठीक करने का कोई तरीका है?

धन्यवाद।

यदि आपको सहायता की आवश्यकता है, तो कृपया https://github.com/adoptopenjdk/openjdk-support/ में मुद्दों को खोलें।