You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@santuario.apache.org by Scott Cantor <ca...@osu.edu> on 2004/11/03 23:10:25 UTC
Change in 1.2RC? Sign/Verify without a parse between them
Hi,
Just testing the RC jarfile recently posted with OpenSAML. Something I just
noted because of how my test was written is that it appears to be harder
(impossible?) to verify a signature if the XML being signed isn't read in
from a DOM.
I used to be able to create a signature over a DOM and fill it in, and then
immediately verify the signature in the normal manner without an intervening
step to dump the XML out and reparse it back in.
I always found that certain objects (KeyInfo in particular) weren't set up
when I did this, but at least the core signature stuff seemed to be in
place. Now I get a crash in the SignedInfo object while verifying because
the reference array is null.
Is this just a completely unsupported idea? I admit it's not perhaps common,
but it's kind of useful for testing.
-- Scott
RE: Change in 1.2RC? Sign/Verify without a parse between them
Posted by Scott Cantor <ca...@osu.edu>.
> This little patch will help your problems, I haven't committed it
> because my current CVS checkout is changed with some work I'm doing
> with SAX signatures, but it should work for you.
> Please test it and when I came back home I'll commit and test
> it in a clean tree.
The patch worked for me.
There may well be other similar issues in the code with un-set members after
signing, because SAML signatures aren't all that advanced, we use as little
functionality as possible.
But this helps me a lot for testing, thanks.
-- Scott
RE: Change in 1.2RC? Sign/Verify without a parse between them
Posted by Scott Cantor <ca...@osu.edu>.
> This little patch will help your problems, I haven't committed it
> because my current CVS checkout is changed with some work I'm doing
> with SAX signatures, but it should work for you.
> Please test it and when I came back home I'll commit and test
> it in a clean tree.
Ok, thanks.
> Well, you are the second guy with the same gripe and perhaps
> I should reconsider it, but till now I'm still thinking it is better
> the way it is right now.
> The xml-sec 1.2 is/will be binary compatible with 1.1 one,
> i.e. if you have something compiled with 1.1 you just change the 1.1 jar
> with 1.2 jar and everything should work fine.
Ok, this was one of my questions. I'm not very experienced with Java, so I
wasn't sure whether it was binary compatible or not, and with Eclipse it's
hard to tell since it's always rebuilding things. I think binary
compatibility is probably ok.
-- Scott
Re: Change in 1.2RC? Sign/Verify without a parse between them
Posted by ra...@r-bg.com.
>
> Sure, it's pasted below, minus some Eclipse junk. The crash is in the
> Manifest.verifyReferences method when it checks the size of the
> references
> array. That array is null, unless you parse the SignedInfo from text
> into a
> DOM. It doesn't get initialized when the signature objects are built
> during
> signing. This is the general issue across the code, it doesn't
> maintain a
> two-way sync between the state of the objects and the DOM fragments so
> that
> you can operate in either "realm" consistently.
>
This little patch will help your problems, I haven't committed it
because my current CVS checkout is changed with some work I'm doing
with SAX signatures, but it should work for you.
Please test it and when I came back home I'll commit and test it in a
clean tree.
Index: Manifest.java
===================================================================
RCS file:
/home/cvs/xml-security/src/org/apache/xml/security/signature/
Manifest.java,v
retrieving revision 1.30
diff -u -r1.30 Manifest.java
--- Manifest.java 25 Sep 2004 19:42:22 -0000 1.30
+++ Manifest.java 9 Nov 2004 10:01:25 -0000
@@ -286,6 +286,10 @@
*/
public boolean verifyReferences(boolean followManifests)
throws MissingResourceFailureException,
XMLSecurityException {
+ if (_referencesEl==null) {
+ this._referencesEl =
XMLUtils.selectDsNodes(this._constructionElement.getFirstChild(),
+ Constants._TAG_REFERENCE);
+ }
if (log.isDebugEnabled()) {
log.debug("verify " +_referencesEl.length + " References");
log.debug("I am " + (followManifests
> While I'm mentioning this, I also noticed a change in the exception
> declaration of the XMLSignature element-based constructor. This
> required me
> to make a code change, because the 1.1 library was declared as
> throwing an
> IOException, which I had to catch, and now it complains that there is
> no
> such exception thrown. I don't know if this is a great idea since it
> breaks
> existing applications without a lot of reason that I can see...
>
> -- Scott
>
Well, you are the second guy with the same gripe and perhaps I should
reconsider it, but till now I'm still thinking it is better the way it
is right now.
The xml-sec 1.2 is/will be binary compatible with 1.1 one, i.e. if you
have something compiled with 1.1 you just change the 1.1 jar with 1.2
jar and everything should work fine.
But it is not near source compatibly with 1.1, this is because a lot of
exceptions that are declared to be thrown in 1.1 are not needed
anymore, and will never be. This is just the change between using some
XPath instructions that throw some exceptions and using its DOM
counterparts that don't throw any exception, or some other changes like
this. I think is better to change the throw signature and tell the
people that the all exceptions will never be thrown again.
Hope it convince you, anyway I'm open to be convinced to declare to
throw something will never be thrown.
Regards,
Raul
http://r-bg.com
RE: Change in 1.2RC? Sign/Verify without a parse between them
Posted by Scott Cantor <ca...@osu.edu>.
> It's little strange but it's also true that it is good for testing. Can
> you post the stacktrace so i can take a look and see if there is something
> we can do about it?
Sure, it's pasted below, minus some Eclipse junk. The crash is in the
Manifest.verifyReferences method when it checks the size of the references
array. That array is null, unless you parse the SignedInfo from text into a
DOM. It doesn't get initialized when the signature objects are built during
signing. This is the general issue across the code, it doesn't maintain a
two-way sync between the state of the objects and the DOM fragments so that
you can operate in either "realm" consistently.
While I'm mentioning this, I also noticed a change in the exception
declaration of the XMLSignature element-based constructor. This required me
to make a code change, because the 1.1 library was declared as throwing an
IOException, which I had to catch, and now it complains that there is no
such exception thrown. I don't know if this is a great idea since it breaks
existing applications without a lot of reason that I can see...
-- Scott
java.lang.NullPointerException
at
org.apache.xml.security.signature.Manifest.verifyReferences(Manifest.java:29
0)
at
org.apache.xml.security.signature.SignedInfo.verify(SignedInfo.java:223)
at
org.apache.xml.security.signature.XMLSignature.checkSignatureValue(XMLSignat
ure.java:591)
at org.opensaml.SAMLSignedObject.verify(SAMLSignedObject.java:323)
at
org.opensaml.SignatureTest$theTest.testSignature(SignatureTest.java:78)
at
org.opensaml.SignatureTest$theTest.access$0(SignatureTest.java:69)
at
org.opensaml.SignatureTest.testSignatureLoop(SignatureTest.java:62)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
Re: Change in 1.2RC? Sign/Verify without a parse between them
Posted by Raul Benito <ra...@r-bg.com>.
> Hi,
>
> Just testing the RC jarfile recently posted with OpenSAML. Something I
> just
> noted because of how my test was written is that it appears to be harder
> (impossible?) to verify a signature if the XML being signed isn't read in
> from a DOM.
>
> I used to be able to create a signature over a DOM and fill it in, and
> then
> immediately verify the signature in the normal manner without an
> intervening
> step to dump the XML out and reparse it back in.
>
> I always found that certain objects (KeyInfo in particular) weren't set up
> when I did this, but at least the core signature stuff seemed to be in
> place. Now I get a crash in the SignedInfo object while verifying because
> the reference array is null.
>
> Is this just a completely unsupported idea? I admit it's not perhaps
> common,
> but it's kind of useful for testing.
>
> -- Scott
It's little strange but it's also true that it is good for testing. Can
you post the stacktrace so i can take a look and see if there is something
we can do about it?
Regards,
p.s-I'm going to be off-net for 10 days so don't expect a lot of answers
from me, but feel free to post issues for 1.2RC.
Raul
http://r-bg.com