Please do. Sorry - trying to do this before my morning coffee...
On Wed, Feb 21, 2024 at 10:01:26AM +0100, Paolo Bonzini wrote:
On 2/21/24 13:34, Sasha Levin wrote:
On Wed, Feb 21, 2024 at 2/21/24 13:34, Sasha Levin wrote:
There are dozens of distros, both commercial and non-commercial, whose
users need a *real* description of what is being fixed. By writing
CVE descriptions that make no sense, you're creating more work for
everyone involved, without putting in place a process to clarify these
things except through "the maintainers of the relevant subsystem
affected"---who are not CC'd to these messages and therefore might not
even know that the CVE announcement exists. [...] My suggestion is
to CC the author of the fix and the maintainer
This whole process didn't exist up until this point, and distros as well
as individuals were creating CVEs without a useful messages nor without
acks from the relevant authors/maintainers. What changed now?
First, that _when_ a CVE was created, there was a human in the loop
deciding who to write. Here we have scripts that clearly got
confused, pulling patches that were not included in the description.
Commit messages make the most sense when the need is to relay technical
information about an issue.
Second, that there is going to be thousands more occurrences of this
work overall.
Third, that the relevant maintainers were not on the hook as the sole
"authority to dispute or modify an assigned CVE". Maintainers were
given this additional work without, as far as I know, anybody telling
us, and I'd like to be able to do it efficiently and without adding
more bureaucracy to an already-thankless work.
So now you're asking us to drop this additional work on them by
reviewing CVE requests?
Looking at CVE-2024-0562, which we've previously discussed as an
example, were the maintainers of the relevant subsystem consulted before
the CVE was assigned?
CVE-2024-0562 matches perfectly what you're doing: create a CVE only
after the bug is fixed, to improve communication on how to update. Of
course the timing was off by a year, but hey "a bug is a bug" no?
Early communication of these issues is indeed an improvement that can
be made by having the kernel CNA. But if everything is automated and
on day one you have already such garbage, it's not going to go well.
The timing is off, but my point is that the maintainers were never
consulted whether this issue is really a security issue or a dud.
Is it really a security issue?
I'd also note that the if a certain user/distro requires massaged
explanations to be "user readable" and dumbed down to layman terms, then
it is on that user/distro to provide it to them (heck, I was doing this
exact work while making Ksplice updates years ago).
It's not "a certain user/distro", it's all of them---whether
commercial or not. And again, by removing any human vetting of what
goes into CVEs, you're pushing work on N distros thousands of times
per year instead of having it done only once upstream.
So I've worked in quite a few places in the past decade or so (Oracle,
Microsoft, Google, ...) and let me tell you from experience that all
those companies deeply care about security and CVEs, and the best CVE
description was one that simply pointed to the upstream commit.
So yes, I disagree with your "all of them" statement. For that matter,
I'd argue that the number of users who need massaged messages are the
vast minority.
I'll also note that you're not answering any of my questions:
1) as KVM maintainer (who is not allowed to post linux-cve-announce)
how can I be aware of all CVEs that are created and affect my subsystem?
How were you aware until a few weeks ago where CVE assignments were
handled by different entities?
2) how are you going to handle patch dependencies? Are they going to
be rolled into a single entry or split into multiple announcements?
Likely multiple different entries.
3) are the scripts used to generate the CVEs public? Can fixes to the
scripts be developed in the open?
Yup - https://git.kernel.org/pub/scm/linux/security/vulns.git/ .
4) what happened with 5.15 having only the revert but not the
revert-of-revert? Does this mean that it has the bug fixed by commit
87165c64fe1a9, and does this contradict the fact that updating to the
latest release of a given LTS branch is the best course of action?
It is always best to run the latest released kernel.