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)을 사용합니다.
강화된 런타임을 지원하기 위한 최소 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 위의 내용도 효과가 있는지 확인할 수 있습니까? 그렇다면 해당 변경 사항을 빌드 스크립트에 추가하겠습니다.

또한 entitlements.plist 파일에 다음을 추가하여 jdk8에서 이 작업을 수행할 수 있었습니다.

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

jdk11 앱 공증 테스트: 보고 (성공)

jdk12 앱 공증 테스트: 보고 (성공)

@gdams 죄송합니다. JDK를 직접 구축한 적이 없습니다. 저는 항상 바이너리 배포판을 다운로드했습니다. 오늘의 MacOS용 JDK 11 테스트 빌드를 어딘가에서 다운로드할 수 있게 만들 수 있습니까? 그런 다음 JDK를 묶고 싶은 애플리케이션에 대해 Apple로부터 공증을 받을 수 있습니다. 변경 사항이 작동하는지 확인할 수 있습니다.

@tkie JDK11+에서 모든 것을 수정하는 수정 사항을 적용했습니다. 이 변경 사항은 다음 릴리스까지 눈에 띄지 않을 것입니다(사람들이 즉시 사용할 수 있도록 재출시 가능성에 대해 Adopt 사람들과 논의하겠습니다.

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로 테스트했습니다. 공증도 성공적이었습니다.
내 관점에서 문제는 해결되었으며 Java 8을 조사할 필요가 없습니다.
Java 11 이상에서 이 문제를 해결해 주셔서 감사합니다.

또한 Java 1.8 런타임이 포함된 애플리케이션을 공증하려고 할 때 "바이너리는 10.9 SDK보다 오래된 SDK를 사용합니다" 오류가 발생합니다.

우리는 현재 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년 1월까지 공증 요구 사항을 일시적으로 완화 했기 때문일 수 있습니다.

도움이 되는 경우 로그 사본을 전달할 수 있습니다.

JIT 기능에 대한 자격을 추가했습니까? 그것이 없으면 공증에 실패합니다. JRE가 이것을 필요로 한다고 확신합니다.

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

@gdams의 업스트림 예제를 사용하여 이것을 시도했습니다. 우리는 Xcode 대신 명령줄 도구를 사용하고 있습니다. 전환해야 할 수도 있지만 피할 수 있기를 바랍니다. 서명 단계를 개선하는 문제일 수 있습니다. 공증 이전에는 모든 것이 더 간단했습니다 ...

분명히, 공증은 Apple의 현재 완화된 요구 사항으로 인해 공증 없이도 성공 합니다. 우려는 경고가 미래의 실패를 나타냅니다.

누군가 XCode를 사용할 때 @davideby 가 언급한 JSON 로그를 찾을 수 있는 위치를 알려준다면 XCode를 사용하여 우리 소프트웨어의 또 다른 공증을 수행하고 그러한 경고가 나타나는지 확인하겠습니다.
공증이 성공했다는 것만 알 수 있는데 아직 로그 파일에 경고가 있는지 확인하지 않았습니다.

나는 이 문서 에서 일하고 있다. 특히 "요청 상태 확인" 섹션을 참조하십시오.

@gdams hardenend 런타임 지원이 다시 사라진 것 같습니까? jdk-11.0.4+11.4를 사용하면 공증이 작동합니다. 그러나 jdk-11.0.5+10을 사용하면 강화된 런타임 지원이 활성화되지 않는다는 오류가 발생합니다.

강화된 런타임 옵션 없이 실행 파일에 서명한 것 같습니다. 하려고 노력하다
코드 설계 명령에 --option runtime 를 추가하십시오.

2019년 11월 5일 화요일 07:56 David Eby 알림 @github.com 작성:

안녕 여러분,
이것이 완전히 닫혀 있는지 확실하지 않습니다. 최신 macOS를 번들로 제공합니다
OpenJDK 11 JRE(OpenJDK11U-jre_x64_mac_hotspot_11.0.5_10.tar.gz)
공증 프로세스가 성공하는 동안
(아마도) 실패할 것임을 나타내는 JSON 로그의 경고
미래. 예를 들어:

{
"심각도": "경고",
"코드": null,
"경로": "XYZ.app.zip/XYZ.app/Contents/jdk-11/bin/java",
"message": "실행 파일에 강화된 런타임이 활성화되어 있지 않습니다.",
"docUrl": null,
"아키텍처": "x86_64"
},

다른 사람들이 보고한 성공적인 공증이 기한인 것 같습니다.
Apple에 일시적으로 공증 요구 사항 완화
https://developer.apple.com/news/?id=09032019a ~ 2020년 1월.

도움이 되는 경우 로그 사본을 전달할 수 있습니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/AdoptOpenJDK/openjdk-build/issues/1130?email_source=notifications&email_token=ALFWETDWY6UNPTKTOAOHGFLQSEDKHA5CNFSM4H3I6DJ2YY3PNVWWK3TUL52HS4DFVEXG43VM
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/ALFWETGV56Q5HXDOMCPKBKTQSEDKHANCNFSM4H3I6DJQ
.

Apple이 업데이트를 출시했습니다: https://developer.apple.com/news/?id=12232019a
OS X 10.15에서 JDK8을 사용하면 2월 3일(4주 후)부터 완전히 실패하기 시작한다는 것을 올바르게 이해하고 있습니까?
꽤 나쁠텐데..

Apple이 업데이트를 출시했습니다: https://developer.apple.com/news/?id=12232019a
OS X 10.15에서 JDK8을 사용하면 2월 3일(4주 후)부터 완전히 실패하기 시작한다는 것을 올바르게 이해하고 있습니까?
꽤 나쁠텐데..

아니요, 그렇게 될 일은 아닙니다. 그것은 나쁜 일이지만 지금 작동하는 것들은 계속 작동할 것입니다. 공증을 위해 앱을 제출하려면 여러 요구 사항을 충족해야 합니다. 그 중 하나는 코드 서명이고 다른 하나는 런타임 강화입니다. 인터넷에서 다운로드한 앱을 Catalina(10.15)에 설치하려면 공증이 제대로 되었는지 게이트키퍼 검사를 통과해야 합니다. 그것은 바로 지금 Catalina에서 발생합니다.

2003년 2월 3일에 발생하는 일은 코드 서명 및 런타임 강화와 관련하여 기준을 충족하지 못하면 Apple에서 앱을 공증할 수 없다는 것입니다.

Apple은 현재 유예 기간 중이므로 무엇이든 제출할 수 있으며 요구 사항을 충족하지 못하더라도 공증할 것입니다. 2월 3일 이후에는 앱 공증을 받을 수 없으므로 통과하지 않으면 새 앱을 배포할 수 없습니다. 물론 7월에 애플은 9월이 될 것이라고 말했다. 9월에는 1월이라고 했고, 12월에는 2월이라고 했습니다. 그래서 그들은 상황이 옳지 않다는 것을 인식하고 있으며 그렇게 함으로써 많은 사람들에게 피해를 줄 것입니다.

그리고 그들의 해결 방법입니다. 고객에게 관리자 액세스 권한이 있는 경우 제어판으로 이동하여 앱을 인증하여 공증되지 않은 모든 항목을 설치하도록 허용할 수 있습니다.

런타임 강화로 어려움을 겪고 있는 사람들을 위해 사용 가능한 6가지 plist 인타이틀먼트를 모두 추가하고 사용 중인 Java 런타임이 -deep 옵션(MacOS에 있음)을 사용할 때 공동 설계되는 폴더에 있는지 확인하십시오. , 또는 프레임워크). JRE를 플러그인에 넣은 경우 타사에서 공동 설계한 것으로 가정하고 해당 위치를 코드 설계하거나 강화하지 않습니다. MacOS 및 Frameworks 이외의 다른 위치에서는 코드 설계가 무시합니다.

