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.

Hello,

Bug #971367 in mariadb reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/b7a48218608cf7787785eea741e84aed0d72c8ce
------------------------------------------------------------------------
Add Files-Excluded section to d/copyright based on d/rules deletions

Until now unwanted upstream storage engines, precompiled binaries and 3rd
party libraries and components have been removed in debian/rules clean
section, but the proper way to exclude is to filter them out from the
upstream release tarball before including them in Debian to begin with.

Closes: #971005, #971367
Gbp-Dch: full
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/971367

We believe that the bug you reported is fixed in the latest version of
mariadb, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 971367@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Otto Kekäläinen <otto@debian.org> (supplier of updated mariadb package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sat, 29 Aug 2026 19:19:19 +0000
Source: mariadb
Architecture: source
Version: 1:11.8.9+ds-1
Distribution: unstable
Urgency: medium
Maintainer: Debian MySQL Maintainers <pkg-mysql-maint@lists.alioth.debian.org>
Changed-By: Otto Kekäläinen <otto@debian.org>
Closes: 971005 971367 1140151 1140296
Changes:
 mariadb (1:11.8.9+ds-1) unstable; urgency=medium
 .
   [ Otto Kekäläinen ]
   * New upstream maintenance release version 11.8.9. Includes several fixes as
     noted at https://mariadb.com/docs/release-notes/community-server/11.8/11.8.9
     and also the following security issues:
     - CVE-2026-61081
     - CVE-2026-60585
     - CVE-2026-60331
     - CVE-2026-60747
     - CVE-2026-47023
     - CVE-2026-60184
   * Drop patches applied upstream
   * Update server trace to include new parameters and values
     - New option innodb-index-shrink (default TRUE)
   * Clean up d/copyright of files that no longer ship in this release
   * Update Lintian overrides for new upstream version
   * Update maintainer documentation to ensure it is current
   * Skip tests main.mysql_client_test* as they require Internet access
   * Salsa CI: Clean away defunct test jobs and start testing with MySQL 9.7
 .
   [ Luke Yasuda ]
   * d/*.lintian-overrides: fix all the mismatched-override
   * d/mariadb-server.links: drop the use of dh-exec
   * d/control: upgrade debhelper compatibility level to 14
   * d/watch: add +ds suffix
   * Add Files-Excluded section to d/copyright based on d/rules deletions.
     Until now unwanted upstream storage engines, precompiled binaries and 3rd
     party libraries and components have been removed in debian/rules clean
     section, but the proper way to exclude is to filter them out from the
     upstream release tarball before including them in Debian to begin with.
     (Closes: #971005, #971367)
   * d/copyright: drop entries for excluded files
   * d/gbp.conf: do not force check upstream sigs.
     We repack orig tarballs now, leaving this on will cause
     "gbp import-orig --uscan" to fail. uscan already checks the upstream
     signature and gbp does it again and fails, which is not we want.
   * drop unused source lintian overrides
   * drop unused local-options
 .
   [ Dick Hollenbeck ]
   * libmariadb-dev: make Multi-Arch: same co-installable (Closes: #1140296)
   * libmariadb-dev-compat: make Multi-Arch: same co-installable
     (Closes: #1140151)
 .
   [ Daniel Black ]
   * MDEV-39584: links mariadb.org/kb -> mariadb.com/docs
Checksums-Sha1:
 f114f162477ff9b2282988dadc531ce985d2ee88 5396 mariadb_11.8.9+ds-1.dsc
 0ce74570334ff745fbb094b090db199eaebe5f96 42060036 mariadb_11.8.9+ds.orig.tar.xz
 8b2be388aac7078dee76b049d307731508107c3a 302748 mariadb_11.8.9+ds-1.debian.tar.xz
 89033ead6c297bc3300190eec288a6da0608fa09 13742 mariadb_11.8.9+ds-1_source.buildinfo
Checksums-Sha256:
 315f5670a29b9db536c1704fa5ef9ec9e0761258181a1ac7632e4cea10217b0a 5396 mariadb_11.8.9+ds-1.dsc
 af102b8ca599d764b74788a95ce14b737b17441811fea6e49392cf2890d2dc28 42060036 mariadb_11.8.9+ds.orig.tar.xz
 58114dba766cb7922dc0c6d5a8d29a584676487d67ec888ba0c9012e0a7600b9 302748 mariadb_11.8.9+ds-1.debian.tar.xz
 d3e4c2bd92b666eb838c2e34b7caeafb660d3a94fe53b709f633a9c7807a6ce6 13742 mariadb_11.8.9+ds-1_source.buildinfo
Files:
 4a9026f906893210ed8a644242cf1c05 5396 database optional mariadb_11.8.9+ds-1.dsc
 0932c1707fbafb14b180036ccb8624c9 42060036 database optional mariadb_11.8.9+ds.orig.tar.xz
 c7d230209a7fa9a2ddd982b9fb37c5a8 302748 database optional mariadb_11.8.9+ds-1.debian.tar.xz
 35fe965d6dca045cb603ab3c0bf0407a 13742 database optional mariadb_11.8.9+ds-1_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEmbRSsR88dMO0U+RvvthEn87o2ogFAmqVskEACgkQvthEn87o
2oirHxAAroj3xtAHXsKbrg4nPpAReNeeXZdkBKunklVvdgiMqqZdVgMnw9uouiU4
egjKJhwIxpCppIwmApO2rr9FditmqDJ9twhUcRgs4vENCTGyhjToWjw+GbaCMYj6
OtCQxC9g8tc/suElvunlSngu2ax0doM0DbgcqPwYZOlrPU9B9Dixxwb+RMon3yjO
gVtpmKyQjBIT/FL4zXE8zh9xAmb4eZMNjxzDpDG3hM/FPmSOaiUfoSzH7SVj6iR5
KESF2OHc1YHSIMPnzricafcTVsJCpBM3SgDX5qJ8+5l8bXFbR8PmDoj3M1WEzGKr
rMjuNuKbb0xlX0yPNrbTgwYkagQuvq65P8G6ABGn2TdYeb/9o0NRTPZF2ZEgtpZZ
JnPYpgUmjLHa+hrOLQpfNSXw9U47q5OHyuUMoRJMBHXN5qw2YkL6YS6J08rnAYqi
UUVUfX78yGshtP003XTccUodF9K5LEz8dRKgKT80GwKO0O65x0FG6tlAInajBxb0
enblTKAXA3iKbiXCq7bLCAq5PTawzjfMrvMr8IXpIGsMlmnGVOoJ6dyPDHfDJK5f
v+6nDzhsYo4HpwFgk/tmdLG6zOXQrqYQADpEE/RFOWdEvMgag/8EoLpfH6KBi0Kh
JS4Q82bY8OYjVTbECxmQe1YvcoHj23Wmyn3Nl2lWEZgnQq8vHHM=
=iZV1
-----END PGP SIGNATURE-----