Community
Participate
Working Groups
This is probably already on your calendar ... but, appears certs need to be "renewed". Jars signed with current certificate are returning Warning: This jar contains entries whose signer certificate will expire within six months. from jarsigner -verify Using "-verbose -cert" gives this additional detail X.509, CN="Eclipse.org Foundation, Inc", OU=Digital ID Class 3 - Java Object Signing, O="Eclipse.org Foundation, Inc", L=Ottawa, ST=Ontario, C=CA [certificate will expire on 4/13/12 7:59 PM] I hope there is some way to "renew" or "extend" the certificate ... so that things signed with old one will not show up as "expired" in April ... but, I'm not sure how all that works. I hope, also, there is some to do this before April, so that things signed for Indigo SR2 (February) "get the latest" ... also good to have well in advance of Juno (June) since some jars are not necessarily "rebuilt" right up to last minute. (That is, might be built and finished in March ... maybe).
the simrel checker is also warning us about this : http://build.eclipse.org/juno/simrel/reports/verifydiroutput/verified.txt org.eclipse.jetty.bundles.f.source_8.0.1.201109140450.jar: jar verified. Warning: This jar contains entries whose signer certificate will expire within six months. Re-run with the -verbose and -certs options for more details.
I am fully confident that everyone, including Verisign, Thawte, and dozens of other competing offerings will be reminding us regularly from now 'till spring.
This is on the to-do list for the first half of March. > I hope there is some way to "renew" or "extend" the certificate ... so that > things signed with old one will not show up as "expired" in April ... but, I'm > not sure how all that works. FWIW, once something is signed with a valid cert, it is forever valid. Certs are renewed, but it's really not the same cert as the expired one. We generate a new private key and a new CSR, and obtain a brand new 3-year cert.
(In reply to comment #3) > This is on the to-do list for the first half of March. > > > I hope there is some way to "renew" or "extend" the certificate ... so that > > things signed with old one will not show up as "expired" in April ... but, I'm > > not sure how all that works. > > FWIW, once something is signed with a valid cert, it is forever valid. Certs > are renewed, but it's really not the same cert as the expired one. We generate > a new private key and a new CSR, and obtain a brand new 3-year cert. So, those "old" Indigo SR2 jars will be considered "valid" but will forever give the warning "certificate expired on 4/13/12" (After April, that is). Seems like a bummer, but probably just shows how much I don't know.
> > So, those "old" Indigo SR2 jars will be considered "valid" but will forever > give the warning "certificate expired on 4/13/12" (After April, that is). Seems > like a bummer, but probably just shows how much I don't know. To answer my own question, I had to go all the way back to "Europa", but did find jars there that reported "expired" but were still considered valid. $ jarsigner -verify org.eclipse.platform_3.3.3.r33x_r20080129.jar jar verified. Warning: This jar contains entries whose signer certificate has expired. Not sure how that is useful information (that, it's "verified", but contains "expired certificate") but guess it means things to security people in the right context.
If the warning bothers you, you do have the option of re-signing everything with the new cert... but you'd be doing this every three years :) If you ask me, that message shouldn't be a 'warning' per se, but an 'info' message. Anyway, the kind folks at digicert have offered us a FREE 3-year code signing cert... Pretty hard to say no to 'free' :-D
Thanks to our friends at Digicert (http://www.digicert.com/code-signing/) for the generous donation of a 3-year Java code signing cert. We've been using DigiCert for our SSL certs for over 7 years now. I've installed the new signing certificate, updated the signer and tested. New certificate is valid until March 5, 2015. droy@build:/opt/public/download-staging.priv/technology/phoenix> jarsigner -verify -verbose -certs org.eclipse.osgi.util_3.0.0.jar 936 Wed Apr 04 11:43:06 EDT 2012 META-INF/MANIFEST.MF 450 Wed Apr 04 11:43:08 EDT 2012 META-INF/ECLIPSE_.SF 7816 Wed Apr 04 11:43:08 EDT 2012 META-INF/ECLIPSE_.RSA sm 57 Wed Apr 04 11:43:04 EDT 2012 META-INF/eclipse.inf [entry was signed on 4/4/12 11:43 AM] X.509, CN="Eclipse.org Foundation, Inc.", OU=IT, O="Eclipse.org Foundation, Inc.", L=Ottawa, ST=Ontario, C=CA [certificate is valid from 2/28/12 7:00 PM to 3/5/15 7:00 AM] X.509, CN=DigiCert High Assurance Code Signing CA-1, OU=www.digicert.com, O=DigiCert Inc, C=US [snip] s = signature was verified m = entry is listed in manifest k = at least one certificate was found in keystore i = at least one certificate was found in identity scope jar verified. Please test at your earliest convenience.
I've been using/testing and seems to work fine (little that I know how to test signing). I do want to emphasize, for general knowledge sharing, as mentioned in comment 7, that the "key" file name in META-INF name has changed to "ECLIPSE_.SF". Originally, when we started signing at Eclipse, it was "ECLIPSE.SF", then three years later (when that first one expired) it became "ECLIPSEF.SF", and, now "ECLIPSE_.SF". This effects two things I know of. 1. In WTP, we had some heuristic code used during a build that, in short, said "if a quick peek shows a bundle has already been signed, then add it to the "exclude list" and don't try processing it again." And in my hasty coding, I hard coded the values to last only three years .... if (entryname.endsWith("ECLIPSE.SF") || entryname.endsWith("ECLIPSEF.SF")) { ... So, now that heuristic code has to be "fixed" (bug 376265). So, long story short, if you could attempt to remember in future to always use "ECLISPE"<something>".SF" we could fix our heuristic to be a little more resilient to future changes (i.e. use, essentially a regex expression such as "ECLIPSE.*\.SF" 2. Many builds project use a "p2 comparator" to compare two bundles that have been built and end up with exact same version and qualifier (since the existing one will be used, if no change to version or qualifier, so the comparator is a test that they really are the same). So, now, with new signing cert, the comparator shows lots of "warnings" of the form "previous bundle contained 'ECLIPSEF.SF'. This does no harm ... just wanted to put the side effect in writing. (I think you can close as "fixed" ... thanks for all you do).
Thanks, David. Perhaps I'm doing something wrong, but every time I "renew" the cert it seems I have to generate a new private key, and I always seem to run into errors when I try to do that withing the same Alias in the keystore. So I always create a new Alias (2006 was just Eclipse, 2009 Eclipse Foundation, and Eclipse.org in 2012). In any case, I _had_ to create a new private key for 2012 since the old key size was too small. Again, I'm probably doing something wrong, but if this process turns out to be correct, I'll simply create new aliases based on "EclipseYYYY", such as Eclipse2015, Eclipse2018, etc. so that your regexp works.
