SWT binary jars signing - "Invalid signature file digest for Manifest main attributes"

[Phillipus]

Download any SWT Binary file from https://download.eclipse.org/eclipse/downloads/drops4/R-4.32-202406010610/ (in the "SWT Binary and Source" section).

Unzip the file and then run the command jarsigner -verify swt.jar:

"java.lang.SecurityException: Invalid signature file digest for Manifest main attributes"

I don't know whether this is a known problem or if it's too late to do anything about it, but thought I'd report it anyway. Could be that a third-party app links to one of these and might get a security exception.

[Phillipus]

Actually, it's the same for the latest 4.33 I-builds.

Seems to be the case since 4.31. Verifying the jars from 4.30 gives jar is unsigned.

[merks]

The generated reports indicate that all content on the update sites are signed:

https://download.eclipse.org/oomph/archive/reports-extra/R-4.32-202406010610/download.eclipse.org/eclipse/updates/4.32/R-4.32-202406010610/index.html
https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.33-I-builds/index.html

I'm not sure what produces those binaries...

[MohananRahul]

I think it is from swt build scripts.

[Phillipus]

Strange. The jars from I20240713-0130 are unsigned and the ones from I20240713-1800 are signed (although incorrectly).

[HannesWell]

The signing of the native SWT binaries for Mac and Windows happens in
https://github.com/eclipse-platform/eclipse.platform.swt/blob/c3f74749040c35395336903cba360dbe2a354a1b/Jenkinsfile#L250-L269

Download any SWT Binary file from https://download.eclipse.org/eclipse/downloads/drops4/R-4.32-202406010610/ (in the "SWT Binary and Source" section).

But these jars are packaged in
https://github.com/eclipse-platform/eclipse.platform.swt/blob/c3f74749040c35395336903cba360dbe2a354a1b/binaries/pom.xml#L162-L187

and they are indeed not signed. But these packages are only created for the download section and are different from the artifacts in the p2 repository. The artifacts in the p2-repo are jar-signed (or at least shouled be singed) as usual.

[netomi]

Could it be that the manifest is amended by some process after signing and thus breaking the digests of the manifest file?

[netomi]

can the signing be disabled again till we figure out what messes with the manifest after signing?

it certainly gives a bad impression to release artifacts whose signature is bad.

[iaik-jheher]

This is still an issue as of 4.35; the jar files shipped on the official release index have invalid signatures.

Is there any update on this?

[HannesWell]

Could it be that the manifest is amended by some process after signing and thus breaking the digests of the manifest file?

I had another look at the build script and the jar file build for the p2-repository indeed has it's content changed changed in the process of making it available for the download-site:
https://github.com/eclipse-platform/eclipse.platform.swt/blob/c3f74749040c35395336903cba360dbe2a354a1b/binaries/pom.xml#L172-L176

The extra manifest entry could probably already be added when building the jar for the p2-repo with Maven and for the updated language-specific properties files it should be checked why it is done this way and if it's necessary then it should be done in the maven build as well, so that the content doesn't have to be changed at all.

I didn't found a way to instruct the jar ANT-task to remove signatures, but I would consider this just a workaround any ways.

The changes become obvious if one compares the jar from the p2-repo with the one from the download side: