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.
Jonah
_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/orbit-dev
