Documenting security advisories

Documenting security advisories

[Marta Rybczynska]

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.

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?

What do you think?

Kind regards,
Marta

Re: [yocto-security] Documenting security advisories

[Michael Opdenacker]

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?

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?

>
>
> I wouldn't add them to the docs themselves, but a link in the docs to 
> the advisory page would be good.


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.

Cheers
Michael.

-- 
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [docs] [yocto-security] Documenting security advisories

[Richard Purdie]

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