|Re: [orbit-dev] Orbit contribute directly to simrel|
On Thu, 3 Dec 2020 at 03:05, Pierre-Charles David <pierre-charles.david@xxxxxxx> wrote:
Le 26/11/2020 à 19:55, Jonah Graham a écrit :
However there is some technical debt that needs to be dealt with at some point. I think the signatures in the batik 1.6 bundles are now out of date. IIUC they will be fully invalid at the end of 2020. The bundles with the soon to expire signatures that are in current Orbit got resigned: https://bugs.eclipse.org/bugs/show_bug.cgi?id=553288
$ jarsigner -verify -verbose:summary -certs ~/Downloads/org.apache.batik.css_1.6.0.v201011041432.jar
which has in its output:
[certificate will expire on 31/12/2020, 18:59]
Pardon me if this is naive, I am by no means an expert on these matters, but thinking about this I'm not sure I understand the issue, or the concrete impacts it can have.
I say If I Understand Correctly (IIUC) a few times below because I too am by no means an expert. I hope I have put you on the right course.
I understand that the certificate owned by the foundation is only valid for a certain time, and must be renewed from time to time to ensure the organisation is still alive/legitimate/trustworthy. But if an artifact (here a Batik 1.6 JAR) has been signed at a time when the certificate was valid, and thus the EF assumed trustworthy, how can the signature itself become invalid later? Surely the bits in the JAR are the same as they have always been, and will not magically become different/corrupt/evil on 2021-01-01.
If there is indeed an issue, what concrete effects can we expect when e.g. installing GMF (which embed the Batik 1.6 JARs in its repo) in an Eclipse instance after 31/12/2020?
IIUC the jar is valid longer than the certificate used to sign it, but even the jar itself becomes out of date sometime after it was signed. A bunch of the current bundles in orbit (built from the old CVS sources) were in that state and Roland resigned them for 2020-12 release.
The effect is (once again IIUC) that users get prompted about it when installing that content. I think there are some screenshots in https://bugs.eclipse.org/bugs/show_bug.cgi?id=552251 that shows what happened last time.
Thanks for the pointer. https://bugs.eclipse.org/bugs/show_bug.cgi?id=552251#c9, like Thomas's answer, points to the need for a valid TSA at the time of signature, which was the missing piece in my understanding. It seems that the Batik 1.6 JARs do have a timestamp, for example org.apache.batik.bridge-1.6.0.v201011041432.jar has been timestamped by a TSA which had a valid certificate at the time (from what I understand). That being said, for the same JAR, jarsigner also indicates the signing was done with SHA1 and RSA with a 1024 keysize, both of which are now considered insecure.
Back to the top