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

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

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

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

Hello!

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&page=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.

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

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.

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 (0x00007fc6c7d92000)
libgcrypt.so.20 => /usr/lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007fc6c755200

# ldd $(which mariadb) | grep -e crypt -e tls -e ssl
libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30
(0x00007f11defad000)

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/

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

Fair enough, removing RC severity here.

Cheers,
        Moritz

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

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).

Hello!

I've experimented with trying to filter out extra upstream source
directories we don't like automatically in the git-buildpackage step
with filters in
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/f4214a4bee3f4f35ae31746c542cf54bfc9536f7

This would help fix both
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971005 and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971367

Unfortunately the filter stanzas don't seem to have any effect then
the gbp import is running.

Noting this now down in the issues and will later return to debug why
git-buildpackage does not abide to the filter stanzas.

Dear submitter,

as the package mariadb-10.5 has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/1004944

The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.

Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Scott Kitterman (the ftpmaster behind the curtain)

Hi!

Thanks for reviewing build logs. Can you please double-check what log
and version you looked at and from what year?

The bug report was filed on a very old version. Latest version of this
package in 10.5 series is 1:10.5.26-0+deb11u2.

I am 98% confident MariaDB never built using WolfSSL in Debian at all,
and I am 100% confident that it hasn't built since 2020 and commit
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/ca2574aa88434d1c49456c677b7dcb904902daaf.

MR https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/101
would potentially close this issue.