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

[Robert Marcano]

On 1/24/19 11:05 AM, Sean Mullan wrote:
> 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.

Thanks for the info, but this is for corporate intranet application 
distribution of an ISV (us) application, no untrusted code installation. 
We are signing our code with a certificate from a private CA and the CA 
is embedded on the native updater/launcher as the exclusive CA used for 
dowloaded updates validation. It is more like the Firefox/Chrome updater.

> 
>> 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.

Yea, I added an option to remove the signatures from the downloaded 
updates (after signature validation) so they are not validated anymore 
at launch time.

> 
>> 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 
>