[RFC] Mark of upstream CVE patches

[RFC] Mark of upstream CVE patches

[Mariano Lopez]

There is an initiative to track vulnerable software being built (see 
bugs 8119 and 7515). The idea is to have a testing tool that would check 
the recipe versions against CVEs. In order to accomplish such task there 
is need to reliable mark the patches from upstream that solve CVEs.

There have been two options to mark the patches that solve CVEs:

1. Have  "CVE" and the CVE number as the patch filename.
   Pros:
     Doesn't require a new tag.
   Cons:
     It is not flexible to add more information, for example two CVEs in 
the same patch

2. Add a new tag in the patch that have the CVE information.
   Pros:
     It is flexible and can add more information.
   Cons:
     Require a change in the patch metadata.

What I would recommend is to add a new tag in the patch, it must contain 
the CVE ID. With this it would be possible to look for the CVE 
information easily in the testing tool or in NIST, MITRE, or another web 
page. For example, this would be part of the patch for CVE-2013-6435, 
currently in OE-Core:

-- snip --

Upstream-Status: Backport
CVE: CVE-2013-6435

Reference:
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2013-6435

-- snip --

The expected output of this discussion is a standard format for CVE 
patches that most, if not all, of community members agree on.

Please let me know your comments.

Cheers,

Mariano Lopez

Re: [RFC] Mark of upstream CVE patches

[Otavio Salvador]

On Tue, Dec 15, 2015 at 2:03 PM, Mariano Lopez
<mariano.lopez@linux.intel.com> wrote:
> There is an initiative to track vulnerable software being built (see bugs
> 8119 and 7515). The idea is to have a testing tool that would check the
> recipe versions against CVEs. In order to accomplish such task there is need
> to reliable mark the patches from upstream that solve CVEs.

I support this initiative and I also second the preference for the tag
in the patch header. It is easy to add, grep for, and simple.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [OE-core] [RFC] Mark of upstream CVE patches

[Otavio Salvador]

On Tue, Dec 15, 2015 at 2:03 PM, Mariano Lopez
<mariano.lopez@linux.intel.com> wrote:
> There is an initiative to track vulnerable software being built (see bugs
> 8119 and 7515). The idea is to have a testing tool that would check the
> recipe versions against CVEs. In order to accomplish such task there is need
> to reliable mark the patches from upstream that solve CVEs.

I support this initiative and I also second the preference for the tag
in the patch header. It is easy to add, grep for, and simple.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [RFC] Mark of upstream CVE patches

[Philip Balister]

I also suggest copying the

https://lists.yoctoproject.org/listinfo/yocto-security

list.

Philip

On 12/15/2015 11:03 AM, Mariano Lopez wrote:
> There is an initiative to track vulnerable software being built (see
> bugs 8119 and 7515). The idea is to have a testing tool that would check
> the recipe versions against CVEs. In order to accomplish such task there
> is need to reliable mark the patches from upstream that solve CVEs.
> 
> There have been two options to mark the patches that solve CVEs:
> 
> 1. Have  "CVE" and the CVE number as the patch filename.
>   Pros:
>     Doesn't require a new tag.
>   Cons:
>     It is not flexible to add more information, for example two CVEs in
> the same patch
> 
> 2. Add a new tag in the patch that have the CVE information.
>   Pros:
>     It is flexible and can add more information.
>   Cons:
>     Require a change in the patch metadata.
> 
> What I would recommend is to add a new tag in the patch, it must contain
> the CVE ID. With this it would be possible to look for the CVE
> information easily in the testing tool or in NIST, MITRE, or another web
> page. For example, this would be part of the patch for CVE-2013-6435,
> currently in OE-Core:
> 
> -- snip --
> 
> Upstream-Status: Backport
> CVE: CVE-2013-6435
> 
> Reference:
> https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2013-6435
> 
> -- snip --
> 
> The expected output of this discussion is a standard format for CVE
> patches that most, if not all, of community members agree on.
> 
> Please let me know your comments.
> 
> Cheers,
> 
> Mariano Lopez

