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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
