[xmlsec] upgrade to CentOS7

Thu Jun 8 19:11:20 PDT 2017

Well, I guess I’m doing something wrong or my environment is messing things up.  Your command worked just fine:

$ xmlsec1 --decrypt --aeskey ~iamadmin/dev_common/goldenpr/.sorkeys/symkey_GDS encrypted_data.xml
<?xml version="1.0"?>
<Ping/>

Russ.

On Jun 8, 2017, at 6:43 PM, Aleksey Sanin <aleksey at aleksey.com<mailto:aleksey at aleksey.com>> wrote:

Can you try to reproduce this issue with xmlsec1 command line utility?

-- Aleksey

On Jun 8, 2017, at 6:34 PM, Russell Beall <beall at usc.edu<mailto:beall at usc.edu>> wrote:

I must admit I don’t have a lot of practice with C debuggers, so I haven’t examined the structure yet, but I did try upgrading to the latest 1.2.24 as well as downgrading back to 1.2.16.  Both of those versions also exhibit this behavior.  (I deleted entirely the previous version before compiling and linking with the replacement, so I know it was using the expected version).

Then, the next step I took was to boil it down to the most basic possible example.  I downloaded your code from this link:
https://www.aleksey.com/xmlsec/api/xmlsec-decrypt-with-keys-mngr.html#xmlsec-example-decrypt2<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.aleksey.com_xmlsec_api_xmlsec-2Ddecrypt-2Dwith-2Dkeys-2Dmngr.html-23xmlsec-2Dexample-2Ddecrypt2&d=DwMFaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=GZq8AbZkmDZnHhY_emMoUA&m=SR9eFKXsUSQlRXnWYTbZk9hc8HcVeC3gT6Q-9kIWBsE&s=5bcrqz6R-4tkR1Ye02H5nFqfGE97CkzVmv_AfxcsMhI&e=>

changed only the use of DES keys to AES keys.  Dropped my encrypted xml packet in a file and then ran the code with the file and key.  The same exact behavior occurred.  Very odd.  This should now be a vanilla install and Centos7 VM with a vanilla example.

I compiled with this
$ /usr/bin/gcc -I/usr -I/usr/include/libxml2 -I/usr/local/iamadmin/xmlsec/include/xmlsec1 -L/usr/lib64 -L/usr/local/iamadmin/xmlsec/lib -lxmlsec1 -lxmlsec1-openssl -lxslt -lxml2 -lcrypto -DXMLSEC_CRYPTO_OPENSSL decryptstd.c

and ran with this.
$ export LD_LIBRARY_PATH=/usr/local/iamadmin/xmlsec/lib
$ a.out encrypted_data.xml ~iamadmin/dev_common/goldenpr/.sorkeys/symkey_GDS
Error: decryption failed
Decrypted XML data:
<?xml version="1.0"?>
<Ping/>

I also added one print statement within the failure block to print the document anyway despite the failure, and it shows the document was decrypted even though encCtx_>result is null.

I have a coworker who I hear also had this problem with a similar system and hacked around it by just taking the buffer contents from the xmlSecEncCtxDecryptToBuffer function if it isn't null and scanning the original document for the key name.  I’d rather not resort to that if I can use the API as designed.  But he is also more experienced with C debuggers and we could take a look at the encCtx structure when he gets back next week.

Sorry if I’m taking up too much bandwidth on the list.  I hope I’m onto something that will end up being a potentially useful bugfix rather than just missing something stupid.

Regards,
Russ.

=========================
Russell Beall  |  Systems Programmer IV
Enterprise Identity Management | University of Southern California
(213) 740-7221  |  beall at usc.edu<mailto:beall at usc.edu>

On Jun 8, 2017, at 3:53 PM, Russell Beall <beall at usc.edu<mailto:beall at usc.edu>> wrote:

Ok, thanks.  I’ll try those ideas.

Regards,
Russ.

=========================
Russell Beall  |  Systems Programmer IV
Enterprise Identity Management | University of Southern California
(213) 740-7221  |  beall at usc.edu<mailto:beall at usc.edu>

On Jun 8, 2017, at 3:51 PM, Aleksey Sanin <aleksey at aleksey.com<mailto:aleksey at aleksey.com>> wrote:

Hm... next idea is that some compilation flags are different. Basically
what you describe looks like your code is looking at the wrong places
in encCtx struct because it looks different. I would go into debugger
and examine the memory block for encCtx to see how it looks like.

Another approach is to recompile (the lastest) xmlsec version and see
if it solves the problem.

Aleksey

On 6/8/17 3:47 PM, Russell Beall wrote:
Yes, the includes point to /usr/include/xmlsec1 and there is only one
installation of xmlsec on the box installed via yum.

$ yum info xmlsec1
Loaded plugins: auto-update-debuginfo, fastestmirror, langpacks, verify
Loading mirror speeds from cached hostfile
Installed Packages
Name        : xmlsec1
Arch        : x86_64
Version     : 1.2.20
Release     : 5.el7
Size        : 555 k
Repo        : installed
From repo   : base
Summary     : Library providing support for "XML Signature" and "XML
Encryption" standards
URL         : https://urldefense.proofpoint.com/v2/url?u=http-3A__www.aleksey.com_xmlsec_&d=DwIDaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=GZq8AbZkmDZnHhY_emMoUA&m=wlYaqIJM27mvlCJIVYuW4l0Odsgx_qawVLtTbdu2h8I&s=sG2W-Vo4Ho-WqcECYXdPwIh9LaFoEqaKoJjAclYIOQ4&e=
License     : MIT
Description : XML Security Library is a C library based on LibXML2  and
OpenSSL.
           : The library was created with a goal to support major XML
security
           : standards "XML Digital Signature" and "XML Encryption”.

