[xmlsec] upgrade to CentOS7

Aleksey Sanin aleksey at aleksey.com
Fri Jun 9 18:28:19 PDT 2017 

Yeah, that's the downside of the old compilers that didn't have
size_t and now it can not be easily changed w/o breaking ABI
compatibility (there is a comment about that in the code :) ).

Anyway, glad you figured it out. I hope you can pass it to
your coworker as well :)

Best,

Aleksey

On 6/9/17 4:32 PM, Russell Beall wrote:
> Thanks!  This provided more progress.  I was able to compile a working
> example from the examples directory and change DES to AES in that same
> example file.  That worked when using the locally compiled installation.  
> 
> After a lot of experimentation and working back and forth with the
> system default installation as well as the locally compiled one, I was
> finally able to narrow it down to just one of the options suggested by
> the example compile which also ended up making the RPM version also
> work.  I also found and noted that the recommended options are listed in
> the file
> /usr/lib64/xmlsec1Conf.sh
> 
> Given the particular type of bad behavior I was experiencing, this
> option does make sense.  The option was:
> -DXMLSEC_NO_SIZE_T
> 
> It is unclear to me why that option is needed because there is a size_t
> type in the system.  But the xmlsec code and configure script looks like
> it wants this specifically to be sizeof = 4 but size_t has a sizeof = 8.
> 
> So obviously it would be bad if the libraries were compiled
> with xmlSecSize = 4 but my code tried to compile with xmlSecSize = 8.
>  That would easily cause a mismatch in the location of the result fields
> in the encCtx structure.
> 
> I guess there is a dependency on 4 byte size which makes it not possible
> to just use size_t directly on whatever architecture you’re on?
> 
> Thanks again for pointing me in the right directions!
> Regards,
> Russ.
> 
>> On Jun 8, 2017, at 7:15 PM, Aleksey Sanin <aleksey at aleksey.com
>> <mailto:aleksey at aleksey.com>> wrote:
>>
>> Great, this tells us that this is compiler or linker issue: xmlsec
>> tool compiles with exactly the same flags as the library itself.
>>
>> Can you try to compile the examples/ folder? Do the examples work as
>> expected? If yes then can you try to compile your program with the
>> same gcc flags? Another option is to try pkg-config (if you have it
>> installed).
>>
>> Aleksey
>>
>> On Jun 8, 2017, at 7:11 PM, Russell Beall <beall at usc.edu
>> <mailto:beall at usc.edu>> wrote:
>>
>>> 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=>
>>>
>

More information about the xmlsec mailing list