[fpc-devel] OpenSSL v1.1.x DLL loading / Bug 37137

[Wayne Sherman]

On Thu, Jun 25, 2020 at 11:43 PM Michael Van Canneyt
<michael at freepascal.org> wrote:
> >
> > 3) I recommend the newest libraries be tried first, working backwards
> > towards the oldest.
>
> This is already so ? The version numbers are added from new to old ?

The libraries are currently loading in this order:
     First attempt:  ssleay32.dll / libeay32.dll (older names, but not oldest)
     Second attempt (util):  libcrypto-1_1-x64.dll (newest name)
     Third attempt (ssl):  libssl32.dll (oldest name)
     Fourth attempt (ssl):  libssl-1_1-x64.dll (newest name)

They should be tried as pairs in this order (win64 shown):
     1)  libssl-1_1-x64.dll / libcrypto-1_1-x64.dll  (newest)
     2)  ssleay32.dll / libeay32.dll (older)
     3)  libssl32.dll / libeay32.dll (oldest)

On Thu, Jun 25, 2020 at 11:43 PM Michael Van Canneyt
<michael at freepascal.org> wrote:
>
> On Wed, 24 Jun 2020, Wayne Sherman via fpc-devel wrote:
>
> > *Bug Reference:*
> > "OpenSSL v1.1.1 could not loaded on Windows platform"
> > https://bugs.freepascal.org/view.php?id=37137
> > ...
> > 2) There is a problem with the loading.  The DLLs names have to be handled
> > in pairs.  If the first DLL fails to load (crypto/util DLL), then both
> > should be skipped and the next pair tried.  If the second DLL (SSL lib)
> > fails to load, the first one needs to be unloaded and the pair skipped to
> > try the next pair.  Otherwise it is possible to load two DLLs that are not
> > matched versions.
> >
> > Reference master branch code:
> > https://github.com/graemeg/freepascal/blob/master/packages/openssl/src/openssl.pas#L5634
>
> This needs to be checked.

I ran a test.  If a system has a stray file it can cause mismatched
DLLs to load (which could result in strange bugs)
Please see attached image "OpenSSL_dll_loading_screenshot.png"

> > 3) I recommend the newest libraries be tried first, working backwards
> > towards the oldest.
>
> This is already so ? The version numbers are added from new to old ?

The libraries are current loading in this order:
     First attempt:  ssleay32.dll / libeay32.dll (older name pair, but
not oldest)
     Second attempt (util):  libcrypto-1_1-x64.dll (newest name)
     Third attempt (ssl):  libssl32.dll (oldest name)
     Fourth attempt (ssl):  libssl-1_1-x64.dll (newest name)

They should be tried as pairs in this order (Win64 shown):
     1) libssl-1_1-x64.dll / libcrypto-1_1-x64.dll  (newest)
     2) ssleay32.dll / libeay32.dll (older)
     3) libssl32.dll / libeay32.dll (oldest)

> > 4) The bug report says "Fixed in Version: 3.2.0", but that appears to be
> > incorrect.
>
> I have changed that to 4.0

From:  https://www.openssl.org/policies/releasestrat.html
    openssl versions 1.1.0, 1.0.2, 1.0.1, 1.0.0 and 0.9.8 are no
longer supported

So can Windows openssl v1.1 library loading be included in the next
maintenance release (v3.2.1?) instead of waiting for v4.0?

Would you like me to have a go at a revised patch?

Thanks,

Wayne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenSSL_dll_loading_screenshot.png
Type: image/png
Size: 186295 bytes
Desc: not available
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20200626/927fba17/attachment-0001.png>