[prev in list] [next in list] [prev in thread] [next in thread]
List: xml-security-dev
Subject: RE: Using XMLSecurity with a JCA provider other than default one
From: Julien TAUPIN <julien.taupin () ilex ! fr>
Date: 2005-09-28 8:08:19
Message-ID: 8A2519E092F1604484939145D4EDB7C201C1AC37 () courriel ! ilex-si ! com
[Download RAW message or body]
I post the traces :
The problem of the stack overflow comes only with the JRE 1.3 (and the JCE
classes in an additionnal jar as it is included in the JRE only since 1.4).
There is a stackoverflow because the process come into a vicious circle.
That's why the trace are not complete : there is no other end than killing
the.
I add the traces for the problem in 1.4
JRE 1.3 (plugin with Internet Explorer)
-----------------BEGIN TRACE ----------------
Plug-in Java(TM): Version 1.3.1_08
Utilisation de la version JRE 1.3.1_08 Java HotSpot(TM) Client VM
Répertoire d'accueil de l'utilisateur = C:\Documents and Settings\services
Configuration du proxy : Configuration manuelle
Proxy : proxy2:8080
Remplacement du proxy : jtau-xp,<local>
----------------------------------------------------
c: clear console window
f: finalize objects on finalization queue
g: garbage collect
h: display this help message
l: dump classloader list
m: print memory usage
q: hide console
s: dump system properties
t: dump thread list
x: clear classloader cache
0-5: set trace level to <n>
----------------------------------------------------
Providers list :
MyProvider
SUN
SunRsaSign
SunJCE
java.lang.StackOverflowError
at java.lang.Exception.<init>(Unknown Source)
at java.lang.ClassNotFoundException.<init>(Unknown Source)
at java.lang.ClassLoader.findBootstrapClass(Native Method)
at java.lang.ClassLoader.findBootstrapClass0(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.security.Security.getImpl(Unknown Source)
at java.security.MessageDigest.getInstance(Unknown Source)
at sun.security.util.ManifestEntryVerifier.setEntry(Unknown Source)
at java.util.jar.JarVerifier.beginEntry(Unknown Source)
at java.util.jar.JarVerifier$VerifierStream.<init>(Unknown Source)
at java.util.jar.JarFile.getInputStream(Unknown Source)
at sun.misc.URLClassPath$4.getInputStream(Unknown Source)
at sun.misc.Resource.getBytes(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$100(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.security.Security.getImpl(Unknown Source)
at java.security.MessageDigest.getInstance(Unknown Source)
at sun.security.util.ManifestEntryVerifier.setEntry(Unknown Source)
at java.util.jar.JarVerifier.beginEntry(Unknown Source)
at java.util.jar.JarVerifier$VerifierStream.<init>(Unknown Source)
at java.util.jar.JarFile.getInputStream(Unknown Source)
at sun.misc.URLClassPath$4.getInputStream(Unknown Source)
at sun.misc.Resource.getBytes(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$100(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.security.Security.getImpl(Unknown Source)
at java.security.MessageDigest.getInstance(Unknown Source)
-----------------END TRACE ----------------
With JRE 1.4 :
-----------------BEGIN TRACE ----------------
java.lang.ExceptionInInitializerError
at javax.crypto.Cipher.a(DashoA6275)
at javax.crypto.Cipher.getInstance(DashoA6275)
at
com.MyCryptoProvider.initializeXML(MyCryptoProvider.java:158)
at test.TestXMLEnc.<clinit>(TestXMLEnc.java:104)
Caused by: java.lang.SecurityException: Cannot set up certs for
trusted CAs
at javax.crypto.SunJCE_b.<clinit>(DashoA6275)
... 4 more
Caused by: java.lang.SecurityException: Jurisdiction policy files
are not signed by trusted signers!
at javax.crypto.SunJCE_b.f(DashoA6275)
at javax.crypto.SunJCE_b.e(DashoA6275)
at javax.crypto.SunJCE_s.run(DashoA6275)
at java.security.AccessController.doPrivileged(Native
Method)
-----------------END TRACE ----------------
-----Message d'origine-----
De : Sean Mullan [mailto:Sean.Mullan@Sun.COM]
Envoyé : mardi 27 septembre 2005 15:13
À : security-dev@xml.apache.org
Objet : Re: Using XMLSecurity with a JCA provider other than default one
Can you send me the relevant part of the stack overflow trace? I am curious
about this problem but I need to see more details.
Thanks,
Sean
Julien TAUPIN wrote:
> Yes but the problem is that if I place my Provider on the first
> position the Sun jarverifier failed when it tries to verify a signed
> jar. It seems to be a bug in the sun jarverifier (I use the JRE 1.3 and
1.4).
>
> So I thought that JCEMapper.setProviderId() method would save me !
>
> -----Message d'origine-----
> De : Vishal Mahajan [mailto:vmahajan@amberpoint.com] Envoyé : mardi 27
> septembre 2005 11:51 À : security-dev@xml.apache.org Objet : Re: Using
> XMLSecurity with a JCA provider other than default one
>
> Did you try using the Security.insertProviderAt method?
>
> Vishal
>
> Julien TAUPIN wrote:
>
>
>>I thought that the only way to use my own JCA provider was to place it
>>at the first place of the providers with the following code :
>>
>> Provider[] providers = Security.getProviders();
>> for(int i=0; i<providers.length; i++)
>> {
>> Security.removeProvider(providers[i].getName());
>> }
>>
>> Provider myProvider = null;
>> Security.addProvider(myProvider);
>> for(int i=0; i<providers.length; i++)
>> {
>> Security.addProvider(providers[i]);
>> }
>>
>>How can I ask XmlSecurity to use an instance of MyProvider without
>>executing this code ?
>>
>>For the stack overflow problem it seems that it is a bug in the Sun
>>JarVerifier. This one use the default provider to verify the signature
>>of the archive but if the default provider is not the SUN one, it
>>causes the stack overflow exception.
>>
>>-----Message d'origine-----
>>De : Sean Mullan [mailto:Sean.Mullan@Sun.COM] Envoyé : mardi 20
>>septembre 2005 22:34 À : security-dev@xml.apache.org Objet : Re: Using
>>XMLSecurity with a JCA provider other than default one
>>
>>Julien TAUPIN wrote:
>>
>>
>>
>>>Hi all,
>>>
>>>Is it possible to use the XML Security API with a JCA / JCE provider
>>>which is not the default provider.
>>>
>>>
>>
>>Yes.
>>
>>
>>
>>
>>>The problem is that I need to use a specific provider but when I
>>>define this one as the default provider the jar verifier causes a
>>>stack overflow exception.
>>>
>>>
>>
>>Could be a bug but more details are needed.
>>
>>--Sean
>>
>>
>>
>
>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic