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
Re: OpenSSL 3.0 is in the tree
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. -- Guido Falsi
Re: OpenSSL 3.0 is in the tree
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. Thanks for your work, Rainer
Re: OpenSSL 3.0 is in the tree
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 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, -- Pierre Pronchery
Re: OpenSSL 3.0 is in the tree
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! -- Guido Falsi
Re: OpenSSL 3.0 is in the tree
On 24/06/23 16:47, Dimitry Andric wrote: On 24 Jun 2023, at 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. Regarding affected ports, see also the llvm-16-update exp-run bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271047 and similarly, the openssl 3.0 exp-run bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271656 Hi, Thanks for your work on this, I understand and appreciate the importance of getting OpenSSL 3 in the tree. I am trying to uupdate to the new head with openssl 3 and am observing something I did not expect. Some ports are building fine but then failing at runtime. For example, security/pam_ssh_agent_auth fails at runtime when trying to use sudo (which uses this library via pam): in try_dlopen(): /usr/local/lib/pam_ssh_agent_auth.so: (null): Undefined symbol "RSA_generate_key" I see RSA_generate_key is deprecated, but should still be present in the library, I'm guessing there is some define or compile option I could enable in the port to make it work, but I'm failing to find the correct solution. Any help appreciated. Anyway in general be warned that things are also failing at runtime in unexpected ways! -- Guido Falsi
Re: OpenSSL 3.0 is in the tree
On 24 Jun 2023, at 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. Regarding affected ports, see also the llvm-16-update exp-run bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271047 and similarly, the openssl 3.0 exp-run bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271656 -Dimitry signature.asc Description: Message signed with OpenPGP
OpenSSL 3.0 is in the tree
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.
