Bill,
Yes, at the moment I don't have a timeframe for a next major release
because I don't have any big features planned for development.
Aleksey
On 11/9/11 12:16 PM, Bell, Bill wrote:
Aleksey,
Thanks for the clarifications. They definitely help improve my understanding of
the intent and constraints.
Regarding the "significant release" question, I agree that this issue is not
enough by itself to motivate such a release. I was just curious to know if you already
had other changes planned that would justify such a change. It sounds like you don't, and
that is perfectly reasonable.
Thanks again,
Bill
-----Original Message-----
From: Aleksey Sanin [mailto:[email protected]]
Sent: Tuesday, November 08, 2011 9:50 AM
To: Bell, Bill
Cc: [email protected]
Subject: Re: [xmlsec] Configuration on 64-bit Linux
See answers in line.
Aleksey
On 11/8/11 7:52 AM, Bell, Bill wrote:
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?
[aleksey] Correct. Only ABI is a 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?
[aleksey] There should be no issues if it is defined to size_t
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?
[aleksey] I don't have a timeframe, sorry. There should be enough reasons to
break backward compatibility and this issue alone is not enough.
Thanks,
Bill
-----Original Message-----
From: Aleksey Sanin [mailto:[email protected]]
Sent: Friday, November 04, 2011 2:03 PM
To: Bell, Bill
Cc: [email protected]
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
[email protected]
http://www.aleksey.com/mailman/listinfo/xmlsec
_______________________________________________
xmlsec mailing list
[email protected]
http://www.aleksey.com/mailman/listinfo/xmlsec
