Community
Participate
Working Groups
I'm opening this as an "info" bug, just to document it. Nothing to "fix", but encountered a build problem where exactly one bundle was not signed in one run. The build was our last one for our WTP 3.2.4 release, wtp-R3.2.4-M/2011051103332 The first sign of trouble was the comparator log, it said there was a difference of file counts in a bundle (that had exact same version). Message 1 canonical: osgi.bundle,org.eclipse.jst.common.frameworks,1.1.404.v201103311600 Difference found for canonical: osgi.bundle,org.eclipse.jst.common.frameworks,1.1.404.v201103311600 between file:/home/data/httpd/download.eclipse.org/webtools/downloads/drops/R3.2.4/M-3.2.4-20110331151153/repository/ and file:/shared/webtools/projects/wtp-R3.2.4-M/workdir/M-3.2.4-20110511033327/buildrepository/jst-sdk Difference in [canonical: osgi.bundle,org.eclipse.jst.common.frameworks,1.1.404.v201103311600]: file:/home/data/httpd/download.eclipse.org/webtools/downloads/drops/R3.2.4/M-3.2.4-20110331151153/repository/ contains 90 files and file:/shared/webtools/projects/wtp-R3.2.4-M/workdir/M-3.2.4-20110511033327/buildrepository/jst-sdk contains 88 files I downloaded the bundles in question and discovered the two missing files were the signature files in META-INF: ECLIPSE.RSA, ECLIPSE.SF. To confirm, I went back to build machine and checked the signing logs. I downloaded the last several recent ones to search for that particular bundle, using, such as scp david_williams@build.eclipse.org:/opt/public/download-staging.priv/arch/signer.log.1.gz . Turns out there was a message there indicating the error: jarsigner: unable to sign jar: no response from the Timestamping Authority. The complete msg was as below, showing the bundle in question: Processing /opt/public/download-staging.priv/webtools/temp-M-3.2.4-20110511033327-jst-sdk.zip/temp-M-3.2.4-20110511033327-jst-sdk.zip Extracting plugins/org.eclipse.jst.common.frameworks_1.1.404.v201103311600.jar Running Repack Sign on /opt/public/download-staging.priv/webtools/temp-M-3.2.4-20110511033327-jst-sdk.zip/temp_temp-M-3.2.4-20110511033327-jst-sdk.zip/plugins/org.eclipse.jst.common.frameworks_1.1.404.v201103311600.jar 2011-05-11 00:58:39: build SIGNER(20100): asked to sign /opt/public/download-staging.priv/webtools/temp-M-3.2.4-20110511033327-jst-sdk.zip/temp_temp-M-3.2.4-20110511033327-jst-sdk.zip/org.eclipse.jst.common.frameworks_1.1.404.v201103311600.jar 2011-05-11 00:58:39 build SIGNER(20100): Signing JAR file /opt/public/download-staging.priv/webtools/temp-M-3.2.4-20110511033327-jst-sdk.zip/temp_temp-M-3.2.4-20110511033327-jst-sdk.zip/org.eclipse.jst.common.frameworks_1.1.404.v201103311600.jar updating: META-INF/MANIFEST.MF jarsigner: unable to sign jar: no response from the Timestamping Authority. When connecting from behind a firewall then an HTTP proxy may need to be specified. Supply the following options to jarsigner: -J-Dhttp.proxyHost=<hostname> -J-Dhttp.proxyPort=<portnumber> 2011-05-11 00:58:55: build SIGNER(20100): Finished signing /opt/public/download-staging.priv/webtools/temp-M-3.2.4-20110511033327-jst-sdk.zip/temp_temp-M-3.2.4-20110511033327-jst-sdk.zip/org.eclipse.jst.common.frameworks_1.1.404.v201103311600.jar Adding plugins/org.eclipse.jst.common.frameworks_1.1.404.v201103311600.jar to /opt/public/download-staging.priv/webtools/temp-M-3.2.4-20110511033327-jst-sdk.zip/temp-M-3.2.4-20110511033327-jst-sdk.zip.temp So, lucky this wasn't the bundle we were fixing this build, and lucky this was the only "failed to contact signing authority" message in recent logs (that is, we would not have detected it, if the version/qualifier had indeed changed, and lucky our handy-dandy pw-compare-and-mirror build script pick the correct (previous) one to include in the distribution when version/qualifier is the same, so a rebuild wasn't required. Does emphasize the need for a "releng test" to confirm all bundles signed, after a build.
The general issue of "unable to contact signing authority" is described and discussed in bug 321795, so will close as a dup of it, just to maintain cross-reference. As described there, there is no way for infrastructure to flag is as an error (jar signer just prints a message, doesn't use an exit code to flag the exception) so the only fix, as far as I know, is a post-build "releng test". This particular bug, though, is odd that is was exactly one bundle that 'failed to sign' ... guess signing authority was "unreachable" for only a few milliseconds?! *** This bug has been marked as a duplicate of bug 321795 ***
