[Maria-docs] CVE list for connectors
Hello, On this page: https://mariadb.com/kb/en/library/security/ I can find CVEs that affect MariaDB server and releases they were fixed in. Other useful page is this one: https://mariadb.com/kb/en/library/security-vulnerabilities-in-oracle-mysql-t... -- I'd like to ask you to also list CVEs applicable for connectors and versions of connectors (CONC, CONJ, ODBC) they were fixed in, since there is not direct relationship between: 1) server nad CONC 2) ODBC and CONC Server is (or atleast should be) built on top of released version of the CONC, not the latest Git content. Atleast downstreams starts to use this scheme (separate server and client library - the CONC), so they depend only on the released versions of the CONC. -- For example CVE-2018-3081 should be fixed in CONC 3.0.5, however since nor git commit, nor CONC release notes says it explicitly, I can only guess. -- Michal Schorm Associate Software Engineer Core Services - Databases Team Red Hat
Hi, Michal! On Aug 21, Michal Schorm wrote:
Hello,
On this page: https://mariadb.com/kb/en/library/security/ I can find CVEs that affect MariaDB server and releases they were fixed in.
Other useful page is this one: https://mariadb.com/kb/en/library/security-vulnerabilities-in-oracle-mysql-t...
--
I'd like to ask you to also list CVEs applicable for connectors and versions of connectors (CONC, CONJ, ODBC) they were fixed in, since there is not direct relationship between: 1) server nad CONC 2) ODBC and CONC Server is (or atleast should be) built on top of released version of the CONC, not the latest Git content.
Yes, absolutely. We're not quite there yet, but moving there.
Atleast downstreams starts to use this scheme (separate server and client library - the CONC), so they depend only on the released versions of the CONC.
For example CVE-2018-3081 should be fixed in CONC 3.0.5, however since nor git commit, nor CONC release notes says it explicitly, I can only guess.
You're right, it is fixed in CONC 3.0.5, I've updated release noted. It's not shown on the https://mariadb.com/kb/en/security/ page yet because that page is generated from release notes, automatically picking up the correct server version, and this code doesn't support Connector/C yet. I've reported a bug, so it should be fixed soon, I assume. Regards, Sergei Chief Architect MariaDB and security@mariadb.org
I've reported a bug, so it should be fixed soon, I assume.
Thank you, that will be really nice enhancement. -- Michal Schorm Associate Software Engineer Core Services - Databases Team Red Hat On Tue, Aug 21, 2018 at 7:19 PM, Sergei Golubchik <serg@mariadb.org> wrote:
Hi, Michal!
On Aug 21, Michal Schorm wrote:
Hello,
On this page: https://mariadb.com/kb/en/library/security/ I can find CVEs that affect MariaDB server and releases they were fixed in.
Other useful page is this one: https://mariadb.com/kb/en/library/security-vulnerabilities-in-oracle- mysql-that-did-not-exist-in-mariadb/
--
I'd like to ask you to also list CVEs applicable for connectors and versions of connectors (CONC, CONJ, ODBC) they were fixed in, since there is not direct relationship between: 1) server nad CONC 2) ODBC and CONC Server is (or atleast should be) built on top of released version of the CONC, not the latest Git content.
Yes, absolutely. We're not quite there yet, but moving there.
Atleast downstreams starts to use this scheme (separate server and client library - the CONC), so they depend only on the released versions of the CONC.
For example CVE-2018-3081 should be fixed in CONC 3.0.5, however since nor git commit, nor CONC release notes says it explicitly, I can only guess.
You're right, it is fixed in CONC 3.0.5, I've updated release noted.
It's not shown on the https://mariadb.com/kb/en/security/ page yet because that page is generated from release notes, automatically picking up the correct server version, and this code doesn't support Connector/C yet. I've reported a bug, so it should be fixed soon, I assume.
Regards, Sergei Chief Architect MariaDB and security@mariadb.org
participants (2)
-
Michal Schorm -
Sergei Golubchik