Community
Participate
Working Groups
I noticed many messages in signing logs as pasted below. And, I have confirmed in fact our build was not signed. This is bad. Because ... if we'd "delivered" this build in its unsigned state, then technically speaking we'd have to retag everything so the future signed version (once fixed) would "replace" the jars that are unsigned. So ... we're stuck and can't deliver a build until signing is fixed. Seems to me the whole process should fail if this happens, with some error message sent ... but I think there's already a bug on that somewhere. /opt/public/download-staging.priv/webtools/wtp-P-P20100804181547-20100804181547.zip/temp_wtp-P-P20100804181547-20100804181547.zip/org.eclipse.wst.common_ui.feature.patch_3.0.5.v200910060730-10_87w311_21171841.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>
> Seems to me the whole process should fail if this happens, with some error > message sent ... but I think there's already a bug on that somewhere. Actually, shouldn't we just sign without the timestamp? An easy fix here would be to attempt connection to the tsa .. if no connection, sign without the timestamp.
(In reply to comment #1) > > Seems to me the whole process should fail if this happens, with some error > > message sent ... but I think there's already a bug on that somewhere. > > Actually, shouldn't we just sign without the timestamp? An easy fix here would > be to attempt connection to the tsa .. if no connection, sign without the > timestamp. Well ... problem is ... I'm assuming the timestamp is there for a reason, and the bundle is "not correctly signed" unless its there. And, while on the surface, it might seem fine to have a "mostly signed" version ... it would be secure ... and fix it later ... the problem is that it might end up being that way forever, sort of. The issue is that eclipse/p2/osgi all assume the bundle (jar) is completely unique based on its 4 part version number. And the way that version is currently computed or derived does not take signing into account. So, someone might end up with version 3.6.2.v20100805 signed one way without timestamp one day, then later have a different jar, still version 3.6.2.v20100805, signed a different way. This violates the strictly unique assumption. Elsewhere, I've argued against being so strict about that assumption (when it comes to signing) but others disagree and think the strict uniqueness is fundamentally required. Of course, if the timestamp is not really needed, then that'd be a different thing. If I recall, that was important since otherwise a few years from now a jar's cert might give an "expired" warning, even though valid at the time of signing.
Adding John for comment (he's the expert in these signing and uniqueness matters) [but he might be out of office this week?].
Yes, David's point is exactly correct. We want our jars to be timestamped so that if the certificate expires, the certificate can be compared with the timestamp and we will know that the certificate was valid at the time of signing. The implementation of this feature on the eclipse.org servers is described in bug 263708. If this is silently failing, we will have to ask our teams to retag their bundles so that our builds include new bundles with TSA support.
It looks like the signing process is working this morning. Any idea on the root cause of the timeouts to the timestamp authority?
Yes, we shouldn't be silently falling back to a signature without timestamp if the TSA can't be reached. Failing is better. I suspect uptime of the TSA server is not generally a problem, and that this is actually a configuration problem on our end that is preventing the connection from happening. Having said that, if removing TSA is the only way we can get our M1 build out the door by tomorrow then I think we can live with it. We would just need to retag all our changed bundles once the TSA is enabled again.
> Yes, we shouldn't be silently falling back to a signature without timestamp if > the TSA can't be reached. This is the default behaviour of jarsigner, and from reading the docs, it doesn't seem that jarsigner offers me any options in detecting or determining the state of the tsa. A quick 'wget' of the TSA url used returns a 404, so there must be some black magic happening behind the scenes. From here, I'll mark this has an enhancement, since we're following the default behaviour, and there is no readily available workaround.
(In reply to comment #7) > > Yes, we shouldn't be silently falling back to a signature without timestamp if > > the TSA can't be reached. > > This is the default behaviour of jarsigner, and from reading the docs, it > doesn't seem that jarsigner offers me any options in detecting or determining > the state of the tsa. A quick 'wget' of the TSA url used returns a 404, so > there must be some black magic happening behind the scenes. From David and Kim's comments, it looks like the signing fails completely when the TSA part fails. I.e., it doesn't go ahead and sign without timestamp. This is fine to me... it's easier for projects to detect the failure in their build if there is no signature at all, but it would be a very subtle failure if there was still a signature but without timestamp. A problem like that would only be discovered a couple of years later when the certificate expires. More important to me is understanding why this TSA interaction sometimes fails. I would have expected the verisign server to be fairly reliable and not be failing randomly. If there is a configuration problem on the eclipse.org side that might be causing this it would be valuable to track it down. It doesn't surprise me that a simple wget returns 404 since your request doesn't contain the correct headers for the TSA protocol (RFC 3161). There is another tool called "tsget" that is the equivalent of wget for TSA (http://www.opentsa.org/#client).
> More important to me is understanding why this TSA interaction sometimes fails. > I would have expected the verisign server to be fairly reliable Why does that matter? Eclipse.org has 99.95% + availability, and I assume Verisign has 99.999+. Either of those are 100%, so we know this _will_ happen again. So the question is, what do we want to do about it?
>So the question is, what do we want to do about it? A minimum I'd expect is that Eclipse project builds (other may decide otherwise) get a test (or even build) failure when this happens.
*** Bug 345461 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > *** Bug 345461 has been marked as a duplicate of this bug. *** To summarize implications of this dup'ed bug ... in a WTP build, exactly one bundle was not signed due to "unable to contact". Luckily in this one case, it was detected, and ended up not mattering if signed or not, but in many other cases, if exactly one bundle was not signed, it would be very hard to detect without some automated "post build" signing test. Just wanted to document it so we'd have a trail of how frequently this occurs ... which is not very often! ... just potentially serious when it does.
> just potentially serious when it does. Since we can't really catch the exception, perhaps release-quality builds should run a verify after signing?
(In reply to comment #13) > > just potentially serious when it does. > > Since we can't really catch the exception, perhaps release-quality builds > should run a verify after signing? I agree. Unless someone knows of a better solution. Should we move this to "cross-project" for general awareness? Volunteers for some handy ant tasks or scripts fixups to jarsigner application? (yes, to answer my own question, I will move, after this comment). BTW, I realized after I said "doesn't occur often", that I did not really know, since, after all, it is hard to detect unless you are looking for it ... so I downloaded all signing logs, and did a grep on all of them. They span about 160 days (one log for each day), about 5 months worth, ... and grep found there were 72 occurrences, on 14 different days. So ... I'd still say "not often" ... but more than one every six months.
I'm moving this bug to cross-project list to increase general awareness. The issue is that a couple of times a month, for a short period of time, the "Timestamping Authority server" can not be reached, which causes signing to fail for (usually) just a few bundles. It appears this can be generally "fixed" (such as to fail whole build) since the 'jar signer' program does not have any options to control its behavior and apparently does not return an error code, or any indication of error ... just does not sign the jar, and prints a message to the log. (Sign ...) So, I'm moving here to cross-project as general advice that it would be a good practice to explicitly "verify" your bundles are signed after a build ... at least for really important ones, such as for milestones or releases. And ... naturally, if any readers of this list have any better ideas or creates a general purpose ant task or something, that'd be great. I suggest we leave this open until after indigo, then close as "won't fix", and document this "best practice" on some wiki's somewhere? unless someone does come forward with a better idea, or general purpose ant task to help automate the verification. Thanks,
Assigning to myself just to avoid lots of future notification mails for everyone ... but not volunteering to fix anything ... so sign up on cc if interested ... and don't be bashful to re-assign to yourself, if you want to propose and implement some improvement. Thanks,
> It appears this can be generally "fixed" (such as to fail whole build) since ... can NOT be generally "fixed" ... must learn to proofread
Counting this education as complete, and I even wrote up a small caution in one of our signing FAQs with some hints of how to check after the build: http://wiki.eclipse.org/JAR_Signing#Can_the_signing_process_fail.3F
