[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [orbit-dev] Orbit contribute directly to simrel
|
Le 03/12/2020 à 14:44, Jonah Graham a
écrit :
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.
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.