Aleksey, Thank you for your response. I still have a couple of questions.
You mention that "xmlSecSize was defined as 4 bytes on 64 bit platform for backward compatibility". Is ABI the only backward compatibility issue, or is there some other API-level compatibility that is of concern? What is the intent for xmlSecSize? If ABI wasn't an issue, should it be size_t on 64-bit platforms? Do you believe that if it was defined to size_t on 64-bit platforms that there would be any issues? As a note, on Win64, xmlSecSize is defined to size_t, since the configuration is done via configure.js, not the regular configure script. It does not seem to cause a problem. Finally, I notice in the code, that there is a comment regarding changing the definition of xmlSecSize to a typedef. Presumably that will need to happen in a "significant release" (is that 2.x.x or 1.3.x?). Do you have a potential timeframe for such a change? Thanks, Bill -----Original Message----- From: Aleksey Sanin [mailto:alek...@aleksey.com] Sent: Friday, November 04, 2011 2:03 PM To: Bell, Bill Cc: xmlsec@aleksey.com Subject: Re: [xmlsec] Configuration on 64-bit Linux Hi Bill, You need to define the XMLSEC_NO_SIZE_T flag. If you are using pkg config that comes with xmlsec then it should be defined there. The xmlSecSize was defined as 4 bytes on 64 bit platform for backward compatibility. Unfortunately, I can't simply make it 8 bytes because it will break binary ABI. Aleksey On 11/4/11 12:56 PM, Bell, Bill wrote: > Aleksey, > > I have a question regarding configuration of XML Sec on 64-Bit Linux. > > I have an application that crashes on 64-bit RHEL, it does not crash on other > platforms (32/64-bit Windows, 32-bit RHEL). > > Working Environment: > XMLSec - version 1.2.16 > OpenSSL - 1.0.0a > OS: RHEL5 - 64-bit > Compiler: GCC 4.1.2 > > In debugging the problem, I have determined that the issue is that xmlSecSize > is "unsigned int" in the library, and "size_t" in my application. > I have identified that the source of the problem is the configure script that > correctly detects that size_t is 8 bytes, but then decides to define > XMLSEC_NO_SIZE_T since it isn't 4. > > The problem is that my application is defining xmlSecSize to size_t and thus > the sizes of the structures (in particular xmlSecEncCtx) are computed > differently in the library and in my application code, leading to memory > corruption when I set structure members. > > The line that triggers the problem is line 11793: > if test "$ac_cv_sizeof_size_t" -ne "4" ; then > XMLSEC_DEFINES="$XMLSEC_DEFINES -DXMLSEC_NO_SIZE_T" > fi > > I have searched the archives and I found the following email threads: > [xmlsec] Xmlsec Issue on Linux x86_64, XMLSEC_NO_SIZE_T - > http://www.aleksey.com/pipermail/xmlsec/2007/008006.html > [xmlsec] Crash on Ubuntu - > http://www.aleksey.com/pipermail/xmlsec/2009/008778.html > FW: [xmlsec] Bug on hpux-ia64-64 ? - > http://www.aleksey.com/pipermail/xmlsec/2009/008759.html > > That all seem to be related to 64-bit platforms. Unfortunately, there doesn't > seem to be a clear resolution to the problem in any of these threads. > > Per the question you posed in the first thread, I have checked out the most > recent sources from GIT, and have run autogen.sh. It behaves the same as > 1.2.16. Also, I have looked at the configure script in 1.2.18 and it has the > same test. > > So, my question is: What should be the definition of xmlSecSize on 64-bit > Linux platforms? Should it be "size_t" or "unsigned int"? > > If it should be size_t, I believe that the configure script can be updated to > use: > if test "$ac_cv_sizeof_size_t" -ne "4"&& test "$ac_cv_sizeof_size_t" -ne "8" > ; then > XMLSEC_DEFINES="$XMLSEC_DEFINES -DXMLSEC_NO_SIZE_T" > fi > > The questions in the HPUX thread are interesting ones. It seems like the > reason that the author saw problems in the digest and signature functions is > because of endianness, where the wrong word was getting the result value (the > high-end word that was then truncated). > It looks like the OpenSSL API is a bit inconsistent (perhaps for backward > compatibility). EVP_DigestUpdate() passes a size_t for the size argument, but > EVP_DigestFinal() still passes an "unsigned int *". > So, this leads to another question: Has the XML Sec code been updated to > ensure that the right type is passed to the underlying OpenSSL functions, and > then cast'ed to xmlSecSize when they need to be saved? > If the answer to this is "yes", then it seems like it might be safe to allow > xmlSecSize to be size_t (8-bytes) on 64-bit platforms. > > I appreciate your guidance on how to resolve this issue. > > My preference is to allow xmlSecSize to be size_t so that my internal users > do not need to change anything, but I want to ensure that it is a safe > definition. I do not see any warnings in the build logs, but I would like a > more definite answer. > > Thanks in advance for your help, > Bill > > William Bell > Mentor Graphics Corporation > 720 494-1141 (Office) > > PRIVACY AND CONFIDENTIALITY NOTICE > > This email and any attachments may contain confidential or privileged > information for the sole use of the intended recipient. Any review, reliance > or distribution by others or forwarding without express permission is > strictly prohibited. If you are not the intended recipient, please contact > the sender and delete all copies. > > _______________________________________________ > xmlsec mailing list > xmlsec@aleksey.com > http://www.aleksey.com/mailman/listinfo/xmlsec _______________________________________________ xmlsec mailing list xmlsec@aleksey.com http://www.aleksey.com/mailman/listinfo/xmlsec
