[xmlsec] extended character set encryption/decryption

Russell Beall beall at usc.edu
Mon Apr 1 11:12:49 PDT 2013


I have a question about how to work with this library when dealing with extended characters.

I recently upgraded from old versions of libxml and libxmlsec.
libxml 2.6.9 --> 2.7.7
libxmlsec 1.2.5 --> 1.2.16

We are using a fairly boilerplate copy of the recipe for encrypting the xml and then decrypting it on the other end of the communication line.  The old version of these libraries would refrain from converting the XML encoding of characters.  The new version of these libraries seems to be translating these encodings back to their wide character format, and this then crashes the system.

What I would like to do, is figure out which API flag can be used to retain the encoding.  Possibly I also need to switch to wchar buffers or something else, because calling free on the regular buffer seems to corrupt memory.

For instance, if a section of the XML has this:

before going into xmlsec it gets translated into this by a perl function:

At the top of the xml block, I tried specifying an encoding of "US-ASCII" and I was hoping this would keep the libraries from converting it back.  I need the encoding to stay in place because it needs to be converted only at the final destination code.  I tried also setting "US-ASCII" as the encoding value on the call to xmlSecTmplEncDataCreate, but no matter what value I set on that field, even an invalid one, it doesn't seem to change the behavior.

I'm hoping someone on this list can help me with a clue to point me in the right direction.

It would also be very good to get a pointer to the documentation that specifies how to set a value for the xmlChar options, and what options are accepted.  I searched through lots of documentation at:

and found no reference on how to configure those options, just that they existed and expected some value in an xmlChar.


Russell Beall
Systems Programmer IV
Enterprise Identity Management
University of Southern California
beall at usc.edu<mailto:beall at usc.edu>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20130401/64b74166/attachment.html>

More information about the xmlsec mailing list