Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Verify Windows & Mac Signatures are present on all necessary executables #3494

Closed
andrew-m-leonard opened this issue Oct 3, 2023 · 12 comments · Fixed by adoptium/ci-jenkins-pipelines#848
Closed

Verify Windows & Mac Signatures are present on all necessary executables #3494

andrew-m-leonard opened this issue Oct 3, 2023 · 12 comments · Fixed by adoptium/ci-jenkins-pipelines#848
Assignees
@andrew-m-leonard
Labels
testing Issues that enhance or fix our test suites

Comments

@andrew-m-leonard
Copy link
Contributor

We now sign both Windows & Mac JMOD executeables, as well as the bin executables. Due to the danger of the signing service failing silently we should add a simple verify test to the SmokeTests
Windows:

signtool verify /v abc.exe

Mac:

codesign --verify --verbose abc.dylib
@github-actions github-actions bot added the testing Issues that enhance or fix our test suites label Oct 3, 2023
@andrew-m-leonard
Copy link
Contributor Author

An example of a silent failure:
https://ci.adoptium.net/job/build-scripts/job/jobs/job/jdk17u/job/jdk17u-mac-x64-temurin/352/consoleFull
https://ci.adoptium.net/job/build-scripts/job/release/job/sign_installer/9806/console

00:49:19  + echo 'Signing workspace/build/src/build/macosx-x86_64-server-release/support/modules_libs/java.desktop/libosxui.dylib using Eclipse Foundation codesign service'
00:49:19  Signing workspace/build/src/build/macosx-x86_64-server-release/support/modules_libs/java.desktop/libosxui.dylib using Eclipse Foundation codesign service
00:49:19  ++ dirname workspace/build/src/build/macosx-x86_64-server-release/support/modules_libs/java.desktop/libosxui.dylib
00:49:19  + dir=workspace/build/src/build/macosx-x86_64-server-release/support/modules_libs/java.desktop
00:49:19  ++ basename workspace/build/src/build/macosx-x86_64-server-release/support/modules_libs/java.desktop/libosxui.dylib
00:49:19  + file=libosxui.dylib
00:49:19  + mv workspace/build/src/build/macosx-x86_64-server-release/support/modules_libs/java.desktop/libosxui.dylib workspace/build/src/build/macosx-x86_64-server-release/support/modules_libs/java.desktop/unsigned_libosxui.dylib
00:49:19  + '[' mac == mac ']'
00:49:19  + curl --fail --silent --show-error -o workspace/build/src/build/macosx-x86_64-server-release/support/modules_libs/java.desktop/libosxui.dylib -F file=@workspace/build/src/build/macosx-x86_64-server-release/support/modules_libs/java.desktop/unsigned_libosxui.dylib -F entitlements=@/var/jenkins/workspace/build-scripts/jobs/jdk17u/jdk17u-mac-x64-temurin/entitlements.plist https://cbi.eclipse.org/macos/codesign/sign
00:49:19  + chmod --reference=workspace/build/src/build/macosx-x86_64-server-release/support/modules_libs/java.desktop/unsigned_libosxui.dylib workspace/build/src/build/macosx-x86_64-server-release/support/modules_libs/java.desktop/libosxui.dylib

@andrew-m-leonard andrew-m-leonard mentioned this issue Oct 24, 2023
Closed
11 tasks
@sxa sxa mentioned this issue Oct 27, 2023
Closed
@andrew-m-leonard andrew-m-leonard changed the title Extend SmokeTests to verify Windows & Mac Signatures are present on all necessary executables Verify Windows & Mac Signatures are present on all necessary executables Nov 21, 2023
@andrew-m-leonard andrew-m-leonard self-assigned this Nov 21, 2023
@andrew-m-leonard
Copy link
Contributor Author

andrew-m-leonard commented Nov 21, 2023 •
edited

To ensure the resulting artifacts attached to the build job are signed (just in case copy artifact fails silently), I propose adding a new job after all signing has been done, to "VerifySigning"

