[MDEV-4105] Improving security announcements on Knowledgebase Created: 2013-01-28  Updated: 2014-11-28  Due: 2014-11-17  Resolved: 2014-11-28

Status: Closed
Project: MariaDB Server
Component/s: Documentation
Affects Version/s: N/A
Fix Version/s: N/A

Type: Bug Priority: Critical
Reporter: Colin Charles Assignee: Sergei Golubchik
Resolution: Fixed Votes: 3
Labels: None


 Description   

We had a request that we might want to improve security announcements in the Knowledgebase so that people didn't have to wade thru changelog to see what had changed.

The suggestion was to make it similar to how the Apache project handles this:
http://httpd.apache.org/security_report.html

Is this something we can do? A lot of distributions for example are finding that we rock thanks to our security policy. No harm making it easier for everyone.

In fact, if we list MySQL information, it can make the knowledgebase a lot more useful for people using MySQL too.

Let me know what you think



 Comments   
Comment by Sergei Golubchik [ 2013-01-28 ]

security announcements are highlighted in the release notes, there's no need to go through changelogs for that.
See https://kb.askmonty.org/en/mariadb-5166-release-notes/ for example

Comment by Colin Charles [ 2013-01-28 ]

I should have said: release notes/changelogs.

What apache provides for httpd is not something we have ever provided. Its more a central resource.

Comment by Bryan Alsdorf [ 2013-06-19 ]

One thing we could do is wrap the changelog entries in a macro, i.e.
<<securityfix cve="blah123">>FIxed blah 123<</securityfix>>

Then we would have a page that lists all of those excerpts. Only a days work or so to implement, though going back would take dbart some time to update old entries.

Comment by Daniel Bartholomew [ 2013-06-19 ]

I'm all for improving the documentation, so I'm fine with going back and adding macros to changelogs, release notes, and etc...

Comment by Sergei Golubchik [ 2014-08-26 ]

bryan, when can you have this macro?
As far as I understand, the idea is to write in the changelog:

 <<securityfix cve="blah123">>FIxed blah 123<</securityfix>> 

and then all these entries will be additionally visible on a separate "Security Fixes" page? Per version?

Hmm. In fact, there's no need for a macro, KB can recognize patters and turn them into links, like MDEV-1234. Similarly, it can be taught to recognize CVE-2010-1234 patterns (it's CVE-\d\d\d\d-\d\d\d\d). Turn them into links (like http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1234) and additionally collect on a separate page. Is that doable?

Then I'll prepare the list of CVEs to be added to release notes.

Comment by Bryan Alsdorf [ 2014-08-26 ]

Good suggestion Sergei. I just need to create the dynamic page and reparse the old changelogs (The KB just extracts / saves the links on save).

I'm talking to Rasmus about where this fits into my schedule.

Comment by Daniel Bartholomew [ 2014-08-27 ]

Bryan, I'll be adding the CVE-####-#### text from the list Sergei gives me to all of the old Changelogs and Release Notes, so no need for you to do the reparse as it will happen automatically as I edit/save the pages.

Comment by Bryan Alsdorf [ 2014-08-28 ]

This is now done from the KB point of things. CVE-XXXX-XXXX is now recognized as an auto link.

There is now a macro <<listcve>> to list CVEs. By default it lists all CVEs that are on pages with titles matching the pattern "MariaDB X.X.X" so it will grab the CVE's from changelogs but not if we have a CVE on some other random page. You also can pass an optional product parameter to the macro to limit what is displayed. This argument should be a regexp, i.e. <<listcve product="MariaDB 10.0.\d+">>

Comment by Daniel Black [ 2014-09-12 ]

Note - http://cve.mitre.org/cve/identifiers/syntaxchange.html

Might need a regex change.

Comment by Bryan Alsdorf [ 2014-09-18 ]

Thanks danblack. We are using this regex which should handle the new format.

 CVE-(?P<CVE>\d{4}\-\d{4,})

Comment by Sergei Golubchik [ 2014-10-12 ]

Our issues in Jira:

CVE-2012-5611 MDEV-3884 5.5.28a, 5.3.11, 5.2.13, 5.1.66
CVE-2012-4414 MDEV-382 10.0.0, 5.5.27, 5.3.8, 5.2.13, 5.1.66
CVE-2012-5614 MDEV-3910 5.5.21
CVE-2012-5615 MDEV-3909 5.5.29, 5.2.14, 5.3.12
CVE-2012-5612 MDEV-3908 5.5.29, 10.0.1
CVE-2012-5627 MDEV-3915 5.5.29, 5.2.14, 5.3.12

Oracle CPUs

July 2014

