Mailing-List: contact security-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: security-dev@xml.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <8A2519E092F1604484939145D4EDB7C201C1AC37@courriel.ilex-si.com>
From: Julien TAUPIN <julien.taupin@ilex.fr>
To: security-dev@xml.apache.org
Subject: RE: Using XMLSecurity with a JCA provider other than default one
Date: Wed, 28 Sep 2005 10:08:19 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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=E9pertoire d'accueil de l'utilisateur =3D 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 :=20
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 :=20

-----------------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]=20
Envoy=E9 : mardi 27 septembre 2005 15:13
=C0 : 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=20
> position the Sun jarverifier failed when it tries to verify a signed=20
> jar. It seems to be a bug in the sun jarverifier (I use the JRE 1.3 =
and
1.4).
>=20
> So I thought that JCEMapper.setProviderId() method would save me !
>=20
> -----Message d'origine-----
> De : Vishal Mahajan [mailto:vmahajan@amberpoint.com] Envoy=E9 : mardi =
27=20
> septembre 2005 11:51 =C0 : security-dev@xml.apache.org Objet : Re: =
Using=20
> XMLSecurity with a JCA provider other than default one
>=20
> Did you try using the Security.insertProviderAt method?
>=20
> Vishal
>=20
> Julien TAUPIN wrote:
>=20
>=20
>>I thought that the only way to use my own JCA provider was to place =
it=20
>>at the first place of the providers with the following code :
>>
>>     Provider[] providers =3D Security.getProviders();
>>     for(int i=3D0; i<providers.length; i++)
>>     {
>>       Security.removeProvider(providers[i].getName());
>>     }
>>    =20
>>     Provider myProvider =3D null;
>>     Security.addProvider(myProvider);
>>     for(int i=3D0; i<providers.length; i++)
>>     {
>>       Security.addProvider(providers[i]);
>>     }
>>
>>How can I ask XmlSecurity to use an instance of MyProvider without=20
>>executing this code ?
>>
>>For the stack overflow problem it seems that it is a bug in the Sun=20
>>JarVerifier. This one use the default provider to verify the =
signature=20
>>of the archive but if the default provider is not the SUN one, it=20
>>causes the stack overflow exception.
>>
>>-----Message d'origine-----
>>De : Sean Mullan [mailto:Sean.Mullan@Sun.COM] Envoy=E9 : mardi 20=20
>>septembre 2005 22:34 =C0 : security-dev@xml.apache.org Objet : Re: =
Using=20
>>XMLSecurity with a JCA provider other than default one
>>
>>Julien TAUPIN wrote:
>>=20
>>
>>
>>>Hi all,
>>>
>>>Is it possible to use the XML Security API with a JCA / JCE provider =

>>>which is not the default provider.
>>>  =20
>>>
>>
>>Yes.
>>
>>=20
>>
>>
>>>The problem is that I need to use a specific provider but when I=20
>>>define this one as the default provider the jar verifier causes a=20
>>>stack overflow exception.
>>>  =20
>>>
>>
>>Could be a bug but more details are needed.
>>
>>--Sean
>>
>>=20
>>
>=20
>=20