High memory usage / leaks was: Best mailing list for JVM embedding
sean.mullan at oracle.com
Thu Jan 24 15:05:47 UTC 2019
On 1/24/19 8:25 AM, Robert Marcano wrote:
> On 1/23/19 8:59 AM, Sean Mullan wrote:
>> On 1/22/19 8:50 PM, Bernd Eckenfels wrote:
>>> I don’t think the launcher is doing this, it is the class loader,
>>> that’s nothing new. You can turn on verbose security debug to see it
>>> in all versions.
>> Yes, and it only verifies the signature(s) on the JAR. It doesn't
>> validate the certificate chain.
> I noticed that trying to identify the higher memory usage after what
> looks like a big application is loaded. I am doing memory profiling and
> notice JarFile taking more memory that on Java 8. Still need to detect
> the real cause for an independent test case. We probably didn't notice
> this slowdown before because Oracle's JNLP implementation was slow
> enough at startup.
> IMHO the class library should not do doing signature checks without
> certificate validation, because it doesn't give any protection if the
> signature is not verified, the only thing it could do now is to detect
> some random bit flips, that maybe the Zip format CRC detect before that.
> With no certificate verification the signature could be replaced by
> anybody with bad intentions.
It's a fair point, although since URLClassLoader is a subclass of
SecureClassLoader the certificate chain does get populated into the
CodeSource of the classes loaded, so one could potentially write a
custom ClassLoader or additional code to additionally validate the
certificate chain. Also, keep in mind that validating a certificate
chain for signed code is not usually sufficient to determine if you
actually trust who signed the code; some additional policy configuration
(or UI prompts) are usually required. Also, if you run the application
with a SecurityManager you can grant the signed JARs additional
permissions based on who signed the code in an associated policy file,
see  for more info.
> Maybe adding a constructor flag to URLClassloader to pass to JarFile to
> skip verification and a system property to tell the Java startup code to
> skip verification of java.class.path (just for compatibility with old
> code that expect it to be done). There is precedent of other runtimes
> that added options to disable this, like CLR  (Ii not only verified
> signatures, It do CRL/OSCP checks too)
It's easy enough to strip signatures from JAR files (which you mention
below). So if this is really an issue, I would be more inclined to just
do that if it is an option.
> Our new launcher replacing JNLP now do signature verification in native
> code, at download time, and install on a system area (not user home
> directory), so signature verification at application launch is a
> slowdown we want to avoid, but think on another kind of users, those
> deploying to OS Stores (for example Windows Store), why add the slowdown
> of verification when the application is verified by the store client at
> install time?, this could help these situations too.
> Note: This can be avoided removing the signatures of all JARs if you
> distribute to an OS store, there are a few libraries that distribute
> their JARs signed (The old Java Help framework comes to my mind right now)
More information about the core-libs-dev