Re: [OE-core] [RFC] Mark of upstream CVE patches

[Philip Balister]

I also suggest copying the

https://lists.yoctoproject.org/listinfo/yocto-security

list.

Philip

On 12/15/2015 11:03 AM, Mariano Lopez wrote:
> There is an initiative to track vulnerable software being built (see
> bugs 8119 and 7515). The idea is to have a testing tool that would check
> the recipe versions against CVEs. In order to accomplish such task there
> is need to reliable mark the patches from upstream that solve CVEs.
> 
> There have been two options to mark the patches that solve CVEs:
> 
> 1. Have  "CVE" and the CVE number as the patch filename.
>   Pros:
>     Doesn't require a new tag.
>   Cons:
>     It is not flexible to add more information, for example two CVEs in
> the same patch
> 
> 2. Add a new tag in the patch that have the CVE information.
>   Pros:
>     It is flexible and can add more information.
>   Cons:
>     Require a change in the patch metadata.
> 
> What I would recommend is to add a new tag in the patch, it must contain
> the CVE ID. With this it would be possible to look for the CVE
> information easily in the testing tool or in NIST, MITRE, or another web
> page. For example, this would be part of the patch for CVE-2013-6435,
> currently in OE-Core:
> 
> -- snip --
> 
> Upstream-Status: Backport
> CVE: CVE-2013-6435
> 
> Reference:
> https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2013-6435
> 
> -- snip --
> 
> The expected output of this discussion is a standard format for CVE
> patches that most, if not all, of community members agree on.
> 
> Please let me know your comments.
> 
> Cheers,
> 
> Mariano Lopez

Re: [RFC] Mark of upstream CVE patches

[Richard Purdie]

On Tue, 2015-12-15 at 11:30 -0500, Philip Balister wrote:
> I also suggest copying the
> 
> https://lists.yoctoproject.org/listinfo/yocto-security
> 
> list.

and the architecture list, this is something that should apply to more
than OE-Core ideally.

Cheers,
Richard

> Philip
> 
> On 12/15/2015 11:03 AM, Mariano Lopez wrote:
> > There is an initiative to track vulnerable software being built
> > (see
> > bugs 8119 and 7515). The idea is to have a testing tool that would
> > check
> > the recipe versions against CVEs. In order to accomplish such task
> > there
> > is need to reliable mark the patches from upstream that solve CVEs.
> > 
> > There have been two options to mark the patches that solve CVEs:
> > 
> > 1. Have  "CVE" and the CVE number as the patch filename.
> >   Pros:
> >     Doesn't require a new tag.
> >   Cons:
> >     It is not flexible to add more information, for example two
> > CVEs in
> > the same patch
> > 
> > 2. Add a new tag in the patch that have the CVE information.
> >   Pros:
> >     It is flexible and can add more information.
> >   Cons:
> >     Require a change in the patch metadata.
> > 
> > What I would recommend is to add a new tag in the patch, it must
> > contain
> > the CVE ID. With this it would be possible to look for the CVE
> > information easily in the testing tool or in NIST, MITRE, or
> > another web
> > page. For example, this would be part of the patch for CVE-2013
> > -6435,
> > currently in OE-Core:
> > 
> > -- snip --
> > 
> > Upstream-Status: Backport
> > CVE: CVE-2013-6435
> > 
> > Reference:
> > https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2013-6435
> > 
> > -- snip --
> > 
> > The expected output of this discussion is a standard format for CVE
> > patches that most, if not all, of community members agree on.
> > 
> > Please let me know your comments.
> > 
> > Cheers,
> > 
> > Mariano Lopez

Re: [OE-core] [RFC] Mark of upstream CVE patches

[Richard Purdie]

On Tue, 2015-12-15 at 11:30 -0500, Philip Balister wrote:
> I also suggest copying the
> 
> https://lists.yoctoproject.org/listinfo/yocto-security
> 
> list.

and the architecture list, this is something that should apply to more
than OE-Core ideally.

Cheers,
Richard