@gdams
Copy link
Member

gdams commented Nov 21, 2023

To ensure the resulting artifacts attached to the build job are signed (just in case copy artifact fails silently), I propose adding a new job after all signing has been done, to "VerifySigning"

Is there a reason to not check the signature straight after signing a single binary? E.g right now I believe we loop though each binary and sign it. The most logical place to catch the error would be straight afterwards I'm guessing? We could then even add a retry logic to the curl command. My only concern there is that right now all our signing is done on the Linux codesign VM, I'm not sure how easy it would be to check the signature on Linux

@gdams
Copy link
Member

gdams commented Nov 21, 2023

following up, It looks like uthenticode can be used to check windows signatures on Linux

@gdams
Copy link
Member

gdams commented Nov 21, 2023

I've also been able to validate windows code signatures using osslsigncode:

osslsigncode verify java.exe
PE checksum   : 000155B8

Message digest algorithm  : SHA256
Current message digest    : 3F0E8B1E1C0616025C4ADDD6F0F2057CDB853C368F79AC2804D7CA5ECF648F38 
Calculated message digest : 3F0E8B1E1C0616025C4ADDD6F0F2057CDB853C368F79AC2804D7CA5ECF648F38 

Signature Index: 0  (Primary Signature)
Signer's certificate:
	Signer #0:
		Subject: /C=CA/ST=Ontario/L=Ottawa/O=Eclipse.org Foundation, Inc./OU=IT/CN=Eclipse.org Foundation, Inc./emailAddress=webmaster@eclipse.org
		Issuer : /C=US/O=DigiCert, Inc./CN=DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1
		Serial : 0DF7A7C90906301AD2F0C24D3377187B
		Certificate expiration date:
			notBefore : May  2 00:00:00 2022 GMT
			notAfter : May 21 23:59:59 2024 GMT

Number of certificates: 5
	Signer #0:
		Subject: /C=CA/ST=Ontario/L=Ottawa/O=Eclipse.org Foundation, Inc./OU=IT/CN=Eclipse.org Foundation, Inc./emailAddress=webmaster@eclipse.org
		Issuer : /C=US/O=DigiCert, Inc./CN=DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1
		Serial : 0DF7A7C90906301AD2F0C24D3377187B
		Certificate expiration date:
			notBefore : May  2 00:00:00 2022 GMT
			notAfter : May 21 23:59:59 2024 GMT
	------------------
	Signer #1:
		Subject: /C=US/O=DigiCert, Inc./CN=DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1
		Issuer : /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Trusted Root G4
		Serial : 08AD40B260D29C4C9F5ECDA9BD93AED9
		Certificate expiration date:
			notBefore : Apr 29 00:00:00 2021 GMT
			notAfter : Apr 28 23:59:59 2036 GMT
	------------------
	Signer #2:
		Subject: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Trusted Root G4
		Issuer : /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Trusted Root G4
		Serial : 059B1B579E8E2132E23907BDA777755C
		Certificate expiration date:
			notBefore : Aug  1 12:00:00 2013 GMT
			notAfter : Jan 15 12:00:00 2038 GMT
	------------------
	Signer #3:
		Subject: /C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo RSA Time Stamping CA
		Issuer : /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
		Serial : 300F6FACDD6698747CA94636A7782DB9
		Certificate expiration date:
			notBefore : May  2 00:00:00 2019 GMT
			notAfter : Jan 18 23:59:59 2038 GMT
	------------------
	Signer #4:
		Subject: /C=GB/ST=Manchester/O=Sectigo Limited/CN=Sectigo RSA Time Stamping Signer #4
		Issuer : /C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo RSA Time Stamping CA
		Serial : 394C25E17CA06D27A865E23BD91D22D4
		Certificate expiration date:
			notBefore : May  3 00:00:00 2023 GMT
			notAfter : Aug  2 23:59:59 2034 GMT

Message digest algorithm: SHA256