CVE-2014-4258 5.5.38, 10.0.12
CVE-2014-4260 5.5.38, 10.0.12
CVE-2014-2494 5.5.38, 10.0.12
CVE-2014-4207 5.5.38, 10.0.12
CVE-2014-4243 5.5.36, 10.0.9

April 2014

CVE-2014-2436 5.5.37, 10.0.11
CVE-2014-2440 5.5.37, 10.0.11
CVE-2014-2419 5.5.36, 10.0.9
CVE-2014-0384 5.5.36, 10.0.9
CVE-2014-2430 5.5.37, 10.0.11
CVE-2014-2438 5.5.36, 10.0.9
CVE-2014-2432 5.5.36, 10.0.9
CVE-2014-2431 5.5.37, 10.0.11

January 2014

CVE-2014-0412 5.1.73, 5.5.35, 10.0.8
CVE-2014-0402 5.1.72, 5.5.34, 10.0.7
CVE-2014-0386 5.1.72, 5.5.34, 10.0.7
CVE-2013-5891 5.5.34, 10.0.7
CVE-2014-0401 5.1.73, 5.5.35, 10.0.8
CVE-2014-0437 5.1.73, 5.5.35, 10.0.8
CVE-2014-0393 5.1.72, 5.5.34, 10.0.7
CVE-2014-0420 5.5.35, 10.0.8
CVE-2013-5908 5.1.73, 5.5.35, 10.0.8

October 2014

CVE-2013-5807 5.5.33, 10.0.5
CVE-2012-2750 5.1, 5.5.23
CVE-2013-3839 5.1.71, 5.5.33, 10.0.5

July 2013

CVE-2013-1861 5.1.70, 5.5.32, 10.0.4
CVE-2013-3809 5.5.32, 10.0.4
CVE-2013-3793 5.5.32, 10.0.4
CVE-2013-3802 5.1.70, 5.5.32, 10.0.4
CVE-2013-3805 5.5.31, 10.0.3
CVE-2013-3804 5.1.70, 5.5.32, 10.0.4
CVE-2013-3808 5.1.69, 5.5.31, 10.0.3
CVE-2013-3801 5.5.31, 10.0.3
CVE-2013-3783 5.5.32, 10.0.4
CVE-2013-3794 5.5.31, 10.0.3
CVE-2013-3812 5.5.32, 10.0.4

April 2013

CVE-2013-1521 5.1.68, 5.5.30, 10.0.2
CVE-2013-2378 5.1.68, 5.5.30, 10.0.2
CVE-2013-1552 5.1.68, 5.5.30, 10.0.2
CVE-2013-1531 5.1.67, 5.5.29, 10.0.1
CVE-2013-2375 5.1.69, 5.5.31, 10.0.3
CVE-2013-1523 5.5.30, 10.0.2
CVE-2013-1544 5.1.69, 5.5.31, 10.0.3
CVE-2013-1512 5.5.30, 10.0.2
CVE-2013-1532 5.1.69, 5.5.31, 10.0.3
CVE-2013-2389 5.1.69, 5.5.31, 10.0.3
CVE-2013-2392 5.1.69, 5.5.31, 10.0.3
CVE-2013-1555 5.1.68, 5.5.30, 10.0.2
CVE-2013-1526 5.5.30, 10.0.2
CVE-2012-5614 5.1.68, 5.5.30, 10.0.2
CVE-2013-2376 5.5.31, 10.0.3
CVE-2013-1511 5.5.31, 10.0.3
CVE-2013-1548 5.1.64
CVE-2013-2391 5.1.69, 5.5.31, 10.0.3
CVE-2013-1506 5.1.68, 5.5.30, 10.0.2
CVE-2013-1502 5.5.31, 10.0.3

January 2013

CVE-2012-5612 5.5.29, 10.0.1
CVE-2012-5611 5.1.67, 5.5.29, 10.0.1
CVE-2012-5060 5.1.66, 5.5.28
CVE-2013-0384 5.1.67, 5.5.29, 10.0.1
CVE-2013-0389 5.1.67, 5.5.29, 10.0.1
CVE-2013-0386 5.5.29, 10.0.1
CVE-2013-0385 5.1.67, 5.5.29, 10.0.1
CVE-2013-0375 5.1.67, 5.1.29
CVE-2012-1702 5.1.67, 5.5.29, 10.0.1
CVE-2013-0383 5.1.67, 5.5.29, 10.0.1
CVE-2013-0368 5.5.29, 10.0.1
CVE-2012-0572 5.1.67, 5.5.29, 10.0.1
CVE-2013-0371 5.5.29, 10.0.1
CVE-2012-0574 5.1.67, 5.5.29, 10.0.1
CVE-2012-1705 5.1.67, 5.5.29, 10.0.1
CVE-2012-0578 5.5.29, 10.0.1
CVE-2013-0367 5.5.29, 10.0.1
CVE-2012-5096 5.5.29, 10.0.1

