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