직접 서명해도 작동하지 않을 수도 있지만 외부의 누군가가 다음과 같은 유형의 공증 경고(오류가 되고 2월 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/resolveing_common_notarization_issues 에 따르면 이는 예상되는 일이며 우선 새로운 버전으로 바이너리를 생성해야 합니다.

2월 3일부터 OS X 10.15+용 소프트웨어 업데이트 릴리스를 중단할 수는 없지만 현재 상황은 그대로일 것입니다. 그리고 기업 환경에 일부 보안 메커니즘을 비활성화해야 한다고 말하는 것은 종종 불가능하며 절대 불가능합니다. 받아들일 수 있는 길..

OS X 10.15+용 소프트웨어 업데이트 릴리스를 중단할 수 없습니다.

FWIW 우리의 솔루션은 https://github.com/stooke/jdk8u-xcode10 을 통해 최신 SDK로 직접 구축하는 것이었습니다.

어제부터 모든 공증 경고가 마침내 오류로 변한 것 같습니다. 즉, 더 이상 Java 기반 애플리케이션을 공증할 수 없습니다.

안녕 여러분. 내 연결된 문제가 이 문제를 참조하여 종료되었으므로 여기에서 내 문제를 다시 언급하고 싶습니다. 나는 여전히 누군가가 고칠 방법에 대한 훌륭한 힌트를 가지고 있기를 바랍니다.

우리의 애플리케이션 로직은 jar 파일에 포함되어 있습니다. 이 jar 파일은 나중에 packagesbuild 명령(http://s.sudre.free.fr/Software/Packages/about.html)을 사용하여 애플리케이션 패키지에 번들됩니다. 이 번들은 AdoptOpenJDK 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}" '{}' \;

물론 6가지 권한이 모두 있으며 응용 프로그램을 설치한 후에도 볼 수 있습니다.

강화된 런타임이 활성화될 때까지 모든 것이 잘 작동합니다. 공증을 통과했지만 제공된 Java 버전으로 애플리케이션을 시작할 수 없습니다. 그것은 말한다

VM을 초기화하는 동안 오류가 발생했습니다. CodeHeap 'non-nmethods'에서 충분한 공간을 예약할 수 없습니다(2496K).

사전 설치된 Java 버전으로 응용 프로그램을 시작하면 제대로 작동하는 것 같습니다.

어제부터 모든 공증 경고가 마침내 오류로 변한 것 같습니다. 즉, 더 이상 Java 기반 애플리케이션을 공증할 수 없습니다.

어제 같은 문제가 발생했습니다. 오늘은 괜찮습니다. 어제 Apple은 Java 라이브러리가 서명되지 않고 오류가 있다고 보고했습니다. 오늘, 그들은 서명되지 않았지만 경고로보고되었습니다. 결론적으로, Apple은 내 패키지를 공증했습니다.

어제 같은 문제가 발생했습니다. 오늘은 괜찮습니다.

나도 이것을 보았고, 아마도 Apple이 2월 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 서명이 8월 21일 https://github.com/AdoptOpenJDK/openjdk-build/commit/5cd5306b4e97437aa2129dffd7e83e2f7cfd9255#diff -9a6d9f1628b9075aa83e1에서 제거되었음을 확인했습니다. 언급된 티켓 https://github.com/AdoptOpenJDK/TSC/issues/107 이 종료되었습니다. 다시 가져올 계획이 있습니까?

VM을 초기화하는 동안 오류가 발생했습니다. CodeHeap 'non-nmethods'에서 충분한 공간을 예약할 수 없습니다(2496K).

이것을 다시 한 번 살펴본 후 문제가 우리 스크립트에 있었던 것 같습니다. 역사적으로 성장하여 JRE에 추가로 서명했습니다. 이제 JRE의 찾기 기호 부분을 제거하기만 하면 제대로 작동하는 것 같습니다.

@abauman-7signal이 언급했듯이 실제로 모든 오류는 이제 다시 경고입니다. 아마도 2월 3일까지일 것입니다.
OpenJDK 13을 공증하고 나중에 실제로 작동하게 하는 방법에 대한 아이디어가 있습니까?

지금 이 문제를 해결할 수 있는 좋은 방법이 있습니까? macOS 10.15.2 및 openjdk8 사용 시도

현재 상태를 요약하려고 합니다. 저는 이 분야의 전문가가 아니기 때문에 요약에 오류가 있을 수 있습니다. @gdams 는 AdoptOpenJDK를 공증하고 강화된 런타임 지원을 가능하게 하는 노력을 주도하고 있지만 완료하느라 바쁩니다. 그래서 소금 한 알과 함께 섭취하십시오 ...

HotSpot이 포함된 JDK 11 작업은 곧 OpenJ9가 포함된 JDK 11에서 완료되었습니다. JDK 번들링은 문제 없이 작동해야 합니다. 이 작업의 결과는 다음 분기 CPU(2020년 4월)에 포함될 예정입니다. 완전한 공증과 강화된 런타임 지원으로 더 빨리 사용할 수 있는 11.0.6의 재구축이 있는지 여부는 아직 결정되지 않았습니다. 기존 바이너리는 이미 공증되었으며 문제 없이 2월 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 은 아직 진행 중이며 ETA가 없습니다. 여기서 주요 문제는 JDK 8이 공증 및 강화된 런타임을 지원하지 않는 이전 Xcode로만 빌드를 지원한다는 것입니다. 최신 Xcode 버전을 사용하려는 노력이 진행 중이지만 결과 바이너리는 아직 테스트 스위트를 통과하지 못했습니다. @gdams 는 Apple과 함께 검토하고 있습니다. 기존 실행 파일은 공증되었으며 2월 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

3월에 출시될 JDK 14는 JDK 11과 동일한 기능을 가져야 합니다. 공증 및 강화된 런타임 지원이 포함된 JDK 14의 Nightly 빌드가 곧 제공될 것입니다. 이를 위해서는 최소한 https://github.com/AdoptOpenJDK/openjdk-build/pull/1517 이 필요합니다.

다른 모든 JDK(9, 10, 12, 13)는 수명이 다하여 범위를 벗어났습니다.

이 업데이트와 이 문제를 해결하기 위한 노력에 감사드립니다.

가능한 한 빨리 11.0.6을 다시 빌드할 수 있도록 하십시오. 현재로서는 임베디드 Java 런타임이 포함된 애플리케이션을 출시하는 우리와 같은 개발자는 2월 3일 이후 2개월 후 11.0.7이 릴리스될 때까지 Catalina에서 작동하는 새 빌드를 출시할 수 없을 것이라고 생각합니다. (제거되기 전에 11.0.4+11.2를 가져오지 않는 한 우리는 그렇게 했습니다.)

도움이 된다면 보다 일반적인 릴리스 전에 애플리케이션 빌드 및 공증 시스템으로 테스트해 보겠습니다.

도움이 된다면 보다 일반적인 릴리스 전에 애플리케이션 빌드 및 공증 시스템으로 테스트해 보겠습니다.

@mdgood 이미 최신 업데이트된 공증 업데이트가 있는 JDK11의 야간 빌드 중 하나를 얻을 수 있습니다. https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk11u/job/jdk11u-mac-x64-hotspot을 참조하십시오.

어떻게 지내는지 보고 싶습니다. 알려 줘요!

@gdams 포인터 주셔서 감사합니다. 좋은 소식입니다! 이것을 잡아서 결과를 보고하겠습니다.

3월에 출시될 JDK 14는 JDK 11과 동일한 기능을 가져야 합니다. 공증 및 강화된 런타임 지원이 포함된 JDK 14의 Nightly 빌드가 곧 제공될 것입니다. 이를 위해서는 최소한 #1517이 필요합니다.

다른 모든 JDK(9, 10, 12, 13)는 수명이 다하여 범위를 벗어났습니다.

JDK 13의 수명이 종료 되지 않았습니다 . JDK 14가 3월에 릴리스될 때만 수명이 종료됩니다. 최신 JDK의 공증된 빌드를 가질 수 있도록 공증된 JDK 13의 다른 빌드를 재고하고 발행하십시오.

@gadams 11.0.7 의 1월 30일 야간 빌드가 제대로 작동하고 있습니다. 우리의 애플리케이션 빌드는 경고 없이 공증되었으며 Catalina에서 잘 설치되고 작동합니다. 다음 주에 새로운 제한 사항이 적용된 후 다시 확인하기 위해 신청서를 작성하고 공증하려고 합니다.

구축 및 공증은 어제도 잘 작동했습니다.

2020-02-06 06:01:30 +0000 현재 다음과 같은 공증 오류가 발생합니다.

심각도 | "오류"
경로 | "..../Contents/Plugins/Java.Runtime/Contents/Home/jre/bin/java"
메시지 | "바이너리는 10.9 SDK보다 오래된 SDK를 사용합니다."
건축 | "x86_64"

따라서 가까운 시일 내에 동일한 문제를 보게 될 것이라고 가정합니다.

10.9 이상에 대해 빌드된 Java 8 JRE에 대한 진행 상황이나 일정이 있습니까? RMI 변경으로 인해 여전히 Java 8과 번들해야 합니다.

모든 정보를 주시면 감사하겠습니다. 여전히 중요한 장애물이 있는 경우 이전에 언급한 이 리포지토리를 사용하여 직접 구축할 수 있습니다.
https://github.com/stooke/jdk8u-xcode10

그러나 앞으로 며칠 내에 Java 8 JRE를 사용할 수 있게 된다면 나는 그것을 기다리는 것을 훨씬 선호할 것입니다.

@addsomebass 임박한 것은 없습니다. 제 기억이 맞다면, 우리 팀원 중 한 명이 당신이 연결하는 패치를 가지고 놀았고 결과 바이너리는 테스트 스위트를 통과하지 못했습니다. 따라서 알려진 결함이 있는 JDK를 번들로 묶습니다.

@addsomebass 저는 @aahlenst가 언급한 테스트 실패를 해결하기 위해 Apple과 협력하고 있습니다. https://github.com/stooke/jdk8u-xcode10 의 패치가 프로덕션 준비가 되지 않았으며 테스트에 실패했음을 반복합니다.

현재 목표는 공증된 jdk8 바이너리를 월말까지 준비하는 것입니다.

@gdams 업데이트에 감사드립니다. 이에 대한 작업에 정말 감사드립니다.

여전히 문제가 있지만 모든 사람의 작업에 감사드립니다.

JDK14의 최신 EA에서 jpackage를 사용하여 .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

문제는 다음 중 하나를 수행할 수 있다는 것입니다.

• 공증된 앱을 빌드했지만 실행되지 않거나
• 실행 가능한 앱을 빌드하지만 공증하지 않습니다.

한 가지 제쳐두고 - jpackage에서 Mac용 서명 앱이 현재 손상 되어 사용할 수 없습니다. 런타임이 서명되지 않았을 때 작동했지만 이제는 내가 직접 서명해야 합니다.

런타임(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)

만세! 그러나 JRE가 있는 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 및 모든 dylib 및 jar에 직접 서명하여 실행할 수 있었습니다. 자격 파일에서 이 줄을 설정했습니까?

<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 감사합니다 - 시도해보겠습니다. 지금까지 자격을 작성하지 않았지만 2월 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 지금 서명이 깨졌습니다. 공증을 받으려면
• 자신의 코드에 서명해야 합니다.
• JRE에 다시 서명해야 합니다. -f 를 사용하여 서명을 강제 실행합니다.
• 모든 서명 호출에서 자격을 지정해야 합니다.

안녕하세요, 현재 Java 8 또는 Java 9용 Mac 빌드가 있는지 여쭤봐도 될까요? 그러면 새 규칙에 따라 공증을 받을 수 있나요?

@ijabz 귀하의 질문을 올바르게 이해하고 있다면 응용 프로그램 내에서 jvm을 묶고 공증하고 싶습니다. 현재로서는 할 수 없습니다. 최신 AdoptOpenJDK 빌드는 이전 버전의 Mac OS SDK로 빌드되었으며 재패키징 및 재공증할 수 없습니다.

Java만 설치하려는 경우 최신 .pkg 설치 프로그램이 OSX Catalina에서 작동하며 저는 Java를 설치하고 실행할 수 있습니다. 이 설치 프로그램은 공증되었으며 문제 없이 컴퓨터에 Java를 설치할 수 있습니다.

gadams는 Java 8의 공증 가능한 빌드를 얻기 위해 노력하고 있으며 이달 말에 완료되기를 희망하고 있습니다. 나는 그와 다른 모든 사람들에게 행운을 빕니다.

귀하의 질문을 올바르게 이해하고 있다면 애플리케이션 내에서 jvm을 번들로 제공한 다음 이를 공증하고 싶습니다. 현재, 당신은 할 수 없습니다

네 맞습니다. 제 부분에서 코드 변경이 필요하지만 AdoptOpenJDK Java 11 빌드가 작동합니까?

또는 Oracle 빌드를 설치하면 작동합니다. 현재 MacOS에서 Oracle Java 8을 사용하고 있으며 2월 3일까지 작동했습니다. 이것이 .pkg 빌드를 의미합니까?

지금 사용할 수 있는 솔루션을 찾고 있습니다. 현재 옵션이 무엇인지 잘 모르겠습니다.

@ijabz 개인적으로 작업하지 않았기 때문에 Java 11 이상에 대해 말할 수 없습니다. 여기의 의견으로 판단하면 작동하는 번들을 얻는 방법이 있는 것 같습니다. Java 8 빌드 작업에 대해서만 이야기할 수 있습니다.

mac 설치 프로그램 패키지 또는 .pkg 파일은 소프트웨어 설치 프로그램입니다. 현재 공증되고 다음과 같이 Java를 올바르게 설치하는 AdoptOpenJDK 빌드에 사용할 수 있는 .pkg 설치 프로그램이 있습니다.
https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u242-b08/OpenJDK8U-jdk_x64_mac_hotspot_8u242b08.pkg

내가 멍청하다고 생각하지만 AdoptOpenJDk가 공증되었지만 월말까지 준비되지 않은 Java 8 빌드에서 작업하고 있다는 것을 이해하지 못하지만 반대로 이미 AdoptOpenJDk Java 8 설치 프로그램이 이미 설치되어 있습니다. 공증된 버전 Java 8?

@ijabz 제 생각에 그 이유는 2020년 2월 3일 이전에 공증된 것이 있다면 여전히 유효하며 macOS Catalina에서 작동하기 때문이라고 생각합니다. 그러나 지금은 규칙이 더 엄격해지기 때문에 다시 공증할 수 없습니다. 따라서 AdoptOpenJDK Java 8 설치 프로그램은 아마도 2월 3일 이전에 공증을 받았으므로 계속 사용할 수 있습니다.

그러나 2월 3일 이후로 Apple은 XCode 10이 필요한 앱을 "강화"하도록 요구하기 때문에 더 이상 패키징할 수 없습니다. 그리고 Java 8은 XCode 10으로 컴파일되지 않았으므로 (아직) 강화할 수 없습니다.

따라서 AdoptOpenJDK Java 8은 2월 3일 이전에 공증을 받았기 때문에 강화되지 않았음에도 불구하고 설치할 수 있습니다. 그러나 이제 더 이상 새 버전을 만들거나 프로그램을 패키지로 묶는 것이 불가능합니다. 강화할 수 없고 따라서 공증할 수 없기 때문입니다.

내가 읽은 것에서 최소한 JDK 11.0.7 및 JDK 14가 제대로 작동하는 것 같고 XCode 10을 사용하여 컴파일되고 "강화"되었으며 최소한 JDK 14를 사용하여 프로그램을 패키징할 수 있습니다.

알겠습니다. 감사합니다. 이제 더 잘 이해했습니다.
JDK 11.0.7 및 JDK 14를 참조할 때 한 가지 더 말씀드리면 AdoptOpenJDk 빌드를 의미한다고 가정합니다. AdoptOpenJDk 빌드의 상황은 Oracle 사이트에서 다운로드할 수 있는 상황과 동일합니까?

죄송합니다. 잘 모르겠습니다. OpenJDK로만 시도했습니다(AdoptOpenJDK가 아니라 다른 배포판이지만 모든 OpenJDK 배포판에서 동일하다고 생각합니다). 그러나 XCode 10과 호환되도록 JDK 8을 변경해야 하고 내가 아는 한 Oracle은 OpenJDK 및 자체 배포에서 동일한 변경을 수행하기 때문에 JDK 8도 강화되지 않았다고 생각합니다( 그렇지 않으면 그들은 또한 강화될 Java 8의 OpenJDK 버전을 출시했을 것입니다). 그러나 내가 말했듯이 나는 그것을 시도하지 않았습니다.

알았어 고마워. AdoptOpenJdk 빌드를 사용하면 Oracle에서 다운로드하는 것보다 이점이 무엇인지 완전히 확신하지 못하기 때문에 질문합니다.

@ijabz Oracle JDK는 제한된 사용 사례에서만 무료로 사용할 수 있습니다( Oracle Java SE 라이선스 FAQ 참조). Oracle의 OpenJDK 빌드 도 사용할 수 있으며 여전히 제한 없이 무료로 사용할 수 있지만 지원되는 플랫폼 및 버전의 수는 여기 AdoptOpenJDK에서 제공하는 것보다 훨씬 적습니다. 이름에서 알 수 있듯이 AdoptOpenJDK는 OpenJDK의 빌드입니다. 우리의 주요 목표 중 하나는 모든 변경 사항을 업스트림하는 것입니다. OpenJDK의 다른 공급업체(Amazon, Azul, BellSoft, SAP 등)는 정책이 다를 수 있습니다.

맞아요. 이제 최신 빌드용으로 MacOS 빌드만 제공하는 것 같습니다. 감사합니다.

@gdams , 공증된 jdk8 바이너리가 월말까지 준비될 것으로 예상하십니까? 또한 J9 JVM이 포함됩니까?

@gdams , 공증된 jdk8 바이너리가 월말까지 준비될 것으로 예상하십니까? 또한 J9 JVM이 포함됩니까?

BellSoft JDK8 배포판(https://bell-sw.com/pages/java-8u242/)을 사용해 볼 수 있습니까? AdoptOpenJDK J8을 BellSoft J8로 교체하고 "The binary uses an SDK older than the 10.9 SDK." 를 없애고 마침내 공증을 받았습니다.

BellSoft J8은 이미 공증 준비가 완료된 것 같습니다.

내가 알기로는 BellSoft JDK는 무료가 아닙니다..

내가 알기로는 BellSoft JDK는 무료가 아닙니다..

GPL에 대한 "CLASSPATH" 예외가 있는 GNU 일반 공중 사용 허가서(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 응용 프로그램 스레드" 스레드의 예외 java.lang.UnsatisfiedLinkError: /private/var/folders/0f/trlp6tp95qjbzm99ds8pt8zm0000gp/T/JxBrowser/7.5/libbrowsercore_toolkit.dylib: dlopen/trlpfolders60ptm99 JxBrowser/7.5/libbrowsercore_toolkit.dylib, 1): 적합한 이미지를 찾을 수 없습니다. 찾았습니다:
/private/var/folders/0f/trlp6tp95qjbzm99ds8pt8zm0000gp/T/JxBrowser/7.5/libbrowsercore_toolkit.dylib: (/private/var/folders/0f/trlp6tp95qjbzm99ds00pt의 코드 서명. 라이브러리 유효성 검사를 사용하여 진행 중: 매핑 프로세스와 매핑된 파일(플랫폼이 아님)이 서로 다른 팀 ID를 가짐

이것은 내가 가지고 있는 라이브러리도 작동하려면 해당 권한이 필요하다는 것을 의미합니까, 아니면 제 마음대로 되는 것입니까?

공증 프로세스에서 가장 실망스러운 부분은 이 릴리스 프로세스를 CI/CD 파이프라인에 연결해야 한다는 것입니다. Apple이 테스트 엔드포인트를 제공했으면 합니다. 공증은 필요 없고 공증 가능 여부만 알면 됩니다. 물론 그 차이는 작지만 몇 가지가 불편합니다.

1. 타사에 대한 업데이트를 사용하는 경우 업데이트가 공증 가능한지 확인하는 접수 프로세스가 필요합니다. 검증을 위해 해당 제3자를 제출함으로써 저는 이제 제 회사 신용을 사용하는 제3자를 공증했으며 제 보안 담당자는 그것이 좋지 않다고 생각합니다.
2. 나는 고객에게 제공할 생각이 전혀 없는 것을 매일 공증을 위해 제출하고 있으며, 단순한 테스트 이상을 수행하도록 승인된 자격 증명을 사용해야 합니다. 이러한 자격 증명은 이제 내 파이프라인의 일부이기 때문에 자격 증명 위반에 대한 보안 노출 영역이 더 큽니다. 따라서 자격 증명을 사용하지 않거나 테스트 목적으로만 사용되는 자격 증명을 사용하는 테스트 끝점을 원합니다.

@gravelld @dg76 문제를 겪고 있는 다른 사람이 있습니까? 자격을 생성하려고 시도했지만 라이브러리 유효성 검사를 비활성화하지 않는 것 같습니다.

@dcboy95 죄송합니다. 전체 번들에 대한 적용 범위와 관련하여 특정 권한이 어떻게 작동하는지 모르겠습니다. 코드 서명과 함께 내가 함께 제공한 전체 라이브러리를 사임해야 한다는 것을 알았습니다. 따라서 함께 제공되는 전체 코드베이스에도 자격이 있어야 한다는 의미일까요? 죄송합니다.

@dcboy95 codesign 과 자신의 인증서를 사용하여 "libbrowsercore_toolkit.dylib" 파일을 사임하면 된다고 생각합니다. (이 제안을 여기에 이미 게시했다고 생각했지만 나에게서 어떤 응답도 찾을 수 없습니다.) 오류는 라이브러리에 나머지 응용 프로그램과 다른 서명이 있음을 나타내는 것 같습니다. 그리고 다른 사람이 아무 것도 넣지 않도록 모든 것이 동일한 서명을 가져야 한다고 생각합니다. 따라서 "libbrowsercore_toolkit.dylib"에서 코드 디자인을 실행해 보십시오. 문제가 해결됩니까?

@ dg76 불행히도 작동하지 않았습니다. 타사 라이브러리를 사용하면 다른 버전이 있는 경우 자체적으로 다시 설치됩니다. 따라서 해당 파일을 코드 설계할 때 이전 파일로 인식하고 수정된 파일을 대체하여 새 파일을 다운로드합니다. 같은 오류가 발생합니다. com.apple.security.cs.disable-library-validation 권한이 이 문제를 해결할 것이라고 생각했지만 그렇지 않은 것 같습니다.

@dcboy95 제 생각에는 이것이 작동하지 않을 것 같습니다. Apple 공증 시스템의 목적은 개발자가 앱의 모든 부분이 테스트를 거쳤고 문제가 없음을 확인하도록 하는 것입니다. 개발자가 테스트하고 확인하지 않은 부분을 런타임 중에 다른 개발자로부터 로드하는 것은 허용되지 않을 수 있습니다. 그냥 자동 다운로드 기능을 비활성화 할 수 없습니까?

@dg76 정보 감사합니다. 문서를 조사하여 이것이 가능한지 확인해야 합니다. 다시 한 번 감사합니다

완전히 공증된 AdoptOpenJDK 14+36 이 출시되었습니다. 문제가 있는 경우 다시 보고해 주십시오.

완전히 공증된 JDK 8은 아직 작업 중입니다. 다음 분기 CPU(4월 17일에서 가장 가까운 화요일)에 이것이 포함되기를 바랍니다.

필요한 패치는 일부 테스트 실행(TCK 포함)을 통과했지만 더 많은 검증이 필요합니다. @gdams 는 머지 않은 미래에 테스트용 빌드를 제공할 수 있도록 현재 상태를 게시할 계획입니다.

@aahlenst JDK 11에 대한 계획이 있습니까?

@dcboy95 공증된 JDK 11은 다음 분기 CPU의 일부로 게시될 예정입니다(오라클의 규칙을 올바르게 기억한다면 4월 17일에서 가장 가까운 화요일 직후). 그 동안 https://adoptopenjdk.net/nightly.html?variant=openjdk11&jvmVariant=hotspot 에서 JDK 11의 야간 빌드를 가져와 작동하지 않으면 다시 보고할 수 있습니다.

안녕하세요 설치 프로그램에 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 솔루션을 시도했습니다.

명령: codesign --verbose=4 --deep --force -s "개발자 ID 응용 프로그램: abc (xxxxx)" jdk-11.0.7+7

산출:
jdk-11.0.7+7: 기존 서명 교체
jdk-11.0.7+7: 리소스 포크, Finder 정보 또는 이와 유사한 쓰레기는 허용되지 않습니다.

그러나 그것은 다음과 같은 오류를 나타냅니다 ...
jdk-11.0.7+7: 코드에 리소스가 없지만 서명은 리소스가 있어야 함을 나타냅니다.

내가 뭔가 잘못하고 있습니까?

야간 빌드에서 11.0.7+7을 시도했습니다. 공증이 통과되고 신청서가 성공적으로 나타납니다. 그러나 바이너리(dylib)는 이제 JNA에서 사용하는 네이티브 로드에 의해서만 실행된 jar 번들에서 조회되는 것 같습니다. 결과적으로 이제 시스템에 설치된 dylib에 액세스하려고 할 때 애플리케이션이 UnsatisfiedLinkErrors를 수신합니다. 이것은 이전에 작동했습니다.

@MoxxiManagam dylibs에 서명되었습니까? codesign -v -v /path/to/dylib 로 확인하십시오.

@aahlenst 의심스럽습니다. 시스템에 설치된 타사 dylib(장치 드라이버)이며 우리 응용 프로그램의 일부가 아닙니다. 또한 활성 com.apple.security.cs.disable-library-validation 자격이 있는데 문제가 되지 않습니다.

lib는 /usr/local/lib/ 디렉토리에 있습니다.

JDK 11 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 에는 xattributes가 나열되지 않습니다.

흥미롭게도 파일을 다른 위치( Contents/MacOS 폴더 외부)로 옮기 거나 파일 확장자를 .dylib 이외의 다른 것으로 변경하면 위의 무의미한 것 없이 코드 서명 및 서명 확인이 정상적으로 통과합니다. 오류. 코드 설계 메커니즘은 파일의 위치도 고려해야 하므로 Contents/Home/lib/jli/libjli.dylib 의 파일 결과와 달라야 합니다.

공증(야간 빌드) 후 /usr/local/lib/ 내에서 찾을 수 없는 드라이버 dylib에 대한 업데이트가 있습니까?

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: 리소스 포크, Finder 정보 또는 이와 유사한 쓰레기는 허용되지 않습니다.

@NishikaDeSilva 는 codesign 명령을 실행하기 전에 디렉토리에서 이것을 실행합니다:

xattr -cr .

그것은 효과가 있습니다. 재귀 -cr 가 필요하지 않으며 최상위 폴더에서 com.apple.FinderInfo 만 제거하면 충분합니다. 최상위 폴더의 FinderInfo 속성이 전체 패키지의 코드 설계를 방해하는 것은 당연합니다.

해당 xattr이 있는지 여부에 관계없이 libjli.dylib는 여전히 자체적으로 공동 설계할 수 없습니다. 코드 설계 메커니즘은 포함하는 패키지 코드 서명으로 무언가를 확인하기 위해 해당 특정 위치에 dylib가 필요합니까? 만약 그렇다면(또는 그것에 관계없이), 왜 전체 패키지가 기본적으로 단순히 공동 설계되지 않습니까?

꼭 필요한 경우가 아니면 전체 JRE 코드를 코드 서명하지 않는 것이 좋습니다.

@gadams @aahlenst 공증된 JDK 1.8에 대한 업데이트가 있습니까? 4월 17일 발매인가요? 시험해 볼 이전 키트가 있습니까?

다음 주에는 공증과 강화된 런타임이 없는 8u252가 먼저 있을 것입니다. 그 후, 우리는 스위치를 뒤집어 공증과 강화된 런타임으로 스위치를 만들 것입니다. 추가 정보가 이어집니다. 다른 사람이 테스트할 준비가 된 바이너리가 이미 있는지 여부는 알 수 없습니다.

8u252에는 이후 SDK에 대해 빌드된 libAppleScriptEngine.dylib가 포함되므로 '바이너리는 10.9 SDK보다 오래된 SDK를 사용합니다'와 함께 실패하지 않습니다. 이것이 가장 도움이 될 것입니다. https://stackoverflow.com/questions/61208189/java-notarization -of-libapplescriptengine-dylib-failing-with-the-binary-uses-an

오랫동안 기다려온 8u252가 나왔지만 그 안에 있는 거의 모든 바이너리가 여전히 sdk 10.8로 빌드되어 성공적인 공증을 방해하는 것으로 나타났습니다.
https://ci.adoptopenjdk.net/view/work%20in%20progress/job/jdk8u-mac-x64-hotspot-notarized/10/ 의 JRE에는 10.14 바이너리가 포함되어 있으므로 공식 8u252에도 포함되기를 바랍니다.

다음 주에는 공증과 강화된 런타임이 없는 8u252가 먼저 있을 것입니다. 그 후, 우리는 스위치를 뒤집어 공증과 강화된 런타임으로 스위치를 만들 것입니다.

공유할 수 있는 일정이 있습니까?

@meshcow 추정하기 어렵습니다. 그래서 처음부터 견적을 내지 않았습니다. 일반 빌드가 있는 파이프라인은 여전히 ​​실행 중입니다(예: HotSpot의 14.0.1 및 OpenJ9의 11.0.7). 런타임이 강화된 버전은 나중에 빌드됩니다.

@meshcow - 우리는 Mac Os 공증 패치를 테스트하기 위해 8u252.1을 구축할 것입니다. 하루나 이틀 안에 여기에 올 것입니다.

참고로 저는 BellSoft 8u252를 사용하여 공증을 허용하기 위해 이후 SDK에 대해 빌드된 libAppleScriptEngine.dylib를 가져오고 그것이 작동하는지 확인할 수 있습니다.

또한 내가 AdoptJDk 11.0.7 JRE 빌드를 내 앱에 번들로 포함하고 내 애플리케이션을 성공적으로 공증했는지 확인할 수 있습니다.

참고로 저는 BellSoft 8u252를 사용하여 공증을 허용하기 위해 이후 SDK에 대해 빌드된 libAppleScriptEngine.dylib를 가져오고 그것이 작동하는지 확인할 수 있습니다.

앱과 함께 jre를 번들하는 데 무엇을 사용하고 있는지 말씀해 주시겠습니까? javapackager를 사용하면 fxbundlerpath/Contents/MacOS/libpackager.dylib: is already signed 라고 표시됩니다.
AdoptJDK 11에서는 어떻게 합니까?

Appbundler(InfinityKind 포크)를 사용했습니다 - https://github.com/TheInfiniteKind/appbundler/
내일 stackoveflow에 대한 자세한 답변을 게시하려고 합니다.

@as1an https://stackoverflow.com/questions/58548736/notarize-existing-java-application-for-macos-catalina 에서 내 질문에 대한 답변을 추가했습니다.

테스트할 J9 JVM 1.8 공증 빌드가 있는 사람이 있습니까?

@meshcow 추정하기 어렵습니다. 그래서 처음부터 견적을 내지 않았습니다. 일반 빌드가 있는 파이프라인은 여전히 ​​실행 중입니다(예: HotSpot의 14.0.1 및 OpenJ9의 11.0.7). 런타임이 강화된 버전은 나중에 빌드됩니다.

@aahlenst J9 버전의 1.8 JVM도 포함됩니까?

이번주에 옵니다.

감사합니다!

공증된 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)이며 앱은 당사 인증서로 서명됩니다. JRE의 모든 항목이 이미 서명된 것으로 나타났기 때문에 JRE 내에서 아무 것도 서명하지 않았습니다.
지금까지 문제가 없습니다.

@meshcow 나는 이것이 관련이 없다는 것을 알고 있으며 이것이 이에 대한 올바른 포럼이 아닌 경우 사과하지만 번들 앱에서 JNI를 작동시키는 데 어려움을 겪고 있으며 거기에 도달하는 데 도움이 된 리소스를 공유할 수 있는지 궁금합니다. . 내가 찾을 수 있는 모든 현재 Java 앱 번들러는 JRE가 공증 가능한 경우에도 공증을 방지하는 강화되지 않은 실행 파일을 생성합니다.

이 마지막 장애물을 극복하는 데 도움을 주시면 감사하겠습니다.

@addsomebass - 우리는 표준 책 접근 방식을 사용합니다. Java Invocation API를 사용하여 JVM을 로드하고 [순수] Java 앱을 시작하는 Objective C로 작성된 작은 실행 프로그램입니다. 런처는 /Contents/MacOs 아래의 OSX 앱 디렉토리에 저장됩니다. JRE는 /Contents/[app-name]/jre 아래의 Java 앱 폴더에 저장됩니다.
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 자체 런처가 필요하지 않다고 생각합니다. Java 14의 Java packager jpackage를 사용하여 번들로 제공되는 일반 Java 프로그램에서 JNI를 사용하고 있습니다. 여기에서 내 단계를 찾을 수 있습니다: https://blog.dgunia.de/2020/02/12/signed-macos-programs- with-java-14/ JNI 부분이 아닌 서명만 설명합니다. 하지만 그 과정에서 서명된 일반 JNI dylib 파일을 만들었습니다. 지금까지 잘 작동하고 공증이 가능했습니다.

@addsomebass @dg76 Java 8은 14가 아니라 우리의 경우입니다.

@meshcow @dg76 팁 감사합니다. RMI 변경으로 인해 Java 8도 사용해야 합니다.

지금 공증을 지원해주셔서 감사합니다. 하지만 패키지에서 javapackager 는 어디에 있습니까? javapackager 없이 "일반" jdk8 빌드만 찾을 수 있습니다. javapackager가 내장된 전체 jdk가 있습니까?

@gdams @aahlenst
지난주에 출시된 Open J9 강화 버전을 사용했으며 공증 과정에서 Apple로부터 다음 오류가 발생했습니다.

{ "심각도": "오류", "코드": null, "경로": "/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 폴더에 압축을 풀고 서명 확인 -

codesign -vvvv jdk8u252-b09-jre-j9jdk8u252-b09-jre-j9/: 코드에 리소스가 없지만 서명은 리소스가 있어야 함을 나타냅니다.

둘 다 관련이 있는지 확실하지 않습니다. 이에 대한 수정 사항이 있습니까?

감사합니다.

도움이 필요하면 https://github.com/adoptopenjdk/openjdk-support/에서 문제를 여십시오.