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

[Michael Van Canneyt]

On Fri, 26 Jun 2020, Wayne Sherman wrote:

> 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)

Oh, you mean the DLL names. 
I thought you meant the version numbers. Yes, this can be changed too.

>>
>> 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"

We'll adapt the mechanism.

>> 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

Maybe, but for backwards compatibility they must be supported in FPC.

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

No worries, 4.0 means we can consider it for the next fix release.
That will be 3.2.2 (even numbers only for releases, odd indicates
development sources)

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

Sure. If you create a patch, upload it to the bugtracker and assign it to me
(or mail here so I can have a look)

Michael.