You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@santuario.apache.org by "Krzysztof Benedyczak (JIRA)" <ji...@apache.org> on 2010/12/09 21:35:05 UTC

[jira] Commented: (SANTUARIO-253) org.apache.xml.security.utils.resolver.ResourceResolver is not thread safe

    [ https://issues.apache.org/jira/browse/SANTUARIO-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969931#action_12969931 ] 

Krzysztof Benedyczak commented on SANTUARIO-253:
------------------------------------------------

Hi Colm,

I've tested your patch (against 1.4.4 release not against the trunk) - at least statistically it helped. I've got no error after the test which typically caused ~10 of them. Looking at patch: yes, should be ok now. But of course I support your Santuario-254, the current code needs a rewrite (static synchronized is bad, no need to say why).

Can you write me when the fixed release is expected? As I understand from -254 desc. the patch is a short-term solution, which will appear in something before 1.5 release?

Thanks for a quick reaction,
Krzysztof

> org.apache.xml.security.utils.resolver.ResourceResolver is not thread safe
> --------------------------------------------------------------------------
>
>                 Key: SANTUARIO-253
>                 URL: https://issues.apache.org/jira/browse/SANTUARIO-253
>             Project: Santuario
>          Issue Type: Bug
>          Components: Java
>    Affects Versions: Java 1.4.4
>         Environment: Irrelevant - the bug is fully portable.
>            Reporter: Krzysztof Benedyczak
>            Assignee: Colm O hEigeartaigh
>            Priority: Critical
>         Attachments: santuario-253.patch
>
>
> Here are additional details, but hopefully the title is enough.
> My library is using xmlsec to sign and verify xml signatures. Sometimes I get the following exception when invoking DOMXMLSignature.sign():
> javax.xml.crypto.dsig.XMLSignatureException: javax.xml.crypto.URIReferenceException: org.apache.xml.security.utils.
> resolver.ResourceResolverException: Could not find a resolver for URI #SAMLblahblah and Base null
> which is caused by an exception thrown in ResourceResolver.getInstance(Attr uri, String BaseURI) (last line).
> This is clearly a bug as ResolverFragment is a correct resolver for the reported URI (and my implementation is working 99,x% of time).
> I'm pretty sure that cause is in the aforementioned method getInstance(). ResourceResolver maintains a static Vector which is modified at runtime. During initialization (it is a bug but from practical PoV not that severe) and unfortunately also in getInstance() method, what is a problem. When two threads call it the vector might be permuted by first thread when the latter is iterating over it.
> Please notice that it can't be fixed in any code using your library as the method is public and static and also called many times from xmlsec itself. Even if I synchronized each and every call to xmlsec API (forgetting for a moment about terrible performance loss) I'd have no guarantee that other code in my final app won't use your library directly.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.