From: Jiri Kosina <jikos@kernel.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: corbet@lwn.net, workflows@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
security@kernel.org, linux@leemhuis.info,
Kees Cook <keescook@chromium.org>,
Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
Krzysztof Kozlowski <krzk@kernel.org>,
Lukas Bulwahn <lukas.bulwahn@gmail.com>,
Sasha Levin <sashal@kernel.org>, Lee Jones <lee@kernel.org>
Subject: Re: [PATCH v4] Documentation: Document the Linux Kernel CVE process
Date: Thu, 15 Feb 2024 18:38:05 +0100 (CET) [thread overview]
Message-ID: <nycvar.YFH.7.76.2402151817440.21798@cbobk.fhfr.pm> (raw)
In-Reply-To: <2024021500-laziness-grimace-ed80@gregkh>
On Thu, 15 Feb 2024, Greg Kroah-Hartman wrote:
> The Linux kernel project now has the ability to assign CVEs to fixed
> issues, so document the process and how individual developers can get a
> CVE if one is not automatically assigned for their fixes.
There is still one thing that's not clear to me with this new process, and
that's how embargos are going to be handled.
Currently, the process is broken as well, but at least understood by
everybody.
- issues are reported to security@kernel.org. No CVE assigned, 7days
embargo, then fix gets pushed out
- at some point (in parallel, before, or after the above), the issue gets
reported to linux-distros@. CVE gets assigned, and downstreams start
integrating the fix (once available) to their codebase.
- embargo is lifted, fixes are released with proper CVE reference
How is the new process going to look like? Please keep in mind that
linux-stable is (by far!) *not* the only downstream of Linux Kernel
project.
We've had this discussion in other contexts already, but I whole-heartedly
believe that it's in no way in the Linux Kernel project's interest to kill
those other downstreams (read: Linux distros) (*) ... or is it?
(*) just looking at how much those not-basing-on-stable distros are
contributing to mainline
Thanks,
--
Jiri Kosina
SUSE Labs
next prev parent reply other threads:[~2024-02-15 17:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-15 12:10 Greg Kroah-Hartman
2024-02-15 15:03 ` Jürgen Groß
2024-02-15 17:49 ` Greg Kroah-Hartman
2024-02-16 8:04 ` Jürgen Groß
2024-02-15 17:38 ` Jiri Kosina [this message]
2024-02-15 18:24 ` Greg Kroah-Hartman
2024-02-16 19:26 ` Josh Poimboeuf
2024-02-16 20:27 ` Jiri Kosina
2024-02-16 21:45 ` Theodore Ts'o
2024-02-16 21:51 ` Jiri Kosina
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=nycvar.YFH.7.76.2402151817440.21798@cbobk.fhfr.pm \
--to=jikos@kernel.org \
--cc=corbet@lwn.net \
--cc=gregkh@linuxfoundation.org \
--cc=keescook@chromium.org \
--cc=konstantin@linuxfoundation.org \
--cc=krzk@kernel.org \
--cc=lee@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@leemhuis.info \
--cc=lukas.bulwahn@gmail.com \
--cc=sashal@kernel.org \
--cc=security@kernel.org \
--cc=workflows@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox