High memory usage / leaks was: Best mailing list for JVM embedding

[Sean Mullan]

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.
>>
>> --Sean
> 
> 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 [1] 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 [1] (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)
> 
> [1] 
> https://blogs.msdn.microsoft.com/shawnfa/2007/05/07/bypassing-the-authenticode-signature-check-on-startup/ 

--Sean

[1] 
https://docs.oracle.com/en/java/javase/11/security/permissions-jdk1.html#GUID-7450CEFD-8EDC-495E-A7A3-6C2561FA4999