Giuseppe D'Angelo via Development wrote: > Innocent users may have their own build scripts that pull OpenSSL 1 and > build Qt against that, without realizing that they're playing with fire. > We should never expose users to insecure defaults, hence the opt-in > flag, and a build error if you ask for autodetection and only OpenSSL 1 > is found.
Why is that Qt's problem? Qt does not and cannot check that all security updates for all dependencies have been applied, even when using a branch supported by upstream, so I do not see why this case would be any different. Especially because not every OpenSSL 1 out there is going to be insecure (due to LTS distros etc.). And neither is every OpenSSL 3 out there going to be secure. (Just because updates are available from upstream does not automatically mean they are going to be installed.) Qt should just use whatever OpenSSL is installed on the system and be done with it. Chances are that any OpenSSL 1 it finds will be from some LTS distro with backported security fixes anyway. And if the OpenSSL in use is actually insecure, that is something purely between upstream (OpenSSL) and downstream (the distro/OS, the application developer, and/or the end user), and hence completely out of the scope of Qt. Same as for any other third- party dependency. As long as Qt does not bundle an insecure OpenSSL, I do not see the issue here. Kevin Kofler -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development