Error loading libxmlsec

[hafedh-trimeche]

Hi,

Please note this error message when trying to load libxmlsec (1.3.1) using LoadLibrary.

The procedure entry point xmlNanoFTPCleanup could not be located in the dynamic link library D:\DevStudio\xmlsec1-1.3.1-win64\bin\libxmlsec.dll. 

Dependencies are:

capi.dll
legacy.dll
libcrypto-3-x64.dll
libexslt.dll
libssl-3-x64.dll
libxml2.dll
libxmlsec-openssl.dll
libxmlsec.dll
libxslt.dll
loader_attic.dll
padlock.dll

Best regards.

[lsh123]

Are you building the XMLSec library yourself? If not then could you please try the latest build 1.3.2?

[hafedh-trimeche]

Hi,

Please note that these libraries were downloaded from https://www.aleksey.com/xmlsec/download/win64/xmlsec1-1.3.2-win64.zip

Best regards.

[lsh123]

You original question mentions " D:\DevStudio\xmlsec1-1.3.1-win64..."

I just checked and 1.3.2 doesn't have this symbol and 1.3.1 does (this is expected, FTP was disabled between these two versions):

[xmlsec1-1.3.2] $ grep -r xmlNanoFTPCleanup *
grep: libxml2/bin/libxml2.dll: binary file matches
libxml2/include/libxml2/libxml/nanoftp.h:       xmlNanoFTPCleanup       (void);
grep: libxml2/lib/libxml2.lib: binary file matches
grep: libxml2/lib/libxml2_a.lib: binary file matches
grep: libxml2/lib/libxml2_a_dll.lib: binary file matches

[xmlsec1-1.3.1] $ grep -r xmlNanoFTPCleanup *
grep: libxml2/bin/libxml2.dll: binary file matches
libxml2/include/libxml2/libxml/nanoftp.h:       xmlNanoFTPCleanup       (void);
grep: libxml2/lib/libxml2.lib: binary file matches
grep: libxml2/lib/libxml2_a.lib: binary file matches
grep: libxml2/lib/libxml2_a_dll.lib: binary file matches
grep: xmlsec/bin/libxmlsec.dll: binary file matches
grep: xmlsec/bin/libxmlsec.pdb: binary file matches
grep: xmlsec/lib/libxmlsec_a.lib: binary file matches

However, even 1.3.1 should work as long as you link libxml2 as well. This symbol is defined there.

[lsh123]

BTW, if you are loading a dynamic library on Windows that depends on other libraries, then you either need to load all dependencies first, or use SetDllDirectory to ensure that dependencies are resolved correctly. The xmlNanoFTPCleanup symbol might just happen to be the first one that library load can't resolve.

[hafedh-trimeche]

version 1.3.2 used:

The new message is dealing with xmlNanoHTTPCleanup not xmlNanoFTPCleanup:

The procedure entry point xmlNanoHTTPCleanup could not be located in the dynamic link library D:\xmlsec\libxmlsec.dll.

[lsh123]

The new message is dealing with xmlNanoHTTPCleanup not xmlNanoFTPCleanup:

Well, see above. The LoadLibrary can't find dependencies (libxml2 in this case).

[hafedh-trimeche]

[lsh123]

The tool works because it's in the same directory. Please read up about DLL loading process on Windows.

[hafedh-trimeche]

This code is used to locate missing DLLs :

function DllLoad(out Module:TModuleHandle;FileName:string):Boolean;
var
  Ext       : string;
  {$IFDEF MSWINDOWS}
  ErrorMode : UINT;
  LibDir    : string;
  {$ENDIF}
begin
  Module := NULL_MODULEHANDLE;
  Ext    := AnsiUpperCase(ExtractFileExt(FileName));
  {$IFDEF MSWINDOWS}
