Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 345461

Summary:	Odd case where one bundle failed to be signed
Product:	[WebTools] WTP Releng	Reporter:	David Williams <david_williams>
Component:	releng	Assignee:	webtools.releng <webtools.releng-inbox>
Status:	RESOLVED DUPLICATE	QA Contact:	David Williams <david_williams>
Severity:	normal
Priority:	P3	Keywords:	info
Version:	3.10
Target Milestone:	---
Hardware:	PC
OS:	Linux
Whiteboard:

Description David Williams

2011-05-11 12:08:23 EDT

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.

Comment 1 David Williams

2011-05-11 12:13:40 EDT

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 ***