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]