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
