Обсуждение: Release of CVEs
The release notes for the new version reference some CVEs that have not been publically released yet. Are they slow, or is this something that needs to be added to the release process checklist? For example, see the CVE hyperlink for json parsing at: https://bucardo.org/postgres_all_versions.html#version_9.4.5 which leads to: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5289 It's also possible the wrong CVE was entered, but I don't see one that seems to pertain to the issue described (and CVE-2015-5288, -3166, -3167, -0243, -0244 are in the same boat). -- Greg Sabino Mullane greg@endpoint.com End Point Corporation PGP Key: 0x14964AC8
On Sun, Oct 11, 2015 at 8:54 PM, Greg Sabino Mullane <greg@endpoint.com> wrote: > The release notes for the new version reference some CVEs that > have not been publically released yet. Are they slow, or is > this something that needs to be added to the release > process checklist? My guess is that they are simply slow to refresh. If you look at RedHat stuff they mark those CVEs with the same numbers in their bug tracker (the database is not updated though). https://access.redhat.com/security/cve/CVE-2015-5288 https://access.redhat.com/security/cve/CVE-2015-5289 > It's also possible the wrong CVE was entered, but I don't see > one that seems to pertain to the issue described (and > CVE-2015-5288, -3166, -3167, -0243, -0244 are in the same boat). As is CVE-2015-0241, which dates of February. This is way more than slow... Perhaps we should contact cve at mitre dot org regarding that. Thoughts? -- Michael
On 10/11/2015 04:54 AM, Greg Sabino Mullane wrote: > The release notes for the new version reference some CVEs that > have not been publically released yet. Are they slow, or is > this something that needs to be added to the release > process checklist? These days MITRE is lagging 2-6 weeks behind publication for getting CVEs on their website. That's why I didn't bother to link them from the announcement. I don't know that there's anything the PostgreSQL project can do about it. If anyone on this list is connected with MITRE, please ask them what they need to be more prompt. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On Mon, Oct 12, 2015 at 2:54 AM, Josh Berkus wrote: > I don't know that there's anything the PostgreSQL project can do about > it. If anyone on this list is connected with MITRE, please ask them > what they need to be more prompt. http://cve.mitre.org/ has a "Contact Us" tab linking to the address I mentioned. That may be a start as at this state this is far more than 6 weeks. -- Michael
Michael Paquier <michael.paquier@gmail.com> writes: > On Mon, Oct 12, 2015 at 2:54 AM, Josh Berkus wrote: >> I don't know that there's anything the PostgreSQL project can do about >> it. If anyone on this list is connected with MITRE, please ask them >> what they need to be more prompt. > http://cve.mitre.org/ has a "Contact Us" tab linking to the address I > mentioned. That may be a start as at this state this is far more than > 6 weeks. I'm inclined to start by asking the Red Hat security guys, from whom we obtained all these CVE numbers to begin with. Will check into it tomorrow. regards, tom lane
I wrote: > Michael Paquier <michael.paquier@gmail.com> writes: >> On Mon, Oct 12, 2015 at 2:54 AM, Josh Berkus wrote: >>> I don't know that there's anything the PostgreSQL project can do about >>> it. If anyone on this list is connected with MITRE, please ask them >>> what they need to be more prompt. >> http://cve.mitre.org/ has a "Contact Us" tab linking to the address I >> mentioned. That may be a start as at this state this is far more than >> 6 weeks. > I'm inclined to start by asking the Red Hat security guys, from whom > we obtained all these CVE numbers to begin with. Will check into it > tomorrow. According to the Red Hat guys, the fundamental problem is that Mitre like to research and write up the official CVE descriptions themselves ... which would be fine if they had adequate resources to do it in a timely fashion, but they don't really. Apparently, most of our bugs are of low enough severity to be way down their priority list. (Maybe we should consider that a good thing.) However, Red Hat did also point out a possible alternative: instead of linking to the Mitre website, we could link to Red Hat's own repository of CVE descriptions at https://access.redhat.com/security/cve/ for example https://access.redhat.com/security/cve/CVE-2015-5289 This is not as unofficial as it might seem, because for several years now Mitre has officially delegated responsibility for initial assignment of CVE numbers for all open-source issues to Red Hat. (It's just final wording of the descriptions that they're insisting on doing themselves.) A quick browse through some of the relevant items says that this is at least as good as cve.mitre.org in terms of the descriptions of the security issues, but it is a bit Red-Hat-centric in that there's info about which Red Hat package releases include a fix, but not about package releases from other vendors such as Ubuntu. As a former wearer of the red fedora, I'm not going to pretend to have an unbiased opinion on whether we should switch our security-page links to point to Red Hat's entries instead of Mitre's. But it's something worth considering, given that we're seeing as much as a year's lag in Mitre's pages. regards, tom lane
On 14/10/15 18:19, Tom Lane wrote: > I wrote: >> Michael Paquier <michael.paquier@gmail.com> writes: >>> On Mon, Oct 12, 2015 at 2:54 AM, Josh Berkus wrote: >>>> I don't know that there's anything the PostgreSQL project can do about >>>> it. If anyone on this list is connected with MITRE, please ask them >>>> what they need to be more prompt. >>> http://cve.mitre.org/ has a "Contact Us" tab linking to the address I >>> mentioned. That may be a start as at this state this is far more than >>> 6 weeks. >> I'm inclined to start by asking the Red Hat security guys, from whom >> we obtained all these CVE numbers to begin with. Will check into it >> tomorrow. > According to the Red Hat guys, the fundamental problem is that Mitre like > to research and write up the official CVE descriptions themselves ... > which would be fine if they had adequate resources to do it in a timely > fashion, but they don't really. Apparently, most of our bugs are of low > enough severity to be way down their priority list. (Maybe we should > consider that a good thing.) > > However, Red Hat did also point out a possible alternative: instead of > linking to the Mitre website, we could link to Red Hat's own repository > of CVE descriptions at > https://access.redhat.com/security/cve/ > for example > https://access.redhat.com/security/cve/CVE-2015-5289 > > This is not as unofficial as it might seem, because for several years now > Mitre has officially delegated responsibility for initial assignment of > CVE numbers for all open-source issues to Red Hat. (It's just final > wording of the descriptions that they're insisting on doing themselves.) > > A quick browse through some of the relevant items says that this is at > least as good as cve.mitre.org in terms of the descriptions of the > security issues, but it is a bit Red-Hat-centric in that there's info > about which Red Hat package releases include a fix, but not about package > releases from other vendors such as Ubuntu. > > As a former wearer of the red fedora, I'm not going to pretend to have > an unbiased opinion on whether we should switch our security-page links > to point to Red Hat's entries instead of Mitre's. But it's something > worth considering, given that we're seeing as much as a year's lag in > Mitre's pages. > > regards, tom lane > > Would be be possibly to link to the Red Hat pages, and (at least semi) automate their replacement by the official pages when they become available? Cheers, Gavin