[xmlsec] extended character set encryption/decryption
beall at usc.edu
Tue Apr 2 10:52:39 PDT 2013
Same behavior with 2.8. Couldn't get 2.9 to compile (on Solaris 10).
I'll see if I can track it down again. I remember locating it like two years ago and hacking in a patch, but then I didn't want to use the patch/hack, so I reworked the usage of the API. I thought I sent an email about it to the list then, but I can't find it in my sent mail.
I note that separating the API by running xmlSecEncCtxDecryptToBuffer, and then xmlParseMemory on the result of that does not have any parse error. This actually solved my problem as well, because then I can use xmlDocDumpMemoryEnc to force the encoding to US-ASCII so I can get it out of the C++ code and over into the python code where it is parsed and used.
On Apr 1, 2013, at 8:03 PM, Daniel Veillard <veillard at redhat.com>
> On Mon, Apr 01, 2013 at 10:03:44PM +0000, Russell Beall wrote:
>> Maybe the code I used to use will still work for this, but when I upgraded the libraries, I had to switch from
>> This was because decrypting packets like below produces a document error, perhaps within libxml:
>> Entity: line 4: parser error : internal error
>> InNodeContext:error=5:libxml2 library function failed:Failed to parse content
>> 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?
> Honnestly no, this is issued inside libxml2 parser
> I would need some kind of stack trace to understand what is going on
> plus you are still using a relatively old libxml2 version.
>> Maybe I need to run another upgrade of libxml or libxmlsec?
> worth trying, 2.8.x or 2.9.0
> Daniel Veillard | Open Source and Standards, Red Hat
> veillard at redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
> http://veillard.com/ | virtualization library http://libvirt.org/
More information about the xmlsec