From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: michael.opdenacker@bootlin.com,
Mark Hatle <mark.hatle@kernel.crashing.org>,
Marta Rybczynska <rybczynska@gmail.com>
Cc: yocto-security@lists.yoctoproject.org,
YP docs mailing list <docs@lists.yoctoproject.org>
Subject: Re: [docs] [yocto-security] Documenting security advisories
Date: Tue, 19 Dec 2023 10:25:10 +0000 [thread overview]
Message-ID: <ed80038150aff772343b79d24185a600412d1d2a.camel@linuxfoundation.org> (raw)
In-Reply-To: <360a6c05-ec1e-4cef-b2d3-de18bd52aadb@bootlin.com>
On Tue, 2023-12-19 at 11:00 +0100, Michael Opdenacker via
lists.yoctoproject.org wrote:
> Hi Marta
>
> On 18.12.23 at 20:27, Mark Hatle wrote:
> > On 12/18/23 9:37 AM, Marta Rybczynska wrote:
> > > Hello,
> > > When discussing security processes, there is one thing that we haven't
> > > set up for now. This is, where are we going to put any possible
> > > security advisories affecting the Yocto Project. The need to release
> > > such an advisory could happen one day.
>
> Good idea to anticipate this!
>
> > >
> > > A security advisory describes in more detail a single issue or a
> > > series of issues. Gives the context, workarounds, information about
> > > the version where the issue is fixed. An issue from an advisory is
> > > likely affecting multiple versions of YP, and might have different
> > > fixes for each version. The advisory will be referenced in the CVE
> > > issue, security aggregators etc.
> > >
> > > Where can we put such advisories:
> > > * mailing list of the affected layer/module
> > > * general documentation in "Release Manuals", using a separate section
> > > for advisories with links from each of the affected versions? OR a
> > > separate manual section?
> >
> > My suggestion is send it to both yocto-security and have a
> > yoctoproject.org/security page that just lists each advisor.
>
> What about the yocto-announce mailing list too?
We have a specific place for mailing list security issues which is the
yocto-security list. I don't think this makes sense for announce.
> Hey, what about a notification from the tool itself too, something that
> would catch users' attention if their version is impacted? Like the
> build system running a CVE check on its own version?
That has a lot of "phone home" potential privacy issues unfortunately.
>
> Well, there would be room for advisories in the docs, typically under
> the "migration-guides" folder for release notes and migration guides.
>
> The pros of using the docs are that they are reviewed by the community,
> and they may be easier to find next to release manuals.
>
> The cons I see are that docs take more time to update because of the
> review process, compared to a page on the website if members of the
> security team already have access. Unless Richard, Michael H. or the
> documentation maintainer rushes them in. I guess you don't have much
> time when you submit a CVE issue.
>
> I guess this also depends on how and how many times each advisory is
> modified, and whether this should be a collaborative process or not.
I suspect the time for docs patches should be ok in general and if we
really needed to we could turn something around quickly. I'd not expect
many updates but improvements should be fine using the usual processes.
Cheers,
Richard
prev parent reply other threads:[~2023-12-19 10:25 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-18 15:37 Documenting security advisories Marta Rybczynska
[not found] ` <a4b99195-4cf4-4392-b8be-43357fb22002@kernel.crashing.org>
2023-12-19 10:00 ` [yocto-security] " Michael Opdenacker
2023-12-19 10:25 ` Richard Purdie [this message]
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=ed80038150aff772343b79d24185a600412d1d2a.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=docs@lists.yoctoproject.org \
--cc=mark.hatle@kernel.crashing.org \
--cc=michael.opdenacker@bootlin.com \
--cc=rybczynska@gmail.com \
--cc=yocto-security@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).