October 2012

CVE-2012-3163 5.1.65, 5.5.27
CVE-2012-3158 5.1.65, 5.5.27
CVE-2012-3177 5.1.66, 5.5.28
CVE-2012-3147 5.5.27
CVE-2012-3166 5.1.64, 5.5.26
CVE-2012-3173 5.1.64, 5.5.26
CVE-2012-3144 5.5.27
CVE-2012-3150 5.1.65, 5.5.27
CVE-2012-3180 5.1.66, 5.5.28
CVE-2012-3149 5.5.27
CVE-2012-3156 5.5.26
CVE-2012-3167 5.1.64, 5.5.26
CVE-2012-3197 5.1.65, 5.5.27
CVE-2012-3160 5.1.66, 5.5.28

July 2012

CVE-2012-1735 5.5.24
CVE-2012-0540 5.1.63, 5.5.24
CVE-2012-1757 5.5.24
CVE-2012-1756 5.5.24
CVE-2012-1734 5.1.63, 5.5.24
CVE-2012-1689 5.1.63, 5.5.23

April 2012

CVE-2012-1703 5.1.62, 5.5.22
CVE-2012-0583 5.1.61, 5.5.20
CVE-2012-1697 5.5.22
CVE-2012-1688 5.1.62, 5.5.22
CVE-2012-1696 5.5.20
CVE-2012-1690 5.1.62, 5.5.22

January 2012

this is the first CPU that includes MySQL, so it has issues for all MySQL history, not only new issues since the last CPU. That's why it has no version numbers

CVE-2012-0113 5.1.x, 5.5.x
CVE-2011-2262 5.1.x, 5.5.x
CVE-2012-0116 5.1.x, 5.5.x
CVE-2012-0118 5.1.x, 5.5.x
CVE-2012-0496 5.5.x
CVE-2012-0087 5.0.x, 5.1.x
CVE-2012-0101 5.0.x, 5.1.x
CVE-2012-0102 5.0.x, 5.1.x
CVE-2012-0115 5.1.x, 5.5.x
CVE-2012-0119 5.1.x, 5.5.x
CVE-2012-0120 5.1.x, 5.5.x
CVE-2012-0484 5.0.x, 5.1.x, 5.5.x
CVE-2012-0485 5.1.x, 5.5.x
CVE-2012-0486 5.5.x
CVE-2012-0487 5.5.x
CVE-2012-0488 5.5.x
CVE-2012-0489 5.5.x
CVE-2012-0490 5.0.x, 5.1.x, 5.5.x
CVE-2012-0491 5.5.x
CVE-2012-0495 5.5.x
CVE-2012-0112 5.1.x, 5.5.x
CVE-2012-0117 5.5.x
CVE-2012-0114 5.0.x, 5.1.x, 5.5.x
CVE-2012-0492 5.1.x, 5.5.x
CVE-2012-0493 5.5.x
CVE-2012-0075 5.0.x, 5.1.x, 5.5.x
CVE-2012-0494 5.5.x
Comment by Otto Kekäläinen [ 2014-10-17 ]

Is this feature now implemented? I don't see any CVE identifiers in the release notes or changelog of 5.5.40. Oracle just released a bunch of security notices, it would be cool to have them added to the release notes in retrospect so distro packagers can track what CVE is fixed in what version.

In Debian the security tracker looks like this: https://security-tracker.debian.org/tracker/source-package/mariadb-5.5
And each upload of a package has fixed CVE's listed: http://anonscm.debian.org/cgit/pkg-mysql/mariadb-5.5.git/tree/debian/changelog

Comment by Daniel Bartholomew [ 2014-10-20 ]

I'll be adding the identifiers to the release notes this week. Thanks

Comment by Daniel Bartholomew [ 2014-10-21 ]

I've taken serg's list above and added the CVEs to the relevant release notes (and when I had an MDEV, to the changelogs as well, if the changelog mentioned the MDEV).

I then created a page to display all of the CVEs at: https://mariadb.com/kb/en/security/

I also updated each "What is MariaDB x.x?" page with a list of CVEs fixed in that individual series.

Lastly, I added two shortcuts to mariadb.org, similar to the mariadb.org/jira one, they both redirect to the CVE page:

I think the only thing left to do is to establish the formalities of how CVE identifiers are added to release notes and changelogs going forward.

Generated at Thu Feb 08 06:53:45 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.