> Philip
> 
> On 12/15/2015 11:03 AM, Mariano Lopez wrote:
> > There is an initiative to track vulnerable software being built
> > (see
> > bugs 8119 and 7515). The idea is to have a testing tool that would
> > check
> > the recipe versions against CVEs. In order to accomplish such task
> > there
> > is need to reliable mark the patches from upstream that solve CVEs.
> > 
> > There have been two options to mark the patches that solve CVEs:
> > 
> > 1. Have  "CVE" and the CVE number as the patch filename.
> >   Pros:
> >     Doesn't require a new tag.
> >   Cons:
> >     It is not flexible to add more information, for example two
> > CVEs in
> > the same patch
> > 
> > 2. Add a new tag in the patch that have the CVE information.
> >   Pros:
> >     It is flexible and can add more information.
> >   Cons:
> >     Require a change in the patch metadata.
> > 
> > What I would recommend is to add a new tag in the patch, it must
> > contain
> > the CVE ID. With this it would be possible to look for the CVE
> > information easily in the testing tool or in NIST, MITRE, or
> > another web
> > page. For example, this would be part of the patch for CVE-2013
> > -6435,
> > currently in OE-Core:
> > 
> > -- snip --
> > 
> > Upstream-Status: Backport
> > CVE: CVE-2013-6435
> > 
> > Reference:
> > https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2013-6435
> > 
> > -- snip --
> > 
> > The expected output of this discussion is a standard format for CVE
> > patches that most, if not all, of community members agree on.
> > 
> > Please let me know your comments.
> > 
> > Cheers,
> > 
> > Mariano Lopez

Re: [RFC] Mark of upstream CVE patches

[Philip Balister]

On 12/15/2015 11:37 AM, Richard Purdie wrote:
> On Tue, 2015-12-15 at 11:30 -0500, Philip Balister wrote:
>> I also suggest copying the
>>
>> https://lists.yoctoproject.org/listinfo/yocto-security
>>
>> list.
> 
> and the architecture list, this is something that should apply to more
> than OE-Core ideally.

I thought the exact same thing seconds after hitting send. I'll let the
security and architecture people decide which list is best for discussion.

What I do want to see is fewer discussions cross posted across many lists.

Philip

> 
> Cheers,
> Richard
> 
>> Philip
>>
>> On 12/15/2015 11:03 AM, Mariano Lopez wrote:
>>> There is an initiative to track vulnerable software being built
>>> (see
>>> bugs 8119 and 7515). The idea is to have a testing tool that would
>>> check
>>> the recipe versions against CVEs. In order to accomplish such task
>>> there
>>> is need to reliable mark the patches from upstream that solve CVEs.
>>>
>>> There have been two options to mark the patches that solve CVEs:
>>>
>>> 1. Have  "CVE" and the CVE number as the patch filename.
>>>   Pros:
>>>     Doesn't require a new tag.
>>>   Cons:
>>>     It is not flexible to add more information, for example two
>>> CVEs in
>>> the same patch
>>>
>>> 2. Add a new tag in the patch that have the CVE information.
>>>   Pros:
>>>     It is flexible and can add more information.
>>>   Cons:
>>>     Require a change in the patch metadata.
>>>
>>> What I would recommend is to add a new tag in the patch, it must
>>> contain
>>> the CVE ID. With this it would be possible to look for the CVE
>>> information easily in the testing tool or in NIST, MITRE, or
>>> another web
>>> page. For example, this would be part of the patch for CVE-2013
>>> -6435,
>>> currently in OE-Core:
>>>
>>> -- snip --
>>>
>>> Upstream-Status: Backport
>>> CVE: CVE-2013-6435
>>>
>>> Reference:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2013-6435
>>>
>>> -- snip --
>>>
>>> The expected output of this discussion is a standard format for CVE
>>> patches that most, if not all, of community members agree on.
>>>
>>> Please let me know your comments.
>>>
>>> Cheers,
>>>
>>> Mariano Lopez
> 

Re: [OE-core] [RFC] Mark of upstream CVE patches

[Philip Balister]

