eclipse-platform
SWT binary jars signing - "Invalid signature file digest for Manifest main attributes"
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.
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.
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...
Strange. The jars from I20240713-0130 are unsigned and the ones from I20240713-1800 are signed (although incorrectly).
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.
Could it be that the manifest is amended by some process after signing and thus breaking the digests of the manifest file?
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.
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?
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:
For the record and to avoid further confusion: The issue with modified content has been fixed, but it doesn't mean that the jar in the swt.zip is signed, due to the nature how signing is currently set up. To be precise the contained jar is signed if no changes has been made in SWT since the previous build, because then the jar is replaced with the baseline (the previous build) and contains the signatures from that build. In the current build signing happens after the swt.zip is packed and because signing is currently set up to happen at the latest point when building a project it would require more configuration changes to ensure that (maybe this change could only be done for the SWT projects so the impact would be local). But since before releases usually a few builds without changes happen, I assume that the release jars will have valid signatures anyway.
With https://github.com/eclipse-platform/eclipse.platform.swt/pull/2083 even the case described before should be handled and the artifacts should always be signed.