This was talked about a while ago but the original cpe here which pointed to portage was wrong and the current one is wrong. This package does not have a cpe in the cpe dictionary which is necessary for cve's to be assigned to it. There is lots of automation to check for new cpe's if none is filled in but at the moment none that validates cpe's currently filled in. With this logic, if work isn't being done to make this current cpe actually exist in the cpe dictionary it should be removed so this package is shown as having no cpe which is the current reality. If you're interested in searching the cpe dictionary yourself, you can use this: https://nvd.nist.gov/products/cpe/search?namingFormat=2.3&orderBy=CPEURI.
That string was recommended by a fellow Googler. Does portage-utils have a CPE? I don't see one in the dictionary, so perhaps we should just remove that line entirely. Assigning to the maintainer though since security@ doesn't really have ownership over this.
Yeap, this ... again. Are there objections to just dropping the cpe thing this time?
(In reply to Fabian Groffen from comment #2) > Yeap, this ... again. > > Are there objections to just dropping the cpe thing this time? no kidding :) I'm fine with having them across the tree if it helps the google people, but atm I feel like we're getting very mixed messages/conflicting changes from them, and they're the only people who I know use them..
I'm sorry for the mixed signals from google. I don't know the other googler that requested this change, all I know is that the info in the file is incorrect and wanted to point it out. As per the question of does portage-utils have a CPE, no it doesn't. That's what I meant by "This package does not have a cpe in the cpe dictionary which is necessary for cve's to be assigned to it.". "This package" referring to the title of the bug that mentions app-portage/portage-utils which may have been a bit confusing. As per the comments about removing the cpe. If we're talking about just removing it for this package, yes, that's what I was requesting. I brought up the part about "if work isn't being done to make this current cpe actually exist in the cpe dictionary" because typically cpe's are created and maintained by package owners or distributors. There are several examples of this in gentoo itself where gentoo created the cpe for the package with the source as gentoo. As per the comment about google being the only one to use the CPEs. I was unaware we are the only one's that do it this way. It's a fairly common way to track CVE's as far as I know but if this is the case, maybe in the future we can work towards a way to pull away from it as well. I'm not sure about that but not having to rely on upstream for security scanning capabilities would probably be a good thing. I know most of the time I make a pull requests to make it as simple as possible to do these changes on your end but wanted to see if there was any work being done here as mentioned above so I just made a bug for discussion this time. Thank you all for looking into this. It is perfectly reasonable to remove the entire cpe line from this packages metadata. I appreciate all the help in making this work more accurately. If another googler in the future attempts to change this, feel free to point to this bug which should give necessary context for others involved.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=efb8fd83db0cdd062b100b763fa9e02609179081 commit efb8fd83db0cdd062b100b763fa9e02609179081 Author: John Helmert III <ajak@gentoo.org> AuthorDate: 2023-10-09 03:02:50 +0000 Commit: John Helmert III <ajak@gentoo.org> CommitDate: 2023-10-09 03:05:45 +0000 app-portage/portage-utils: remove cpe upstream metadata It seems that vapier's suggestion to use PN in the CPE can actually cause problems because it doesn't exist in MITRE's dictionary. Closes: https://bugs.gentoo.org/912463 Signed-off-by: John Helmert III <ajak@gentoo.org> app-portage/portage-utils/metadata.xml | 1 - 1 file changed, 1 deletion(-)