Authenticated attributes:
	Signing time: Oct 26 18:42:07 2023 GMT
	Microsoft Individual Code Signing purpose
	Message digest: DA80041B8F69C40302737ABBFA885586E58C79BC0F00677E0ABF0437E338EFE0 
	URL description: http://www.eclipse.org/
	Text description: Eclipse Foundation, Inc.

The signature is timestamped: Oct 26 18:42:13 2023 GMT
Hash Algorithm: sha384
Timestamp Verified by:
		Issuer : /C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo RSA Time Stamping CA
		Serial : 394C25E17CA06D27A865E23BD91D22D4

CAfile: /etc/ssl/cert.pem
TSA's certificates file: /etc/ssl/cert.pem
TSA's CRL distribution point: http://crl.sectigo.com/SectigoRSATimeStampingCA.crl
Connecting to http://crl.sectigo.com/SectigoRSATimeStampingCA.crl
Timestamp Server Signature CRL verification: ok
Timestamp Server Signature verification: ok
Signature verification time: Oct 26 18:42:13 2023 GMT
CRL distribution point: http://crl3.digicert.com/DigiCertTrustedG4CodeSigningRSA4096SHA3842021CA1.crl
Connecting to http://crl3.digicert.com/DigiCertTrustedG4CodeSigningRSA4096SHA3842021CA1.crl
Signature CRL verification: ok
Signature verification: ok

Number of verified signatures: 1
Succeeded

@andrew-m-leonard
Copy link
Contributor Author

To ensure the resulting artifacts attached to the build job are signed (just in case copy artifact fails silently), I propose adding a new job after all signing has been done, to "VerifySigning"

Is there a reason to not check the signature straight after signing a single binary? E.g right now I believe we loop though each binary and sign it. The most logical place to catch the error would be straight afterwards I'm guessing? We could then even add a retry logic to the curl command. My only concern there is that right now all our signing is done on the Linux codesign VM, I'm not sure how easy it would be to check the signature on Linux

@gdams so yeah the eclipse-sign-node is Linux, but also I was thinking i'd like to verify the "actual" artifacts on the upstream job, just in case something goes awry from after signing and the artifacts being copied to the upstream job.
This also makes verifying easier, since we can simply run on a Windows node (signtool verify ..) or Mac (codesign --verify).

@andrew-m-leonard
Copy link
Contributor Author

oh and there's another aspect, in that we have 3 places where signing/notarise occurs:

  • JMOD signing during build
  • jdk/bin signing after build
  • installer signing and notarize

The verify will unpack the jdk/jre and verify all .exe/dll/dylib, and also notarize check the .pkg using spctl.

@gdams
Copy link
Member

gdams commented Nov 21, 2023

and also notarize check the .pkg using spctl.

Note that if you're going to wait until this stage you may as well skip macOS checking. It is impossible to notarize an installer without every binary being signed so we may as well rely on Apple to do these checks for us

@andrew-m-leonard
Copy link
Contributor Author

and also notarize check the .pkg using spctl.

Note that if you're going to wait until this stage you may as well skip macOS checking. It is impossible to notarize an installer without every binary being signed so we may as well rely on Apple to do these checks for us

good point, that's very true for Mac

@andrew-m-leonard
Copy link
Contributor Author

@gdams although it's only the "installers" .pkg that are notarised? the .tar.gz are not.

@gdams
Copy link
Member

gdams commented Nov 22, 2023

@gdams although it's only the "installers" .pkg that are notarised? the .tar.gz are not.

yes but the installers contain the extracted tar.gz so there's never going to be a difference between the contents

@andrew-m-leonard
Copy link
Contributor Author

yes but the installers contain the extracted tar.gz so there's never going to be a difference between the contents
We hope :-)

@andrew-m-leonard andrew-m-leonard mentioned this issue Nov 28, 2023
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@andrew-m-leonard andrew-m-leonard

Labels
testing Issues that enhance or fix our test suites
Projects
No open projects
Adoptium 4Q 2023 Plan
Status: Done
Milestone
No milestone
2 participants
@gdams @andrew-m-leonard