Open hafedh-trimeche opened 11 months ago
@hafedh-trimeche, Thanks for posting this issue, please provide your detailed error reproduction steps and error logs.
Hi,
Please find this log: xmlsec 1.3.1#1
:00007FFBB708090D ; C:\Windows\System32\ucrtbased.dll
:00007FFBB7036966 ; C:\Windows\System32\ucrtbased.dll
:00007FFBB704E3CA ; C:\Windows\System32\ucrtbased.dll
:00007FFBB704E4C8 ; C:\Windows\System32\ucrtbased.dll
:00007FFBB704F17A ; C:\Windows\System32\ucrtbased.dll
:00007FFBB707912C ; C:\Windows\System32\ucrtbased.dll
:00007FFBD9377CC0 ; D:\xmlsec\libxmlsec1.dll
:00007FFBD9377D30 ; D:\xmlsec\libxmlsec1.dll
:00007FFBD93C525E ; D:\xmlsec\libxmlsec1.dll
uXMLSec.DumpDSigDebug($1E6BCAD38D0)
and this one:
[00007FFBB7036966] Unknown function at ferror + $476
[00007FFBB704E3CA] Unknown function at __p__commode + $DDA
[00007FFBB704E4C8] Unknown function at __p__commode + $ED8
[00007FFBB704F17A] Unknown function at __p__commode + $1B8A
[00007FFBB707912C] __stdio_common_vfprintf + $5C
[00007FFBDB107CC0] Unknown function at xmlSecSimpleKeysStoreAdoptKey + $25EB5
[00007FFBDB107D30] Unknown function at xmlSecSimpleKeysStoreAdoptKey + $25F25
[00007FFBDB15525E] Unknown function at xmlSecSimpleKeysStoreAdoptKey + $73453
[0000000001780B26] uXMLSec.DumpDSigDebug (Line 175, "uXMLSec.pas" + 2) + $14
uXMLSec.DumpDSigDebug is calling:
xmlSecDSigCtxDebugDump(dsigCtx,xmlSecDSigOutput)
Please which sizes 32/64 of time_t & xmlSecSize for the version 1.3.1#1?
According to the documentation, xmlSecSize should have a 64 length (size_t).
core xmlsec and all xmlsec-crypto libraries:
(ABI breaking change) Added support for the [KeyInfoReference Element](https://www.w3.org/TR/xmldsig-core1/#sec-KeyInfoReference).
(ABI breaking change) Switched xmlSecSize to use size_t by default. Use "--enable-size-t=no" configure option ("size_t=no" on Windows) to restore the old behaviour (note that support for xmlSecSize being different from size_t will be removed in the future).
(API breaking change) Changed the key search to strict mode: only keys referenced by KeyInfo are used. To restore the old "lax" mode, set XMLSEC_KEYINFO_FLAGS_LAX_KEY_SEARCH flag on xmlSecKeyInfoCtx or use '--lax-key-search' option for XMLSec command line utility.
(API breaking change) The KeyName element content is now trimmed before key search is performed.
(API breaking change) Disabled FTP support by default. Use "--enable-ftp" configure option to restore it. Also added "--enable-http" and "--enable-files" configure options to control support for loading files over HTTP or locally.
(API/ABI breaking change) Disabled MD5 digest method by default. Use "--enable-md5" configure options ("legacy-crypto" option on Windows) to re-enable MD5.
(ABI breaking change) Added "failureReason" file to xmlSecDSigCtx and xmlEncCtx to provide more granular operation failure reason.
(ABI breaking change) Removed deprecated functions.
Added support for loading keys through [ossl-store](https://www.openssl.org/docs/man3.0/man7/ossl_store.html) interface (e.g. for using keys from an HSM). Also see '--privkey-openssl-store' and '--pubkey-openssl-store ' command line options for XMLSec utility.
Added ability to control transforms binary chunk size to improve performance (see '--transform-binary-chunk-size' command line option for XMLSec utility).
Fixed all potentially unsafe integer conversions and all the other warnings.
Added [XML Signature 1.1 interop (2012)](https://www.w3.org/TR/2012/NOTE-xmldsig-core1-interop-20121113/) and [XML Encryption 1.1 interop (2012)](https://www.w3.org/TR/2012/NOTE-xmlenc-core1-interop-20121113/) tests.
Best regards.
@hafedh-trimeche, My computer is 64 bit and I can build xmlSecport successfully:
printf("sizeof time_t is: %d\n", sizeof(time_t));
output:
sizeof time_t is: 8
@hafedh-trimeche, Does this problem still exist?
Yes it does: xmlsec 1.3.1#2
xmlSec has the latest version 1.3.2, do I need to update it?
Sorry I can't! I'm using VCPKG which automatically generates library. Waiting for the next version. You can check https://github.com/lsh123/xmlsec
I will submit a PR as soon as possible to upgrade xmlSec in vcpkg to 1.3.2. You can test it on your local machine by then.
I don't believe changes in 1.3.2 would resolve this problem. Overall, this looks like one of the two possible issues for me:
@hafedh-trimeche, The latest xmlsec 1.3.4 can solved your issue?
Hello, Even VCPKG updated, xmlsec still at version 1.3.3:
With the same result!
Did you ever check if you call the function with the right argument types, build with the right link lib, run with the right runtime lib?
IIUC the call is coming from pascal (Line 175, "uXMLSec.pas" + 2
). Not sure if there aren't more traps at the language boundary.
xmlSecDSigCtxDebugDump has only two (2) parameters: dsigCtx & output which are pointers. output is open using fopen('xmlSec.log','w') and shouldn't cause problem. It seams that the library doesn't check some null values before dumping related content. The calling convention doesn't matter because the library is a 64 bit one. Best regards.
I used fopen and fclose function statically linked to open and close Log file: https://github.com/tinyBigGAMES/CPas/blob/main/lib/CPas.CRuntime.pas
This exception is raised:
OpenSSL: FATAL
---------------------------
OPENSSL_Uplink(00007FFD4F3DCA38,08): no OPENSSL_Applink
Is there a way to log content to a memory stream (buffer) not to a file?
If you can reproduce the issue with xmlsec command line utility then it would be easier to debug it. Use --print-debug
flag to trigger xmlSecDSigCtxDebugDump usage. As of now, I stand by my comment above about mismatch between headers / compile flags and library version. Using xmlsec command line utility would guarantee that compilation / linking is consistent.
oh I missed it: "I used fopen and fclose function statically linked to open and close Log file". Of course this is going to crash. Welcome to Microsoft runtimes hell. Question 2.7 in the FAQ (https://www.aleksey.com/xmlsec/faq.html).
oh I missed it: "I used fopen and fclose function statically linked to open and close Log file". Of course this is going to crash. Welcome to Microsoft runtimes hell. Question 2.7 in the FAQ (https://www.aleksey.com/xmlsec/faq.html).
Well, runtimes hell is what vcpkg tries to eliminate AFAIU. There are even post-build checks. So I wouldn't be surprised if executables from the ports just work.
But does the user project use the same configuration as the ports?
And does OPENSSL_Applink have a meaning here?
Describe the bug xmlSecDSigCtxDebugDump Acces Violation.
Environment
To Reproduce Steps to reproduce the behavior:
Expected behavior xmlSecDSigCtxDebugDump reports a signature log.