[xmlsec] upgrade to CentOS7

[Aleksey Sanin]

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         : http://www.aleksey.com/xmlsec/
> 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>> 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>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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=DwIDaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=GZq8AbZkmDZnHhY_emMoUA&m=1AGkTwrp5nWha7lyn0bYHX4bM0IttToIxnlHQGKlbKE&s=5ignWrNrPf6_n_D9cghpaTcszAnGOqzkesdtRUVGv1E&e=
>