On 1/4/07, Yang Paulex wrote:
This issue is interesting, because if you tried to load any classes in the
security provider jars by Class.forName(), it fails. But if you invoke the
Security.getProviders() at first, the issue disappears.
After deeper look inside, I found the key is the time at which
o.a.h.security.fortress.Services is loaded, Services will try to load all
security provider classes, if you invoke the Class.forName("some class in
bouncycastle") at first, the stacktrace will look like:
Class.forName()->URLClassLoader->JarFile(bouncycastle.jar
)->JarVerifier->Services->JarFile(bouncycastle.jar again!)->JarVerifier...
Please note that for good reasons, the JarFile instance for bc.jar are
cached by URLClassLoader, so it is reused when Services tries to load
security provider from bc.jar, but unfortunetely when Services returned,
the
internal status of that JarFile instance has been changed, so that NPE is
thrown.
One workaround is to add "Security.getProviders()" to j.u.jar.JarVerifier
's
static init block, so that it is guarenteed that the security providers
will
be loaded before any classes in certified jars are explicitly used. But
I'm
not sure it is the right thing to do. any security gurus to comment?
IMHO the case with BC provider only is just particular case of classloader
bug. As you pointed out URLClassloader caches JarFile instances - so the
problem is that during JarFile object initialization there may be request to
load a class from the same jar-file. For example, the request may be
initiated by a security manager (not by Services class).
So adding to static init block "Security.getProviders()" will resolve
problem only with "bouncycastle.jar".
Thanks,
Stepan.
2007/1/4, Leo Li (JIRA) <[EMAIL PROTECTED]>:
>
> [classlib][security]Class.forName("
> org.bouncycastle.jce.provider.BouncyCastleProvider"); fails while
> org.bouncycastle.jce.provider.BouncyCastleProvider is added as a
security
> provider
>
>
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-2940
> URL: https://issues.apache.org/jira/browse/HARMONY-2940
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Leo Li
> Priority: Critical
>
>
> Here is a testcase:
>
> public void test()
> {
> Class cls = Class.forName("
> org.bouncycastle.jce.provider.BouncyCastleProvider");
> }
>
> Harmony fails.
>
> After digging into it, I found that it is related with bcprov.jar has a
> certificate signed by the signature provided by itself. I tried to
remove
> it signature and move it into the boot directory and it works.
>
> So I recommend to put an unsigned bcprov.jar into the boot directory.
>
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> https://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see:
http://www.atlassian.com/software/jira
>
>
>
--
Paulex Yang
China Software Development Labotary
IBM
--
Stepan Mishura
Intel Enterprise Solutions Software Division
