On 5/25/2023 2:11 AM, Tomas Mraz wrote:
It requires to have the openssl built and installed in a way so the legacy
provider is loadable.
The easiest way to do that is to place the legacy provider DLL in the
same directory as openssl.exe and then use:
openssl ... -provider-path=. -legacy
The '.' will be used in the context of the location of the main
executable wherever it is located on the system.
A hardcoded default path for providers is applied at compile time, which
is probably done for security reasons. Since this bypasses the default
Windows DLL loader search path when loading providers, the use of the
-provider-path option on Windows when loading the legacy provider DLL is
necessary in nearly all cases.
The default Windows DLL loader search mechanism includes looking in the
main executable directory when loading a DLL:
https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order
"7. The folder from which the application loaded."
IMO, the provider loader should first attempt to load the provider DLL
from a user defined -provider-path (if supplied), then the same
directory as the executable (Windows only?), and finally the hardcoded
compile time path. Doing so would be more in line with how Windows
naturally functions, not likely introduce any major security issues
(i.e. not load rogue DLLs), and avoid having to specify -provider-path
on the command line to access the legacy provider.
--
Thomas Hruska
Shining Light Productions
Home of BMP2AVI and Win32 OpenSSL.
https://www.slproweb.com/
