From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: "<yocto@lists.yoctoproject.org>" <yocto@lists.yoctoproject.org>,
openembedded-architecture
<openembedded-architecture@lists.openembedded.org>
Subject: Open letter to the CVE Project/CNAs
Date: Mon, 22 Apr 2024 20:37:18 +0100 [thread overview]
Message-ID: <8738470640cac255caf789fed51d834c57f1b983.camel@linuxfoundation.org> (raw)
The recent NVD changes have impacted a number of projects and there are
quite a few uneasy developers out there, not just in the Yocto Project
community but much more widely. There could be some simple changes or
process improvements that the CVE Project could make which would
massively help things.
The key thing for many of us is to have accurate product/vendor
identification and useful version constraints. A secondary issue is an
easy process to allow updates/addition of that information.
The intent would be to have accurate CVE data at source, freeing NVD
andothers to validate/improve/vet that information.
As such I'm inviting our community to sign this open letter, the intent
of which is show the demand for these improvements:
https://github.com/yoctoproject/cve-cna-open-letter
I've chosen to use github pull requests for this for ease.
Please feel free to share this widely as I believe the ideas here would
benefit many projects as we all face a similar challenge.
What we don't want to see is "pay for access" data, or a fragmented
data ecosystem which is becoming a real risk.
The letter deliberately doesn't dive into implementation details as it
would complicate a simple message, those details are a solvable problem
if the desire is there. The version 5 schema already hints at some of
this path, this proposal would just take it a step further again by
allowing buy in from the CNAs themselves.
If there is a good process and tooling to allow updates of CVE entries
with information, even if it is optional, it will get adopted if it
works well and is helpful.
Cheers,
Richard
(on behalf of the Yocto Project/OpenEmbedded TSCs)
reply other threads:[~2024-04-22 19:37 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=8738470640cac255caf789fed51d834c57f1b983.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=openembedded-architecture@lists.openembedded.org \
--cc=yocto@lists.yoctoproject.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).