On 12/15/2015 11:37 AM, Richard Purdie wrote:
> On Tue, 2015-12-15 at 11:30 -0500, Philip Balister wrote:
>> I also suggest copying the
>>
>> https://lists.yoctoproject.org/listinfo/yocto-security
>>
>> list.
> 
> and the architecture list, this is something that should apply to more
> than OE-Core ideally.

I thought the exact same thing seconds after hitting send. I'll let the
security and architecture people decide which list is best for discussion.

What I do want to see is fewer discussions cross posted across many lists.

Philip

> 
> Cheers,
> Richard
> 
>> Philip
>>
>> On 12/15/2015 11:03 AM, Mariano Lopez wrote:
>>> There is an initiative to track vulnerable software being built
>>> (see
>>> bugs 8119 and 7515). The idea is to have a testing tool that would
>>> check
>>> the recipe versions against CVEs. In order to accomplish such task
>>> there
>>> is need to reliable mark the patches from upstream that solve CVEs.
>>>
>>> There have been two options to mark the patches that solve CVEs:
>>>
>>> 1. Have  "CVE" and the CVE number as the patch filename.
>>>   Pros:
>>>     Doesn't require a new tag.
>>>   Cons:
>>>     It is not flexible to add more information, for example two
>>> CVEs in
>>> the same patch
>>>
>>> 2. Add a new tag in the patch that have the CVE information.
>>>   Pros:
>>>     It is flexible and can add more information.
>>>   Cons:
>>>     Require a change in the patch metadata.
>>>
>>> What I would recommend is to add a new tag in the patch, it must
>>> contain
>>> the CVE ID. With this it would be possible to look for the CVE
>>> information easily in the testing tool or in NIST, MITRE, or
>>> another web
>>> page. For example, this would be part of the patch for CVE-2013
>>> -6435,
>>> currently in OE-Core:
>>>
>>> -- snip --
>>>
>>> Upstream-Status: Backport
>>> CVE: CVE-2013-6435
>>>
>>> Reference:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2013-6435
>>>
>>> -- snip --
>>>
>>> The expected output of this discussion is a standard format for CVE
>>> patches that most, if not all, of community members agree on.
>>>
>>> Please let me know your comments.
>>>
>>> Cheers,
>>>
>>> Mariano Lopez
> 

Re: [RFC] Mark of upstream CVE patches

[Richard Purdie]

On Tue, 2015-12-15 at 11:49 -0500, Philip Balister wrote:
> On 12/15/2015 11:37 AM, Richard Purdie wrote:
> > On Tue, 2015-12-15 at 11:30 -0500, Philip Balister wrote:
> > > I also suggest copying the
> > > 
> > > https://lists.yoctoproject.org/listinfo/yocto-security
> > > 
> > > list.
> > 
> > and the architecture list, this is something that should apply to
> > more
> > than OE-Core ideally.
> 
> I thought the exact same thing seconds after hitting send. I'll let
> the
> security and architecture people decide which list is best for
> discussion.
> 
> What I do want to see is fewer discussions cross posted across many
> lists.

Agreed, right now I just want people to get thinking about the right
place for some of these discussions to happen too though.

I suspect the right place is architecture since we're likely going to
want to update the patch submission guidelines and reach a wide
audience with this. I believe Mariano will repost onto the architecture
list and anyone interested can join in there.

Cheers,

Richard

Re: [OE-core] [RFC] Mark of upstream CVE patches

[Richard Purdie]

On Tue, 2015-12-15 at 11:49 -0500, Philip Balister wrote:
> On 12/15/2015 11:37 AM, Richard Purdie wrote:
> > On Tue, 2015-12-15 at 11:30 -0500, Philip Balister wrote:
> > > I also suggest copying the
> > > 
> > > https://lists.yoctoproject.org/listinfo/yocto-security
> > > 
> > > list.
> > 
> > and the architecture list, this is something that should apply to
> > more
> > than OE-Core ideally.
> 
> I thought the exact same thing seconds after hitting send. I'll let
> the
> security and architecture people decide which list is best for
> discussion.
> 
> What I do want to see is fewer discussions cross posted across many
> lists.

Agreed, right now I just want people to get thinking about the right
place for some of these discussions to happen too though.

