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
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.
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.
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
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
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
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
>
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
>
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
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
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
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
12 matches
Mail list logo
