Gregory Shimansky wrote:
> Hello
> 
> Today I've found the reason of why drlvm currently cannot use jar files 
> signed 
> with jarsigner in classpath. When it is done it throws "SecurityException: 
> K00ec" :) . The reason is that SHA1 provider cannot be found by security API 
> to check the signature.
> 
> It cannot be found because now bootclasspath.properties is taken from 
> classlib 
> and it does not mention bcprov-jdk14-129.jar where this provider should be 
> found. As a workaround this jar file may be added to bootclasspath, but this 
> is not really correct.
> 
> The class of SHA1 provider 
> org.bouncycastle.jce.provider.JDKMessageDigest$SHA1 
> shouldn't really appear in bootclasspath because security provider is an 
> extension and should be loaded by an extension class loader, not bootstrap. 

That's right, the security providers are loaded from the jre/lib/ext
directory by the extensions classloader.

In the classlib build they are put there as 'bcprov.jar'.

See also [1], we may need extra algorithms for verifying signed JARs.

[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/[EMAIL
 PROTECTED]

> This is AFAIK something that drlvm doesn't have in kernel classes at the 
> moment. I think the correct way to fix the problem would be to add one and 
> invoke it somehow... but I don't really know the subtleties of classloader 
> hierarchy so I am not sure how and when it should be invoked.

Hmm, yes that is something that needs fixing.

Note also that specifying -jar to the launcher will invoke
"org.apache.harmony.kernel.vm.JarRunner" by default.

> The workaround like adding bcprov-jdk14-129.jar to bootclasspath is not 
> enough, the directory lib/boot/security has to be copied from classlib as 
> well or security engine cannot find the provider. This is pretty simple to 
> fix I think.
> 
> One more interesting thing is that first after clean rebuild of drlvm I 
> had "SecurityException: K00ec" thrown. But after several incremental rebuilds 
> when I just changed classlib and rebuilt drlvm to copy changed jar files to 
> its deploy directory the exception appeared to have a normal message like
> 
> java.lang.SecurityException: META-INF/TESTKEY.SF has invalid digest for 
> Hello.class in /home/gregory/work/tests/Hello.jar
> 
> So some resources don't appear in drlvm deploy dir by default, but I couldn't 
> find which files make the difference. This is something to be fixed 
> separately.

Yep, that means that the resources are not being copied into the right
place so they are not loaded by the Msg class.

Regards,
Tim


-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to