Bug#971367: [debian-mysql] Bug#971367: Bug#971367: Bug#971367: mariadb-10.5 should not embed wolfssl
Great news! My faith in humanity and the victory of sanity has been restored. I've now pushed on mariadb-10.5 master the necessary changes in https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/ca2574aa88434d1c49456c677b7dcb904902daaf I will keep this issue open, and start excluding extras/wolfssl in the gbp.conf next time I import a new upstream (instead of the d/rules hack done now).
Bug#971367: [debian-mysql] Bug#971367: Bug#971367: Bug#971367: mariadb-10.5 should not embed wolfssl
On Wed, Sep 30, 2020 at 08:09:10PM +0300, Otto Kekäläinen wrote: > Control: forwarded -1 https://jira.mariadb.org/browse/MDEV-21835 > > Note that the upstream MariaDB uses OpenSSL both for building the > server and the client. In Debian OpenSSL is forbidden in the current > state (or so has e.g. Clint Byrum stated), so in Debian we build using > alternatives, which for the server means GnuTLS and for the client > WolfSSL (former YaSSL). > > The long term solution is to wait for OpenSSL 3.0 to be released and > build against it (as it has no license issues). The short term > solution is to hope for upstream to add support for building the > client with the system WolfSSL library. Hi Otto, FTP masters changed their assessment on treating OpenSSL as a system library, see the FTP meeting log at http://meetbot.debian.net/debian-ftp/2020/debian-ftp.2020-03-13-20.02.html and the followup discussion at https://lists.debian.org/debian-devel/2020/10/msg00165.html As such, you can switch to OpenSSL without needing to wait for OpenSSL 3.0 \o/ Cheers, Moritz
Bug#971367: [debian-mysql] Bug#971367: Bug#971367: Bug#971367: mariadb-10.5 should not embed wolfssl
On Wed, Sep 30, 2020 at 08:09:10PM +0300, Otto Kekäläinen wrote: > Control: forwarded -1 https://jira.mariadb.org/browse/MDEV-21835 > > Note that the upstream MariaDB uses OpenSSL both for building the > server and the client. In Debian OpenSSL is forbidden in the current > state (or so has e.g. Clint Byrum stated), so in Debian we build using > alternatives, which for the server means GnuTLS and for the client > WolfSSL (former YaSSL). > > The long term solution is to wait for OpenSSL 3.0 to be released and > build against it (as it has no license issues). The short term > solution is to hope for upstream to add support for building the > client with the system WolfSSL library. Fair enough, removing RC severity here. Cheers, Moritz
Bug#971367: [debian-mysql] Bug#971367: Bug#971367: Bug#971367: mariadb-10.5 should not embed wolfssl
On Wed, 30 Sep 2020 20:09:10 +0300 =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?= wrote: > Control: forwarded -1 https://jira.mariadb.org/browse/MDEV-21835 > > Note that the upstream MariaDB uses OpenSSL both for building the > server and the client. In Debian OpenSSL is forbidden in the current > state (or so has e.g. Clint Byrum stated), so in Debian we build using > alternatives, which for the server means GnuTLS and for the client > WolfSSL (former YaSSL). > > The long term solution is to wait for OpenSSL 3.0 to be released and > build against it (as it has no license issues). The short term > solution is to hope for upstream to add support for building the > client with the system WolfSSL library. Or just ignore the alleged OpenSSL issue and simply use the system libssl. It's a home-made problem by Debian and not everyone agrees that this OpenSSL licensing issue is actually valid. I opted to do that e.g. in librelp, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951911 Regards, Michael signature.asc Description: OpenPGP digital signature
Bug#971367: [debian-mysql] Bug#971367: Bug#971367: Bug#971367: Bug#971367: mariadb-10.5 should not embed wolfssl
Correction to the previous email: The server builds (apparently statically) with WolfSSL while the client uses GnuTLS (dynamically): # mariadb -Bse 'SHOW VARIABLES' | grep -e version_ssl_library version_ssl_library WolfSSL 4.4.0 # ldd $(which mariadbd) | grep -e crypt -e tls -e ssl libcrypt.so.1 => /usr/lib/x86_64-linux-gnu/libcrypt.so.1 (0x7fc6c7d92000) libgcrypt.so.20 => /usr/lib/x86_64-linux-gnu/libgcrypt.so.20 (0x7fc6c755200 # ldd $(which mariadb) | grep -e crypt -e tls -e ssl libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (0x7f11defad000) Ref: - https://mariadb.com/kb/en/ssltls-system-variables/#version_ssl_library - https://mariadb.com/kb/en/tls-and-cryptography-libraries-used-by-mariadb/ - https://mariadb.com/kb/en/secure-connections-overview/
Bug#971367: [debian-mysql] Bug#971367: Bug#971367: Bug#971367: mariadb-10.5 should not embed wolfssl
Control: forwarded -1 https://jira.mariadb.org/browse/MDEV-21835 Note that the upstream MariaDB uses OpenSSL both for building the server and the client. In Debian OpenSSL is forbidden in the current state (or so has e.g. Clint Byrum stated), so in Debian we build using alternatives, which for the server means GnuTLS and for the client WolfSSL (former YaSSL). The long term solution is to wait for OpenSSL 3.0 to be released and build against it (as it has no license issues). The short term solution is to hope for upstream to add support for building the client with the system WolfSSL library.
Bug#971367: mariadb-10.5 should not embed wolfssl
On Tue, Sep 29, 2020 at 02:57:48PM +0200, Helmut Grohne wrote: > Source: mariadb-10.5 > Version: 1:10.5.5-1 > Tags: security > Severity: serious > Justification: unsupportable by the Debian security team > > Hi Otto, > > I've hinted that the situation about an embedded ssl library might be > suboptimal earlier. Since then, I've checked (using the buildd logs) > that indeed mariadb does build an embedded copy of wolfssl. I've also > checked with the Debian security team (Moritz Muehlenhoff in > particular). Such an embedding is unsupportable by the security team. Actually when I saw this in IRC, I thought the "-DWITH_SSL=bundled" referred to MariaDB 10.5 having switched to a bundled version of OpenSSL. Historically mariadb/mysql has always used a bundled copy of yassl (now named wolfssl), so not switching to the shared src:wolfssl is not a regression over the status quo in buster. But by all means if we can find a way to fix the build to use the system-wide WolfSSL, let's do it. Cheers, Moritz
Bug#971367: [debian-mysql] Bug#971367: Bug#971367: mariadb-10.5 should not embed wolfssl
Hello! > Thank you for the background. Let me detail on the security side. The > issue is not with using wolfssl. The issue is with using a bundled ssl > library. Doing so means that a single bug in wolfssl must be uploaded > several times in order to fix it. I think it would be ok to use the > system copy of wolfssl. However, that's not what happens when you > specifcy -DWITH_SSL=system it seems. Would > -DWITH_SSL=/usr/include/wolfssl be an option? > > Does that look resolvable now? I've tested this before and it didn't work, but I tested it again and made sure to document it in the same upstream issue I referenced earlier: https://jira.mariadb.org/browse/MDEV-21835?focusedCommentId=167192=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-167192 Seems the cmake/ssl.cmake expects to find OpenSSL then given a custom path, and when it does not, it aborts the build in the configure stage.
Bug#971367: [debian-mysql] Bug#971367: mariadb-10.5 should not embed wolfssl
On Tue, Sep 29, 2020 at 03:24:52PM +0100, Robie Basak wrote: > The relevant previous bug is > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921488 where the > packaging switched from "system" to "bundled". Switching back to > "system" would regress that licensing problem. > > Also relevant is > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924937 which is the > same situation but for Postgres. > > I don't know how to resolve this conflict between Debian's security > position and Debian's licensing position, but hopefully the above > references provide some background to help someone else figure this out. Thank you for the background. Let me detail on the security side. The issue is not with using wolfssl. The issue is with using a bundled ssl library. Doing so means that a single bug in wolfssl must be uploaded several times in order to fix it. I think it would be ok to use the system copy of wolfssl. However, that's not what happens when you specifcy -DWITH_SSL=system it seems. Would -DWITH_SSL=/usr/include/wolfssl be an option? Does that look resolvable now? Helmut
Bug#971367: [debian-mysql] Bug#971367: Bug#971367: mariadb-10.5 should not embed wolfssl
Switching to OpenSSL 3.0 would remove the license issue (as 3.0 is Apache licensed), but it is still alpha and in experimental only. https://packages.debian.org/source/experimental/openssl I've suggested upstream they would support system WolfSSL but it hasn't been a priority so far and I am not sure how much work it would require. https://jira.mariadb.org/browse/MDEV-21835
Bug#971367: [debian-mysql] Bug#971367: mariadb-10.5 should not embed wolfssl
Hi, The relevant previous bug is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921488 where the packaging switched from "system" to "bundled". Switching back to "system" would regress that licensing problem. Also relevant is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924937 which is the same situation but for Postgres. I don't know how to resolve this conflict between Debian's security position and Debian's licensing position, but hopefully the above references provide some background to help someone else figure this out. Robie signature.asc Description: PGP signature
Bug#971367: mariadb-10.5 should not embed wolfssl
Source: mariadb-10.5 Version: 1:10.5.5-1 Tags: security Severity: serious Justification: unsupportable by the Debian security team Hi Otto, I've hinted that the situation about an embedded ssl library might be suboptimal earlier. Since then, I've checked (using the buildd logs) that indeed mariadb does build an embedded copy of wolfssl. I've also checked with the Debian security team (Moritz Muehlenhoff in particular). Such an embedding is unsupportable by the security team. For that reason, I'm filing this as a release critical bug. It expresses a veto of the security team for including the package in a stable release as is. On a technical level, this seems easy to solve. You currently pass -DWITH_SSL=bundled. The build system supports -DWITH_SSL=system in principle. What I'm less sure about is whether doing so breaks any functionality and whether the involved licenses are actually compatible. I do hope that you can sort this out. Thanks for your hard work in managing this complex package and otherwise integrating it into Debain. Helmut
