1.2 C++ release

About 10 days ago Berin mentioned that he was preparing for a 1.2 release. I'm curious how that's progressing. (What I really want to know, of course, is when it might be out.)

RE: Bug in XSCryptCryptoBase64.cpp

To the best of my knowledge this: int b[2] = {0xf0, 0x0f}; int i=0; int t = b[i++] | b[i++]; Will evaluate to t=0xf0 and i=2. /David -Original Message- From: Milan Tomic [mailto:[EMAIL PROTECTED] Sent: 9. marts 2005 07:26 To: security-dev@xml.apache.org Subject: RE: Bug in XSCryptCrypto

RE: Bug in XSCryptCryptoBase64.cpp

Interesting question! I dug around in my parchment scrolls, and it turns out that the ambiguous order of execution goes way back. My ancient K & R says, "expressions involving one of the associative and commutative operators (*, +, &, ^, |) can be rearranged even when parenthesized. In most case

DO NOT REPLY [Bug 33936] New: - XMLSignatureInput.updateOutputStream should not call reset on the inputstream

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33936] - XMLSignatureInput.updateOutputStream should not call reset on the inputstream

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Somone... help... please ...

Hello All,   (Raul, Berin, someone listen to me …)   I have managed to generated the XML DSig and embed it into the required document at the location desired (There is a requirement for the dsig element to be present at a fixed location in the document)   Now when I try to verify the

Re: Somone... help... please ...

Ritesh, leaving the namepaceAware on true and use some ugly XPath like "//*[local-name()='Header']/*[local-name()='SenderInfo']/*[local-name()='SenderID']" will match the node you would have called "//Header/SenderInfo/SenderID" in absence of namespaces. Sadly it matches nodes even in the wrong nam

RE: Somone... help... please ...

javax.xml.parsers.DocumentBuilderFactory dbf = javax.xml.parsers.DocumentBuilderFactory.newInstance(); dbf.setNamespaceAware(true); javax.xml.parsers.DocumentBuilder db = dbf.newDocumentBuilder(); Document signedDoc = db.parse(new java.io.ByteArrayInputStream(signedStr

Re: Somone... help... please ...

Read again :) I can't see an ugly XPath with all that local-name() stuff. In your case it would be: xPath = "//*[local-name()=ParentPrescription]" + "/*[local-name()=pertinentInformation1]" + "/*[local-name()=pertinentPrescription]" + "/*[local-name()=author]" + "/*[local-name()=signatureTe

SOLVED: Re: Somone... help... please ...

/*[local-name()='elementName']-syntax did the trick. Fine! I don't like how the XPaths look either, but at least they match the right nodes. AFAIK the next version of XPath will be somewhat less unwieldy with regard to namespaces, but it may take a while before we can take advantage of the new feat

Re: Somone... help... please ...

Ok, You must put always namespaceAware(true), for fixing your xpath problems is recommended to do something like that: Element nscontext = XMLUtils.createDSctx(doc, "ds", Constants.SignatureSpecNS); //retrieve the signature Element

DO NOT REPLY [Bug 33936] - XMLSignatureInput.updateOutputStream should not call reset on the inputstream

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Xalan initialization changed.

Hi, I have just commit in CVS, some changes the way xalan is initialized and used. Before this, xalan was initialized(register the FuncHere function, etc...) at Init.init() and used to search the Elements to sign/verify in IdResolver. Now, after the changes xalan is only initialized the first ti

DO NOT REPLY [Bug 33936] - XMLSignatureInput.updateOutputStream should not call reset on the inputstream

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33936] - XMLSignatureInput.updateOutputStream should not call reset on the inputstream

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

RE: Xalan initialization changed.

> I want to known, If someone experiments any performance change(either > increase or decrease) or any error with the changes. And this is > target for Scott if it is now possible to run xml-sec cvs in java 1.5 > without xalan(not doing any xpath transformation of course). Thanks, Raul, I will de

RE: Xalan initialization changed.

No luck so far. When I try it with 1.5, I get this trace (leaving out the parts before this library starts up): java.lang.NoClassDefFoundError: org/apache/xml/utils/PrefixResolver at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:164) at org.a

Problems with XMLDSIG on JWSDP 1.3

Hi, I am currently having problems with producing a valid XMLDSIG signature on JWSDP. First I wrote signing and verifying handlers for Axis and had no problems. I then ported this implementation to JWSDP 1.3 - for a client. When I sign then verify the server verification succeeds. However the XMLD