I suspect the right place is architecture since we're likely going to
want to update the patch submission guidelines and reach a wide
audience with this. I believe Mariano will repost onto the architecture
list and anyone interested can join in there.

Cheers,

Richard

Re: [RFC] Mark of upstream CVE patches

[Mariano Lopez]

On 12/15/2015 11:13 AM, Richard Purdie wrote:
> On Tue, 2015-12-15 at 11:49 -0500, Philip Balister wrote:
>> On 12/15/2015 11:37 AM, Richard Purdie wrote:
>>> On Tue, 2015-12-15 at 11:30 -0500, Philip Balister wrote:
>>>> I also suggest copying the
>>>>
>>>> https://lists.yoctoproject.org/listinfo/yocto-security
>>>>
>>>> list.
>>> and the architecture list, this is something that should apply to
>>> more
>>> than OE-Core ideally.
>> I thought the exact same thing seconds after hitting send. I'll let
>> the
>> security and architecture people decide which list is best for
>> discussion.
>>
>> What I do want to see is fewer discussions cross posted across many
>> lists.
> Agreed, right now I just want people to get thinking about the right
> place for some of these discussions to happen too though.
>
> I suspect the right place is architecture since we're likely going to
> want to update the patch submission guidelines and reach a wide
> audience with this. I believe Mariano will repost onto the architecture
> list and anyone interested can join in there.

I just started the thread onto the architecture list, lets move move the 
discussion there. Here is the link:

http://lists.openembedded.org/pipermail/openembedded-architecture/2015-December/000025.html

>
> Cheers,
>
> Richard
>
>
>
>
>

Re: [OE-core] [RFC] Mark of upstream CVE patches

[Mariano Lopez]

On 12/15/2015 11:13 AM, Richard Purdie wrote:
> On Tue, 2015-12-15 at 11:49 -0500, Philip Balister wrote:
>> On 12/15/2015 11:37 AM, Richard Purdie wrote:
>>> On Tue, 2015-12-15 at 11:30 -0500, Philip Balister wrote:
>>>> I also suggest copying the
>>>>
>>>> https://lists.yoctoproject.org/listinfo/yocto-security
>>>>
>>>> list.
>>> and the architecture list, this is something that should apply to
>>> more
>>> than OE-Core ideally.
>> I thought the exact same thing seconds after hitting send. I'll let
>> the
>> security and architecture people decide which list is best for
>> discussion.
>>
>> What I do want to see is fewer discussions cross posted across many
>> lists.
> Agreed, right now I just want people to get thinking about the right
> place for some of these discussions to happen too though.
>
> I suspect the right place is architecture since we're likely going to
> want to update the patch submission guidelines and reach a wide
> audience with this. I believe Mariano will repost onto the architecture
> list and anyone interested can join in there.

I just started the thread onto the architecture list, lets move move the 
discussion there. Here is the link:

http://lists.openembedded.org/pipermail/openembedded-architecture/2015-December/000025.html

>
> Cheers,
>
> Richard
>
>
>
>
>

Re: [RFC] Mark of upstream CVE patches

[Sona Sarmadi]

Hi Mariano, all,

See my comments regarding "Bug 8119 - Define a format to mark Upstream CVE patches" below.


> There is an initiative to track vulnerable software being built (see bugs 8119
> and 7515). The idea is to have a testing tool that would check the recipe
> versions against CVEs. In order to accomplish such task there is need to
> reliable mark the patches from upstream that solve CVEs.
> 
> There have been two options to mark the patches that solve CVEs:
> 
> 1. Have  "CVE" and the CVE number as the patch filename.
>    Pros:
>      Doesn't require a new tag.
>    Cons:
>      It is not flexible to add more information, for example two CVEs in the same
> patch
> 2. Add a new tag in the patch that have the CVE information.
>    Pros:
>      It is flexible and can add more information.
>    Cons:
>      Require a change in the patch metadata.
> 
> What I would recommend is to add a new tag in the patch, it must contain the
> CVE ID. With this it would be possible to look for the CVE information easily in
> the testing tool or in NIST, MITRE, or another web page. For example, this
> would be part of the patch for CVE-2013-6435, currently in OE-Core:
> 
> -- snip --
> 
> Upstream-Status: Backport
> CVE: CVE-2013-6435
> 
> Reference:
> https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2013-6435
> 
> -- snip --
> 
> The expected output of this discussion is a standard format for CVE patches
> that most, if not all, of community members agree on.
> 
> Please let me know your comments.

We are supposed to have reference to the CVE identifier both in the patch file/s
 and the commit message(e.g.  xxx- CVE-2013-6435.pacth) according to the guidelines 
for "Patch name convention and commit message" in the Yocto 
Wiki https://wiki.yoctoproject.org/wiki/Security.

If a patch address multiple CVEs, perhaps we should name the patch:
Fix-for-multiple-CVEs.patch and list all CVEs in the patch file.

Will this not solve the problem? Do you think there is still need for a new tag "CVE"?

Adding RedHat reference is ok for me along with Mitre & NVD or other useful 
& reliable references.

I have updated Yocto security wiki. Please feel free to update the page if you have 
some improvement or send your text/suggestion to me or Michael and we will help you.

Thanks
//Sona

Re: [RFC] Mark of upstream CVE patches

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 806 bytes --]

On 16 December 2015 at 09:03, Sona Sarmadi <sona.sarmadi@enea.com> wrote:

> We are supposed to have reference to the CVE identifier both in the patch
> file/s
>  and the commit message(e.g.  xxx- CVE-2013-6435.pacth) according to the
> guidelines
> for "Patch name convention and commit message" in the Yocto
> Wiki https://wiki.yoctoproject.org/wiki/Security.
>
> If a patch address multiple CVEs, perhaps we should name the patch:
> Fix-for-multiple-CVEs.patch and list all CVEs in the patch file.
>
> Will this not solve the problem? Do you think there is still need for a
> new tag "CVE"?
>

I'd say a new tag is essential if we want to automate tooling, to reduce
the chance of false-positives from simply searching the patch for something
that looks like a CVE reference.

Ross

