Ok. Thanks very much for taking the time to help. Regards, Russ.
On Apr 1, 2013, at 3:22 PM, Aleksey Sanin <[email protected]> wrote: > This parser error doesn't look good. I would report it to libxml2 > maintenanerce. > > Aleksey > > On 4/1/13 3:03 PM, Russell Beall wrote: >> Ok. >> >> Maybe the code I used to use will still work for this, but when I upgraded >> the libraries, I had to switch from >> xmlSecEncCtxDecrypt >> to >> xmlSecEncCtxDecryptToBuffer >> >> This was because decrypting packets like below produces a document error, >> perhaps within libxml: >> Entity: line 4: parser error : internal error >> <USCID>5843020612</USCID> >> ^ >> func=xmlSecReplaceNodeBufferAndReturn:file=xmltree.c:line=573:obj=unknown:subj=xmlParse >> InNodeContext:error=5:libxml2 library function failed:Failed to parse content >> func=xmlSecEncCtxDecrypt:file=xmlenc.c:line=648:obj=unknown:subj=xmlSecReplaceNodeBuffe >> r:error=1:xmlsec library function failed:node=EncryptedData >> >> This happened regardless of extended character sets. >> >> Previously I would decrypt to a document and then do an xmlDocDumpMemory to >> get the data. >> >> Does this ring any kind of a bell? >> >> Maybe I need to run another upgrade of libxml or libxmlsec? >> >> Thanks, >> Russ. >> >> On Apr 1, 2013, at 2:04 PM, Aleksey Sanin <[email protected]> >> wrote: >> >>> Yes. I am not exactly sure what was the original behavior but this >>> transformation looks correct to me: c14n does replace the entities. >>> >>> Aleksey >>> >>> On 4/1/13 1:40 PM, Russell Beall wrote: >>>> Looks like I spoke too soon. What made it appear to work just now was >>>> actually a fix that my coworker put in place on the receiving end to >>>> re-encode the characters if they showed up unencoded. The change I made >>>> to parse the document differently did not actually maintain the encoding. >>>> >>>> The original request is this: >>>> <?xml version="1.0" encoding="US-ASCII" ?> >>>> <Update> >>>> <Person> >>>> <IDs> >>>> <USCID>5843020612</USCID> >>>> </IDs> >>>> <Multi-KIMRole> >>>> <KIMRole> >>>> <RoleID>xxxáxxx</RoleID> >>>> </KIMRole> >>>> <KIMRole> >>>> <RoleID>xxxöxxx</RoleID> >>>> </KIMRole> >>>> </Multi-KIMRole> >>>> </Person> >>>> </Update> >>>> >>>> running xmllint as you specified generates the following, and converts the >>>> encoded characters back to original: >>>> >>>> $ xmllint --c14n misctest/unicodedevascii.xml >>>> <Update> >>>> <Person> >>>> <IDs> >>>> <USCID>5843020612</USCID> >>>> </IDs> >>>> <Multi-KIMRole> >>>> <KIMRole> >>>> <RoleID>xxxáxxx</RoleID> >>>> </KIMRole> >>>> <KIMRole> >>>> <RoleID>xxxöxxx</RoleID> >>>> </KIMRole> >>>> </Multi-KIMRole> >>>> </Person> >>>> </Update> >>>> >>>> Does this show what you were looking for? >>>> >>>> Thanks, >>>> Russ. >>>> >>>> >>>> ============================== >>>> Russell Beall >>>> Systems Programmer IV >>>> Enterprise Identity Management >>>> University of Southern California >>>> [email protected] >>>> ============================== >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Apr 1, 2013, at 11:34 AM, Aleksey Sanin <[email protected]> wrote: >>>> >>>>> Can you run your file through "xmllint --c14n"? This will tell us if >>>>> the issue is on libxml2 or xmlsec sides. >>>> >>>> >>>> _______________________________________________ >>>> xmlsec mailing list >>>> [email protected] >>>> http://www.aleksey.com/mailman/listinfo/xmlsec >>>> >>> >> >> >> _______________________________________________ >> xmlsec mailing list >> [email protected] >> http://www.aleksey.com/mailman/listinfo/xmlsec >> > _______________________________________________ xmlsec mailing list [email protected] http://www.aleksey.com/mailman/listinfo/xmlsec
