All that the document says is "the authority to dispute or modify an
assigned CVE for a specific kernel change lies solely with the maintainers
of the relevant subsystem affected". But it doesn't say:
* how the maintainer would ask for such a modification or dispute
Email.
* if and how anyone else could propose them
Email.
* whether the CVE team can also do them unilaterally
Yup, through email :)
Perhaps since there's no archive for cve@xxxxxxxxxx, there should be a
public discussion mailing list (e.g. linux-cve@vger) that maintainers can
reply to? The private cve@xxxxxxxxxx alias would then be just for the
request of embargoed CVEs.
What's wrong with lkml for discussion? I'll add a "reply-to" to point
there as well so that it will properly redirect if you respond to a
message sent to the -announce list.
It would be great if modifications or disputes could simply be sent as
patches to the vulns.git repo. You guys can have push hooks or something
like that that take care of sending messages to linux-cve-announce etc.
Yes, I'll gladly take that as well!
Another underspecified part is the early request of CVEs. Some questions I
have:
* what information is needed
What ever information you feel is necessary. What would you do if you
had to make up your mind on this?
At the minimum, a git id :)
* is there a limit on embargo length similar to security@xxxxxxxxxx
We have no embargos here, you should NOT be emailing this alias about
any unfixed security things, the document explicitly states this.
* should it be acked by the subsystem maintainer
Not needed, but sure, if you want to.
More in general, I think you're underestimating the extra work for the
"listeners" of CVEs, that will come from bugs in the script or other
not-so-well-defined aspects of the process. I really think it would be a
good idea to behave "as if" you were already creating CVE, but for now just
send out the announcements and publish the JSON in a git repo.
How is it any different from the existing "listeners" of CVEs today? in
fact, it's a world better as the meta-data we are now providing in the
json files is so much better than all of the crud that all of the other
CNAs were putting in there, it's not even a fair comparison.
I've already had soo many threads from the "Red Hat product security
team" including flow charts and other fun things to last me quite a
while already, and that's just in the past few days.
Given that the "Red Hat product security team" was the #1 offender in
creating CVEs against the kernel that caused us so much work and
headaches that it pushed me over the edge to go through all of the extra
work to actually become a CNA, I think it's worth considering what you
are asking for here.
In other words, they know how to contact us, before, we could never
contact them. This is up to them to decide how to interact, not us.
And remember, the number of RH systems that that team affects is pretty
much in the rounding error of the other Linux systems out there, not
that I'm counting or anything, just saying :)
That's the benifit of being a CNA, we can ACTUALLY MODIFY the CVE
records, previously it was almost impossible to ever do so.
Agreed. There is potential to do much better than before.
Totally agreed, thanks for the questions!
greg k-h