2007/1/12, Stepan Mishura <[EMAIL PROTECTED]>:
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.jaragain!)->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".
This workaround can resolve problems related with any security providers.
But I agree this is just a special case, that's exactly why I have concern
on it. And I thought that maybe URLClassLoader should not cache the JarFile
instance until it is fully initiated, but because URLClassLoader is so
widely used, so I need more tests to validate.
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
--
Paulex Yang
China Software Development Labotary
IBM
