Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Critical
-
Resolution: Fixed
-
Affects Version/s: N/A
-
Fix Version/s: N/A
-
Component/s: Documentation
-
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
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Thanks Daniel Black. We are using this regex which should handle the new format.
CVE-(?P<CVE>\d{4}\-\d{4,})
Our issues in Jira:
| CVE-2012-5611 | |
5.5.28a, 5.3.11, 5.2.13, 5.1.66 |
| CVE-2012-4414 | |
10.0.0, 5.5.27, 5.3.8, 5.2.13, 5.1.66 |
| CVE-2012-5614 | |
5.5.21 |
| CVE-2012-5615 | |
5.5.29, 5.2.14, 5.3.12 |
| CVE-2012-5612 | |
5.5.29, 10.0.1 |
| CVE-2012-5627 | |
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 |
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
I'll be adding the identifiers to the release notes this week. Thanks
I've taken Sergei Golubchik'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.
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