[-- Attachment #2: Type: text/html, Size: 1334 bytes --]

Re: [OE-core] [RFC] Mark of upstream CVE patches

[Burton, Ross]

On 16 December 2015 at 09:03, Sona Sarmadi <sona.sarmadi@enea.com> wrote:

> We are supposed to have reference to the CVE identifier both in the patch
> file/s
>  and the commit message(e.g.  xxx- CVE-2013-6435.pacth) according to the
> guidelines
> for "Patch name convention and commit message" in the Yocto
> Wiki https://wiki.yoctoproject.org/wiki/Security.
>
> If a patch address multiple CVEs, perhaps we should name the patch:
> Fix-for-multiple-CVEs.patch and list all CVEs in the patch file.
>
> Will this not solve the problem? Do you think there is still need for a
> new tag "CVE"?
>

I'd say a new tag is essential if we want to automate tooling, to reduce
the chance of false-positives from simply searching the patch for something
that looks like a CVE reference.

Ross

Re: [RFC] Mark of upstream CVE patches

[Mariano Lopez]

[-- Attachment #1: Type: text/plain, Size: 1107 bytes --]



On 12/16/2015 03:21 AM, Burton, Ross wrote:
>
> On 16 December 2015 at 09:03, Sona Sarmadi <sona.sarmadi@enea.com 
> <mailto:sona.sarmadi@enea.com>> wrote:
>
>     We are supposed to have reference to the CVE identifier both in
>     the patch file/s
>      and the commit message(e.g.  xxx- CVE-2013-6435.pacth) according
>     to the guidelines
>     for "Patch name convention and commit message" in the Yocto
>     Wiki https://wiki.yoctoproject.org/wiki/Security.
>
>     If a patch address multiple CVEs, perhaps we should name the patch:
>     Fix-for-multiple-CVEs.patch and list all CVEs in the patch file.
>
>     Will this not solve the problem? Do you think there is still need
>     for a new tag "CVE"?
>
>
> I'd say a new tag is essential if we want to automate tooling, to 
> reduce the chance of false-positives from simply searching the patch 
> for something that looks like a CVE reference.
>
> Ross

The conclusion of this thread is to add the tag "CVE" to the metadata of 
submitted CVE patches. I will edit the wiki to show this requirement.

Mariano

[-- Attachment #2: Type: text/html, Size: 2526 bytes --]

Re: [OE-core] [RFC] Mark of upstream CVE patches

[Mariano Lopez]

On 12/16/2015 03:21 AM, Burton, Ross wrote:
>
> On 16 December 2015 at 09:03, Sona Sarmadi <sona.sarmadi@enea.com 
> <mailto:sona.sarmadi@enea.com>> wrote:
>
>     We are supposed to have reference to the CVE identifier both in
>     the patch file/s
>      and the commit message(e.g.  xxx- CVE-2013-6435.pacth) according
>     to the guidelines
>     for "Patch name convention and commit message" in the Yocto
>     Wiki https://wiki.yoctoproject.org/wiki/Security.
>
>     If a patch address multiple CVEs, perhaps we should name the patch:
>     Fix-for-multiple-CVEs.patch and list all CVEs in the patch file.
>
>     Will this not solve the problem? Do you think there is still need
>     for a new tag "CVE"?
>
>
> I'd say a new tag is essential if we want to automate tooling, to 
> reduce the chance of false-positives from simply searching the patch 
> for something that looks like a CVE reference.
>
> Ross

The conclusion of this thread is to add the tag "CVE" to the metadata of 
submitted CVE patches. I will edit the wiki to show this requirement.

Mariano

Re: [oe] [RFC] Mark of upstream CVE patches

[Benjamin Esquivel]

On Mon, 2016-01-04 at 12:25 -0600, Mariano Lopez wrote:
> 
> On 12/16/2015 03:21 AM, Burton, Ross wrote:
> > 
> > On 16 December 2015 at 09:03, Sona Sarmadi <sona.sarmadi@enea.com 
> > <mailto:sona.sarmadi@enea.com>> wrote:
> > 
> >     We are supposed to have reference to the CVE identifier both in
> >     the patch file/s
> >      and the commit message(e.g.  xxx- CVE-2013-6435.pacth)
> > according
> >     to the guidelines
> >     for "Patch name convention and commit message" in the Yocto
> >     Wiki https://wiki.yoctoproject.org/wiki/Security.
> > 
> >     If a patch address multiple CVEs, perhaps we should name the
> > patch:
> >     Fix-for-multiple-CVEs.patch and list all CVEs in the patch
> > file.
> > 
> >     Will this not solve the problem? Do you think there is still
> > need
> >     for a new tag "CVE"?
> > 
> > 
> > I'd say a new tag is essential if we want to automate tooling, to 
> > reduce the chance of false-positives from simply searching the
> > patch 
> > for something that looks like a CVE reference.
> > 
> > Ross
> 
> The conclusion of this thread is to add the tag "CVE" to the metadata
> of 
> submitted CVE patches. I will edit the wiki to show this requirement.

Please let us know when the wiki has the changes reflected :)
 
> 
> Mariano

Re: [OE-core] [RFC] Mark of upstream CVE patches

[Benjamin Esquivel]

On Mon, 2016-01-04 at 12:25 -0600, Mariano Lopez wrote:
> 
> On 12/16/2015 03:21 AM, Burton, Ross wrote:
> > 
> > On 16 December 2015 at 09:03, Sona Sarmadi <sona.sarmadi@enea.com 
> > <mailto:sona.sarmadi@enea.com>> wrote:
> > 
> >     We are supposed to have reference to the CVE identifier both in
> >     the patch file/s
> >      and the commit message(e.g.  xxx- CVE-2013-6435.pacth)
> > according
> >     to the guidelines
> >     for "Patch name convention and commit message" in the Yocto
> >     Wiki https://wiki.yoctoproject.org/wiki/Security.
> > 
> >     If a patch address multiple CVEs, perhaps we should name the
> > patch:
> >     Fix-for-multiple-CVEs.patch and list all CVEs in the patch
> > file.
> > 
> >     Will this not solve the problem? Do you think there is still
> > need
> >     for a new tag "CVE"?
> > 
> > 
> > I'd say a new tag is essential if we want to automate tooling, to 
> > reduce the chance of false-positives from simply searching the
> > patch 
> > for something that looks like a CVE reference.
> > 
> > Ross
> 
> The conclusion of this thread is to add the tag "CVE" to the metadata
> of 
> submitted CVE patches. I will edit the wiki to show this requirement.

Please let us know when the wiki has the changes reflected :)
 
> 
> Mariano

Re: [oe] [RFC] Mark of upstream CVE patches

[Mariano Lopez]

On 01/04/2016 02:17 PM, Benjamin Esquivel wrote:
> On Mon, 2016-01-04 at 12:25 -0600, Mariano Lopez wrote:
>> On 12/16/2015 03:21 AM, Burton, Ross wrote:
>>> On 16 December 2015 at 09:03, Sona Sarmadi <sona.sarmadi@enea.com
>>> <mailto:sona.sarmadi@enea.com>> wrote:
>>>
>>>      We are supposed to have reference to the CVE identifier both in
>>>      the patch file/s
>>>       and the commit message(e.g.  xxx- CVE-2013-6435.pacth)
>>> according
>>>      to the guidelines
>>>      for "Patch name convention and commit message" in the Yocto
>>>      Wiki https://wiki.yoctoproject.org/wiki/Security.
>>>
>>>      If a patch address multiple CVEs, perhaps we should name the
>>> patch:
>>>      Fix-for-multiple-CVEs.patch and list all CVEs in the patch
>>> file.
>>>
>>>      Will this not solve the problem? Do you think there is still
>>> need
>>>      for a new tag "CVE"?
>>>
>>>
>>> I'd say a new tag is essential if we want to automate tooling, to
>>> reduce the chance of false-positives from simply searching the
>>> patch
>>> for something that looks like a CVE reference.
>>>
>>> Ross
>> The conclusion of this thread is to add the tag "CVE" to the metadata
>> of
>> submitted CVE patches. I will edit the wiki to show this requirement.
> Please let us know when the wiki has the changes reflected :)

