----- Original message -----
From: Pierre-Charles David <pierre-charles.david@xxxxxxx>
Sent by: orbit-dev-bounces@xxxxxxxxxxx
To: orbit-dev@xxxxxxxxxxx
Cc:
Subject: [EXTERNAL] Re: [orbit-dev] Orbit contribute directly to simrel
Date: Thu, Dec 3, 2020 2:05 AM
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 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?
