Created attachment 153741 [details] Makefile with CPE information added lang/gcc-aux has had vulnerabilities with a CPE identifier assigned (e.g. CVE-2008-1367). This patch add CPE information as suggested in the FreeBSD wiki[0]. [0] https://wiki.freebsd.org/Ports/CPE
according to: http://www.cvedetails.com/cve/CVE-2008-1367/ CVE-2008-1367 applies to gcc 4.3.x gcc-aux is version 4.9.x To me this CVE is not applicable. Why do you think it is?
(In reply to John Marino from comment #1) Yes, the CVE does not apply directly. The FreeBSD wiki states with regard to CPE: "When should CPE information be added? If you maintain a port for a piece of software that already has an entry in the CPE dictionary, you SHOULD add CPE information to it the next time you upgrade to a new version, and you MAY do it right away. If you're updating a port because of an advisory that includes a CVE number, you MUST add CPE information to the port."[0] Since gcc has a CPE dictionary entry, i do think the CPE information should be added. The alternative (according to the procedure laid out in the wiki) is to wait for an new/current CPE number and then add the CPE information, but this could be tackled head on. [0] https://wiki.freebsd.org/Ports/CPE
I don't agree with that interpretation. I don't read it to mean "any CVE, ever, even if it's obsolete". E.g. read it as "If you maintain a port for a piece of software that already has an [applicable/current] entry in the CPE dictionary," ... It makes no sense to be to add an expired CVE that doesn't not apply. I'm happy to get the security team to clarify.
(In reply to John Marino from comment #3) > I don't read it to mean "any CVE, ever, even if it's obsolete". > ... > It makes no sense to be to add an expired CVE that doesn't not apply. The CVE is just a reference to a past vulnerabilty and the fact that (therefore) the gcc has a CPE name. This patch does not add the CVE information. I do agree that it makes little sense to add that specific CVE information, but that is not what i am doing and not what i am arguing for. > E.g. read it as "If you maintain a port for a piece of software that already > has an [applicable/current] entry in the CPE dictionary," ... I think you confuse something. This patch adds CPE information about the port, aka. information that uniquely identifies the software (vendor, name, version etc.). The main purpose of the CPE dictionary is to provide consistent information about (referencing) the software[0]. That is the reason why you will find vendor information, but not references to vulnerabilities. The vulnerability information is provided via a CVE (not CPE), and the NVD uses CPE to identify the specific software (flavors) affected. [0] "Common Platform Enumeration (CPE) is a standardized method of describing and identifying classes of applications, operating systems, and hardware devices present among an enterprise's computing assets." http://scap.nist.gov/specifications/cpe/
so this is to prepare for the case a new CVE is issued in the future? What's the impact of not implementing this patch? Likewise, what is the benefit for adding it given no applicable CVE?
now that I focus on the patch rather than the CVE, I see it's rather benign, but I still would like to understand the benefit.
(In reply to John Marino from comment #5) > so this is to prepare for the case a new CVE is issued in the future? Yes. > What's the impact of not implementing this patch? Less automation for admins. The CPE allows administrators to check whether or not their specific systems are affected. > Likewise, what is the benefit for adding it given no applicable CVE? An administrator will know if her systems are affected by a CVE, since a vulnerability might be platform specific. It also allows discovery of vulnerabilities since they are (only) exploitable in specific configurations. E.g. there might be a CVE for Apache, but only exploitable on FreeBSD. CPE basically adds context information to a plain CVE. It can also be combined with other data sources (e.g. OVAL etc.).
okay. It seems there's no negative to adding it, and there could be benefits in the future, so I'm okay with it. I was originally thinking it was the CVE that was the focus, not the CPE identifiers.
(In reply to John Marino from comment #8) No problem. Glad we could sort it out.
A commit references this bug: Author: marino Date: Thu Mar 5 09:01:27 UTC 2015 New revision: 380478 URL: https://svnweb.freebsd.org/changeset/ports/380478 Log: lang/gcc-aux, lang/gcc47-aux, lang/gnatdroid-arm*: Add CPE information There are no active CVEs against GCC 4.7.x or 4.9.x, but GCC is listed in the CPE database due to earlier CVEs. To prepare for future CVEs, add the CPE information. Note that CPE_VERSION has to be defined since these ports use their own version schemes rather than GCC version numbers. PR: 198252 PR: 198257 Submitted by: shun (dropcut.net) Changes: head/lang/gcc-aux/Makefile.common head/lang/gcc47-aux/Makefile.common
It's in, with 3 changes: 1) CPE_PRODUCT defined like gcc47-aux (not sure how important this was) 2) CPE_VERSION defined to ${GCC_VERSION} since gcc-aux has its own version scheme, this was required 3) I moved the block to Makefile.common so that lang/gnatdroid-armv5 and lang/gnatdroid-armv7 also get the CPE information. thanks!