You can find it here:

http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines#CVE_Patches

>   
>> Mariano

-- 
Mariano Lopez

Re: [OE-core] [RFC] Mark of upstream CVE patches

[Mariano Lopez]

On 01/04/2016 02:17 PM, Benjamin Esquivel wrote:
> On Mon, 2016-01-04 at 12:25 -0600, Mariano Lopez wrote:
>> On 12/16/2015 03:21 AM, Burton, Ross wrote:
>>> On 16 December 2015 at 09:03, Sona Sarmadi <sona.sarmadi@enea.com
>>> <mailto:sona.sarmadi@enea.com>> wrote:
>>>
>>>      We are supposed to have reference to the CVE identifier both in
>>>      the patch file/s
>>>       and the commit message(e.g.  xxx- CVE-2013-6435.pacth)
>>> according
>>>      to the guidelines
>>>      for "Patch name convention and commit message" in the Yocto
>>>      Wiki https://wiki.yoctoproject.org/wiki/Security.
>>>
>>>      If a patch address multiple CVEs, perhaps we should name the
>>> patch:
>>>      Fix-for-multiple-CVEs.patch and list all CVEs in the patch
>>> file.
>>>
>>>      Will this not solve the problem? Do you think there is still
>>> need
>>>      for a new tag "CVE"?
>>>
>>>
>>> I'd say a new tag is essential if we want to automate tooling, to
>>> reduce the chance of false-positives from simply searching the
>>> patch
>>> for something that looks like a CVE reference.
>>>
>>> Ross
>> The conclusion of this thread is to add the tag "CVE" to the metadata
>> of
>> submitted CVE patches. I will edit the wiki to show this requirement.
> Please let us know when the wiki has the changes reflected :)

You can find it here:

http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines#CVE_Patches

>   
>> Mariano

-- 
Mariano Lopez