//  ErrorMode := SetErrorMode(SEM_FAILCRITICALERRORS or SEM_NOALIGNMENTFAULTEXCEPT or SEM_NOGPFAULTERRORBOX or SEM_NOOPENFILEERRORBOX);
  ErrorMode := SetErrorMode(SEM_NOOPENFILEERRORBOX);
  if Ext='' then FileName := FileName+'.dll';
  {$ELSE}
  if Ext='' then FileName := FileName+'.so';
  {$ENDIF}
  try
    {$IFDEF MSWINDOWS}
    if FileExists(LibrarySearchPath+FileName) then FileName := LibrarySearchPath+FileName;
    LibDir := ExtractFileDir(FileName);
    if Pos('\',LibDir)>0 then AddDllDirectory(PChar(LibDir));

    Module := LoadLibraryEx(PChar(FileName),0,LOAD_LIBRARY_SEARCH_DEFAULT_DIRS    or
                                              LOAD_LIBRARY_SEARCH_APPLICATION_DIR or
                                              LOAD_LIBRARY_SEARCH_USER_DIRS       or
                                              LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR    or
                                              LOAD_WITH_ALTERED_SEARCH_PATH
                                              );
    if Module<=32 then Module := LoadLibrary(PChar(FileName));
    if Module<=32 then Module := NULL_MODULEHANDLE;
    {$ELSE}
    Module := dlopen(PChar(FileName),RTLD_NOW);
    {$ENDIF}
  except
    Module := NULL_MODULEHANDLE;
  end;
  Result := (Module<>NULL_MODULEHANDLE);
  if (not Result) then
  begin
    MissedFunctions.Add('Library: '+FileName+' Error: '+SysErrorMessage(GetLastError));
    MissedFunctions.SaveToFile(MissedFunctionsFileName);
  end;
  {$IFDEF MSWINDOWS}
  SetErrorMode(ErrorMode);
  {$ENDIF}
end;

[lsh123]

Well, there is a bug somewhere. You just confirmed with CheckDDL tool that libraries can be loaded and all symbols resolved.

[hafedh-trimeche]

Hi, I used msys2 package https://packages.msys2.org/base/mingw-w64-xmlsec and libraries loaded with no errors but this log generated:

-------XMLSec-------
File         : ../../xmlsec1-1.2.37/src/transforms.c
Line         : 1324
Func         : xmlSecTransformNodeRead
ErrorObject  : 
ErrorSubject : xmlSecTransformIdListFindByHref
Raison       : 1
Msg          : href=http://www.w3.org/2001/04/xmldsig-more#hmac-ripemd160
--------------------

-------XMLSec-------
File         : ../../xmlsec1-1.2.37/src/transforms.c
Line         : 600
Func         : xmlSecTransformCtxNodeRead
ErrorObject  : SignatureMethod
ErrorSubject : xmlSecTransformNodeRead
Raison       : 1
Msg          : 
--------------------

-------XMLSec-------
File         : ../../xmlsec1-1.2.37/src/xmldsig.c
Line         : 668
Func         : xmlSecDSigCtxProcessSignedInfoNode
ErrorObject  : SignatureMethod
ErrorSubject : xmlSecTransformCtxNodeRead
Raison       : 1
Msg          : 
--------------------

and this DSig log:

= SIGNATURE CONTEXT
== Status: unknown
== flags: 0x00000018
== flags2: 0x00000000
== Id: "DSIG-63AF1F267A"
== Key Info Read Ctx:
= KEY INFO READ CONTEXT
== flags: 0x00000000
== flags2: 0x00000000
== enabled key data: all
== RetrievalMethod level (cur/max): 0/1
== TRANSFORMS CTX (status=0)
== flags: 0x00000000
== flags2: 0x00000000
== enabled transforms: all
=== uri: NULL
=== uri xpointer expr: NULL
== EncryptedKey level (cur/max): 0/1
=== KeyReq:
==== keyId: NULL
==== keyType: 0x00000000
==== keyUsage: 0xffffffff
==== keyBitsSize: 0
=== list size: 0
== Key Info Write Ctx:
= KEY INFO WRITE CONTEXT
== flags: 0x00000000
== flags2: 0x00000000
== enabled key data: all
== RetrievalMethod level (cur/max): 0/1
== TRANSFORMS CTX (status=0)
== flags: 0x00000000
== flags2: 0x00000000
== enabled transforms: all
=== uri: NULL
=== uri xpointer expr: NULL
== EncryptedKey level (cur/max): 0/1
=== KeyReq:
==== keyId: NULL
==== keyType: 0x00000001
==== keyUsage: 0xffffffff
==== keyBitsSize: 0
=== list size: 0
== Signature Transform Ctx:
== TRANSFORMS CTX (status=0)
== flags: 0x00000000
== flags2: 0x00000000
== enabled transforms: all
=== uri: NULL
=== uri xpointer expr: NULL
=== Transform: exc-c14n (href=http://www.w3.org/2001/10/xml-exc-c14n#)
=== Transform: membuf-transform (href=NULL)
== SignedInfo References List:
=== list size: 0
== Manifest References List:
=== list size: 0

These DLLs are used:

libcrypto-3-x64.dll
libiconv-2.dll
libltdl-7.dll
liblzma-5.dll
libxml2-2.dll
libxmlsec1-openssl.dll
libxmlsec1.dll
libxslt-1.dll
zlib1.dll

Best regards.

[lsh123]

I am not really sure what do you mean by this log. In general if you are building xmlsec yourself you can run 'make check' or 'nmake check' to verify the functionality. There are quite a lot of tests there. Said that, if you found a bug, then it would be great to share repro steps. The log above is not very helpful.

[hafedh-trimeche]

xmlsec 1.3.3 built.

The DLLs successfully loaded but xmlSecTmplSignatureCreateNsPref raised an Acces Violation.

[lsh123]

Likely see question 2.7 the FAQ:

https://www.aleksey.com/xmlsec/faq.html

[hafedh-trimeche]

Hi,

vcpkg package management version 2023-10-18-27 is used to generate xmlsec1 library version 1.3.1.

The library is successfully loaded and the signature is also successfully generated using xmlSecDSigCtxSign but when attempting to generate a report related to this signature using xmlSecDSigCtxDebugDump, an Acces Violation is raised.

[lsh123]

Sorry missed this question -- check section 2.7 of the faq and if it doesn't help then please post the stack trace.

[hafedh-trimeche]

Hi,

I used xmlsec already compiled under vcpkg (xmlsec 1.3.1#1).

Please refer to this issue post: https://github.com/microsoft/vcpkg/issues/34932

Best regards.

[lsh123]

The stack in this post:

[00007FFBB707912C] __stdio_common_vfprintf + $5C [00007FFBDB107CC0] Unknown function at xmlSecSimpleKeysStoreAdoptKey + $25EB5

indicates that there was some other error beforehand that triggered vfprintf call. This is a strong indication that something else is broken in the build (see section 2.7 of the faq again)

[lsh123]

Closing the bug. I am not really sure what I can do to help here. You can try to use the known good Windows binaries from here:

https://www.aleksey.com/xmlsec/download/win64/

If you have more information on the problem, then please reopen.