On Wed, Feb 14, 2024 at 07:43:32AM +0100, Greg Kroah-Hartman wrote: > On Tue, Feb 13, 2024 at 02:35:24PM -0800, Kees Cook wrote: > > On Tue, Feb 13, 2024 at 07:48:12PM +0100, Greg Kroah-Hartman wrote: > > > +No CVEs will be assigned for unfixed security issues in the Linux > > > +kernel, assignment will only happen after a fix is available as it can > > > +be properly tracked that way by the git commit id of the original fix. > > > > This seems at odds with the literal definition of what CVEs are: > > _vulnerability_ enumeration. This is used especially during the > > coordination of fixes; how is this meant to interact with embargoed > > vulnerability fixing? > > Yes, this is totally wrong, it was the original first draft of the > document, that I did on my workstation, and then went on the road for 3+ > weeks and I never sycned up when I got home with the updated version > that is on my laptop. The updated version addresses this, as it was > rightly pointed out by the CVE group that this is not how a CNA is > supposed to only work. > > Yet another reason why keeping changes private is a major pain, not only > for security ones! :( > > Let me send out the proper one after my morning coffee has kicked in and > I resolve the differences, and make the grammer fixes that Randy pointed > out... To make it more obvious here, as others have pointed this out to me as well, here's the updated paragraph that will be in my v2 patch, with proper ';' usage: No CVEs will be automatically assigned for unfixed security issues in the Linux kernel; assignment will only automatically happen after a fix is available and applied to a stable kernel tree, and it will be tracked that way by the git commit id of the original fix. If anyone wishes to have a CVE assigned before an issue is resolved with a commit, please contact the kernel CVE assignment team at <cve@xxxxxxxxxx> to get an identifier assigned from their batch of reserved identifiers. Does that help explain the process better? thanks, greg k-h
