tree a0aceed4a6e7193507d7de7a2d54e47f1986f14a
parent 62bb51bbb663e4f16fee4938f2d56c9c3c1d89ea
author Thomas Watson <tjwatson@us.ibm.com> 1619720816 -0500
committer Thomas Watson <tjwatson@us.ibm.com> 1620162142 -0400

Bug 572034 - Use Java JAR APIs for SignedContent implementation

The SignedContent implementation has had its own implementation to
handle parsing of RSA/DSA/SF files related to JAR signing.  As new
algorithms are added to Java this code has to keep up and understand the
new stuff. This commit removes the home grown implementation for reading
JAR signers and instead uses the built int JarFile and JarInputStream
implementations of Java.

This has some limitations

1) It is not easy to determine the SignerInfo message digest algorithm.
The built in JAR APIs do not expose this detail.  As such the method
SignerInfo.getMessageDigestAlgorthm now always returns "unknown" and the
method has been deprecated

2) Supporting runtime verification of signed bundles that are installed
as directory (exploded) bundles is no longer available.  Doing so will
not perform well as we need to create a JarInputStream to do the
verification over the complete directory structure and that cannot
happen lazily as entries are read from the bundle.  JAR'ed bundles now
just use JarFile under the covers to do runtime verification if
configured.  ZipFile is still used if no runtime verification is
configured (the default).  This is to avoid always parsing the manifest
on restarts.

3) On demand verification of a SignedContentEntry is not possible.  With
the Java JAR APIs you cannot even tell if a JAR entry is signed
until the complete entry itself is read and verified up front. Now a
SignedContentEntry is either signed and its content has been validated
up front or it is not signed or it is signed but invalid (corrupted).
When invalid the SignedContentEntry.verify() will throw an
InvalidContentException, but in this case the entry will still be
unsigned because the JAR APIs will not give us the entry certificates in
this case to indicate the entry is signed.

4) Old deprecated message digest algorithms that may have been used to
sign JARs may no longer be supported by the JAR APIs.  In this case the
JAR will simply be reported as not signed by SignedContent API.  This
fact forced me to have to re-sign many of the test JARs.

Change-Id: I66279a333c22f852948415bddeda355535413106
Signed-off-by: Thomas Watson <tjwatson@us.ibm.com>
Reviewed-on: https://git.eclipse.org/r/c/equinox/rt.equinox.framework/+/180074