[RFC][icedtea-web] Use global JarCertVerifier in JNLPClassLoader - tests

[Jiri Vanek]

On 05/17/2012 12:24 AM, Danesh Dadachanji wrote:
> Hi,

I do not feel skilled enough to review this. Although as far as i walked through it looks very ok!

> The attached patches make JNLPClassLoader use a global JCV to ensure we can actually check the app
> is signed entirely by at least one common signer. Currently, the classloader does not maintain
> verification of jars loaded upon main initialization vs jars loaded at runtime. Therefore, we are
> not actually able to enforce an application to be signed entirely by one signer.
>
> The application may initially be signed entirely (i.e. all resources/archives specified have a
> common signer) but then as classes are loaded at runtime (e.g. via manifest classpath), these are
> not verified along with the original jars. A new JarCertVerifier is used to verify each set.
>
> I used an instance var per JNLPClassLoader to keep track of all the jars verified thus far. Each
> JNLPClassLoader keeps track of its own app's jars so when JNLP extensions are specified, a new
> JNLPClassLoader is created. This ensures there can be separate signers between different JNLPs.
>
> The current method to determine if a jar is signed completely was to check against
> JarCertVerifier#anyJarSigned. This method is somewhat flawed. If any single entry is signed then
> this method returns true. However, if one entry of a jar is signed and another unsigned, then the
> jar is considered unsigned, as is the app as a whole. Therefore, I have included
> JarCertVerifier#isFullySigned in the conditional as well to ensure the app is in fact fully signed.
>
> Another change is the removal of permission checking of nested jars. If the entry of the nested jar
> is signed, then we should assume that the person signing the jar trusts it to do whatever it must.
> The nested jar is given the same security context as its parent jar.
>


> I've extensively tested this against a combination of singed/unsigned entries in

Please share those reproducers. They have to be tracked for regression.

> resource/archive-specified/nested/manifest-classpath/extension jars using JNLPs, the applet tag,
> javaws and jnlp_href, as well as many duplicate jars. I have also run through all the regression

I think this changset do not belongs to 1.1. What is motivation for do so?

> tests for HEAD, 1.2 and 1.1, everything ran fine.
>



^ This is true reason of my reply. This changeset will need bunch of reproducers. They will be 
better even before the push of this changeset so I will be able to track they fix.

Sorry for adding more work but it is really necessary.

Also when I walked through code of JarCertVerifier, it looks like easily to be tempted by unnit 
tests. What do you think?


Thanx again, J.