There may be a potential conflict with gsoap where the python and soap
libraries seem to be clashing on defines.  These may be affecting the
internals:
/usr/include/python2.7/pyconfig-64.h:1188:0: warning: "_POSIX_C_SOURCE"
redefined [enabled by default]
#define _POSIX_C_SOURCE 200112L

/usr/include/features.h:168:0: note: this is the location of the
previous definition
# define _POSIX_C_SOURCE 200809L

This is a python plugin that receives encrypted XML packets via gsoap.

Regards,
Russ.

On Jun 8, 2017, at 2:25 PM, Aleksey Sanin <aleksey at aleksey.com<mailto:aleksey at aleksey.com>
<mailto:aleksey at aleksey.com>> wrote:

Hm... Can you make sure the library you are using matches
the header files you are compiling with?

Aleksey

On 6/8/17 1:55 PM, Russell Beall wrote:
Hello,

First, thank you for all the help I’ve seen flowing through this list
over the years.  I haven’t had many questions since our code has just
been sitting there working most of the time, but it has been nice to see
an active community on this product.

I’m working on upgrading to xmlsec 1.2.20 on CentOS 7.  I’m porting a
functioning usage of xmlsec from Solaris using xmlsec 1.2.16.  The
ported code is practically identical to the online tutorial examples,
but for some reason on this updated system, the decryption engine is not
producing the data in the encCtx object, even though it is successfully
decrypting the XML packet.

The output of the document shows this before the decryption:
<?xml version="1.0"?>
<EncryptedData
xmlns="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_2001_04_xmlenc-23&d=DwIDaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=GZq8AbZkmDZnHhY_emMoUA&m=1AGkTwrp5nWha7lyn0bYHX4bM0IttToIxnlHQGKlbKE&s=-Xwog9L_-70gnLriXpRfsfcT53My74h4l9nz4LDiav4&e= "
Type="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_2001_04_xmlenc-23Element&d=DwIDaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=GZq8AbZkmDZnHhY_emMoUA&m=1AGkTwrp5nWha7lyn0bYHX4bM0IttToIxnlHQGKlbKE&s=n7wOqJl6BkmU1WHOR5aNtn18_k1ceTxMSUW1AicxD00&e= ">
<EncryptionMethod
Algorithm="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_2001_04_xmlenc-23aes128-2Dcbc&d=DwIDaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=GZq8AbZkmDZnHhY_emMoUA&m=1AGkTwrp5nWha7lyn0bYHX4bM0IttToIxnlHQGKlbKE&s=dd-dzD0_VFSpcwn_SGNp3aAR9UweqZXV2m2nUcdGaFA&e= "/>
<KeyInfo
xmlns="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_2000_09_xmldsig-23&d=DwIDaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=GZq8AbZkmDZnHhY_emMoUA&m=1AGkTwrp5nWha7lyn0bYHX4bM0IttToIxnlHQGKlbKE&s=nT1UEj-K2M3303ZeBQ8PwTKCzd1dFIQyikCF39ybEqs&e= ">
<KeyName>symkey_GDS</KeyName>
</KeyInfo>
<CipherData>
<CipherValue>N6BDPUv1BIz88n1IL64aTkiShimUMWnZ+c5bVHDMxEs=</CipherValue>
</CipherData>
</EncryptedData>

And shows this after the decryption:
<?xml version="1.0"?>
<Ping/>

But leaves this data in the encCtx object suggesting that the decryption
process did not work:
encCtx->result: 0
encCtx->encKey: 0
encCtx->resultReplaced: 0

Besides needing to see the a non-null result status, I also need a
non-null encKey object so I can pull the name of the key for use later
in encrypting the response packet.

Is there something I’m missing about this?  Or maybe something peculiar
to CentOS 7?  Doesn’t seem like much would have changed between xmlsec
1.2.16 and 1.2.20.

Thanks for any help!
Regards,
Russ.

=========================
*Russell Beall  |  *Systems Programmer IV
Enterprise Identity Management | University of Southern California
(213) 740-7221  |  beall at usc.edu<mailto:beall at usc.edu>
<mailto:beall at usc.edu> <mailto:beall at usc.edu>

_______________________________________________
xmlsec mailing list
xmlsec at aleksey.com<mailto:xmlsec at aleksey.com> <mailto:xmlsec at aleksey.com>
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.aleksey.com_mailman_listinfo_xmlsec&d=DwIDaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=GZq8AbZkmDZnHhY_emMoUA&m=1AGkTwrp5nWha7lyn0bYHX4bM0IttToIxnlHQGKlbKE&s=5ignWrNrPf6_n_D9cghpaTcszAnGOqzkesdtRUVGv1E&e=

_______________________________________________
xmlsec mailing list
xmlsec at aleksey.com<mailto:xmlsec at aleksey.com>
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.aleksey.com_mailman_listinfo_xmlsec&d=DwIGaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=GZq8AbZkmDZnHhY_emMoUA&m=yjzCQdXNzdU8z7n2-FMBCbA5QAGxAtBULB4oD560OoI&s=w9IMkmVCZwki3XkcR0LXk0cALiRv9LLBudmXSXfM_eE&e=

_______________________________________________
xmlsec mailing list
xmlsec at aleksey.com<mailto:xmlsec at aleksey.com>
http://www.aleksey.com/mailman/listinfo/xmlsec<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.aleksey.com_mailman_listinfo_xmlsec&d=DwMFaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=GZq8AbZkmDZnHhY_emMoUA&m=SR9eFKXsUSQlRXnWYTbZk9hc8HcVeC3gT6Q-9kIWBsE&s=hrBUiJ7jBvn1hXwP7td6bOoBkVaWnEGTYZ176W5F_G8&e=>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20170609/476acb38/attachment-0001.html>