Mark of upstream CVE patches

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 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

I also suggest copying the

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

list.

Philip

Quoted 51 lines · 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

Quoted 5 lines · Philip Balister

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

Quoted 54 lines

Philip

Quoted 51 lines · 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

Quoted 10 lines · Richard Purdie

Quoted 5 lines · Philip Balister

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.

Quoted 10 lines · Philip Balister

Quoted 9 lines · Richard Purdie

Quoted 5 lines · Philip Balister

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.

Quoted 7 lines

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

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"?

On 16 December 2015 at 09:03, Sona Sarmadi <[email protected] <mailto:[email protected]>> 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

Quoted 27 lines · Ross

On 16 December 2015 at 09:03, Sona Sarmadi <[email protected] <mailto:[email protected]>> 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.

Quoted 1 line

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

Quoted 27 lines · Mariano Lopez

Quoted 26 lines · Ross

On 16 December 2015 at 09:03, Sona Sarmadi <[email protected] <mailto:[email protected]>> 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.

Quoted 4 lines

Quoted 1 line

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 :)

Quoted 2 lines

Mariano