Re: OpenSSL 3.0 is in the tree

Am 03.07.23 um 16:53 schrieb Guido Falsi:
> On 03/07/23 15:27, Rainer Hurling wrote:
>> Am 29.06.23 um 18:27 schrieb Pierre Pronchery:
>>>          Hi Guido, freebsd-current@,
>>>
>>> On 6/29/23 15:14, Guido Falsi wrote:
>>>> On 24/06/23 16:22, Ed Maste wrote:
>>>>> Last night I merged OpenSSL 3.0 to main. This, along with the update
>>>>> to Clang 16 and other recent changes may result in some challenges
>>>>> over the next few days or weeks for folks following -CURRENT, such as
>>>>> ports that need to be updated or unanticipated issues in the base
>>>>> system.
>>>>>
>>>>> We need to get this work done so that we can continue moving on with
>>>>> FreeBSD 14; I apologize for the trouble it might cause in the short
>>>>> term. Please follow up to report any trouble you encounter.
>>>>
>>>> Not sure where to ask this, following up to this announcement looks 
>>>> like a reasonable choice.
>>>>
>>>> After updating head to this version I have had some ports provided 
>>>> software fail with messages including: "Unable to load legacy 
>>>> provider."
>>>>
>>>> Most of the time I am able to workaround it by forcing newer 
>>>> algorithms via some configuration. Some other times I have no direct 
>>>> control of what is being asked (like values hardcoded in npm modules)/
>>>>
>>>> This is also happening to me with node, for example, has happened 
>>>> with RDP (looks like windows by default prefers RC4 for RDP 
>>>> sessions), where I was able to fix it though.
>>>>
>>>> Question is, does FreeBSD provide this legacy provider module? Or is 
>>>> it available via ports or some other solution? Or maybe it can be 
>>>> provided via a port? Would make the transition much easier!
>>>
>>> The legacy provider module is part of OpenSSL 3.0, it should be 
>>> installed in /usr/lib/ossl-modules/legacy.so alongside fips.so as 
>>> part Iddd
>>> of the base system.
>>>
>>> It's possible that some programs leveraging capsicum will fail to 
>>> load it, if the initialization of legacy algorithms in OpenSSL is 
>>> performed past entering capabilities mode (since it now requires a 
>>> dlopen() to access the module).
>>>
>>> Let me know if you have any additional details regarding issues with 
>>> the module.
>>>
>>> HTH,
>>
>> If this thread is not the appropriate one for my problem, I apologize.
>>
>> I am the maintainer of the graphics/qgis port. Now that my system 
>> 14.0-CURRENT is updated to clang16 and OpenSSL-3.0, I get the 
>> following abort message when starting qgis:
>>
>> #qgis
>> Failed to load Legacy provider
>>
>> Apparently there is now also a problem with the legacy provider here. 
>> As I understand it, QGIS uses the port devel/qca for authorization and 
>> encryption, so it is also possible that devel/qca is not able to 
>> provide the legacy provider. Therefore I have taken kde@ into CC.
>>
>> Please let me know, if you need more information or some testing.
> 
> This is being worked on by Pierre.
> 
> He pointed me to a patch from him, which I tested successfully:
> 
> https://github.com/freebsd/freebsd-src/pull/787
> 
> I'm now running head with this patch and the legacy provider works fine.
> 
> Hope this helps.
> 

I applied the patch. After rebuilding my system, now the legacy provider 
also works fine for me. graphics/qgis starts again and seems to work as 
expected.

Interestingly, when I start QGIS, I now get the following warnings:

Warning: Incompatible version of OpenSSL (built with OpenSSL 1.x, 
runtime version is >= 3.x)
Warning: QSslSocket: cannot call unresolved function d2i_X509
Warning: QSslSocket::connectToHostEncrypted: TLS initialization failed

These warnings disappeared after rebuilding net/qt5-network and 
net/qt5-networkauth :)

Many thanks for the link with the patch!

Best wishes,
Rainer