Yocto Project - User contributions [en]

How do I

2016-10-28T09:01:35Z

SonaSarmadi:

== Q: How do get the package manager binaries on my target rootfs? ==

'''A:''' Make sure your image has IMAGE_FEATURES += "package-management" included.

== Q: How do I create my own source download mirror ? ==

'''A:'''
Make a complete build with these variables set in your <code>conf/local.conf</code>:

SOURCE_MIRROR_URL ?= "file://source_mirror/sources/"
INHERIT += "own-mirrors"
BB_GENERATE_MIRROR_TARBALLS = "1"

After a complete build, copy all *files* (not symlinks) in your download directory to the desired source mirror directory. Test by setting the variables below in <code>conf/local.conf</code>:

SOURCE_MIRROR_URL ?= "file://source_mirror/sources/"
INHERIT += "own-mirrors"
BB_GENERATE_MIRROR_TARBALLS = "1"
BB_NO_NETWORK = "1"

If you are building with <code>BB_NO_NETWORK</code> and using external layers that are not part of the base Yocto distribution, be aware that recipes which:

# Specify a Git repo as the source, and,
# Specify the revision to be built using a tag name

will cause your build to abort when Bitbake tries to run <code>git ls-remote</code> to resolve the tag name and is unable to access the network. So don't specify <code>SRC_URI</code> like this:

<nowiki>SRC_URI = "git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git;tag=v${PV}"</nowiki>

Instead, use:

<nowiki>SRC_URI = "git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git"</nowiki>
SRCREV = "8885ced062131214448fae056ef453f094303805"

Before putting together your pre-mirror, this command can be used from
your top-level source directory to identify recipes that might be
problematic with <code>BB_NO_NETWORK</code> enabled:

find -name "*.inc" -o -name "*.bb" | xargs grep -li "git;tag="

== Q: How do I put Yocto on a hard drive? ==

'''A:''' bitbake core-image-sato or core-image-sato-sdk

# have a suitable partition on the disk - say partition #3
# this partition will show up as sde3 on my host machine and sda3 on the atom
# mkfs.ext3 /dev/sde3
# mount /dev/sde3 /mnt/target
# mount -o loop tmp/deploy/images/core-image-sato-sdk.ext3 /mnt/target-ext3
# cp -a /mnt/target-ext3/* /mnt/target
# grub-install --recheck --root-directory=/mnt/target /dev/sde

If grub install passed, copy the following to /mnt/target/boot/grub/grub.cfg

set default="0"
set timeout="30"

menuentry 'Yocto SDK' {
insmod part_msdos
insmod ext2
set root='(hd0,msdos3)'
linux /boot/bzImage root=/dev/sda3
}

Thats it - this should boot.

== Q: How do I put my recipe into Yocto? ==

'''A:''' Let's use the Hello World example from Section 3.1.2 of the Yocto Project Reference Manual and expand on it.

* In this example, I'll start with a new meta layer named "meta-jfa" in the Yocto Project files directory, which is named "poky". Then, I will add the new recipe and build the image, which is named "core-image-minimal". I will build it using the autotooled package option. Once built, the image will have the “hello” application.

;Step One
:Create the following directory structure in the ~/poky directory. I'll use my initials to denote the layer and recipe name:

mkdir meta-jfa
mkdir meta-jfa/conf
mkdir meta-jfa/recipes-jfa
mkdir meta-jfa/recipes-jfa/hello

;Step Two
:Next, to make sure the recipe gets searched and located, I'll create the layer.conf file in the meta-jfa/conf directory as follows:

# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"
# We have a packages directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "jfa"
BBFILE_PATTERN_jfa := "^${LAYERDIR}/"
BBFILE_PRIORITY_jfa := "5"

;Step Three
:Now I need to put the recipe (.bb) file into the right directory. So, I will put the file hello_2.7.bb into the meta-jfa/recipes-jfa/hello directory. I picked version 2.7 of the hello program by going to the gnu site for the application (ftp://ftp.gnu.org/gnu/hello/) and downloading it to checkout the version I wanted to include. hello-2.7.tar.gz is the most current. I downloaded it locally and expanded it to look at the license information. The hello_2.7.bb file contains the following:

DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv3+"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
PR = "r0"
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
inherit autotools gettext
:Here is some explanation for a few of the recipe statements:
:* LIC_FILES_CHKSUM = is required and, using file location defaults, points to the COPYING file that is part of the tarball that is downloaded from the SRC_URI address. The md5= part of the statement is generated by running “md5sum COPYING” against the COPYING file I downloaded to examine.
:* ${PV} in the SRC_URI statement is picked up from the part of the recipe file name after the “_”. In this case PV =2.7.

;Step Four
:The recipe is built, so now I can run it:

cd ~/poky
source oe-init-build-env build-hello.

;Step Five
:Before I can use BitBake I need to edit two files. Sourcing the oe-init-build-env file above leaves me in the build-hello directory. Before issuing the bitbake command I need to edit the files conf/local.conf and conf/bblayers.conf in that build-hello directory. The bblayers.conf needs to have the one line added to include the layer you created.

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "4"
BBFILES ?= ""
BBLAYERS = " \
/home/jim/poky/meta \
/home/jim/poky/meta-yocto \
/home/jim/poky/meta-jfa \
"

;Step Six
:The conf/local.conf file needs to have the parallel processing lines edited to speed up the baking on multicore systems. I can do that by uncommenting the BB_NUMBER_THREADS and PARALLEL_MAKE variables. Generally, I would set them equal to twice the number of cores used by my host machine. By default, the MACHINE variable is set to qemux86 and for this example is fine. I need to add a line to include the hello package I am building into the image by adding the following line:

IMAGE_INSTALL_append = " hello"

;Step Seven
:Now I can bake it with this command:
bitbake core-image-minimal
;Step Eight
:Once the image is built, I can test it by starting the QEMU emulator:

runqemu qemux86

;Step Nine
:Once the emulator comes up, login as root with no password. Then, at the prompt, enter "hello" to run your application.

==Q: How do I setup Intel® Atom™ Processor E6xx based system for media playback? ==

'''A:''' To playback media files on an Atom E6xx processor, you need to have the EMGD GFX driver installed. There is a README on this installation in the meta-crownbay directory. However, the official support for EMGD with accelerated 3D and media decode is scheduled for release 1.2, but is in the git repository now, so you need to start with branch, "master" of both the poky and meta-intel repository. And you will need the Intel Crownbay reference platform for the Atom E6xx processor or similar hardware.

; Step 1
Follow the Appendix A example in the Yocto Project Development Manual, but instead of editing out the crownbay references and using the crownbay-noemgd, you do the opposite.

One edit you need to add to the Appendix A instructions is for the file ~/poky/meta-intel/meta-mymachine/conf/mymachine.conf. You need to add the following statement to include audio features needed for the audio part of the videos:
MACHINE_FEATURES += "alsa"

; Step 2
In the Appendix A example a couple of changes are needed to the conf/local.conf and conf/bblayers.conf file edits from the standard example. The bblayers.conf file BBLAYERS statement should look like below, except correct the absolute path to match your system:
BBLAYERS ?= " \
/home/jim/poky/meta \
/home/jim/poky/meta-yocto \
/home/jim/poky/meta-intel \
/home/jim/poky/meta-intel/meta-mymachine \
"
The local.conf file should have some statements in addition to what the Appendix A used:
LICENSE_FLAGS_WHITELIST = "license_emgd-driver-bin_1.10"

# The 2 statements below allow the playing of MP3 files.
# Not specific to videos, but usually included on media use systems.
LICENSE_FLAGS_WHITELIST += "commercial"
POKY_EXTRA_INSTALL += "gst-fluendo-mp3"

# add debug development tweaks and test applications, which include amixer, aplay, arecord, etc.
EXTRA_IMAGE_FEATURES = "debug-tweaks tools-testapps"
; Step 3
After bitbaking the core-image-sato image, I put the .ext3 image on a hard drive per the above How Do I. I also added some h.264, mp4, m4a, and mp3 files to play with before moving the hard drive to the target hardware system.

I used both the Sato GUI Music and Video players to play the files.

That's all there is to it.

==Q: How do I tweak my build system and BitBake configuration for optimal build time as well as provide some guidance on how to collect build metrics and identify bottlenecks. ? ==

'''A:''' You should read the [https://wiki.yoctoproject.org/wiki/Build_Performance Build Performance] wiki page. It provides general tips, a description of the bb-matrix script used for collecting relevant build metrics, a description of how to enable buildstats to generate build performance log data, and a description of how best to apply parallelism to the build.

==Q: How do I get the networking to function on an Acer Aspire One n450 based netbook when using the meta-n450 BSP? ==

'''A:''' While the n450 BSP will boot on the Acer AO532h netbook, the BSP does not enable the Atheros AR5B95 Wireless and AR8132 fast ethernet adapters. The Linux Yocto 3.2 kernel has these drivers, but they are not enabled. All you have to do is to create a Config Fragment file with a .cfg extension in a new directory called 'linux-yocto' in the BSP recipes-kernel/linux directory. The new 'linux-yocto' directory will be at the same level as the linux-yocto_3.2.bbappend file. You will also need to add the following statement to the .bbappend file:

SRC_URI += "file://myconfig.cfg"

The recipes-kernel/linux/linux-yocto/myconfig.cfg needs to contain the following 2 lines:

CONFIG_ATH9K_PCI=y

CONFIG_ATL1C=y

==Q: How do I build the build appliance? ==
'''A:''' Update the MACHINE variable to "qemux86-64" or "qemux86" in your <code>conf/local.conf</code> :

Then, run this command:
# bitbake build-appliance-image

The resulting images (*.vmdk, *.vmx, *.vmxf) will be present in the "tmp/deploy/images" folder
ie:

# unzip Yocto_Build_Appliance.zip
# cd Yocto_Build_Appliance
# ls
Yocto_Build_Appliance.vmdk
Yocto_Build_Appliance.vmx
Yocto_Build_Appliance.vmxf

==Q: How do I build an image without GPLv3 Licensed packages ? ==
'''A:''' Add this line 'INCOMPATIBLE_LICENSE = "GPLv3"' in your <code>conf/local.conf</code> :

Then, build the image:
# bitbake <image-name>

==Q: How do I ensure that I am using the latest upstream version of the package? ==
'''A:''' Add this line 'INHERIT += "distrodata"' in your <code>conf/local.conf</code> :

After that, run this command in the build directory:
# bitbake -c checkpkg <package>
Then, check the 'Version' and 'Upver' fields in the below listed file:
# gedit tmp/log/checkpkg.csv

If those versions are same, then we have the latest upstream version of package

==Q: How do I get a list of CVEs patched? ==
'''A:''' cve-check tool is available from 2.2 release (poky/meta/recipes-devtools/cve-check-tool)

To run it just inherit the class in conf/local.conf file:

# INHERIT += "cve-check"

Source and run:
# bitbake -c cve_check openssl
# bitbake core-image-sato
# bitbake -k -c cve_check universe

Log files are created under
unzip/1_6.0-r5/cve/cve.log
gnutls/3.5.3-r0/cve/cve.log
glibc/2.24-r0/cve/cve.log
glibc-initial/2.24-r0/cve/cve.log
...

Example of log file:
PACKAGE NAME: perl
PACKAGE VERSION: 5.22.1
CVE: CVE-2016-1238
CVE STATUS: Patched
CVE SUMMARY: ....
....
CVSS v2 BASE SCORE: 7.2
VECTOR: LOCAL
MORE INFORMATION: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-1238

How do I

2016-10-28T08:53:38Z

SonaSarmadi:

== Q: How do get the package manager binaries on my target rootfs? ==

'''A:''' Make sure your image has IMAGE_FEATURES += "package-management" included.

== Q: How do I create my own source download mirror ? ==

'''A:'''
Make a complete build with these variables set in your <code>conf/local.conf</code>:

SOURCE_MIRROR_URL ?= "file://source_mirror/sources/"
INHERIT += "own-mirrors"
BB_GENERATE_MIRROR_TARBALLS = "1"

After a complete build, copy all *files* (not symlinks) in your download directory to the desired source mirror directory. Test by setting the variables below in <code>conf/local.conf</code>:

SOURCE_MIRROR_URL ?= "file://source_mirror/sources/"
INHERIT += "own-mirrors"
BB_GENERATE_MIRROR_TARBALLS = "1"
BB_NO_NETWORK = "1"

If you are building with <code>BB_NO_NETWORK</code> and using external layers that are not part of the base Yocto distribution, be aware that recipes which:

# Specify a Git repo as the source, and,
# Specify the revision to be built using a tag name

will cause your build to abort when Bitbake tries to run <code>git ls-remote</code> to resolve the tag name and is unable to access the network. So don't specify <code>SRC_URI</code> like this:

<nowiki>SRC_URI = "git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git;tag=v${PV}"</nowiki>

Instead, use:

<nowiki>SRC_URI = "git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git"</nowiki>
SRCREV = "8885ced062131214448fae056ef453f094303805"

Before putting together your pre-mirror, this command can be used from
your top-level source directory to identify recipes that might be
problematic with <code>BB_NO_NETWORK</code> enabled:

find -name "*.inc" -o -name "*.bb" | xargs grep -li "git;tag="

== Q: How do I put Yocto on a hard drive? ==

'''A:''' bitbake core-image-sato or core-image-sato-sdk

# have a suitable partition on the disk - say partition #3
# this partition will show up as sde3 on my host machine and sda3 on the atom
# mkfs.ext3 /dev/sde3
# mount /dev/sde3 /mnt/target
# mount -o loop tmp/deploy/images/core-image-sato-sdk.ext3 /mnt/target-ext3
# cp -a /mnt/target-ext3/* /mnt/target
# grub-install --recheck --root-directory=/mnt/target /dev/sde

If grub install passed, copy the following to /mnt/target/boot/grub/grub.cfg

set default="0"
set timeout="30"

menuentry 'Yocto SDK' {
insmod part_msdos
insmod ext2
set root='(hd0,msdos3)'
linux /boot/bzImage root=/dev/sda3
}

Thats it - this should boot.

== Q: How do I put my recipe into Yocto? ==

'''A:''' Let's use the Hello World example from Section 3.1.2 of the Yocto Project Reference Manual and expand on it.

* In this example, I'll start with a new meta layer named "meta-jfa" in the Yocto Project files directory, which is named "poky". Then, I will add the new recipe and build the image, which is named "core-image-minimal". I will build it using the autotooled package option. Once built, the image will have the “hello” application.

;Step One
:Create the following directory structure in the ~/poky directory. I'll use my initials to denote the layer and recipe name:

mkdir meta-jfa
mkdir meta-jfa/conf
mkdir meta-jfa/recipes-jfa
mkdir meta-jfa/recipes-jfa/hello

;Step Two
:Next, to make sure the recipe gets searched and located, I'll create the layer.conf file in the meta-jfa/conf directory as follows:

# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"
# We have a packages directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "jfa"
BBFILE_PATTERN_jfa := "^${LAYERDIR}/"
BBFILE_PRIORITY_jfa := "5"

;Step Three
:Now I need to put the recipe (.bb) file into the right directory. So, I will put the file hello_2.7.bb into the meta-jfa/recipes-jfa/hello directory. I picked version 2.7 of the hello program by going to the gnu site for the application (ftp://ftp.gnu.org/gnu/hello/) and downloading it to checkout the version I wanted to include. hello-2.7.tar.gz is the most current. I downloaded it locally and expanded it to look at the license information. The hello_2.7.bb file contains the following:

DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv3+"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
PR = "r0"
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
inherit autotools gettext
:Here is some explanation for a few of the recipe statements:
:* LIC_FILES_CHKSUM = is required and, using file location defaults, points to the COPYING file that is part of the tarball that is downloaded from the SRC_URI address. The md5= part of the statement is generated by running “md5sum COPYING” against the COPYING file I downloaded to examine.
:* ${PV} in the SRC_URI statement is picked up from the part of the recipe file name after the “_”. In this case PV =2.7.

;Step Four
:The recipe is built, so now I can run it:

cd ~/poky
source oe-init-build-env build-hello.

;Step Five
:Before I can use BitBake I need to edit two files. Sourcing the oe-init-build-env file above leaves me in the build-hello directory. Before issuing the bitbake command I need to edit the files conf/local.conf and conf/bblayers.conf in that build-hello directory. The bblayers.conf needs to have the one line added to include the layer you created.

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "4"
BBFILES ?= ""
BBLAYERS = " \
/home/jim/poky/meta \
/home/jim/poky/meta-yocto \
/home/jim/poky/meta-jfa \
"

;Step Six
:The conf/local.conf file needs to have the parallel processing lines edited to speed up the baking on multicore systems. I can do that by uncommenting the BB_NUMBER_THREADS and PARALLEL_MAKE variables. Generally, I would set them equal to twice the number of cores used by my host machine. By default, the MACHINE variable is set to qemux86 and for this example is fine. I need to add a line to include the hello package I am building into the image by adding the following line:

IMAGE_INSTALL_append = " hello"

;Step Seven
:Now I can bake it with this command:
bitbake core-image-minimal
;Step Eight
:Once the image is built, I can test it by starting the QEMU emulator:

runqemu qemux86

;Step Nine
:Once the emulator comes up, login as root with no password. Then, at the prompt, enter "hello" to run your application.

==Q: How do I setup Intel® Atom™ Processor E6xx based system for media playback? ==

'''A:''' To playback media files on an Atom E6xx processor, you need to have the EMGD GFX driver installed. There is a README on this installation in the meta-crownbay directory. However, the official support for EMGD with accelerated 3D and media decode is scheduled for release 1.2, but is in the git repository now, so you need to start with branch, "master" of both the poky and meta-intel repository. And you will need the Intel Crownbay reference platform for the Atom E6xx processor or similar hardware.

; Step 1
Follow the Appendix A example in the Yocto Project Development Manual, but instead of editing out the crownbay references and using the crownbay-noemgd, you do the opposite.

One edit you need to add to the Appendix A instructions is for the file ~/poky/meta-intel/meta-mymachine/conf/mymachine.conf. You need to add the following statement to include audio features needed for the audio part of the videos:
MACHINE_FEATURES += "alsa"

; Step 2
In the Appendix A example a couple of changes are needed to the conf/local.conf and conf/bblayers.conf file edits from the standard example. The bblayers.conf file BBLAYERS statement should look like below, except correct the absolute path to match your system:
BBLAYERS ?= " \
/home/jim/poky/meta \
/home/jim/poky/meta-yocto \
/home/jim/poky/meta-intel \
/home/jim/poky/meta-intel/meta-mymachine \
"
The local.conf file should have some statements in addition to what the Appendix A used:
LICENSE_FLAGS_WHITELIST = "license_emgd-driver-bin_1.10"

# The 2 statements below allow the playing of MP3 files.
# Not specific to videos, but usually included on media use systems.
LICENSE_FLAGS_WHITELIST += "commercial"
POKY_EXTRA_INSTALL += "gst-fluendo-mp3"

# add debug development tweaks and test applications, which include amixer, aplay, arecord, etc.
EXTRA_IMAGE_FEATURES = "debug-tweaks tools-testapps"
; Step 3
After bitbaking the core-image-sato image, I put the .ext3 image on a hard drive per the above How Do I. I also added some h.264, mp4, m4a, and mp3 files to play with before moving the hard drive to the target hardware system.

I used both the Sato GUI Music and Video players to play the files.

That's all there is to it.

==Q: How do I tweak my build system and BitBake configuration for optimal build time as well as provide some guidance on how to collect build metrics and identify bottlenecks. ? ==

'''A:''' You should read the [https://wiki.yoctoproject.org/wiki/Build_Performance Build Performance] wiki page. It provides general tips, a description of the bb-matrix script used for collecting relevant build metrics, a description of how to enable buildstats to generate build performance log data, and a description of how best to apply parallelism to the build.

==Q: How do I get the networking to function on an Acer Aspire One n450 based netbook when using the meta-n450 BSP? ==

'''A:''' While the n450 BSP will boot on the Acer AO532h netbook, the BSP does not enable the Atheros AR5B95 Wireless and AR8132 fast ethernet adapters. The Linux Yocto 3.2 kernel has these drivers, but they are not enabled. All you have to do is to create a Config Fragment file with a .cfg extension in a new directory called 'linux-yocto' in the BSP recipes-kernel/linux directory. The new 'linux-yocto' directory will be at the same level as the linux-yocto_3.2.bbappend file. You will also need to add the following statement to the .bbappend file:

SRC_URI += "file://myconfig.cfg"

The recipes-kernel/linux/linux-yocto/myconfig.cfg needs to contain the following 2 lines:

CONFIG_ATH9K_PCI=y

CONFIG_ATL1C=y

==Q: How do I build the build appliance? ==
'''A:''' Update the MACHINE variable to "qemux86-64" or "qemux86" in your <code>conf/local.conf</code> :

Then, run this command:
# bitbake build-appliance-image

The resulting images (*.vmdk, *.vmx, *.vmxf) will be present in the "tmp/deploy/images" folder
ie:

# unzip Yocto_Build_Appliance.zip
# cd Yocto_Build_Appliance
# ls
Yocto_Build_Appliance.vmdk
Yocto_Build_Appliance.vmx
Yocto_Build_Appliance.vmxf

==Q: How do I build an image without GPLv3 Licensed packages ? ==
'''A:''' Add this line 'INCOMPATIBLE_LICENSE = "GPLv3"' in your <code>conf/local.conf</code> :

Then, build the image:
# bitbake <image-name>

==Q: How do I ensure that I am using the latest upstream version of the package? ==
'''A:''' Add this line 'INHERIT += "distrodata"' in your <code>conf/local.conf</code> :

After that, run this command in the build directory:
# bitbake -c checkpkg <package>
Then, check the 'Version' and 'Upver' fields in the below listed file:
# gedit tmp/log/checkpkg.csv

If those versions are same, then we have the latest upstream version of package

==Q: How do I get a list of CVEs patched? ==
'''A:''' > cve-check tool is available from 2.2 release (poky/meta/recipes-devtools/cve-check-tool)

To run it just inherit the class in conf/local.conf file:

INHERIT += "cve-check"

Source and run
# bitbake -c cve_check openssl
# bitbake core-image-sato
# bitbake -k -c cve_check universe

EX:
bitbake -k -c cve_check universe

log files are created under
unzip/1_6.0-r5/cve/cve.log
gnutls/3.5.3-r0/cve/cve.log
glibc/2.24-r0/cve/cve.log
glibc-initial/2.24-r0/cve/cve.log
foomatic-filters/4.0.17-r1/cve/cve.log
bzip2/1.0.6-r5/cve/cve.log
libxml2/2.9.4-r0/cve/cve.log
....

Example of log file:
PACKAGE NAME: perl
PACKAGE VERSION: 5.22.1
CVE: CVE-2016-1238
CVE STATUS: Patched
CVE SUMMARY: ....
....
CVSS v2 BASE SCORE: 7.2
VECTOR: LOCAL
MORE INFORMATION: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-1238

Security

2016-01-28T06:38:36Z

SonaSarmadi: /* Workflow of Yocto Project's bugzilla */

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

poky/recipes-connectivity/bind/bind_9.9.5.bb

SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://conf.patch \
...
file://bind9_9_5-CVE-2014-8500.patch \

We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

== Yocto Security Team ==

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

'''The team's main responsibilities among others are:'''

* Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
* Responsible for fixing CVEs in the Yocto releases & maintained branches
* Evaluation of tools for security tests
* Responsible for security related info in the Yocto documentations
* Hardening of Yocto release

'''How to Contact Yocto's security team Securely'''
---------------------------------------------
We have set up two security-related mailing lists:
* '''Public List'''
: yocto [dash] security [at] yoctoproject[dot] org
: This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches.

* '''Private List'''
: security [at] yoctoprojct [dot] org (Forwards to the following addresses)

: - '''sona [dot] sarmadi [at] enea [dot] com'''
: - '''mhalstead [at] linuxfoundation [dot] org'''
: For secure communications, please send your messages encrypted to both using the following GPG keys.
: Remember message headers are not encrypted so do not include sensitive information in the subject line.

: Download public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x60FFAF3315BD5928 Sona Sarmadi] [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead]

Anyone can contribute with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility.

'''What you should do if you find a security vulnerability'''
---------------------------------------------
If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source packages used by the Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please send a copy to the security team at Yocto as well.
If you believe this is sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated.

'''What Yocto Security Team does when it receives a security vulnerability'''
---------------------------------------------
The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects analyzes the problem. If they deem that it is a real security problem in their software, the project will email the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros can then agree on a release date when the flaw should be made public.
There is also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy the information to other Opens Source Security mailing lists to inform the whole world of the vulnerability.

'''If an upstream project does not respond quickly'''
---------------------------------------------
If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible.
Normally big Linux vendors fix the problem if the problem affects their products.
Chances are that everyone from the enterprise distros to the commercial Yocto vendors will get fixes done first, but it is nice to have saftey net for issues that really are specific to oe and embedded.

== Branches maintained with security fixes ==
See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch.

Versions in grey are no longer actively maintained with security patches, but well-tested patches may still be accepted for them.)

== Policy for updating package versions for the stable branches ==
The Yocto project purposely limits updating of packages on oe-stable releases to items that address security problems (e.g. CVE's). For packages like qemu we avoid updating between from one "dot.dot" to another related "dot.dot" version since it has been seen in the past that even with "simple" updates, things can go wrong and a lot more testing is required to verify compatibility. Better to only add CVE patches to fix specific point problems.

== Kernel security patches ==

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Bruce Ashfield)

=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (meta-freescale@yoctoproject.org)
* meta-xilinx (meta-xilinx@lists.yoctoproject.org)
* meta-ti (meta-ti@yoctoproject.org)
* etc

== How to test ==

If there is any test case for the vulnerability by the upstream project or community
- Run the test to reproduce the problem and verify the correction.
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase
- Run the regressions test

'''Regression test'''

* Build the core image for at least two architectures (preferably one big-endian and one little-endian)
* Run ptest (for those branches/packages that there is ptest mechanism)

== Patch name convention and commit message ==

Security patches like any Open Source developmen should follow the openembedded's Guidelines:
*[http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines]
*[https://www.kernel.org/doc/Documentation/SecurityBugs kernel security bugs policy]

Note that security patches should have CVE: tag and reference to the CVE identifier both in the patch file/s and the commit message.

'''Ex upstream patch:'''

Please change the upstream patch "wscanf-allocates-too-little-memory.patch" to "CVE-2015-1472.patch" (or CVE-2015-1472-wscanf-allocates-too-little-memory.patch). Keep the original commit message and add reference to the CVE and upstream patch.

<Keep the original commit message>

Upstream-Status: Accepted <or Backport>
CVE: CVE-2015-8370

Reference to upstream patch:
https://sourceware.org/git/?p=glibc.git;a=patch;h=5bd80bfe9ca0d955bfbbc002781bc7b01b6bcb06

Signed-off-by: Joe Developer <joe.developer@example.com>

'''Ex meta patch:'''

Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit message:

bash: CVE-2014-6278 <if there are multiple CVEs list all>

<short description>

<[YOCTO #xxx] if there is any>

References
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-6278
xxxx

Signed-off-by: <your email address>

== Workflow of Yocto Project's bugzilla ==

* After sending the patch to the mailing list, set to: "In progress review"
* Once merged, set to: "Resolved - Fixed"

== Some security related links/useful tools ==

* [http://www.cvedetails.com CVE details]
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html CVE list, Linux kernel 2014]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]

== Security Issues Addressed in Yocto Releases ==
'''Yocto 2.0 - Jethero'''
https://www.yoctoproject.org/downloads/core/jethro20

'''Yocto 1.8.1 - Fido'''
https://www.yoctoproject.org/downloads/core/fido181

'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171

Security

2016-01-28T06:36:58Z

SonaSarmadi:

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

poky/recipes-connectivity/bind/bind_9.9.5.bb

SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://conf.patch \
...
file://bind9_9_5-CVE-2014-8500.patch \

We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

== Yocto Security Team ==

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

'''The team's main responsibilities among others are:'''

* Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
* Responsible for fixing CVEs in the Yocto releases & maintained branches
* Evaluation of tools for security tests
* Responsible for security related info in the Yocto documentations
* Hardening of Yocto release

'''How to Contact Yocto's security team Securely'''
---------------------------------------------
We have set up two security-related mailing lists:
* '''Public List'''
: yocto [dash] security [at] yoctoproject[dot] org
: This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches.

* '''Private List'''
: security [at] yoctoprojct [dot] org (Forwards to the following addresses)

: - '''sona [dot] sarmadi [at] enea [dot] com'''
: - '''mhalstead [at] linuxfoundation [dot] org'''
: For secure communications, please send your messages encrypted to both using the following GPG keys.
: Remember message headers are not encrypted so do not include sensitive information in the subject line.

: Download public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x60FFAF3315BD5928 Sona Sarmadi] [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead]

Anyone can contribute with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility.

'''What you should do if you find a security vulnerability'''
---------------------------------------------
If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source packages used by the Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please send a copy to the security team at Yocto as well.
If you believe this is sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated.

'''What Yocto Security Team does when it receives a security vulnerability'''
---------------------------------------------
The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects analyzes the problem. If they deem that it is a real security problem in their software, the project will email the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros can then agree on a release date when the flaw should be made public.
There is also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy the information to other Opens Source Security mailing lists to inform the whole world of the vulnerability.

'''If an upstream project does not respond quickly'''
---------------------------------------------
If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible.
Normally big Linux vendors fix the problem if the problem affects their products.
Chances are that everyone from the enterprise distros to the commercial Yocto vendors will get fixes done first, but it is nice to have saftey net for issues that really are specific to oe and embedded.

== Branches maintained with security fixes ==
See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch.

Versions in grey are no longer actively maintained with security patches, but well-tested patches may still be accepted for them.)

== Policy for updating package versions for the stable branches ==
The Yocto project purposely limits updating of packages on oe-stable releases to items that address security problems (e.g. CVE's). For packages like qemu we avoid updating between from one "dot.dot" to another related "dot.dot" version since it has been seen in the past that even with "simple" updates, things can go wrong and a lot more testing is required to verify compatibility. Better to only add CVE patches to fix specific point problems.

== Kernel security patches ==

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Bruce Ashfield)

=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (meta-freescale@yoctoproject.org)
* meta-xilinx (meta-xilinx@lists.yoctoproject.org)
* meta-ti (meta-ti@yoctoproject.org)
* etc

== How to test ==

If there is any test case for the vulnerability by the upstream project or community
- Run the test to reproduce the problem and verify the correction.
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase
- Run the regressions test

'''Regression test'''

* Build the core image for at least two architectures (preferably one big-endian and one little-endian)
* Run ptest (for those branches/packages that there is ptest mechanism)

== Patch name convention and commit message ==

Security patches like any Open Source developmen should follow the openembedded's Guidelines:
*[http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines]
*[https://www.kernel.org/doc/Documentation/SecurityBugs kernel security bugs policy]

Note that security patches should have CVE: tag and reference to the CVE identifier both in the patch file/s and the commit message.

'''Ex upstream patch:'''

Please change the upstream patch "wscanf-allocates-too-little-memory.patch" to "CVE-2015-1472.patch" (or CVE-2015-1472-wscanf-allocates-too-little-memory.patch). Keep the original commit message and add reference to the CVE and upstream patch.

<Keep the original commit message>

Upstream-Status: Accepted <or Backport>
CVE: CVE-2015-8370

Reference to upstream patch:
https://sourceware.org/git/?p=glibc.git;a=patch;h=5bd80bfe9ca0d955bfbbc002781bc7b01b6bcb06

Signed-off-by: Joe Developer <joe.developer@example.com>

'''Ex meta patch:'''

Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit message:

bash: CVE-2014-6278 <if there are multiple CVEs list all>

<short description>

<[YOCTO #xxx] if there is any>

References
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-6278
xxxx

Signed-off-by: <your email address>

== Workflow of Yocto Project's bugzilla ==

After sending the patch to the mailing list, set to: "In progress review"
Once merged, set to: "Resolved - Fixed".

== Some security related links/useful tools ==

* [http://www.cvedetails.com CVE details]
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html CVE list, Linux kernel 2014]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]

== Security Issues Addressed in Yocto Releases ==
'''Yocto 2.0 - Jethero'''
https://www.yoctoproject.org/downloads/core/jethro20

'''Yocto 1.8.1 - Fido'''
https://www.yoctoproject.org/downloads/core/fido181

'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171

Security

2016-01-19T11:18:09Z

SonaSarmadi:

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

poky/recipes-connectivity/bind/bind_9.9.5.bb

SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://conf.patch \
...
file://bind9_9_5-CVE-2014-8500.patch \

We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

== Yocto Security Team ==

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

'''The team's main responsibilities among others are:'''

* Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
* Responsible for fixing CVEs in the Yocto releases & maintained branches
* Evaluation of tools for security tests
* Responsible for security related info in the Yocto documentations
* Hardening of Yocto release

'''How to Contact Yocto's security team Securely'''
---------------------------------------------
We have set up two security-related mailing lists:
* '''Public List'''
: yocto [dash] security [at] yoctoproject[dot] org
: This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches.

* '''Private List'''
: security [at] yoctoprojct [dot] org (Forwards to the following addresses)

: - '''sona [dot] sarmadi [at] enea [dot] com'''
: - '''mhalstead [at] linuxfoundation [dot] org'''
: For secure communications, please send your messages encrypted to both using the following GPG keys.
: Remember message headers are not encrypted so do not include sensitive information in the subject line.

: Download public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x60FFAF3315BD5928 Sona Sarmadi] [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead]

Anyone can contribute with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility.

'''What you should do if you find a security vulnerability'''
---------------------------------------------
If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source packages used by the Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please send a copy to the security team at Yocto as well.
If you believe this is sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated.

'''What Yocto Security Team does when it receives a security vulnerability'''
---------------------------------------------
The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects analyzes the problem. If they deem that it is a real security problem in their software, the project will email the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros can then agree on a release date when the flaw should be made public.
There is also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy the information to other Opens Source Security mailing lists to inform the whole world of the vulnerability.

'''If an upstream project does not respond quickly'''
---------------------------------------------
If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible.
Normally big Linux vendors fix the problem if the problem affects their products.
Chances are that everyone from the enterprise distros to the commercial Yocto vendors will get fixes done first, but it is nice to have saftey net for issues that really are specific to oe and embedded.

== Branches maintained with security fixes ==
See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch.

Versions in grey are no longer actively maintained with security patches, but well-tested patches may still be accepted for them.)

== Policy for updating package versions for the stable branches ==
The Yocto project purposely limits updating of packages on oe-stable releases to items that address security problems (e.g. CVE's). For packages like qemu we avoid updating between from one "dot.dot" to another related "dot.dot" version since it has been seen in the past that even with "simple" updates, things can go wrong and a lot more testing is required to verify compatibility. Better to only add CVE patches to fix specific point problems.

== Kernel security patches ==

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Bruce Ashfield)

=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (meta-freescale@yoctoproject.org)
* meta-xilinx (meta-xilinx@lists.yoctoproject.org)
* meta-ti (meta-ti@yoctoproject.org)
* etc

== How to test ==

If there is any test case for the vulnerability by the upstream project or community
- Run the test to reproduce the problem and verify the correction.
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase
- Run the regressions test

'''Regression test'''

* Build the core image for at least two architectures (preferably one big-endian and one little-endian)
* Run ptest (for those branches/packages that there is ptest mechanism)

== Patch name convention and commit message ==

Security patches like any Open Source developmen should follow the openembedded's Guidelines:
*[http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines]
*[https://www.kernel.org/doc/Documentation/SecurityBugs kernel security bugs policy]

Note that security patches should have CVE: tag and reference to the CVE identifier both in the patch file/s and the commit message.

'''Ex upstream patch:'''

Please change the upstream patch "wscanf-allocates-too-little-memory.patch" to "CVE-2015-1472.patch" (or CVE-2015-1472-wscanf-allocates-too-little-memory.patch). Keep the original commit message and add reference to the CVE and upstream patch.

<Keep the original commit message>

Upstream-Status: Accepted <or Backport>
CVE: CVE-2015-8370

Reference to upstream patch:
https://sourceware.org/git/?p=glibc.git;a=patch;h=5bd80bfe9ca0d955bfbbc002781bc7b01b6bcb06

Signed-off-by: Joe Developer <joe.developer@example.com>

'''Ex meta patch:'''

Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit message:

bash: CVE-2014-6278 <if there are multiple CVEs list all>

<short description>

<[YOCTO #xxx] if there is any>

References
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-6278
xxxx

Signed-off-by: <your email address>

== Some security related links/useful tools ==

* [http://www.cvedetails.com CVE details]
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html CVE list, Linux kernel 2014]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]

== Security Issues Addressed in Yocto Releases ==
'''Yocto 2.0 - Jethero'''
https://www.yoctoproject.org/downloads/core/jethro20

'''Yocto 1.8.1 - Fido'''
https://www.yoctoproject.org/downloads/core/fido181

'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171

Security

2016-01-12T10:18:23Z

SonaSarmadi: /* Patch name convention and commit message */

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

poky/recipes-connectivity/bind/bind_9.9.5.bb

SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://conf.patch \
...
file://bind9_9_5-CVE-2014-8500.patch \

We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

== Yocto Security Team ==

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

'''The team's main responsibilities among others are:'''

* Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
* Responsible for fixing CVEs in the Yocto releases & maintained branches
* Evaluation of tools for security tests
* Responsible for security related info in the Yocto documentations
* Hardening of Yocto release

'''How to Contact Yocto's security team Securely'''
---------------------------------------------
We have set up two security-related mailing lists:
* '''Public List'''
: yocto [dash] security [at] yoctoproject[dot] org
: This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches.

* '''Private List'''
: security [at] yoctoprojct [dot] org (Forwards to the following addresses)

: - '''sona [dot] sarmadi [at] enea [dot] com'''
: - '''mhalstead [at] linuxfoundation [dot] org'''
: For secure communications, please send your messages encrypted to both using the following GPG keys.
: Remember message headers are not encrypted so do not include sensitive information in the subject line.

: Download public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x773EF6EF68716A14 Sona Sarmadi] [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead]

Anyone can contribute with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility.

'''What you should do if you find a security vulnerability'''
---------------------------------------------
If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source packages used by the Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please send a copy to the security team at Yocto as well.
If you believe this is sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated.

'''What Yocto Security Team does when it receives a security vulnerability'''
---------------------------------------------
The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects analyzes the problem. If they deem that it is a real security problem in their software, the project will email the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros can then agree on a release date when the flaw should be made public.
There is also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy the information to other Opens Source Security mailing lists to inform the whole world of the vulnerability.

'''If an upstream project does not respond quickly'''
---------------------------------------------
If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible.
Normally big Linux vendors fix the problem if the problem affects their products.
Chances are that everyone from the enterprise distros to the commercial Yocto vendors will get fixes done first, but it is nice to have saftey net for issues that really are specific to oe and embedded.

== Branches maintained with security fixes ==
See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch.

Versions in grey are no longer actively maintained with security patches, but well-tested patches may still be accepted for them.)

== Policy for updating package versions for the stable branches ==
The Yocto project purposely limits updating of packages on oe-stable releases to items that address security problems (e.g. CVE's). For packages like qemu we avoid updating between from one "dot.dot" to another related "dot.dot" version since it has been seen in the past that even with "simple" updates, things can go wrong and a lot more testing is required to verify compatibility. Better to only add CVE patches to fix specific point problems.

== Kernel security patches ==

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Bruce Ashfield)

=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (meta-freescale@yoctoproject.org)
* meta-xilinx (meta-xilinx@lists.yoctoproject.org)
* meta-ti (meta-ti@yoctoproject.org)
* etc

== How to test ==

If there is any test case for the vulnerability by the upstream project or community
- Run the test to reproduce the problem and verify the correction.
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase
- Run the regressions test

'''Regression test'''

* Build the core image for at least two architectures (preferably one big-endian and one little-endian)
* Run ptest (for those branches/packages that there is ptest mechanism)

== Patch name convention and commit message ==

Security patches like any Open Source developmen should follow the openembedded's Guidelines:
*[http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines]
*[https://www.kernel.org/doc/Documentation/SecurityBugs kernel security bugs policy]

Note that security patches should have CVE: tag and reference to the CVE identifier both in the patch file/s and the commit message.

'''Ex upstream patch:'''

Please change the upstream patch "wscanf-allocates-too-little-memory.patch" to "CVE-2015-1472.patch" (or CVE-2015-1472-wscanf-allocates-too-little-memory.patch). Keep the original commit message and add reference to the CVE and upstream patch.

<Keep the original commit message>

Upstream-Status: Accepted <or Backport>
CVE: CVE-2015-8370

Reference to upstream patch:
https://sourceware.org/git/?p=glibc.git;a=patch;h=5bd80bfe9ca0d955bfbbc002781bc7b01b6bcb06

Signed-off-by: Joe Developer <joe.developer@example.com>

'''Ex meta patch:'''

Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit message:

bash: CVE-2014-6278 <if there are multiple CVEs list all>

<short description>

<[YOCTO #xxx] if there is any>

References
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-6278
xxxx

Signed-off-by: <your email address>

== Some security related links/useful tools ==

* [http://www.cvedetails.com CVE details]
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html CVE list, Linux kernel 2014]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]

== Security Issues Addressed in Yocto Releases ==
'''Yocto 2.0 - Jethero'''
https://www.yoctoproject.org/downloads/core/jethro20

'''Yocto 1.8.1 - Fido'''
https://www.yoctoproject.org/downloads/core/fido181

'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171

Security

2016-01-12T10:07:44Z

SonaSarmadi: /* Patch name convention and commit message */

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

poky/recipes-connectivity/bind/bind_9.9.5.bb

SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://conf.patch \
...
file://bind9_9_5-CVE-2014-8500.patch \

We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

== Yocto Security Team ==

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

'''The team's main responsibilities among others are:'''

* Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
* Responsible for fixing CVEs in the Yocto releases & maintained branches
* Evaluation of tools for security tests
* Responsible for security related info in the Yocto documentations
* Hardening of Yocto release

'''How to Contact Yocto's security team Securely'''
---------------------------------------------
We have set up two security-related mailing lists:
* '''Public List'''
: yocto [dash] security [at] yoctoproject[dot] org
: This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches.

* '''Private List'''
: security [at] yoctoprojct [dot] org (Forwards to the following addresses)

: - '''sona [dot] sarmadi [at] enea [dot] com'''
: - '''mhalstead [at] linuxfoundation [dot] org'''
: For secure communications, please send your messages encrypted to both using the following GPG keys.
: Remember message headers are not encrypted so do not include sensitive information in the subject line.

: Download public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x773EF6EF68716A14 Sona Sarmadi] [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead]

Anyone can contribute with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility.

'''What you should do if you find a security vulnerability'''
---------------------------------------------
If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source packages used by the Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please send a copy to the security team at Yocto as well.
If you believe this is sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated.

'''What Yocto Security Team does when it receives a security vulnerability'''
---------------------------------------------
The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects analyzes the problem. If they deem that it is a real security problem in their software, the project will email the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros can then agree on a release date when the flaw should be made public.
There is also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy the information to other Opens Source Security mailing lists to inform the whole world of the vulnerability.

'''If an upstream project does not respond quickly'''
---------------------------------------------
If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible.
Normally big Linux vendors fix the problem if the problem affects their products.
Chances are that everyone from the enterprise distros to the commercial Yocto vendors will get fixes done first, but it is nice to have saftey net for issues that really are specific to oe and embedded.

== Branches maintained with security fixes ==
See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch.

Versions in grey are no longer actively maintained with security patches, but well-tested patches may still be accepted for them.)

== Policy for updating package versions for the stable branches ==
The Yocto project purposely limits updating of packages on oe-stable releases to items that address security problems (e.g. CVE's). For packages like qemu we avoid updating between from one "dot.dot" to another related "dot.dot" version since it has been seen in the past that even with "simple" updates, things can go wrong and a lot more testing is required to verify compatibility. Better to only add CVE patches to fix specific point problems.

== Kernel security patches ==

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Bruce Ashfield)

=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (meta-freescale@yoctoproject.org)
* meta-xilinx (meta-xilinx@lists.yoctoproject.org)
* meta-ti (meta-ti@yoctoproject.org)
* etc

== How to test ==

If there is any test case for the vulnerability by the upstream project or community
- Run the test to reproduce the problem and verify the correction.
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase
- Run the regressions test

'''Regression test'''

* Build the core image for at least two architectures (preferably one big-endian and one little-endian)
* Run ptest (for those branches/packages that there is ptest mechanism)

== Patch name convention and commit message ==

Security patches like any Open Source developmen should follow the openembedded's Guidelines:
[http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines]
[http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines#CVE_Patches] for security patches
[https://www.kernel.org/doc/Documentation/SecurityBugs kernel security bugs policy] for the kernel patches.

In addition security patches should have reference to the CVE identifier both in the patch file/s and the commit message.

'''Ex upstream patch:'''

Please change the upstream patch "wscanf-allocates-too-little-memory.patch" to "CVE-2015-1472.patch" (or CVE-2015-1472-wscanf-allocates-too-little-memory.patch). Keep the original commit message and add reference to the CVE and upstream patch.

<Keep the original commit message>

Upstream-Status: Accepted <or Backport>
CVE: CVE-2015-8370

Reference to upstream patch:
https://sourceware.org/git/?p=glibc.git;a=patch;h=5bd80bfe9ca0d955bfbbc002781bc7b01b6bcb06

Signed-off-by: Joe Developer <joe.developer@example.com>

'''Ex meta patch:'''

Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit message:

bash: CVE-2014-6278 <if there are multiple CVEs list all>

<short description>

<[YOCTO #xxx] if there is any>

References
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-6278
xxxx

Signed-off-by: <your email address>

== Some security related links/useful tools ==

* [http://www.cvedetails.com CVE details]
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html CVE list, Linux kernel 2014]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]

== Security Issues Addressed in Yocto Releases ==
'''Yocto 2.0 - Jethero'''
https://www.yoctoproject.org/downloads/core/jethro20

'''Yocto 1.8.1 - Fido'''
https://www.yoctoproject.org/downloads/core/fido181

'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171

Security

2015-12-16T09:05:14Z

SonaSarmadi: /* Patch name convention and commit message */

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

poky/recipes-connectivity/bind/bind_9.9.5.bb

SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://conf.patch \
...
file://bind9_9_5-CVE-2014-8500.patch \

We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

== Yocto Security Team ==

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

'''The team's main responsibilities among others are:'''

* Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
* Responsible for fixing CVEs in the Yocto releases & maintained branches
* Evaluation of tools for security tests
* Responsible for security related info in the Yocto documentations
* Hardening of Yocto release

'''How to Contact Yocto's security team Securely'''
---------------------------------------------
We have set up two security-related mailing lists:
* '''Public List'''
: yocto [dash] security [at] yoctoproject[dot] org
: This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches.

* '''Private List'''
: security [at] yoctoprojct [dot] org (Forwards to the following addresses)

: - '''sona [dot] sarmadi [at] enea [dot] com'''
: - '''mhalstead [at] linuxfoundation [dot] org'''
: For secure communications, please send your messages encrypted to both using the following GPG keys.
: Remember message headers are not encrypted so do not include sensitive information in the subject line.

: Download public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x773EF6EF68716A14 Sona Sarmadi] [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead]

Anyone can contribute with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility.

'''What you should do if you find a security vulnerability'''
---------------------------------------------
If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source packages used by the Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please send a copy to the security team at Yocto as well.
If you believe this is sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated.

'''What Yocto Security Team does when it receives a security vulnerability'''
---------------------------------------------
The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects analyzes the problem. If they deem that it is a real security problem in their software, the project will email the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros can then agree on a release date when the flaw should be made public.
There is also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy the information to other Opens Source Security mailing lists to inform the whole world of the vulnerability.

'''If an upstream project does not respond quickly'''
---------------------------------------------
If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible.
Normally big Linux vendors fix the problem if the problem affects their products.
Chances are that everyone from the enterprise distros to the commercial Yocto vendors will get fixes done first, but it is nice to have saftey net for issues that really are specific to oe and embedded.

== Branches maintained with security fixes ==
See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch.

Versions in grey are no longer actively maintained with security patches, but well-tested patches may still be accepted for them.)

== Policy for updating package versions for the stable branches ==
The Yocto project purposely limits updating of packages on oe-stable releases to items that address security problems (e.g. CVE's). For packages like qemu we avoid updating between from one "dot.dot" to another related "dot.dot" version since it has been seen in the past that even with "simple" updates, things can go wrong and a lot more testing is required to verify compatibility. Better to only add CVE patches to fix specific point problems.

== Kernel security patches ==

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Bruce Ashfield)

=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (meta-freescale@yoctoproject.org)
* meta-xilinx (meta-xilinx@lists.yoctoproject.org)
* meta-ti (meta-ti@yoctoproject.org)
* etc

== How to test ==

If there is any test case for the vulnerability by the upstream project or community
- Run the test to reproduce the problem and verify the correction.
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase
- Run the regressions test

'''Regression test'''

* Build the core image for at least two architectures (preferably one big-endian and one little-endian)
* Run ptest (for those branches/packages that there is ptest mechanism)

== Patch name convention and commit message ==

Security patches like any Open Source developmen should follow the openembedded's [http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines] and [https://www.kernel.org/doc/Documentation/SecurityBugs kernel security bugs policy] for the kernel patches.

In addition security patches should have reference to the CVE identifier both in the patch file/s and the commit message.

'''Ex upstream patch:'''

Please change the upstream patch "wscanf-allocates-too-little-memory.patch" to "CVE-2015-1472.patch" (or CVE-2015-1472-wscanf-allocates-too-little-memory.patch). Keep the original commit message and add reference to the CVE and upstream patch.

<Keep the original commit message>

Fixes CVE-2015-1472.
Upstream-Status: Backport

Reference to upstream patch:
The patch is from (Paul Pluzhnikov <ppluzhnikov@google.com>
https://sourceware.org/git/?p=glibc.git;a=patch;h=5bd80bfe9ca0d955bfbbc002781bc7b01b6bcb06

Signed-off-by: <your email address>

'''Ex meta patch:'''

Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit message:

bash: CVE-2014-6278 <if there are multiple CVEs list all>

<short description>

<[YOCTO #xxx] if there is any>

References
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-6278
xxxx

Signed-off-by: <your email address>

== Some security related links/useful tools ==

* [http://www.cvedetails.com CVE details]
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html CVE list, Linux kernel 2014]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]

== Security Issues Addressed in Yocto Releases ==
'''Yocto 2.0 - Jethero'''
https://www.yoctoproject.org/downloads/core/jethro20

'''Yocto 1.8.1 - Fido'''
https://www.yoctoproject.org/downloads/core/fido181

'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171

Security

2015-12-16T08:49:03Z

SonaSarmadi: /* Patch name convention and commit message */

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

poky/recipes-connectivity/bind/bind_9.9.5.bb

SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://conf.patch \
...
file://bind9_9_5-CVE-2014-8500.patch \

We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

== Yocto Security Team ==

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

'''The team's main responsibilities among others are:'''

* Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
* Responsible for fixing CVEs in the Yocto releases & maintained branches
* Evaluation of tools for security tests
* Responsible for security related info in the Yocto documentations
* Hardening of Yocto release

'''How to Contact Yocto's security team Securely'''
---------------------------------------------
We have set up two security-related mailing lists:
* '''Public List'''
: yocto [dash] security [at] yoctoproject[dot] org
: This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches.

* '''Private List'''
: security [at] yoctoprojct [dot] org (Forwards to the following addresses)

: - '''sona [dot] sarmadi [at] enea [dot] com'''
: - '''mhalstead [at] linuxfoundation [dot] org'''
: For secure communications, please send your messages encrypted to both using the following GPG keys.
: Remember message headers are not encrypted so do not include sensitive information in the subject line.

: Download public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x773EF6EF68716A14 Sona Sarmadi] [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead]

Anyone can contribute with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility.

'''What you should do if you find a security vulnerability'''
---------------------------------------------
If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source packages used by the Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please send a copy to the security team at Yocto as well.
If you believe this is sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated.

'''What Yocto Security Team does when it receives a security vulnerability'''
---------------------------------------------
The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects analyzes the problem. If they deem that it is a real security problem in their software, the project will email the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros can then agree on a release date when the flaw should be made public.
There is also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy the information to other Opens Source Security mailing lists to inform the whole world of the vulnerability.

'''If an upstream project does not respond quickly'''
---------------------------------------------
If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible.
Normally big Linux vendors fix the problem if the problem affects their products.
Chances are that everyone from the enterprise distros to the commercial Yocto vendors will get fixes done first, but it is nice to have saftey net for issues that really are specific to oe and embedded.

== Branches maintained with security fixes ==
See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch.

Versions in grey are no longer actively maintained with security patches, but well-tested patches may still be accepted for them.)

== Policy for updating package versions for the stable branches ==
The Yocto project purposely limits updating of packages on oe-stable releases to items that address security problems (e.g. CVE's). For packages like qemu we avoid updating between from one "dot.dot" to another related "dot.dot" version since it has been seen in the past that even with "simple" updates, things can go wrong and a lot more testing is required to verify compatibility. Better to only add CVE patches to fix specific point problems.

== Kernel security patches ==

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Bruce Ashfield)

=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (meta-freescale@yoctoproject.org)
* meta-xilinx (meta-xilinx@lists.yoctoproject.org)
* meta-ti (meta-ti@yoctoproject.org)
* etc

== How to test ==

If there is any test case for the vulnerability by the upstream project or community
- Run the test to reproduce the problem and verify the correction.
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase
- Run the regressions test

'''Regression test'''

* Build the core image for at least two architectures (preferably one big-endian and one little-endian)
* Run ptest (for those branches/packages that there is ptest mechanism)

== Patch name convention and commit message ==

Security patches like any Open Source developmen should follow the openembedded's [http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines] and [https://www.kernel.org/doc/Documentation/SecurityBugs kernel security bugs policy] for the kernel patches.

In addition security patches should have reference to the CVE identifier both in the patch file/s and the commit message.

'''Ex upstream patch:'''

Please change the upstream patch "wscanf-allocates-too-little-memory.patch" to "CVE-2015-1472.patch" (or CVE-2015-1472-wscanf-allocates-too-little-memory.patch)

<Keep the original commit message>

Fixes CVE-2015-1472.
Upstream-Status: Backport

Reference to upstream patch:
The patch is from (Paul Pluzhnikov <ppluzhnikov@google.com>
https://sourceware.org/git/?p=glibc.git;a=patch;h=5bd80bfe9ca0d955bfbbc002781bc7b01b6bcb06

Signed-off-by: <your email address>

'''Ex meta patch:'''

Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit message:

bash: CVE-2014-6278 <if there are multiple CVEs list all>

<short description>

<[YOCTO #xxx] if there is any>

References
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-6278
xxxx

Signed-off-by: <your email address>

== Some security related links/useful tools ==

* [http://www.cvedetails.com CVE details]
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html CVE list, Linux kernel 2014]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]

== Security Issues Addressed in Yocto Releases ==
'''Yocto 2.0 - Jethero'''
https://www.yoctoproject.org/downloads/core/jethro20

'''Yocto 1.8.1 - Fido'''
https://www.yoctoproject.org/downloads/core/fido181

'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171

Security

2015-12-16T08:48:42Z

SonaSarmadi: /* Patch name convention and commit message */

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

poky/recipes-connectivity/bind/bind_9.9.5.bb

SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://conf.patch \
...
file://bind9_9_5-CVE-2014-8500.patch \

We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

== Yocto Security Team ==

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

'''The team's main responsibilities among others are:'''

* Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
* Responsible for fixing CVEs in the Yocto releases & maintained branches
* Evaluation of tools for security tests
* Responsible for security related info in the Yocto documentations
* Hardening of Yocto release

'''How to Contact Yocto's security team Securely'''
---------------------------------------------
We have set up two security-related mailing lists:
* '''Public List'''
: yocto [dash] security [at] yoctoproject[dot] org
: This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches.

* '''Private List'''
: security [at] yoctoprojct [dot] org (Forwards to the following addresses)

: - '''sona [dot] sarmadi [at] enea [dot] com'''
: - '''mhalstead [at] linuxfoundation [dot] org'''
: For secure communications, please send your messages encrypted to both using the following GPG keys.
: Remember message headers are not encrypted so do not include sensitive information in the subject line.

: Download public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x773EF6EF68716A14 Sona Sarmadi] [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead]

Anyone can contribute with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility.

'''What you should do if you find a security vulnerability'''
---------------------------------------------
If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source packages used by the Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please send a copy to the security team at Yocto as well.
If you believe this is sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated.

'''What Yocto Security Team does when it receives a security vulnerability'''
---------------------------------------------
The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects analyzes the problem. If they deem that it is a real security problem in their software, the project will email the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros can then agree on a release date when the flaw should be made public.
There is also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy the information to other Opens Source Security mailing lists to inform the whole world of the vulnerability.

'''If an upstream project does not respond quickly'''
---------------------------------------------
If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible.
Normally big Linux vendors fix the problem if the problem affects their products.
Chances are that everyone from the enterprise distros to the commercial Yocto vendors will get fixes done first, but it is nice to have saftey net for issues that really are specific to oe and embedded.

== Branches maintained with security fixes ==
See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch.

Versions in grey are no longer actively maintained with security patches, but well-tested patches may still be accepted for them.)

== Policy for updating package versions for the stable branches ==
The Yocto project purposely limits updating of packages on oe-stable releases to items that address security problems (e.g. CVE's). For packages like qemu we avoid updating between from one "dot.dot" to another related "dot.dot" version since it has been seen in the past that even with "simple" updates, things can go wrong and a lot more testing is required to verify compatibility. Better to only add CVE patches to fix specific point problems.

== Kernel security patches ==

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Bruce Ashfield)

=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (meta-freescale@yoctoproject.org)
* meta-xilinx (meta-xilinx@lists.yoctoproject.org)
* meta-ti (meta-ti@yoctoproject.org)
* etc

== How to test ==

If there is any test case for the vulnerability by the upstream project or community
- Run the test to reproduce the problem and verify the correction.
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase
- Run the regressions test

'''Regression test'''

* Build the core image for at least two architectures (preferably one big-endian and one little-endian)
* Run ptest (for those branches/packages that there is ptest mechanism)

== Patch name convention and commit message ==

Security patches like any Open Source developmen should follow the openembedded's [http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines] and [https://www.kernel.org/doc/Documentation/SecurityBugs kernel security bugs policy] for the kernel patches.

In addition security patches should have reference to the CVE identifier both in the patch file/s and the commit message.

'''Ex upstream patch'''

Please change the upstream patch "wscanf-allocates-too-little-memory.patch" to "CVE-2015-1472.patch" (or CVE-2015-1472-wscanf-allocates-too-little-memory.patch)

<Keep the original commit message>

Fixes CVE-2015-1472.
Upstream-Status: Backport

Reference to upstream patch:
The patch is from (Paul Pluzhnikov <ppluzhnikov@google.com>
https://sourceware.org/git/?p=glibc.git;a=patch;h=5bd80bfe9ca0d955bfbbc002781bc7b01b6bcb06

Signed-off-by: <your email address>

'''Ex meta patch:'''

Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit message:

bash: CVE-2014-6278 <if there are multiple CVEs list all>

<short description>

<[YOCTO #xxx] if there is any>

References
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-6278
xxxx

Signed-off-by: <your email address>

== Some security related links/useful tools ==

* [http://www.cvedetails.com CVE details]
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html CVE list, Linux kernel 2014]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]

== Security Issues Addressed in Yocto Releases ==
'''Yocto 2.0 - Jethero'''
https://www.yoctoproject.org/downloads/core/jethro20

'''Yocto 1.8.1 - Fido'''
https://www.yoctoproject.org/downloads/core/fido181

'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171

Security

2015-12-16T08:44:56Z

SonaSarmadi: /* Patch name convention and commit message */

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

poky/recipes-connectivity/bind/bind_9.9.5.bb

SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://conf.patch \
...
file://bind9_9_5-CVE-2014-8500.patch \

We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

== Yocto Security Team ==

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

'''The team's main responsibilities among others are:'''

* Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
* Responsible for fixing CVEs in the Yocto releases & maintained branches
* Evaluation of tools for security tests
* Responsible for security related info in the Yocto documentations
* Hardening of Yocto release

'''How to Contact Yocto's security team Securely'''
---------------------------------------------
We have set up two security-related mailing lists:
* '''Public List'''
: yocto [dash] security [at] yoctoproject[dot] org
: This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches.

* '''Private List'''
: security [at] yoctoprojct [dot] org (Forwards to the following addresses)

: - '''sona [dot] sarmadi [at] enea [dot] com'''
: - '''mhalstead [at] linuxfoundation [dot] org'''
: For secure communications, please send your messages encrypted to both using the following GPG keys.
: Remember message headers are not encrypted so do not include sensitive information in the subject line.

: Download public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x773EF6EF68716A14 Sona Sarmadi] [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead]

Anyone can contribute with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility.

'''What you should do if you find a security vulnerability'''
---------------------------------------------
If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source packages used by the Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please send a copy to the security team at Yocto as well.
If you believe this is sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated.

'''What Yocto Security Team does when it receives a security vulnerability'''
---------------------------------------------
The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects analyzes the problem. If they deem that it is a real security problem in their software, the project will email the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros can then agree on a release date when the flaw should be made public.
There is also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy the information to other Opens Source Security mailing lists to inform the whole world of the vulnerability.

'''If an upstream project does not respond quickly'''
---------------------------------------------
If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible.
Normally big Linux vendors fix the problem if the problem affects their products.
Chances are that everyone from the enterprise distros to the commercial Yocto vendors will get fixes done first, but it is nice to have saftey net for issues that really are specific to oe and embedded.

== Branches maintained with security fixes ==
See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch.

Versions in grey are no longer actively maintained with security patches, but well-tested patches may still be accepted for them.)

== Policy for updating package versions for the stable branches ==
The Yocto project purposely limits updating of packages on oe-stable releases to items that address security problems (e.g. CVE's). For packages like qemu we avoid updating between from one "dot.dot" to another related "dot.dot" version since it has been seen in the past that even with "simple" updates, things can go wrong and a lot more testing is required to verify compatibility. Better to only add CVE patches to fix specific point problems.

== Kernel security patches ==

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Bruce Ashfield)

=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (meta-freescale@yoctoproject.org)
* meta-xilinx (meta-xilinx@lists.yoctoproject.org)
* meta-ti (meta-ti@yoctoproject.org)
* etc

== How to test ==

If there is any test case for the vulnerability by the upstream project or community
- Run the test to reproduce the problem and verify the correction.
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase
- Run the regressions test

'''Regression test'''

* Build the core image for at least two architectures (preferably one big-endian and one little-endian)
* Run ptest (for those branches/packages that there is ptest mechanism)

== Patch name convention and commit message ==

Security patches like any Open Source developmen should follow the openembedded's [http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines] and [https://www.kernel.org/doc/Documentation/SecurityBugs kernel security bugs policy] for the kernel patches.

In addition security patches should have reference to the CVE identifier both in the patch file/s and the commit message.

Ex: Change the upstream patch "wscanf-allocates-too-little-memory.patch" to "CVE-2015-1472.patch" (or CVE-2015-1472-wscanf-allocates-too-little-memory.patch)

<Keep the original commit message>

Fixes CVE-2015-1472.
Upstream-Status: Backport

Reference to upstream patch:
The patch is from (Paul Pluzhnikov <ppluzhnikov@google.com>
https://sourceware.org/git/?p=glibc.git;a=patch;h=5bd80bfe9ca0d955bfbbc002781bc7b01b6bcb06

Signed-off-by:

Ex: meta patch
Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit message:

bash: CVE-2014-6278 <if there are multiple CVEs list all>

<short description>

<[YOCTO #xxx] if there is any>

References
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-6278
xxxx

Signed-off-by:

== Some security related links/useful tools ==

* [http://www.cvedetails.com CVE details]
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html CVE list, Linux kernel 2014]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]

== Security Issues Addressed in Yocto Releases ==
'''Yocto 2.0 - Jethero'''
https://www.yoctoproject.org/downloads/core/jethro20

'''Yocto 1.8.1 - Fido'''
https://www.yoctoproject.org/downloads/core/fido181

'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171

Security

2015-12-16T08:44:15Z

SonaSarmadi: /* Patch name convention and commit message */

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

poky/recipes-connectivity/bind/bind_9.9.5.bb

SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://conf.patch \
...
file://bind9_9_5-CVE-2014-8500.patch \

We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

== Yocto Security Team ==

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

'''The team's main responsibilities among others are:'''

* Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
* Responsible for fixing CVEs in the Yocto releases & maintained branches
* Evaluation of tools for security tests
* Responsible for security related info in the Yocto documentations
* Hardening of Yocto release

'''How to Contact Yocto's security team Securely'''
---------------------------------------------
We have set up two security-related mailing lists:
* '''Public List'''
: yocto [dash] security [at] yoctoproject[dot] org
: This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches.

* '''Private List'''
: security [at] yoctoprojct [dot] org (Forwards to the following addresses)

: - '''sona [dot] sarmadi [at] enea [dot] com'''
: - '''mhalstead [at] linuxfoundation [dot] org'''
: For secure communications, please send your messages encrypted to both using the following GPG keys.
: Remember message headers are not encrypted so do not include sensitive information in the subject line.

: Download public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x773EF6EF68716A14 Sona Sarmadi] [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead]

Anyone can contribute with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility.

'''What you should do if you find a security vulnerability'''
---------------------------------------------
If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source packages used by the Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please send a copy to the security team at Yocto as well.
If you believe this is sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated.

'''What Yocto Security Team does when it receives a security vulnerability'''
---------------------------------------------
The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects analyzes the problem. If they deem that it is a real security problem in their software, the project will email the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros can then agree on a release date when the flaw should be made public.
There is also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy the information to other Opens Source Security mailing lists to inform the whole world of the vulnerability.

'''If an upstream project does not respond quickly'''
---------------------------------------------
If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible.
Normally big Linux vendors fix the problem if the problem affects their products.
Chances are that everyone from the enterprise distros to the commercial Yocto vendors will get fixes done first, but it is nice to have saftey net for issues that really are specific to oe and embedded.

== Branches maintained with security fixes ==
See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch.

Versions in grey are no longer actively maintained with security patches, but well-tested patches may still be accepted for them.)

== Policy for updating package versions for the stable branches ==
The Yocto project purposely limits updating of packages on oe-stable releases to items that address security problems (e.g. CVE's). For packages like qemu we avoid updating between from one "dot.dot" to another related "dot.dot" version since it has been seen in the past that even with "simple" updates, things can go wrong and a lot more testing is required to verify compatibility. Better to only add CVE patches to fix specific point problems.

== Kernel security patches ==

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Bruce Ashfield)

=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (meta-freescale@yoctoproject.org)
* meta-xilinx (meta-xilinx@lists.yoctoproject.org)
* meta-ti (meta-ti@yoctoproject.org)
* etc

== How to test ==

If there is any test case for the vulnerability by the upstream project or community
- Run the test to reproduce the problem and verify the correction.
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase
- Run the regressions test

'''Regression test'''

* Build the core image for at least two architectures (preferably one big-endian and one little-endian)
* Run ptest (for those branches/packages that there is ptest mechanism)

== Patch name convention and commit message ==

Security patches like any Open Source developmen should follow the openembedded's [http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines] and [https://www.kernel.org/doc/Documentation/SecurityBugs kernel security bugs policy] for the kernel patches.

In addition security patches should have reference to the CVE identifier both in the patch file/s and the commit message.

Ex: Change the upstream patch "wscanf-allocates-too-little-memory.patch" to "CVE-2015-1472.patch" (or CVE-2015-1472-wscanf-allocates-too-little-memory.patch)

<Keep the original commit message>

Fixes CVE-2015-1472.
Upstream-Status: Backport

Reference to upstream patch:
The patch is from (Paul Pluzhnikov <ppluzhnikov@google.com>
https://sourceware.org/git/?p=glibc.git;a=patch;h=5bd80bfe9ca0d955bfbbc002781bc7b01b6bcb06

Signed-off-by:

Ex: meta patch
Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit message:

bash: CVE-2014-6278 <if there are multiple CVEs list all>

<short description>

<[YOCTO #xxx] if there is any>

References
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-6278
xxxx

Signed-off-by:

== Some security related links/useful tools ==

* [http://www.cvedetails.com CVE details]
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html CVE list, Linux kernel 2014]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]

== Security Issues Addressed in Yocto Releases ==
'''Yocto 2.0 - Jethero'''
https://www.yoctoproject.org/downloads/core/jethro20

'''Yocto 1.8.1 - Fido'''
https://www.yoctoproject.org/downloads/core/fido181

'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171

Security

2015-12-16T08:43:14Z

SonaSarmadi: /* Patch name convention and commit message */

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

poky/recipes-connectivity/bind/bind_9.9.5.bb

SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://conf.patch \
...
file://bind9_9_5-CVE-2014-8500.patch \

We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

== Yocto Security Team ==

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

'''The team's main responsibilities among others are:'''

* Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
* Responsible for fixing CVEs in the Yocto releases & maintained branches
* Evaluation of tools for security tests
* Responsible for security related info in the Yocto documentations
* Hardening of Yocto release

'''How to Contact Yocto's security team Securely'''
---------------------------------------------
We have set up two security-related mailing lists:
* '''Public List'''
: yocto [dash] security [at] yoctoproject[dot] org
: This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches.

* '''Private List'''
: security [at] yoctoprojct [dot] org (Forwards to the following addresses)

: - '''sona [dot] sarmadi [at] enea [dot] com'''
: - '''mhalstead [at] linuxfoundation [dot] org'''
: For secure communications, please send your messages encrypted to both using the following GPG keys.
: Remember message headers are not encrypted so do not include sensitive information in the subject line.

: Download public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x773EF6EF68716A14 Sona Sarmadi] [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead]

Anyone can contribute with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility.

'''What you should do if you find a security vulnerability'''
---------------------------------------------
If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source packages used by the Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please send a copy to the security team at Yocto as well.
If you believe this is sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated.

'''What Yocto Security Team does when it receives a security vulnerability'''
---------------------------------------------
The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects analyzes the problem. If they deem that it is a real security problem in their software, the project will email the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros can then agree on a release date when the flaw should be made public.
There is also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy the information to other Opens Source Security mailing lists to inform the whole world of the vulnerability.

'''If an upstream project does not respond quickly'''
---------------------------------------------
If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible.
Normally big Linux vendors fix the problem if the problem affects their products.
Chances are that everyone from the enterprise distros to the commercial Yocto vendors will get fixes done first, but it is nice to have saftey net for issues that really are specific to oe and embedded.

== Branches maintained with security fixes ==
See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch.

Versions in grey are no longer actively maintained with security patches, but well-tested patches may still be accepted for them.)

== Policy for updating package versions for the stable branches ==
The Yocto project purposely limits updating of packages on oe-stable releases to items that address security problems (e.g. CVE's). For packages like qemu we avoid updating between from one "dot.dot" to another related "dot.dot" version since it has been seen in the past that even with "simple" updates, things can go wrong and a lot more testing is required to verify compatibility. Better to only add CVE patches to fix specific point problems.

== Kernel security patches ==

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Bruce Ashfield)

=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (meta-freescale@yoctoproject.org)
* meta-xilinx (meta-xilinx@lists.yoctoproject.org)
* meta-ti (meta-ti@yoctoproject.org)
* etc

== How to test ==

If there is any test case for the vulnerability by the upstream project or community
- Run the test to reproduce the problem and verify the correction.
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase
- Run the regressions test

'''Regression test'''

* Build the core image for at least two architectures (preferably one big-endian and one little-endian)
* Run ptest (for those branches/packages that there is ptest mechanism)

== Patch name convention and commit message ==

Security patches like any Open Source developmen should follow the openembedded's [http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines] and [https://www.kernel.org/doc/Documentation/SecurityBugs kernel security bugs policy] for the kernel patches.

In addition security patches should have reference to the CVE identifier both in the patch file/s and the commit message.

Ex: Change the upstream patch "wscanf-allocates-too-little-memory.patch" to "CVE-2015-1472.patch" (or CVE-2015-1472-wscanf-allocates-too-little-memory.patch)

Fixes CVE-2015-1472.
Upstream-Status: Backport

Reference to upstream patch:
The patch is from (Paul Pluzhnikov <ppluzhnikov@google.com>
https://sourceware.org/git/?p=glibc.git;a=patch;h=5bd80bfe9ca0d955bfbbc002781bc7b01b6bcb06

Signed-off-by:

Ex: meta patch
Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit message:

bash: CVE-2014-6278 <if there are multiple CVEs list all>

<short description>

<[YOCTO #xxx] if there is any>

References
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-6278
xxxx

Signed-off-by:

== Some security related links/useful tools ==

* [http://www.cvedetails.com CVE details]
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html CVE list, Linux kernel 2014]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]

== Security Issues Addressed in Yocto Releases ==
'''Yocto 2.0 - Jethero'''
https://www.yoctoproject.org/downloads/core/jethro20

'''Yocto 1.8.1 - Fido'''
https://www.yoctoproject.org/downloads/core/fido181

'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171

Security

2015-12-16T08:41:41Z

SonaSarmadi: /* Patch name convention and commit message */

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

poky/recipes-connectivity/bind/bind_9.9.5.bb

SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://conf.patch \
...
file://bind9_9_5-CVE-2014-8500.patch \

We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

== Yocto Security Team ==

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

'''The team's main responsibilities among others are:'''

* Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
* Responsible for fixing CVEs in the Yocto releases & maintained branches
* Evaluation of tools for security tests
* Responsible for security related info in the Yocto documentations
* Hardening of Yocto release

'''How to Contact Yocto's security team Securely'''
---------------------------------------------
We have set up two security-related mailing lists:
* '''Public List'''
: yocto [dash] security [at] yoctoproject[dot] org
: This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches.

* '''Private List'''
: security [at] yoctoprojct [dot] org (Forwards to the following addresses)

: - '''sona [dot] sarmadi [at] enea [dot] com'''
: - '''mhalstead [at] linuxfoundation [dot] org'''
: For secure communications, please send your messages encrypted to both using the following GPG keys.
: Remember message headers are not encrypted so do not include sensitive information in the subject line.

: Download public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x773EF6EF68716A14 Sona Sarmadi] [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead]

Anyone can contribute with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility.

'''What you should do if you find a security vulnerability'''
---------------------------------------------
If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source packages used by the Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please send a copy to the security team at Yocto as well.
If you believe this is sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated.

'''What Yocto Security Team does when it receives a security vulnerability'''
---------------------------------------------
The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects analyzes the problem. If they deem that it is a real security problem in their software, the project will email the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros can then agree on a release date when the flaw should be made public.
There is also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy the information to other Opens Source Security mailing lists to inform the whole world of the vulnerability.

'''If an upstream project does not respond quickly'''
---------------------------------------------
If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible.
Normally big Linux vendors fix the problem if the problem affects their products.
Chances are that everyone from the enterprise distros to the commercial Yocto vendors will get fixes done first, but it is nice to have saftey net for issues that really are specific to oe and embedded.

== Branches maintained with security fixes ==
See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch.

Versions in grey are no longer actively maintained with security patches, but well-tested patches may still be accepted for them.)

== Policy for updating package versions for the stable branches ==
The Yocto project purposely limits updating of packages on oe-stable releases to items that address security problems (e.g. CVE's). For packages like qemu we avoid updating between from one "dot.dot" to another related "dot.dot" version since it has been seen in the past that even with "simple" updates, things can go wrong and a lot more testing is required to verify compatibility. Better to only add CVE patches to fix specific point problems.

== Kernel security patches ==

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Bruce Ashfield)

=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (meta-freescale@yoctoproject.org)
* meta-xilinx (meta-xilinx@lists.yoctoproject.org)
* meta-ti (meta-ti@yoctoproject.org)
* etc

== How to test ==

If there is any test case for the vulnerability by the upstream project or community
- Run the test to reproduce the problem and verify the correction.
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase
- Run the regressions test

'''Regression test'''

* Build the core image for at least two architectures (preferably one big-endian and one little-endian)
* Run ptest (for those branches/packages that there is ptest mechanism)

== Patch name convention and commit message ==

Security patches like any Open Source developmen should follow the openembedded's [http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines] and [https://www.kernel.org/doc/Documentation/SecurityBugs kernel security bugs policy] for the kernel patches.

In addition security patches should have reference to the CVE identifier both in the patch file/s and the commit message.

Ex: Upstream patch CVE-2015-1472.patch (or CVE-2015-1472-wscanf-allocates-too-little-memory.patch)

Fixes CVE-2015-1472.
Upstream-Status: Backport

Reference to upstream patch:
The patch is from (Paul Pluzhnikov <ppluzhnikov@google.com>
https://sourceware.org/git/?p=glibc.git;a=patch;h=5bd80bfe9ca0d955bfbbc002781bc7b01b6bcb06

Signed-off-by:

Ex: meta patch
Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit message:

bash: CVE-2014-6278 <if there are multiple CVEs list all>

<short description>

<[YOCTO #xxx] if there is any>

References
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-6278
xxxx

Signed-off-by:

== Some security related links/useful tools ==

* [http://www.cvedetails.com CVE details]
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html CVE list, Linux kernel 2014]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]

== Security Issues Addressed in Yocto Releases ==
'''Yocto 2.0 - Jethero'''
https://www.yoctoproject.org/downloads/core/jethro20

'''Yocto 1.8.1 - Fido'''
https://www.yoctoproject.org/downloads/core/fido181

'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171

Security

2015-12-16T08:06:03Z

SonaSarmadi: /* Patch name convention and commit message */

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

poky/recipes-connectivity/bind/bind_9.9.5.bb

SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://conf.patch \
...
file://bind9_9_5-CVE-2014-8500.patch \

We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

== Yocto Security Team ==

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

'''The team's main responsibilities among others are:'''

* Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
* Responsible for fixing CVEs in the Yocto releases & maintained branches
* Evaluation of tools for security tests
* Responsible for security related info in the Yocto documentations
* Hardening of Yocto release

'''How to Contact Yocto's security team Securely'''
---------------------------------------------
We have set up two security-related mailing lists:
* '''Public List'''
: yocto [dash] security [at] yoctoproject[dot] org
: This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches.

* '''Private List'''
: security [at] yoctoprojct [dot] org (Forwards to the following addresses)

: - '''sona [dot] sarmadi [at] enea [dot] com'''
: - '''mhalstead [at] linuxfoundation [dot] org'''
: For secure communications, please send your messages encrypted to both using the following GPG keys.
: Remember message headers are not encrypted so do not include sensitive information in the subject line.

: Download public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x773EF6EF68716A14 Sona Sarmadi] [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead]

Anyone can contribute with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility.

'''What you should do if you find a security vulnerability'''
---------------------------------------------
If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source packages used by the Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please send a copy to the security team at Yocto as well.
If you believe this is sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated.

'''What Yocto Security Team does when it receives a security vulnerability'''
---------------------------------------------
The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects analyzes the problem. If they deem that it is a real security problem in their software, the project will email the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros can then agree on a release date when the flaw should be made public.
There is also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy the information to other Opens Source Security mailing lists to inform the whole world of the vulnerability.

'''If an upstream project does not respond quickly'''
---------------------------------------------
If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible.
Normally big Linux vendors fix the problem if the problem affects their products.
Chances are that everyone from the enterprise distros to the commercial Yocto vendors will get fixes done first, but it is nice to have saftey net for issues that really are specific to oe and embedded.

== Branches maintained with security fixes ==
See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch.

Versions in grey are no longer actively maintained with security patches, but well-tested patches may still be accepted for them.)

== Policy for updating package versions for the stable branches ==
The Yocto project purposely limits updating of packages on oe-stable releases to items that address security problems (e.g. CVE's). For packages like qemu we avoid updating between from one "dot.dot" to another related "dot.dot" version since it has been seen in the past that even with "simple" updates, things can go wrong and a lot more testing is required to verify compatibility. Better to only add CVE patches to fix specific point problems.

== Kernel security patches ==

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Bruce Ashfield)

=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (meta-freescale@yoctoproject.org)
* meta-xilinx (meta-xilinx@lists.yoctoproject.org)
* meta-ti (meta-ti@yoctoproject.org)
* etc

== How to test ==

If there is any test case for the vulnerability by the upstream project or community
- Run the test to reproduce the problem and verify the correction.
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase
- Run the regressions test

'''Regression test'''

* Build the core image for at least two architectures (preferably one big-endian and one little-endian)
* Run ptest (for those branches/packages that there is ptest mechanism)

== Patch name convention and commit message ==
Security patches like any Open Source developmen should follow the openembedded's [http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines] and [https://www.kernel.org/doc/Documentation/SecurityBugs kernel security bugs policy] for the kernel patches.
In addition security patches should have reference to the CVE identifier both in the patch file/s and the commit message.

Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit message:

bash: CVE-2014-6278

<short description>

<[YOCTO #xxx] if there is any>

References
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-6278
xxxx

Signed-off-by:

== Some security related links/useful tools ==

* [http://www.cvedetails.com CVE details]
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html CVE list, Linux kernel 2014]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]

== Security Issues Addressed in Yocto Releases ==
'''Yocto 2.0 - Jethero'''
https://www.yoctoproject.org/downloads/core/jethro20

'''Yocto 1.8.1 - Fido'''
https://www.yoctoproject.org/downloads/core/fido181

'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171

Security

2015-12-16T07:40:10Z

SonaSarmadi: /* Security Issues Addressed in Yocto Releases */

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

poky/recipes-connectivity/bind/bind_9.9.5.bb

SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://conf.patch \
...
file://bind9_9_5-CVE-2014-8500.patch \

We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

== Yocto Security Team ==

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

'''The team's main responsibilities among others are:'''

* Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
* Responsible for fixing CVEs in the Yocto releases & maintained branches
* Evaluation of tools for security tests
* Responsible for security related info in the Yocto documentations
* Hardening of Yocto release

'''How to Contact Yocto's security team Securely'''
---------------------------------------------
We have set up two security-related mailing lists:
* '''Public List'''
: yocto [dash] security [at] yoctoproject[dot] org
: This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches.

* '''Private List'''
: security [at] yoctoprojct [dot] org (Forwards to the following addresses)

: - '''sona [dot] sarmadi [at] enea [dot] com'''
: - '''mhalstead [at] linuxfoundation [dot] org'''
: For secure communications, please send your messages encrypted to both using the following GPG keys.
: Remember message headers are not encrypted so do not include sensitive information in the subject line.

: Download public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x773EF6EF68716A14 Sona Sarmadi] [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead]

Anyone can contribute with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility.

'''What you should do if you find a security vulnerability'''
---------------------------------------------
If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source packages used by the Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please send a copy to the security team at Yocto as well.
If you believe this is sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated.

'''What Yocto Security Team does when it receives a security vulnerability'''
---------------------------------------------
The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects analyzes the problem. If they deem that it is a real security problem in their software, the project will email the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros can then agree on a release date when the flaw should be made public.
There is also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy the information to other Opens Source Security mailing lists to inform the whole world of the vulnerability.

'''If an upstream project does not respond quickly'''
---------------------------------------------
If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible.
Normally big Linux vendors fix the problem if the problem affects their products.
Chances are that everyone from the enterprise distros to the commercial Yocto vendors will get fixes done first, but it is nice to have saftey net for issues that really are specific to oe and embedded.

== Branches maintained with security fixes ==
See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch.

Versions in grey are no longer actively maintained with security patches, but well-tested patches may still be accepted for them.)

== Policy for updating package versions for the stable branches ==
The Yocto project purposely limits updating of packages on oe-stable releases to items that address security problems (e.g. CVE's). For packages like qemu we avoid updating between from one "dot.dot" to another related "dot.dot" version since it has been seen in the past that even with "simple" updates, things can go wrong and a lot more testing is required to verify compatibility. Better to only add CVE patches to fix specific point problems.

== Kernel security patches ==

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Bruce Ashfield)

=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (meta-freescale@yoctoproject.org)
* meta-xilinx (meta-xilinx@lists.yoctoproject.org)
* meta-ti (meta-ti@yoctoproject.org)
* etc

== How to test ==

If there is any test case for the vulnerability by the upstream project or community
- Run the test to reproduce the problem and verify the correction.
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase
- Run the regressions test

'''Regression test'''

* Build the core image for at least two architectures (preferably one big-endian and one little-endian)
* Run ptest (for those branches/packages that there is ptest mechanism)

== Patch name convention and commit message ==
Security patches like any Open Source developmen should follow the openembedded's [http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines] and [https://www.kernel.org/doc/Documentation/SecurityBugs kernel security bugs policy] for the kernel patches.
In addition security patches should have reference to the CVE identifier both in the patch file/s and the commit message.

Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit message:

bash: CVE-2014-6278

<short description>

<[YOCTO #xxx] if there is any>

References
E.g. [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278 link to CVE] or other useful info/blog/advisory.

Signed-off-by:

== Some security related links/useful tools ==

* [http://www.cvedetails.com CVE details]
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html CVE list, Linux kernel 2014]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]

== Security Issues Addressed in Yocto Releases ==
'''Yocto 2.0 - Jethero'''
https://www.yoctoproject.org/downloads/core/jethro20

'''Yocto 1.8.1 - Fido'''
https://www.yoctoproject.org/downloads/core/fido181

'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171

Security

2015-12-16T07:35:30Z

SonaSarmadi: /* Branches maintained with security fixes */

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

poky/recipes-connectivity/bind/bind_9.9.5.bb

SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://conf.patch \
...
file://bind9_9_5-CVE-2014-8500.patch \

We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

== Yocto Security Team ==

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

'''The team's main responsibilities among others are:'''

* Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
* Responsible for fixing CVEs in the Yocto releases & maintained branches
* Evaluation of tools for security tests
* Responsible for security related info in the Yocto documentations
* Hardening of Yocto release

'''How to Contact Yocto's security team Securely'''
---------------------------------------------
We have set up two security-related mailing lists:
* '''Public List'''
: yocto [dash] security [at] yoctoproject[dot] org
: This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches.

* '''Private List'''
: security [at] yoctoprojct [dot] org (Forwards to the following addresses)

: - '''sona [dot] sarmadi [at] enea [dot] com'''
: - '''mhalstead [at] linuxfoundation [dot] org'''
: For secure communications, please send your messages encrypted to both using the following GPG keys.
: Remember message headers are not encrypted so do not include sensitive information in the subject line.

: Download public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x773EF6EF68716A14 Sona Sarmadi] [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead]

Anyone can contribute with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility.

'''What you should do if you find a security vulnerability'''
---------------------------------------------
If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source packages used by the Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please send a copy to the security team at Yocto as well.
If you believe this is sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated.

'''What Yocto Security Team does when it receives a security vulnerability'''
---------------------------------------------
The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects analyzes the problem. If they deem that it is a real security problem in their software, the project will email the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros can then agree on a release date when the flaw should be made public.
There is also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy the information to other Opens Source Security mailing lists to inform the whole world of the vulnerability.

'''If an upstream project does not respond quickly'''
---------------------------------------------
If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible.
Normally big Linux vendors fix the problem if the problem affects their products.
Chances are that everyone from the enterprise distros to the commercial Yocto vendors will get fixes done first, but it is nice to have saftey net for issues that really are specific to oe and embedded.

== Branches maintained with security fixes ==
See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch.

Versions in grey are no longer actively maintained with security patches, but well-tested patches may still be accepted for them.)

== Policy for updating package versions for the stable branches ==
The Yocto project purposely limits updating of packages on oe-stable releases to items that address security problems (e.g. CVE's). For packages like qemu we avoid updating between from one "dot.dot" to another related "dot.dot" version since it has been seen in the past that even with "simple" updates, things can go wrong and a lot more testing is required to verify compatibility. Better to only add CVE patches to fix specific point problems.

== Kernel security patches ==

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Bruce Ashfield)

=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (meta-freescale@yoctoproject.org)
* meta-xilinx (meta-xilinx@lists.yoctoproject.org)
* meta-ti (meta-ti@yoctoproject.org)
* etc

== How to test ==

If there is any test case for the vulnerability by the upstream project or community
- Run the test to reproduce the problem and verify the correction.
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase
- Run the regressions test

'''Regression test'''

* Build the core image for at least two architectures (preferably one big-endian and one little-endian)
* Run ptest (for those branches/packages that there is ptest mechanism)

== Patch name convention and commit message ==
Security patches like any Open Source developmen should follow the openembedded's [http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines] and [https://www.kernel.org/doc/Documentation/SecurityBugs kernel security bugs policy] for the kernel patches.
In addition security patches should have reference to the CVE identifier both in the patch file/s and the commit message.

Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit message:

bash: CVE-2014-6278

<short description>

<[YOCTO #xxx] if there is any>

References
E.g. [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278 link to CVE] or other useful info/blog/advisory.

Signed-off-by:

== Some security related links/useful tools ==

* [http://www.cvedetails.com CVE details]
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html CVE list, Linux kernel 2014]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]

== Security Issues Addressed in Yocto Releases ==
'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171

'''Yocto 1.7 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy17

'''Yocto 1.6 - Daisy'''
https://www.yoctoproject.org/downloads/core/daisy16

Security

2015-04-27T10:06:52Z

SonaSarmadi: /* Patch name convention and commit message */

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

poky/recipes-connectivity/bind/bind_9.9.5.bb

SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://conf.patch \
...
file://bind9_9_5-CVE-2014-8500.patch \

We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

== Yocto Security Team ==

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

'''The team's main responsibilities among others are:'''

* Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
* Responsible for fixing CVEs in the Yocto releases & maintained branches
* Evaluation of tools for security tests
* Responsible for security related info in the Yocto documentations
* Hardening of Yocto release

'''How to Contact Yocto's security team Securely'''
---------------------------------------------
We have set up two security-related mailing lists:
* '''Public List'''
: yocto [dash] security [at] yoctoproject[dot] org
: This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches.

* '''Private List'''
: security [at] yoctoprojct [dot] org (Forwards to the following addresses)

: - '''sona [dot] sarmadi [at] enea [dot] com'''
: - '''mhalstead [at] linuxfoundation [dot] org'''
: For secure communications, please send your messages encrypted to both using the following GPG keys.
: Remember message headers are not encrypted so do not include sensitive information in the subject line.

: Download public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x773EF6EF68716A14 Sona Sarmadi] [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead]

Anyone can contribute with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility.

'''What you should do if you find a security vulnerability'''
---------------------------------------------
If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source packages used by the Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please send a copy to the security team at Yocto as well.
If you believe this is sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated.

'''What Yocto Security Team does when it receives a security vulnerability'''
---------------------------------------------
The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects analyzes the problem. If they deem that it is a real security problem in their software, the project will email the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros can then agree on a release date when the flaw should be made public.
There is also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy the information to other Opens Source Security mailing lists to inform the whole world of the vulnerability.

'''If an upstream project does not respond quickly'''
---------------------------------------------
If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible.
Normally big Linux vendors fix the problem if the problem affects their products.
Chances are that everyone from the enterprise distros to the commercial Yocto vendors will get fixes done first, but it is nice to have saftey net for issues that really are specific to oe and embedded.

== Branches maintained with security fixes ==

{| class="wikitable"
! Major version
! Current Version
! Branch name
! BitBake version
! Maintainer
|-
|1.7
|1.7
|dizzy
|1.24
|Armin Kuster <akuster808@gmail.com>
|-
|1.6
|1.6.1
|daisy
|1.22
|Saul Wold <sgw@linux.intel.com>
|- style="color: slategray;"
|1.5
|1.5.3
|dora
|1.20
|Robert Yang <liezhi.yang@windriver.com>
|- style="color: slategray;"
|1.4
|1.4.3[https://lists.yoctoproject.org/pipermail/yocto/2014-July/020699.html *]
|dylan
|1.18
|Paul Eggleton <paul.eggleton@linux.intel.com>
|- style="color: slategray;"
|1.3
|1.3.2
|danny
|1.16
|Ross Burton <ross.burton@intel.com>
|- style="color: slategray;"
|}

Security patches (CVEs) is backported to all branches above (if at all possible).
Versions in grey are no longer actively maintained, but well-tested security patches may still be accepted for them.)

See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch

== Policy for updating package versions for the stable branches ==
The Yocto project purposely limits updating of packages on oe-stable releases to items that address security problems (e.g. CVE's). For packages like qemu we avoid updating between from one "dot.dot" to another related "dot.dot" version since it has been seen in the past that even with "simple" updates, things can go wrong and a lot more testing is required to verify compatibility. Better to only add CVE patches to fix specific point problems.

== Kernel security patches ==

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Bruce Ashfield)

=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (meta-freescale@yoctoproject.org)
* meta-xilinx (meta-xilinx@lists.yoctoproject.org)
* meta-ti (meta-ti@yoctoproject.org)
* etc

== How to test ==

If there is any test case for the vulnerability by the upstream project or community
- Run the test to reproduce the problem and verify the correction.
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase
- Run the regressions test

'''Regression test'''

* Build the core image for at least two architectures (preferably one big-endian and one little-endian)
* Run ptest (for those branches/packages that there is ptest mechanism)

== Patch name convention and commit message ==
Security patches like any Open Source developmen should follow the openembedded's [http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines] and [https://www.kernel.org/doc/Documentation/SecurityBugs kernel security bugs policy] for the kernel patches.
In addition security patches should have reference to the CVE identifier both in the patch file/s and the commit message.

Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit message:

bash: CVE-2014-6278

<short description>

<[YOCTO #xxx] if there is any>

References
E.g. [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278 link to CVE] or other useful info/blog/advisory.

Signed-off-by:

== Some security related links/useful tools ==

* [http://www.cvedetails.com CVE details]
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html CVE list, Linux kernel 2014]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]

== Security Issues Addressed in Yocto Releases ==
'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171

'''Yocto 1.7 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy17

'''Yocto 1.6 - Daisy'''
https://www.yoctoproject.org/downloads/core/daisy16

Security

2015-04-27T05:35:08Z

SonaSarmadi: /* Patch name convention and commit message */

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

poky/recipes-connectivity/bind/bind_9.9.5.bb

SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://conf.patch \
...
file://bind9_9_5-CVE-2014-8500.patch \

We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

== Yocto Security Team ==

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

'''The team's main responsibilities among others are:'''

* Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
* Responsible for fixing CVEs in the Yocto releases & maintained branches
* Evaluation of tools for security tests
* Responsible for security related info in the Yocto documentations
* Hardening of Yocto release

'''How to Contact Yocto's security team Securely'''
---------------------------------------------
We have set up two security-related mailing lists:
* '''Public List'''
: yocto [dash] security [at] yoctoproject[dot] org
: This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches.

* '''Private List'''
: security [at] yoctoprojct [dot] org (Forwards to the following addresses)

: - '''sona [dot] sarmadi [at] enea [dot] com'''
: - '''mhalstead [at] linuxfoundation [dot] org'''
: For secure communications, please send your messages encrypted to both using the following GPG keys.
: Remember message headers are not encrypted so do not include sensitive information in the subject line.

: Download public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x773EF6EF68716A14 Sona Sarmadi] [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead]

Anyone can contribute with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility.

'''What you should do if you find a security vulnerability'''
---------------------------------------------
If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source packages used by the Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please send a copy to the security team at Yocto as well.
If you believe this is sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated.

'''What Yocto Security Team does when it receives a security vulnerability'''
---------------------------------------------
The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects analyzes the problem. If they deem that it is a real security problem in their software, the project will email the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros can then agree on a release date when the flaw should be made public.
There is also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy the information to other Opens Source Security mailing lists to inform the whole world of the vulnerability.

'''If an upstream project does not respond quickly'''
---------------------------------------------
If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible.
Normally big Linux vendors fix the problem if the problem affects their products.
Chances are that everyone from the enterprise distros to the commercial Yocto vendors will get fixes done first, but it is nice to have saftey net for issues that really are specific to oe and embedded.

== Branches maintained with security fixes ==

{| class="wikitable"
! Major version
! Current Version
! Branch name
! BitBake version
! Maintainer
|-
|1.7
|1.7
|dizzy
|1.24
|Armin Kuster <akuster808@gmail.com>
|-
|1.6
|1.6.1
|daisy
|1.22
|Saul Wold <sgw@linux.intel.com>
|- style="color: slategray;"
|1.5
|1.5.3
|dora
|1.20
|Robert Yang <liezhi.yang@windriver.com>
|- style="color: slategray;"
|1.4
|1.4.3[https://lists.yoctoproject.org/pipermail/yocto/2014-July/020699.html *]
|dylan
|1.18
|Paul Eggleton <paul.eggleton@linux.intel.com>
|- style="color: slategray;"
|1.3
|1.3.2
|danny
|1.16
|Ross Burton <ross.burton@intel.com>
|- style="color: slategray;"
|}

Security patches (CVEs) is backported to all branches above (if at all possible).
Versions in grey are no longer actively maintained, but well-tested security patches may still be accepted for them.)

See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch

== Policy for updating package versions for the stable branches ==
The Yocto project purposely limits updating of packages on oe-stable releases to items that address security problems (e.g. CVE's). For packages like qemu we avoid updating between from one "dot.dot" to another related "dot.dot" version since it has been seen in the past that even with "simple" updates, things can go wrong and a lot more testing is required to verify compatibility. Better to only add CVE patches to fix specific point problems.

== Kernel security patches ==

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Bruce Ashfield)

=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (meta-freescale@yoctoproject.org)
* meta-xilinx (meta-xilinx@lists.yoctoproject.org)
* meta-ti (meta-ti@yoctoproject.org)
* etc

== How to test ==

If there is any test case for the vulnerability by the upstream project or community
- Run the test to reproduce the problem and verify the correction.
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase
- Run the regressions test

'''Regression test'''

* Build the core image for at least two architectures (preferably one big-endian and one little-endian)
* Run ptest (for those branches/packages that there is ptest mechanism)

== Patch name convention and commit message ==
Security patches like any Open Source developmen should follow the openembedded's [http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines].
In addition security patches should have reference to the CVE identifier both in the patch file/s and the commit message.

Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit message:

bash: CVE-2014-6278

<short description>

<[YOCTO #xxx] if there is any>

References
E.g. [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278 link to CVE] or other useful info/blog/advisory.

Signed-off-by:

== Some security related links/useful tools ==

* [http://www.cvedetails.com CVE details]
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html CVE list, Linux kernel 2014]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]

== Security Issues Addressed in Yocto Releases ==
'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171

'''Yocto 1.7 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy17

'''Yocto 1.6 - Daisy'''
https://www.yoctoproject.org/downloads/core/daisy16

Security

2015-04-22T12:31:08Z

SonaSarmadi:

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

poky/recipes-connectivity/bind/bind_9.9.5.bb

SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://conf.patch \
...
file://bind9_9_5-CVE-2014-8500.patch \

We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

== Yocto Security Team ==

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

'''The team's main responsibilities among others are:'''

* Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
* Responsible for fixing CVEs in the Yocto releases & maintained branches
* Evaluation of tools for security tests
* Responsible for security related info in the Yocto documentations
* Hardening of Yocto release

'''How to Contact Yocto's security team Securely'''
---------------------------------------------
We have set up two security-related mailing lists:
* '''Public List'''
: yocto [dash] security [at] yoctoproject[dot] org
: This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches.

* '''Private List'''
: security [at] yoctoprojct [dot] org (Forwards to the following addresses)

: - '''sona [dot] sarmadi [at] enea [dot] com'''
: - '''mhalstead [at] linuxfoundation [dot] org'''
: For secure communications, please send your messages encrypted to both using the following GPG keys.
: Remember message headers are not encrypted so do not include sensitive information in the subject line.

: Download public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x773EF6EF68716A14 Sona Sarmadi] [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead]

Anyone can contribute with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility.

'''What you should do if you find a security vulnerability'''
---------------------------------------------
If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source packages used by the Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please send a copy to the security team at Yocto as well.
If you believe this is sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated.

'''What Yocto Security Team does when it receives a security vulnerability'''
---------------------------------------------
The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects analyzes the problem. If they deem that it is a real security problem in their software, the project will email the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros can then agree on a release date when the flaw should be made public.
There is also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy the information to other Opens Source Security mailing lists to inform the whole world of the vulnerability.

'''If an upstream project does not respond quickly'''
---------------------------------------------
If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible.
Normally big Linux vendors fix the problem if the problem affects their products.
Chances are that everyone from the enterprise distros to the commercial Yocto vendors will get fixes done first, but it is nice to have saftey net for issues that really are specific to oe and embedded.

== Branches maintained with security fixes ==

{| class="wikitable"
! Major version
! Current Version
! Branch name
! BitBake version
! Maintainer
|-
|1.7
|1.7
|dizzy
|1.24
|Armin Kuster <akuster808@gmail.com>
|-
|1.6
|1.6.1
|daisy
|1.22
|Saul Wold <sgw@linux.intel.com>
|- style="color: slategray;"
|1.5
|1.5.3
|dora
|1.20
|Robert Yang <liezhi.yang@windriver.com>
|- style="color: slategray;"
|1.4
|1.4.3[https://lists.yoctoproject.org/pipermail/yocto/2014-July/020699.html *]
|dylan
|1.18
|Paul Eggleton <paul.eggleton@linux.intel.com>
|- style="color: slategray;"
|1.3
|1.3.2
|danny
|1.16
|Ross Burton <ross.burton@intel.com>
|- style="color: slategray;"
|}

Security patches (CVEs) is backported to all branches above (if at all possible).
Versions in grey are no longer actively maintained, but well-tested security patches may still be accepted for them.)

See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch

== Policy for updating package versions for the stable branches ==
The Yocto project purposely limits updating of packages on oe-stable releases to items that address security problems (e.g. CVE's). For packages like qemu we avoid updating between from one "dot.dot" to another related "dot.dot" version since it has been seen in the past that even with "simple" updates, things can go wrong and a lot more testing is required to verify compatibility. Better to only add CVE patches to fix specific point problems.

== Kernel security patches ==

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Bruce Ashfield)

=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (meta-freescale@yoctoproject.org)
* meta-xilinx (meta-xilinx@lists.yoctoproject.org)
* meta-ti (meta-ti@yoctoproject.org)
* etc

== How to test ==

If there is any test case for the vulnerability by the upstream project or community
- Run the test to reproduce the problem and verify the correction.
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase
- Run the regressions test

'''Regression test'''

* Build the core image for at least two architectures (preferably one big-endian and one little-endian)
* Run ptest (for those branches/packages that there is ptest mechanism)

== Patch name convention and commit message ==
Security patches should have reference to the CVE identifier both in the patch file/s and the commit comment.

Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit comment:

bash: CVE-2014-6278

<short description>

<[YOCTO #xxx] if there is any>

References
E.g. [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278 link to CVE] or other useful info/blog/advisory.

Signed-off-by:

For additional guidelines refer to: [http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines]

== Some security related links/useful tools ==

* [http://www.cvedetails.com CVE details]
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html CVE list, Linux kernel 2014]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]

== Security Issues Addressed in Yocto Releases ==
'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171

'''Yocto 1.7 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy17

'''Yocto 1.6 - Daisy'''
https://www.yoctoproject.org/downloads/core/daisy16

Security

2015-04-15T09:05:01Z

SonaSarmadi: /* Policy for updating package versions for the stable branches */

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

poky/recipes-connectivity/bind/bind_9.9.5.bb

SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://conf.patch \
...
file://bind9_9_5-CVE-2014-8500.patch \

We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

== Yocto Security Team ==

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

'''The team's main responsibilities among others are:'''

* Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
* Responsible for fixing CVEs in the Yocto releases & maintained branches
* Evaluation of tools for security tests
* Responsible for security related info in the Yocto documentations
* Hardening of Yocto release

'''How to Contact Yocto's security team Securely'''
---------------------------------------------
We have set up two security-related mailing lists:
* '''Public List'''
: yocto [dash] security [at] yoctoproject[dot] com
: This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches.

* '''Private List'''
: security [at] yoctoprojct [dot] org (Forwards to the following addresses)

: - '''sona [dot] sarmadi [at] enea [dot] com'''
: - '''mhalstead [at] linuxfoundation [dot] org'''
: For secure communications, please send your messages encrypted to both using the following GPG keys.
: Remember message headers are not encrypted so do not include sensitive information in the subject line.

: Download public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x773EF6EF68716A14 Sona Sarmadi] [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead]

Anyone can contribute with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility.

'''What you should do if you find a security vulnerability'''
---------------------------------------------
If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source packages used by the Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please send a copy to the security team at Yocto as well.
If you believe this is sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated.

'''What Yocto Security Team does when it receives a security vulnerability'''
---------------------------------------------
The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects analyzes the problem. If they deem that it is a real security problem in their software, the project will email the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros can then agree on a release date when the flaw should be made public.
There is also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy the information to other Opens Source Security mailing lists to inform the whole world of the vulnerability.

'''If an upstream project does not respond quickly'''
---------------------------------------------
If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible.
Normally big Linux vendors fix the problem if the problem affects their products.
Chances are that everyone from the enterprise distros to the commercial Yocto vendors will get fixes done first, but it is nice to have saftey net for issues that really are specific to oe and embedded.

== Branches maintained with security fixes ==

{| class="wikitable"
! Major version
! Current Version
! Branch name
! BitBake version
! Maintainer
|-
|1.7
|1.7
|dizzy
|1.24
|Armin Kuster <akuster808@gmail.com>
|-
|1.6
|1.6.1
|daisy
|1.22
|Saul Wold <sgw@linux.intel.com>
|- style="color: slategray;"
|1.5
|1.5.3
|dora
|1.20
|Robert Yang <liezhi.yang@windriver.com>
|- style="color: slategray;"
|1.4
|1.4.3[https://lists.yoctoproject.org/pipermail/yocto/2014-July/020699.html *]
|dylan
|1.18
|Paul Eggleton <paul.eggleton@linux.intel.com>
|- style="color: slategray;"
|1.3
|1.3.2
|danny
|1.16
|Ross Burton <ross.burton@intel.com>
|- style="color: slategray;"
|}

Security patches (CVEs) is backported to all branches above (if at all possible).
Versions in grey are no longer actively maintained, but well-tested security patches may still be accepted for them.)

See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch

== Policy for updating package versions for the stable branches ==
The Yocto project purposely limits updating of packages on oe-stable releases to items that address security problems (e.g. CVE's). For packages like qemu we avoid updating between from one "dot.dot" to another related "dot.dot" version since it has been seen in the past that even with "simple" updates, things can go wrong and a lot more testing is required to verify compatibility. Better to only add CVE patches to fix specific point problems.

== Kernel security patches ==

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Bruce Ashfield)

=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (meta-freescale@yoctoproject.org)
* meta-xilinx (meta-xilinx@lists.yoctoproject.org)
* meta-ti (meta-ti@yoctoproject.org)
* etc

== How to test ==

If there is any test case for the vulnerability by the upstream project or community
- Run the test to reproduce the problem and verify the correction.
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase
- Run the regressions test

'''Regression test'''

* Build the core image for at least two architectures (preferably one big-endian and one little-endian)
* Run ptest (for those branches/packages that there is ptest mechanism)

== Patch name convention and commit message ==
Security patches should have reference to the CVE identifier both in the patch file/s and the commit comment.

Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit comment:

bash: CVE-2014-6278

<short description>

<[YOCTO #xxx] if there is any>

References
E.g. [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278 link to CVE] or other useful info/blog/advisory.

Signed-off-by:

For additional guidelines refer to: [http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines]

== Some security related links/useful tools ==

* [http://www.cvedetails.com CVE details]
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html CVE list, Linux kernel 2014]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]

== Security Issues Addressed in Yocto Releases ==
'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171

'''Yocto 1.7 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy17

'''Yocto 1.6 - Daisy'''
https://www.yoctoproject.org/downloads/core/daisy16

Security

2015-04-15T08:35:01Z

SonaSarmadi: /* Kernel security patches */

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

poky/recipes-connectivity/bind/bind_9.9.5.bb

SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://conf.patch \
...
file://bind9_9_5-CVE-2014-8500.patch \

We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

== Yocto Security Team ==

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

'''The team's main responsibilities among others are:'''

* Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
* Responsible for fixing CVEs in the Yocto releases & maintained branches
* Evaluation of tools for security tests
* Responsible for security related info in the Yocto documentations
* Hardening of Yocto release

'''How to Contact Yocto's security team Securely'''
---------------------------------------------
We have set up two security-related mailing lists:
* '''Public List'''
: yocto [dash] security [at] yoctoproject[dot] com
: This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches.

* '''Private List'''
: security [at] yoctoprojct [dot] org (Forwards to the following addresses)

: - '''sona [dot] sarmadi [at] enea [dot] com'''
: - '''mhalstead [at] linuxfoundation [dot] org'''
: For secure communications, please send your messages encrypted to both using the following GPG keys.
: Remember message headers are not encrypted so do not include sensitive information in the subject line.

: Download public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x773EF6EF68716A14 Sona Sarmadi] [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead]

Anyone can contribute with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility.

'''What you should do if you find a security vulnerability'''
---------------------------------------------
If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source packages used by the Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please send a copy to the security team at Yocto as well.
If you believe this is sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated.

'''What Yocto Security Team does when it receives a security vulnerability'''
---------------------------------------------
The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects analyzes the problem. If they deem that it is a real security problem in their software, the project will email the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros can then agree on a release date when the flaw should be made public.
There is also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy the information to other Opens Source Security mailing lists to inform the whole world of the vulnerability.

'''If an upstream project does not respond quickly'''
---------------------------------------------
If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible.
Normally big Linux vendors fix the problem if the problem affects their products.
Chances are that everyone from the enterprise distros to the commercial Yocto vendors will get fixes done first, but it is nice to have saftey net for issues that really are specific to oe and embedded.

== Branches maintained with security fixes ==

{| class="wikitable"
! Major version
! Current Version
! Branch name
! BitBake version
! Maintainer
|-
|1.7
|1.7
|dizzy
|1.24
|Armin Kuster <akuster808@gmail.com>
|-
|1.6
|1.6.1
|daisy
|1.22
|Saul Wold <sgw@linux.intel.com>
|- style="color: slategray;"
|1.5
|1.5.3
|dora
|1.20
|Robert Yang <liezhi.yang@windriver.com>
|- style="color: slategray;"
|1.4
|1.4.3[https://lists.yoctoproject.org/pipermail/yocto/2014-July/020699.html *]
|dylan
|1.18
|Paul Eggleton <paul.eggleton@linux.intel.com>
|- style="color: slategray;"
|1.3
|1.3.2
|danny
|1.16
|Ross Burton <ross.burton@intel.com>
|- style="color: slategray;"
|}

Security patches (CVEs) is backported to all branches above (if at all possible).
Versions in grey are no longer actively maintained, but well-tested security patches may still be accepted for them.)

See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch

== Policy for updating package versions for the stable branches ==
The Yocto project purposely limits updating of packages on oe-stable releases to items that address security problems (CVE's). E.g. packages like qemu we avoid updating between from one "dot.dot" to another related "dot.dot" version since it has been seen in the past that even with "simple" updates, things can go wrong and a lot more testing is required to verify compatibility. Better to only add CVE patches to fix specific point problems.

== Kernel security patches ==

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Bruce Ashfield)

=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (meta-freescale@yoctoproject.org)
* meta-xilinx (meta-xilinx@lists.yoctoproject.org)
* meta-ti (meta-ti@yoctoproject.org)
* etc

== How to test ==

If there is any test case for the vulnerability by the upstream project or community
- Run the test to reproduce the problem and verify the correction.
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase
- Run the regressions test

'''Regression test'''

* Build the core image for at least two architectures (preferably one big-endian and one little-endian)
* Run ptest (for those branches/packages that there is ptest mechanism)

== Patch name convention and commit message ==
Security patches should have reference to the CVE identifier both in the patch file/s and the commit comment.

Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit comment:

bash: CVE-2014-6278

<short description>

<[YOCTO #xxx] if there is any>

References
E.g. [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278 link to CVE] or other useful info/blog/advisory.

Signed-off-by:

For additional guidelines refer to: [http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines]

== Some security related links/useful tools ==

* [http://www.cvedetails.com CVE details]
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html CVE list, Linux kernel 2014]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]

== Security Issues Addressed in Yocto Releases ==
'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171

'''Yocto 1.7 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy17

'''Yocto 1.6 - Daisy'''
https://www.yoctoproject.org/downloads/core/daisy16

Security

2015-04-15T08:34:38Z

SonaSarmadi: /* Policy for updating package versions for the stable branches */

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

poky/recipes-connectivity/bind/bind_9.9.5.bb

SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://conf.patch \
...
file://bind9_9_5-CVE-2014-8500.patch \

We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

== Yocto Security Team ==

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

'''The team's main responsibilities among others are:'''

* Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
* Responsible for fixing CVEs in the Yocto releases & maintained branches
* Evaluation of tools for security tests
* Responsible for security related info in the Yocto documentations
* Hardening of Yocto release

'''How to Contact Yocto's security team Securely'''
---------------------------------------------
We have set up two security-related mailing lists:
* '''Public List'''
: yocto [dash] security [at] yoctoproject[dot] com
: This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches.

* '''Private List'''
: security [at] yoctoprojct [dot] org (Forwards to the following addresses)

: - '''sona [dot] sarmadi [at] enea [dot] com'''
: - '''mhalstead [at] linuxfoundation [dot] org'''
: For secure communications, please send your messages encrypted to both using the following GPG keys.
: Remember message headers are not encrypted so do not include sensitive information in the subject line.

: Download public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x773EF6EF68716A14 Sona Sarmadi] [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead]

Anyone can contribute with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility.

'''What you should do if you find a security vulnerability'''
---------------------------------------------
If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source packages used by the Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please send a copy to the security team at Yocto as well.
If you believe this is sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated.

'''What Yocto Security Team does when it receives a security vulnerability'''
---------------------------------------------
The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects analyzes the problem. If they deem that it is a real security problem in their software, the project will email the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros can then agree on a release date when the flaw should be made public.
There is also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy the information to other Opens Source Security mailing lists to inform the whole world of the vulnerability.

'''If an upstream project does not respond quickly'''
---------------------------------------------
If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible.
Normally big Linux vendors fix the problem if the problem affects their products.
Chances are that everyone from the enterprise distros to the commercial Yocto vendors will get fixes done first, but it is nice to have saftey net for issues that really are specific to oe and embedded.

== Branches maintained with security fixes ==

{| class="wikitable"
! Major version
! Current Version
! Branch name
! BitBake version
! Maintainer
|-
|1.7
|1.7
|dizzy
|1.24
|Armin Kuster <akuster808@gmail.com>
|-
|1.6
|1.6.1
|daisy
|1.22
|Saul Wold <sgw@linux.intel.com>
|- style="color: slategray;"
|1.5
|1.5.3
|dora
|1.20
|Robert Yang <liezhi.yang@windriver.com>
|- style="color: slategray;"
|1.4
|1.4.3[https://lists.yoctoproject.org/pipermail/yocto/2014-July/020699.html *]
|dylan
|1.18
|Paul Eggleton <paul.eggleton@linux.intel.com>
|- style="color: slategray;"
|1.3
|1.3.2
|danny
|1.16
|Ross Burton <ross.burton@intel.com>
|- style="color: slategray;"
|}

Security patches (CVEs) is backported to all branches above (if at all possible).
Versions in grey are no longer actively maintained, but well-tested security patches may still be accepted for them.)

See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch

== Policy for updating package versions for the stable branches ==
The Yocto project purposely limits updating of packages on oe-stable releases to items that address security problems (CVE's). E.g. packages like qemu we avoid updating between from one "dot.dot" to another related "dot.dot" version since it has been seen in the past that even with "simple" updates, things can go wrong and a lot more testing is required to verify compatibility. Better to only add CVE patches to fix specific point problems.

== Kernel security patches ==

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Bruce Ashfield)

=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (meta-freescale@yoctoproject.org)
* meta-xilinx (meta-xilinx@lists.yoctoproject.org)
* meta-ti (meta-ti@yoctoproject.org)
* etc

== How to test ==

If there is any test case for the vulnerability by the upstream project or community
- Run the test to reproduce the problem and verify the correction.
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase
- Run the regressions test

'''Regression test'''

* Build the core image for at least two architectures (preferably one big-endian and one little-endian)
* Run ptest (for those branches/packages that there is ptest mechanism)

== Patch name convention and commit message ==
Security patches should have reference to the CVE identifier both in the patch file/s and the commit comment.

Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit comment:

bash: CVE-2014-6278

<short description>

<[YOCTO #xxx] if there is any>

References
E.g. [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278 link to CVE] or other useful info/blog/advisory.

Signed-off-by:

For additional guidelines refer to: [http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines]

== Some security related links/useful tools ==

* [http://www.cvedetails.com CVE details]
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html CVE list, Linux kernel 2014]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]

== Security Issues Addressed in Yocto Releases ==
'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171

'''Yocto 1.7 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy17

'''Yocto 1.6 - Daisy'''
https://www.yoctoproject.org/downloads/core/daisy16

Security

2015-04-15T05:52:24Z

SonaSarmadi: /* Security Policy for updating package versions for the stable branches */

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

poky/recipes-connectivity/bind/bind_9.9.5.bb

SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://conf.patch \
...
file://bind9_9_5-CVE-2014-8500.patch \

We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

== Yocto Security Team ==

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

'''The team's main responsibilities among others are:'''

* Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
* Responsible for fixing CVEs in the Yocto releases & maintained branches
* Evaluation of tools for security tests
* Responsible for security related info in the Yocto documentations
* Hardening of Yocto release

'''How to Contact Yocto's security team Securely'''
---------------------------------------------
We have set up two security-related mailing lists:
* '''Public List'''
: yocto [dash] security [at] yoctoproject[dot] com
: This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches.

* '''Private List'''
: security [at] yoctoprojct [dot] org (Forwards to the following addresses)

: - '''sona [dot] sarmadi [at] enea [dot] com'''
: - '''mhalstead [at] linuxfoundation [dot] org'''
: For secure communications, please send your messages encrypted to both using the following GPG keys.
: Remember message headers are not encrypted so do not include sensitive information in the subject line.

: Download public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x773EF6EF68716A14 Sona Sarmadi] [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead]

Anyone can contribute with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility.

'''What you should do if you find a security vulnerability'''
---------------------------------------------
If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source packages used by the Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please send a copy to the security team at Yocto as well.
If you believe this is sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated.

'''What Yocto Security Team does when it receives a security vulnerability'''
---------------------------------------------
The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects analyzes the problem. If they deem that it is a real security problem in their software, the project will email the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros can then agree on a release date when the flaw should be made public.
There is also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy the information to other Opens Source Security mailing lists to inform the whole world of the vulnerability.

'''If an upstream project does not respond quickly'''
---------------------------------------------
If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible.
Normally big Linux vendors fix the problem if the problem affects their products.
Chances are that everyone from the enterprise distros to the commercial Yocto vendors will get fixes done first, but it is nice to have saftey net for issues that really are specific to oe and embedded.

== Branches maintained with security fixes ==

{| class="wikitable"
! Major version
! Current Version
! Branch name
! BitBake version
! Maintainer
|-
|1.7
|1.7
|dizzy
|1.24
|Armin Kuster <akuster808@gmail.com>
|-
|1.6
|1.6.1
|daisy
|1.22
|Saul Wold <sgw@linux.intel.com>
|- style="color: slategray;"
|1.5
|1.5.3
|dora
|1.20
|Robert Yang <liezhi.yang@windriver.com>
|- style="color: slategray;"
|1.4
|1.4.3[https://lists.yoctoproject.org/pipermail/yocto/2014-July/020699.html *]
|dylan
|1.18
|Paul Eggleton <paul.eggleton@linux.intel.com>
|- style="color: slategray;"
|1.3
|1.3.2
|danny
|1.16
|Ross Burton <ross.burton@intel.com>
|- style="color: slategray;"
|}

Security patches (CVEs) is backported to all branches above (if at all possible).
Versions in grey are no longer actively maintained, but well-tested security patches may still be accepted for them.)

See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch

== Policy for updating package versions for the stable branches ==
The yocto project purposely limits updating of packages in oe-core stable releases to items that address CVE, security related items. Some packages such as qemu however we avodid updating from one dot.dot to another dot.dot since we have seen issues in the past with "simple" updates, lots more testing is required vs knowing we are adding a CVE patch to fix a point problem.

== Kernel security patches ==

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Bruce Ashfield)

=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (meta-freescale@yoctoproject.org)
* meta-xilinx (meta-xilinx@lists.yoctoproject.org)
* meta-ti (meta-ti@yoctoproject.org)
* etc

== How to test ==

If there is any test case for the vulnerability by the upstream project or community
- Run the test to reproduce the problem and verify the correction.
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase
- Run the regressions test

'''Regression test'''

* Build the core image for at least two architectures (preferably one big-endian and one little-endian)
* Run ptest (for those branches/packages that there is ptest mechanism)

== Patch name convention and commit message ==
Security patches should have reference to the CVE identifier both in the patch file/s and the commit comment.

Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit comment:

bash: CVE-2014-6278

<short description>

<[YOCTO #xxx] if there is any>

References
E.g. [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278 link to CVE] or other useful info/blog/advisory.

Signed-off-by:

For additional guidelines refer to: [http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines]

== Some security related links/useful tools ==

* [http://www.cvedetails.com CVE details]
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html CVE list, Linux kernel 2014]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]

== Security Issues Addressed in Yocto Releases ==
'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171

'''Yocto 1.7 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy17

'''Yocto 1.6 - Daisy'''
https://www.yoctoproject.org/downloads/core/daisy16

Security

2015-04-15T05:48:28Z

SonaSarmadi:

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

poky/recipes-connectivity/bind/bind_9.9.5.bb

SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://conf.patch \
...
file://bind9_9_5-CVE-2014-8500.patch \

We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

== Yocto Security Team ==

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

'''The team's main responsibilities among others are:'''

* Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
* Responsible for fixing CVEs in the Yocto releases & maintained branches
* Evaluation of tools for security tests
* Responsible for security related info in the Yocto documentations
* Hardening of Yocto release

'''How to Contact Yocto's security team Securely'''
---------------------------------------------
We have set up two security-related mailing lists:
* '''Public List'''
: yocto [dash] security [at] yoctoproject[dot] com
: This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches.

* '''Private List'''
: security [at] yoctoprojct [dot] org (Forwards to the following addresses)

: - '''sona [dot] sarmadi [at] enea [dot] com'''
: - '''mhalstead [at] linuxfoundation [dot] org'''
: For secure communications, please send your messages encrypted to both using the following GPG keys.
: Remember message headers are not encrypted so do not include sensitive information in the subject line.

: Download public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x773EF6EF68716A14 Sona Sarmadi] [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead]

Anyone can contribute with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility.

'''What you should do if you find a security vulnerability'''
---------------------------------------------
If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source packages used by the Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please send a copy to the security team at Yocto as well.
If you believe this is sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated.

'''What Yocto Security Team does when it receives a security vulnerability'''
---------------------------------------------
The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects analyzes the problem. If they deem that it is a real security problem in their software, the project will email the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros can then agree on a release date when the flaw should be made public.
There is also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy the information to other Opens Source Security mailing lists to inform the whole world of the vulnerability.

'''If an upstream project does not respond quickly'''
---------------------------------------------
If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible.
Normally big Linux vendors fix the problem if the problem affects their products.
Chances are that everyone from the enterprise distros to the commercial Yocto vendors will get fixes done first, but it is nice to have saftey net for issues that really are specific to oe and embedded.

== Branches maintained with security fixes ==

{| class="wikitable"
! Major version
! Current Version
! Branch name
! BitBake version
! Maintainer
|-
|1.7
|1.7
|dizzy
|1.24
|Armin Kuster <akuster808@gmail.com>
|-
|1.6
|1.6.1
|daisy
|1.22
|Saul Wold <sgw@linux.intel.com>
|- style="color: slategray;"
|1.5
|1.5.3
|dora
|1.20
|Robert Yang <liezhi.yang@windriver.com>
|- style="color: slategray;"
|1.4
|1.4.3[https://lists.yoctoproject.org/pipermail/yocto/2014-July/020699.html *]
|dylan
|1.18
|Paul Eggleton <paul.eggleton@linux.intel.com>
|- style="color: slategray;"
|1.3
|1.3.2
|danny
|1.16
|Ross Burton <ross.burton@intel.com>
|- style="color: slategray;"
|}

Security patches (CVEs) is backported to all branches above (if at all possible).
Versions in grey are no longer actively maintained, but well-tested security patches may still be accepted for them.)

See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch

== Security Policy for updating package versions for the stable branches ==
The yocto project purposely limits updating of packages in oe-core stable releases to items that address CVE, security related items. Some packages such as qemu however we avodid updating from one dot.dot to another dot.dot since we have seen issues in the past with "simple" updates, lots more testing is required vs knowing we are adding a CVE patch to fix a point problem.

== Kernel security patches ==

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Bruce Ashfield)

=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (meta-freescale@yoctoproject.org)
* meta-xilinx (meta-xilinx@lists.yoctoproject.org)
* meta-ti (meta-ti@yoctoproject.org)
* etc

== How to test ==

If there is any test case for the vulnerability by the upstream project or community
- Run the test to reproduce the problem and verify the correction.
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase
- Run the regressions test

'''Regression test'''

* Build the core image for at least two architectures (preferably one big-endian and one little-endian)
* Run ptest (for those branches/packages that there is ptest mechanism)

== Patch name convention and commit message ==
Security patches should have reference to the CVE identifier both in the patch file/s and the commit comment.

Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit comment:

bash: CVE-2014-6278

<short description>

<[YOCTO #xxx] if there is any>

References
E.g. [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278 link to CVE] or other useful info/blog/advisory.

Signed-off-by:

For additional guidelines refer to: [http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines]

== Some security related links/useful tools ==

* [http://www.cvedetails.com CVE details]
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html CVE list, Linux kernel 2014]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]

== Security Issues Addressed in Yocto Releases ==
'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171

'''Yocto 1.7 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy17

'''Yocto 1.6 - Daisy'''
https://www.yoctoproject.org/downloads/core/daisy16

Security

2015-04-15T05:41:55Z

SonaSarmadi: /* Branches maintained with security fixes */

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

poky/recipes-connectivity/bind/bind_9.9.5.bb

SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://conf.patch \
...
file://bind9_9_5-CVE-2014-8500.patch \

We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

== Yocto Security Team ==

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

'''The team's main responsibilities among others are:'''

* Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
* Responsible for fixing CVEs in the Yocto releases & maintained branches
* Evaluation of tools for security tests
* Responsible for security related info in the Yocto documentations
* Hardening of Yocto release

'''How to Contact Yocto's security team Securely'''
---------------------------------------------
We have set up two security-related mailing lists:
* '''Public List'''
: yocto [dash] security [at] yoctoproject[dot] com
: This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches.

* '''Private List'''
: security [at] yoctoprojct [dot] org (Forwards to the following addresses)

: - '''sona [dot] sarmadi [at] enea [dot] com'''
: - '''mhalstead [at] linuxfoundation [dot] org'''
: For secure communications, please send your messages encrypted to both using the following GPG keys.
: Remember message headers are not encrypted so do not include sensitive information in the subject line.

: Download public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x773EF6EF68716A14 Sona Sarmadi] [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead]

Anyone can contribute with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility.

'''What you should do if you find a security vulnerability'''
---------------------------------------------
If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source packages used by the Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please send a copy to the security team at Yocto as well.
If you believe this is sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated.

'''What Yocto Security Team does when it receives a security vulnerability'''
---------------------------------------------
The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects analyzes the problem. If they deem that it is a real security problem in their software, the project will email the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros can then agree on a release date when the flaw should be made public.
There is also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy the information to other Opens Source Security mailing lists to inform the whole world of the vulnerability.

'''If an upstream project does not respond quickly'''
---------------------------------------------
If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible.
Normally big Linux vendors fix the problem if the problem affects their products.
Chances are that everyone from the enterprise distros to the commercial Yocto vendors will get fixes done first, but it is nice to have saftey net for issues that really are specific to oe and embedded.

== Branches maintained with security fixes ==

{| class="wikitable"
! Major version
! Current Version
! Branch name
! BitBake version
! Maintainer
|-
|1.7
|1.7
|dizzy
|1.24
|Armin Kuster <akuster808@gmail.com>
|-
|1.6
|1.6.1
|daisy
|1.22
|Saul Wold <sgw@linux.intel.com>
|- style="color: slategray;"
|1.5
|1.5.3
|dora
|1.20
|Robert Yang <liezhi.yang@windriver.com>
|- style="color: slategray;"
|1.4
|1.4.3[https://lists.yoctoproject.org/pipermail/yocto/2014-July/020699.html *]
|dylan
|1.18
|Paul Eggleton <paul.eggleton@linux.intel.com>
|- style="color: slategray;"
|1.3
|1.3.2
|danny
|1.16
|Ross Burton <ross.burton@intel.com>
|- style="color: slategray;"
|}

Security patches (CVEs) is backported to all branches above (if at all possible).
Versions in grey are no longer actively maintained, but well-tested security patches may still be accepted for them.)

See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch

== Kernel security patches ==

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Bruce Ashfield)

=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (meta-freescale@yoctoproject.org)
* meta-xilinx (meta-xilinx@lists.yoctoproject.org)
* meta-ti (meta-ti@yoctoproject.org)
* etc

== How to test ==

If there is any test case for the vulnerability by the upstream project or community
- Run the test to reproduce the problem and verify the correction.
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase
- Run the regressions test

'''Regression test'''

* Build the core image for at least two architectures (preferably one big-endian and one little-endian)
* Run ptest (for those branches/packages that there is ptest mechanism)

== Patch name convention and commit message ==
Security patches should have reference to the CVE identifier both in the patch file/s and the commit comment.

Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit comment:

bash: CVE-2014-6278

<short description>

<[YOCTO #xxx] if there is any>

References
E.g. [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278 link to CVE] or other useful info/blog/advisory.

Signed-off-by:

For additional guidelines refer to: [http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines]

== Some security related links/useful tools ==

* [http://www.cvedetails.com CVE details]
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html CVE list, Linux kernel 2014]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]

== Security Issues Addressed in Yocto Releases ==
'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171

'''Yocto 1.7 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy17

'''Yocto 1.6 - Daisy'''
https://www.yoctoproject.org/downloads/core/daisy16

Security

2015-03-10T16:47:19Z

SonaSarmadi: /* Yocto Security Team */

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

poky/recipes-connectivity/bind/bind_9.9.5.bb

SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://conf.patch \
...
file://bind9_9_5-CVE-2014-8500.patch \

We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

== Yocto Security Team ==

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

'''The team's main responsibilities among others are:'''

* Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
* Responsible for fixing CVEs in the Yocto releases & maintained branches
* Evaluation of tools for security tests
* Responsible for security related info in the Yocto documentations
* Hardening of Yocto release

'''How to Contact Yocto's security team Securely'''
---------------------------------------------
We have set up two security-related mailing lists:
* '''Public List'''
: yocto [dash] security [at] yoctoproject[dot] com
: This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches.

* '''Private List'''
: security [at] yoctoprojct [dot] org (Forwards to the following addresses)

: - '''sona [dot] sarmadi [at] enea [dot] com'''
: - '''mhalstead [at] linuxfoundation [dot] org'''
: For secure communications, please send your messages encrypted to both using the following GPG keys.
: Remember message headers are not encrypted so do not include sensitive information in the subject line.

: Download public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x773EF6EF68716A14 Sona Sarmadi] [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead]

Anyone can contribute with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility.

'''What you should do if you find a security vulnerability'''
---------------------------------------------
If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source packages used by the Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please send a copy to the security team at Yocto as well.
If you believe this is sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated.

'''What Yocto Security Team does when it receives a security vulnerability'''
---------------------------------------------
The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects analyzes the problem. If they deem that it is a real security problem in their software, the project will email the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros can then agree on a release date when the flaw should be made public.
There is also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy the information to other Opens Source Security mailing lists to inform the whole world of the vulnerability.

'''If an upstream project does not respond quickly'''
---------------------------------------------
If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible.
Normally big Linux vendors fix the problem if the problem affects their products.
Chances are that everyone from the enterprise distros to the commercial Yocto vendors will get fixes done first, but it is nice to have saftey net for issues that really are specific to oe and embedded.

== Branches maintained with security fixes ==

{| class="wikitable"
! Major version
! Current Version
! Branch name
! BitBake version
! Maintainer
|-
|1.7
|1.7
|dizzy
|1.24
|Armin Kuster <akuster808@gmail.com>
|-
|1.6
|1.6.1
|daisy
|1.22
|Saul Wold <sgw@linux.intel.com>
|- style="color: slategray;"
|1.5
|1.5.3
|dora
|1.20
|Robert Yang <liezhi.yang@windriver.com>
|- style="color: slategray;"
|1.4
|1.4.3[https://lists.yoctoproject.org/pipermail/yocto/2014-July/020699.html *]
|dylan
|1.18
|Paul Eggleton <paul.eggleton@linux.intel.com>
|- style="color: slategray;"
|1.3
|1.3.2
|danny
|1.16
|Ross Burton <ross.burton@intel.com>
|- style="color: slategray;"
|}

Security patches (CVEs) is backported to all branches above (if at all possible).
Versions in grey are no longer actively maintained, but well-tested security patches may still be accepted for them.)

See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch

== Kernel security patches ==

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Bruce Ashfield)

=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (meta-freescale@yoctoproject.org)
* meta-xilinx (meta-xilinx@lists.yoctoproject.org)
* meta-ti (meta-ti@yoctoproject.org)
* etc

== How to test ==

If there is any test case for the vulnerability by the upstream project or community
- Run the test to reproduce the problem and verify the correction.
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase
- Run the regressions test

'''Regression test'''

* Build the core image for at least two architectures (preferably one big-endian and one little-endian)
* Run ptest (for those branches/packages that there is ptest mechanism)

== Patch name convention and commit message ==
Security patches should have reference to the CVE identifier both in the patch file/s and the commit comment.

Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit comment:

bash: CVE-2014-6278

<short description>

<[YOCTO #xxx] if there is any>

References
E.g. [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278 link to CVE] or other useful info/blog/advisory.

Signed-off-by:

For additional guidelines refer to: [http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines]

== Some security related links/useful tools ==

* [http://www.cvedetails.com CVE details]
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html CVE list, Linux kernel 2014]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]

== Security Issues Addressed in Yocto Releases ==
'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171

'''Yocto 1.7 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy17

'''Yocto 1.6 - Daisy'''
https://www.yoctoproject.org/downloads/core/daisy16

Security

2015-03-10T16:44:57Z

SonaSarmadi: /* Yocto Security Team */

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

poky/recipes-connectivity/bind/bind_9.9.5.bb

SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://conf.patch \
...
file://bind9_9_5-CVE-2014-8500.patch \

We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

== Yocto Security Team ==

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

'''The team's main responsibilities among others are:'''

* Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
* Responsible for fixing CVEs in the Yocto releases & maintained branches
* Evaluation of tools for security tests
* Responsible for security related info in the Yocto documentations
* Hardening of Yocto release

'''How to Contact Yocto's security team Securely'''
---------------------------------------------
We have set up two security-related mailing lists:
* '''Public List'''
: yocto [dash] security [at] yoctoproject[dot] com
: This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches.

* '''Private List'''
: security [at] yoctoprojct [dot] org (Forwards to the following addresses)

: - '''sona [dot] sarmadi [at] enea [dot] com'''
: - '''mhalstead [at] linuxfoundation [dot] org'''
: For secure communications, please send your messages encrypted to both using the following GPG keys.
: Remember message headers are not encrypted so do not include sensitive information in the subject line.

: Download public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x773EF6EF68716A14 Sona Sarmadi] [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead]

Anyone can contribute with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility.

'''What you should do if you find a security vulnerability'''
---------------------------------------------
If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source packages used by Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please send a copy to the security team at Yocto as well.
If you believe this is sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated.

'''What Yocto Security Team does when it receives a security vulnerability'''
---------------------------------------------
The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects analyzes the problem. If they deem that it is a real security problem in their software, the project will email the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros can then agree on a release date when the flaw should be made public.
There is also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy the information to other Opens Source Security mailing lists to inform the whole world of the vulnerability.

'''If an upstream project does not respond quickly'''
---------------------------------------------
If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible.
Normally big Linux vendors fix the problem if the problem affects their products.
Chances are that everyone from the enterprise distros to the commercial Yocto vendors will get fixes done first, but it is nice to have saftey net for issues that really are specific to oe and embedded.

== Branches maintained with security fixes ==

{| class="wikitable"
! Major version
! Current Version
! Branch name
! BitBake version
! Maintainer
|-
|1.7
|1.7
|dizzy
|1.24
|Armin Kuster <akuster808@gmail.com>
|-
|1.6
|1.6.1
|daisy
|1.22
|Saul Wold <sgw@linux.intel.com>
|- style="color: slategray;"
|1.5
|1.5.3
|dora
|1.20
|Robert Yang <liezhi.yang@windriver.com>
|- style="color: slategray;"
|1.4
|1.4.3[https://lists.yoctoproject.org/pipermail/yocto/2014-July/020699.html *]
|dylan
|1.18
|Paul Eggleton <paul.eggleton@linux.intel.com>
|- style="color: slategray;"
|1.3
|1.3.2
|danny
|1.16
|Ross Burton <ross.burton@intel.com>
|- style="color: slategray;"
|}

Security patches (CVEs) is backported to all branches above (if at all possible).
Versions in grey are no longer actively maintained, but well-tested security patches may still be accepted for them.)

See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch

== Kernel security patches ==

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Bruce Ashfield)

=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (meta-freescale@yoctoproject.org)
* meta-xilinx (meta-xilinx@lists.yoctoproject.org)
* meta-ti (meta-ti@yoctoproject.org)
* etc

== How to test ==

If there is any test case for the vulnerability by the upstream project or community
- Run the test to reproduce the problem and verify the correction.
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase
- Run the regressions test

'''Regression test'''

* Build the core image for at least two architectures (preferably one big-endian and one little-endian)
* Run ptest (for those branches/packages that there is ptest mechanism)

== Patch name convention and commit message ==
Security patches should have reference to the CVE identifier both in the patch file/s and the commit comment.

Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit comment:

bash: CVE-2014-6278

<short description>

<[YOCTO #xxx] if there is any>

References
E.g. [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278 link to CVE] or other useful info/blog/advisory.

Signed-off-by:

For additional guidelines refer to: [http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines]

== Some security related links/useful tools ==

* [http://www.cvedetails.com CVE details]
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html CVE list, Linux kernel 2014]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]

== Security Issues Addressed in Yocto Releases ==
'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171

'''Yocto 1.7 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy17

'''Yocto 1.6 - Daisy'''
https://www.yoctoproject.org/downloads/core/daisy16

Security

2015-03-10T12:10:39Z

SonaSarmadi: /* Branches maintained with security fixes */

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

poky/recipes-connectivity/bind/bind_9.9.5.bb

SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://conf.patch \
...
file://bind9_9_5-CVE-2014-8500.patch \

We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

== Yocto Security Team ==

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

'''The team's main responsibilities among others are:'''

* Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
* Responsible for fixing CVEs in the Yocto releases & maintained branches
* Evaluation of tools for security tests
* Responsible for security related info in the Yocto documentations
* Hardening of Yocto release

'''How to Contact Yocto's security team Securely'''
---------------------------------------------
We have set up two security-related mailing lists:
* '''Public List'''
: yocto [dash] security [at] yoctoproject[dot] com
: This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches.

* '''Private List'''
: security [at] yoctoprojct [dot] org (Forwards to the following addresses)

: - '''sona [dot] sarmadi [at] enea [dot] com'''
: - '''mhalstead [at] linuxfoundation [dot] org'''
: For secure communications, please send your messages encrypted to both using the following GPG keys.
: Remember message headers are not encrypted so do not include sensitive information in the subject line.

: Download public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x773EF6EF68716A14 Sona Sarmadi] [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead]

Anyone can contribute with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility.

'''What you should do if you find a security vulnerability'''
---------------------------------------------
If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source packages used by Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please send a copy to the security team at Yocto as well.
If you believe this is sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated.

'''What Yocto Security Team do/does when it receives a security vulnerability'''
---------------------------------------------
The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects analyzes the problem. If they deem that it is a real security problem in their software, the project will email the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros can then agree on a release date when the flaw should be made public.
There is also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy the information to other Opens Source Security mailing lists to inform the whole world of the vulnerability.

'''If an upstream project does not respond quickly'''
---------------------------------------------
If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible.
Normally big Linux vendors fix the problem if the problem affects their products.
Chances are that everyone from the enterprise distros to the commercial Yocto vendors will get fixes done first, but it is nice to have saftey net for issues that really are specific to oe and embedded.

== Branches maintained with security fixes ==

{| class="wikitable"
! Major version
! Current Version
! Branch name
! BitBake version
! Maintainer
|-
|1.7
|1.7
|dizzy
|1.24
|Armin Kuster <akuster808@gmail.com>
|-
|1.6
|1.6.1
|daisy
|1.22
|Saul Wold <sgw@linux.intel.com>
|- style="color: slategray;"
|1.5
|1.5.3
|dora
|1.20
|Robert Yang <liezhi.yang@windriver.com>
|- style="color: slategray;"
|1.4
|1.4.3[https://lists.yoctoproject.org/pipermail/yocto/2014-July/020699.html *]
|dylan
|1.18
|Paul Eggleton <paul.eggleton@linux.intel.com>
|- style="color: slategray;"
|1.3
|1.3.2
|danny
|1.16
|Ross Burton <ross.burton@intel.com>
|- style="color: slategray;"
|}

Security patches (CVEs) is backported to all branches above (if at all possible).
Versions in grey are no longer actively maintained, but well-tested security patches may still be accepted for them.)

See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch

== Kernel security patches ==

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Bruce Ashfield)

=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (meta-freescale@yoctoproject.org)
* meta-xilinx (meta-xilinx@lists.yoctoproject.org)
* meta-ti (meta-ti@yoctoproject.org)
* etc

== How to test ==

If there is any test case for the vulnerability by the upstream project or community
- Run the test to reproduce the problem and verify the correction.
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase
- Run the regressions test

'''Regression test'''

* Build the core image for at least two architectures (preferably one big-endian and one little-endian)
* Run ptest (for those branches/packages that there is ptest mechanism)

== Patch name convention and commit message ==
Security patches should have reference to the CVE identifier both in the patch file/s and the commit comment.

Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit comment:

bash: CVE-2014-6278

<short description>

<[YOCTO #xxx] if there is any>

References
E.g. [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278 link to CVE] or other useful info/blog/advisory.

Signed-off-by:

For additional guidelines refer to: [http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines]

== Some security related links/useful tools ==

* [http://www.cvedetails.com CVE details]
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html CVE list, Linux kernel 2014]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]

== Security Issues Addressed in Yocto Releases ==
'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171

'''Yocto 1.7 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy17

'''Yocto 1.6 - Daisy'''
https://www.yoctoproject.org/downloads/core/daisy16

Security

2015-03-10T12:06:09Z

SonaSarmadi: /* Yocto Security Team */

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

poky/recipes-connectivity/bind/bind_9.9.5.bb

SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://conf.patch \
...
file://bind9_9_5-CVE-2014-8500.patch \

We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

== Yocto Security Team ==

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

'''The team's main responsibilities among others are:'''

* Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
* Responsible for fixing CVEs in the Yocto releases & maintained branches
* Evaluation of tools for security tests
* Responsible for security related info in the Yocto documentations
* Hardening of Yocto release

'''How to Contact Yocto's security team Securely'''
---------------------------------------------
We have set up two security-related mailing lists:
* '''Public List'''
: yocto [dash] security [at] yoctoproject[dot] com
: This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches.

* '''Private List'''
: security [at] yoctoprojct [dot] org (Forwards to the following addresses)

: - '''sona [dot] sarmadi [at] enea [dot] com'''
: - '''mhalstead [at] linuxfoundation [dot] org'''
: For secure communications, please send your messages encrypted to both using the following GPG keys.
: Remember message headers are not encrypted so do not include sensitive information in the subject line.

: Download public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x773EF6EF68716A14 Sona Sarmadi] [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead]

Anyone can contribute with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility.

'''What you should do if you find a security vulnerability'''
---------------------------------------------
If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source packages used by Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please send a copy to the security team at Yocto as well.
If you believe this is sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated.

'''What Yocto Security Team do/does when it receives a security vulnerability'''
---------------------------------------------
The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects analyzes the problem. If they deem that it is a real security problem in their software, the project will email the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros can then agree on a release date when the flaw should be made public.
There is also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy the information to other Opens Source Security mailing lists to inform the whole world of the vulnerability.

'''If an upstream project does not respond quickly'''
---------------------------------------------
If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible.
Normally big Linux vendors fix the problem if the problem affects their products.
Chances are that everyone from the enterprise distros to the commercial Yocto vendors will get fixes done first, but it is nice to have saftey net for issues that really are specific to oe and embedded.

== Branches maintained with security fixes ==

{| class="wikitable"
! Major version
! Current Version
! Branch name
! BitBake version
! Maintainer
|-
|1.7
|1.7
|dizzy
|1.24
|Armin Kuster <akuster808@gmail.com>
|-
|1.6
|1.6.1
|daisy
|1.22
|Saul Wold <sgw@linux.intel.com>
|-
|1.5
|1.5.3
|dora
|1.20
|Robert Yang <liezhi.yang@windriver.com>
|- style="color: slategray;"
|1.4
|1.4.3[https://lists.yoctoproject.org/pipermail/yocto/2014-July/020699.html *]
|dylan
|1.18
|Paul Eggleton <paul.eggleton@linux.intel.com>
|- style="color: slategray;"
|1.3
|1.3.2
|danny
|1.16
|Ross Burton <ross.burton@intel.com>
|- style="color: slategray;"
|}

All CVEs (security patches) should be backported to all branches above (if at all possible).
Versions in grey are no longer actively maintained, but well-tested security patches may still be accepted for them.)

See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch

== Kernel security patches ==

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Bruce Ashfield)

=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (meta-freescale@yoctoproject.org)
* meta-xilinx (meta-xilinx@lists.yoctoproject.org)
* meta-ti (meta-ti@yoctoproject.org)
* etc

== How to test ==

If there is any test case for the vulnerability by the upstream project or community
- Run the test to reproduce the problem and verify the correction.
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase
- Run the regressions test

'''Regression test'''

* Build the core image for at least two architectures (preferably one big-endian and one little-endian)
* Run ptest (for those branches/packages that there is ptest mechanism)

== Patch name convention and commit message ==
Security patches should have reference to the CVE identifier both in the patch file/s and the commit comment.

Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit comment:

bash: CVE-2014-6278

<short description>

<[YOCTO #xxx] if there is any>

References
E.g. [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278 link to CVE] or other useful info/blog/advisory.

Signed-off-by:

For additional guidelines refer to: [http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines]

== Some security related links/useful tools ==

* [http://www.cvedetails.com CVE details]
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html CVE list, Linux kernel 2014]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]

== Security Issues Addressed in Yocto Releases ==
'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171

'''Yocto 1.7 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy17

'''Yocto 1.6 - Daisy'''
https://www.yoctoproject.org/downloads/core/daisy16

Security

2015-03-10T12:00:36Z

SonaSarmadi: /* Yocto Security Team */

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

poky/recipes-connectivity/bind/bind_9.9.5.bb

SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://conf.patch \
...
file://bind9_9_5-CVE-2014-8500.patch \

We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

== Yocto Security Team ==

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

'''The team's main responsibilities among others are:'''

* Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
* Responsible for fixing CVEs in the Yocto releases & maintained branches
* Evaluation of tools for security tests
* Responsible for security related info in the Yocto documentations
* Hardening of Yocto release

'''How to Contact Yocto's security team Securely'''
---------------------------------------------
We have set up two security-related mailing lists:
* '''Public List'''
: yocto [dash] security [at] yoctoproject[dot] com
: This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches.

* '''Private List'''
: security [at] yoctoprojct [dot] org (Forwards to the following addresses)

: - '''sona [dot] sarmadi [at] enea [dot] com'''
: - '''mhalstead [at] linuxfoundation [dot] org'''
: For secure communications, please send your messages encrypted to both using the following GPG keys.
: Remember message headers are not encrypted so do not include sensitive information in the subject line.

: Download public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x773EF6EF68716A14 Sona Sarmadi] [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead]

Anyone can contribute with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility.

'''What you should do if you find a security vulnerability'''
---------------------------------------------
If you find a security flaw; a crash, an information leakage or anything that can have a security impact if exploited in any Open Source packages used by Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please copy security team at Yocto as well.
If you believe this is a sensitive information, please report the vulnerability in a secure way, i.e. encrypt email and send it to the private list. This ensures that the exploit is not leaked and exploited before a
response/fix has been generated.

'''What Yocto Security Team do/does when they receive a security vulnerability'''
---------------------------------------------
The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects, analyzes the problem. If they deem that it is a real security problem in their software, the project then mail the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros then can agree on a release date when the flaw should be made public.
There’s also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy other Opens Source Security mailing lists to inform the whole world of vulnerability.

'''If an upstream project does not respond quickly'''
---------------------------------------------
If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible.
Normally big Linux vendors fix the problem if the problem affects their products.
Chances are that everyone from the enterprise distros to the commercial
Yocto vendors will get fixes done first, but it is nice to have saftey net for
issues that really are specific to oe and embedded.

== Branches maintained with security fixes ==

{| class="wikitable"
! Major version
! Current Version
! Branch name
! BitBake version
! Maintainer
|-
|1.7
|1.7
|dizzy
|1.24
|Armin Kuster <akuster808@gmail.com>
|-
|1.6
|1.6.1
|daisy
|1.22
|Saul Wold <sgw@linux.intel.com>
|-
|1.5
|1.5.3
|dora
|1.20
|Robert Yang <liezhi.yang@windriver.com>
|- style="color: slategray;"
|1.4
|1.4.3[https://lists.yoctoproject.org/pipermail/yocto/2014-July/020699.html *]
|dylan
|1.18
|Paul Eggleton <paul.eggleton@linux.intel.com>
|- style="color: slategray;"
|1.3
|1.3.2
|danny
|1.16
|Ross Burton <ross.burton@intel.com>
|- style="color: slategray;"
|}

All CVEs (security patches) should be backported to all branches above (if at all possible).
Versions in grey are no longer actively maintained, but well-tested security patches may still be accepted for them.)

See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch

== Kernel security patches ==

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Bruce Ashfield)

=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (meta-freescale@yoctoproject.org)
* meta-xilinx (meta-xilinx@lists.yoctoproject.org)
* meta-ti (meta-ti@yoctoproject.org)
* etc

== How to test ==

If there is any test case for the vulnerability by the upstream project or community
- Run the test to reproduce the problem and verify the correction.
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase
- Run the regressions test

'''Regression test'''

* Build the core image for at least two architectures (preferably one big-endian and one little-endian)
* Run ptest (for those branches/packages that there is ptest mechanism)

== Patch name convention and commit message ==
Security patches should have reference to the CVE identifier both in the patch file/s and the commit comment.

Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit comment:

bash: CVE-2014-6278

<short description>

<[YOCTO #xxx] if there is any>

References
E.g. [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278 link to CVE] or other useful info/blog/advisory.

Signed-off-by:

For additional guidelines refer to: [http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines]

== Some security related links/useful tools ==

* [http://www.cvedetails.com CVE details]
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html CVE list, Linux kernel 2014]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]

== Security Issues Addressed in Yocto Releases ==
'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171

'''Yocto 1.7 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy17

'''Yocto 1.6 - Daisy'''
https://www.yoctoproject.org/downloads/core/daisy16

Security

2015-03-10T06:47:35Z

SonaSarmadi: /* Vendor kernels */

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

poky/recipes-connectivity/bind/bind_9.9.5.bb

SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://conf.patch \
...
file://bind9_9_5-CVE-2014-8500.patch \

We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

== Yocto Security Team ==

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

'''The team's main responsibilities among others are:'''

* Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
* Responsible for fixing CVEs in the Yocto releases & maintained branches
* Evaluation of tools for security tests
* Responsible for security related info in the Yocto documentations
* Hardening of Yocto release

'''How to Contact Yocto's security team Securely'''
---------------------------------------------
We have set up two security-related mailing lists:
* '''Public List'''
: yocto [dash] security [at] yoctoproject[dot] com
: This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches.

* '''Private List'''
: security [at] yoctoprojct [dot] org (Forwards to the following addresses)

: - '''sona [dot] sarmadi [at] enea [dot] com'''
: - '''mhalstead [at] linuxfoundation [dot] org'''
: For secure communications, please send your messages encrypted to both using the following GPG keys.
: Remember message headers are not encrypted so do not include sensitive information in the subject line.

: Download public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x773EF6EF68716A14 Sona Sarmadi] [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead]

Anyone can contribute Yocto with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility

'''What you should do if you find a security vulnerability'''
---------------------------------------------
If you find a security flaw; a crash, an information leakage or anything that can have a security impact if exploited in any Open Source packages used by Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please copy security team at Yocto as well.
If you believe this is a sensitive information, please report the vulnerability in a secure way, i.e. encrypt email and send it to the private list. This ensures that the exploit is not leaked and exploited before a
response/fix has been generated.

'''What Yocto Security Team do/does when they receive a security vulnerability'''
---------------------------------------------
The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects, analyzes the problem. If they deem that it is a real security problem in their software, the project then mail the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros then can agree on a release date when the flaw should be made public.
There’s also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy other Opens Source Security mailing lists to inform the whole world of vulnerability.

'''If an upstream project does not respond quickly'''
---------------------------------------------
If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible.
Normally big Linux vendors fix the problem if the problem affects their products.
Chances are that everyone from the enterprise distros to the commercial
Yocto vendors will get fixes done first, but it is nice to have saftey net for
issues that really are specific to oe and embedded.

== Branches maintained with security fixes ==

{| class="wikitable"
! Major version
! Current Version
! Branch name
! BitBake version
! Maintainer
|-
|1.7
|1.7
|dizzy
|1.24
|Armin Kuster <akuster808@gmail.com>
|-
|1.6
|1.6.1
|daisy
|1.22
|Saul Wold <sgw@linux.intel.com>
|-
|1.5
|1.5.3
|dora
|1.20
|Robert Yang <liezhi.yang@windriver.com>
|- style="color: slategray;"
|1.4
|1.4.3[https://lists.yoctoproject.org/pipermail/yocto/2014-July/020699.html *]
|dylan
|1.18
|Paul Eggleton <paul.eggleton@linux.intel.com>
|- style="color: slategray;"
|1.3
|1.3.2
|danny
|1.16
|Ross Burton <ross.burton@intel.com>
|- style="color: slategray;"
|}

All CVEs (security patches) should be backported to all branches above (if at all possible).
Versions in grey are no longer actively maintained, but well-tested security patches may still be accepted for them.)

See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch

== Kernel security patches ==

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Bruce Ashfield)

=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (meta-freescale@yoctoproject.org)
* meta-xilinx (meta-xilinx@lists.yoctoproject.org)
* meta-ti (meta-ti@yoctoproject.org)
* etc

== How to test ==

If there is any test case for the vulnerability by the upstream project or community
- Run the test to reproduce the problem and verify the correction.
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase
- Run the regressions test

'''Regression test'''

* Build the core image for at least two architectures (preferably one big-endian and one little-endian)
* Run ptest (for those branches/packages that there is ptest mechanism)

== Patch name convention and commit message ==
Security patches should have reference to the CVE identifier both in the patch file/s and the commit comment.

Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit comment:

bash: CVE-2014-6278

<short description>

<[YOCTO #xxx] if there is any>

References
E.g. [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278 link to CVE] or other useful info/blog/advisory.

Signed-off-by:

For additional guidelines refer to: [http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines]

== Some security related links/useful tools ==

* [http://www.cvedetails.com CVE details]
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html CVE list, Linux kernel 2014]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]

== Security Issues Addressed in Yocto Releases ==
'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171

'''Yocto 1.7 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy17

'''Yocto 1.6 - Daisy'''
https://www.yoctoproject.org/downloads/core/daisy16

Security

2015-03-10T06:46:31Z

SonaSarmadi: /* Vendor kernels */

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

poky/recipes-connectivity/bind/bind_9.9.5.bb

SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://conf.patch \
...
file://bind9_9_5-CVE-2014-8500.patch \

We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

== Yocto Security Team ==

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

'''The team's main responsibilities among others are:'''

* Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
* Responsible for fixing CVEs in the Yocto releases & maintained branches
* Evaluation of tools for security tests
* Responsible for security related info in the Yocto documentations
* Hardening of Yocto release

'''How to Contact Yocto's security team Securely'''
---------------------------------------------
We have set up two security-related mailing lists:
* '''Public List'''
: yocto [dash] security [at] yoctoproject[dot] com
: This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches.

* '''Private List'''
: security [at] yoctoprojct [dot] org (Forwards to the following addresses)

: - '''sona [dot] sarmadi [at] enea [dot] com'''
: - '''mhalstead [at] linuxfoundation [dot] org'''
: For secure communications, please send your messages encrypted to both using the following GPG keys.
: Remember message headers are not encrypted so do not include sensitive information in the subject line.

: Download public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x773EF6EF68716A14 Sona Sarmadi] [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead]

Anyone can contribute Yocto with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility

'''What you should do if you find a security vulnerability'''
---------------------------------------------
If you find a security flaw; a crash, an information leakage or anything that can have a security impact if exploited in any Open Source packages used by Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please copy security team at Yocto as well.
If you believe this is a sensitive information, please report the vulnerability in a secure way, i.e. encrypt email and send it to the private list. This ensures that the exploit is not leaked and exploited before a
response/fix has been generated.

'''What Yocto Security Team do/does when they receive a security vulnerability'''
---------------------------------------------
The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects, analyzes the problem. If they deem that it is a real security problem in their software, the project then mail the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros then can agree on a release date when the flaw should be made public.
There’s also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy other Opens Source Security mailing lists to inform the whole world of vulnerability.

'''If an upstream project does not respond quickly'''
---------------------------------------------
If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible.
Normally big Linux vendors fix the problem if the problem affects their products.
Chances are that everyone from the enterprise distros to the commercial
Yocto vendors will get fixes done first, but it is nice to have saftey net for
issues that really are specific to oe and embedded.

== Branches maintained with security fixes ==

{| class="wikitable"
! Major version
! Current Version
! Branch name
! BitBake version
! Maintainer
|-
|1.7
|1.7
|dizzy
|1.24
|Armin Kuster <akuster808@gmail.com>
|-
|1.6
|1.6.1
|daisy
|1.22
|Saul Wold <sgw@linux.intel.com>
|-
|1.5
|1.5.3
|dora
|1.20
|Robert Yang <liezhi.yang@windriver.com>
|- style="color: slategray;"
|1.4
|1.4.3[https://lists.yoctoproject.org/pipermail/yocto/2014-July/020699.html *]
|dylan
|1.18
|Paul Eggleton <paul.eggleton@linux.intel.com>
|- style="color: slategray;"
|1.3
|1.3.2
|danny
|1.16
|Ross Burton <ross.burton@intel.com>
|- style="color: slategray;"
|}

All CVEs (security patches) should be backported to all branches above (if at all possible).
Versions in grey are no longer actively maintained, but well-tested security patches may still be accepted for them.)

See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch

== Kernel security patches ==

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Bruce Ashfield)

=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (meta-freescale@yoctoproject.org)
* meta-fsl-arm (maintainer: xxx)
* meta-xilinx (meta-xilinx@lists.yoctoproject.org)
* meta-ti (meta-ti@yoctoproject.org)
* etc

== How to test ==

If there is any test case for the vulnerability by the upstream project or community
- Run the test to reproduce the problem and verify the correction.
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase
- Run the regressions test

'''Regression test'''

* Build the core image for at least two architectures (preferably one big-endian and one little-endian)
* Run ptest (for those branches/packages that there is ptest mechanism)

== Patch name convention and commit message ==
Security patches should have reference to the CVE identifier both in the patch file/s and the commit comment.

Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit comment:

bash: CVE-2014-6278

<short description>

<[YOCTO #xxx] if there is any>

References
E.g. [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278 link to CVE] or other useful info/blog/advisory.

Signed-off-by:

For additional guidelines refer to: [http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines]

== Some security related links/useful tools ==

* [http://www.cvedetails.com CVE details]
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html CVE list, Linux kernel 2014]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]

== Security Issues Addressed in Yocto Releases ==
'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171

'''Yocto 1.7 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy17

'''Yocto 1.6 - Daisy'''
https://www.yoctoproject.org/downloads/core/daisy16

Security

2015-03-10T06:42:40Z

SonaSarmadi: /* Linux-yocto */

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

poky/recipes-connectivity/bind/bind_9.9.5.bb

SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://conf.patch \
...
file://bind9_9_5-CVE-2014-8500.patch \

We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

== Yocto Security Team ==

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

'''The team's main responsibilities among others are:'''

* Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
* Responsible for fixing CVEs in the Yocto releases & maintained branches
* Evaluation of tools for security tests
* Responsible for security related info in the Yocto documentations
* Hardening of Yocto release

'''How to Contact Yocto's security team Securely'''
---------------------------------------------
We have set up two security-related mailing lists:
* '''Public List'''
: yocto [dash] security [at] yoctoproject[dot] com
: This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches.

* '''Private List'''
: security [at] yoctoprojct [dot] org (Forwards to the following addresses)

: - '''sona [dot] sarmadi [at] enea [dot] com'''
: - '''mhalstead [at] linuxfoundation [dot] org'''
: For secure communications, please send your messages encrypted to both using the following GPG keys.
: Remember message headers are not encrypted so do not include sensitive information in the subject line.

: Download public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x773EF6EF68716A14 Sona Sarmadi] [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead]

Anyone can contribute Yocto with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility

'''What you should do if you find a security vulnerability'''
---------------------------------------------
If you find a security flaw; a crash, an information leakage or anything that can have a security impact if exploited in any Open Source packages used by Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please copy security team at Yocto as well.
If you believe this is a sensitive information, please report the vulnerability in a secure way, i.e. encrypt email and send it to the private list. This ensures that the exploit is not leaked and exploited before a
response/fix has been generated.

'''What Yocto Security Team do/does when they receive a security vulnerability'''
---------------------------------------------
The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects, analyzes the problem. If they deem that it is a real security problem in their software, the project then mail the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros then can agree on a release date when the flaw should be made public.
There’s also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy other Opens Source Security mailing lists to inform the whole world of vulnerability.

'''If an upstream project does not respond quickly'''
---------------------------------------------
If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible.
Normally big Linux vendors fix the problem if the problem affects their products.
Chances are that everyone from the enterprise distros to the commercial
Yocto vendors will get fixes done first, but it is nice to have saftey net for
issues that really are specific to oe and embedded.

== Branches maintained with security fixes ==

{| class="wikitable"
! Major version
! Current Version
! Branch name
! BitBake version
! Maintainer
|-
|1.7
|1.7
|dizzy
|1.24
|Armin Kuster <akuster808@gmail.com>
|-
|1.6
|1.6.1
|daisy
|1.22
|Saul Wold <sgw@linux.intel.com>
|-
|1.5
|1.5.3
|dora
|1.20
|Robert Yang <liezhi.yang@windriver.com>
|- style="color: slategray;"
|1.4
|1.4.3[https://lists.yoctoproject.org/pipermail/yocto/2014-July/020699.html *]
|dylan
|1.18
|Paul Eggleton <paul.eggleton@linux.intel.com>
|- style="color: slategray;"
|1.3
|1.3.2
|danny
|1.16
|Ross Burton <ross.burton@intel.com>
|- style="color: slategray;"
|}

All CVEs (security patches) should be backported to all branches above (if at all possible).
Versions in grey are no longer actively maintained, but well-tested security patches may still be accepted for them.)

See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch

== Kernel security patches ==

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Bruce Ashfield)

=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (maintainer: xxx)
* meta-fsl-arm (maintainer: xxx)
* meta-xilinx (maintainer: xxx)
* meta-ti (maintainer: xxx)
* etc

== How to test ==

If there is any test case for the vulnerability by the upstream project or community
- Run the test to reproduce the problem and verify the correction.
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase
- Run the regressions test

'''Regression test'''

* Build the core image for at least two architectures (preferably one big-endian and one little-endian)
* Run ptest (for those branches/packages that there is ptest mechanism)

== Patch name convention and commit message ==
Security patches should have reference to the CVE identifier both in the patch file/s and the commit comment.

Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit comment:

bash: CVE-2014-6278

<short description>

<[YOCTO #xxx] if there is any>

References
E.g. [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278 link to CVE] or other useful info/blog/advisory.

Signed-off-by:

For additional guidelines refer to: [http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines]

== Some security related links/useful tools ==

* [http://www.cvedetails.com CVE details]
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html CVE list, Linux kernel 2014]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]

== Security Issues Addressed in Yocto Releases ==
'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171

'''Yocto 1.7 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy17

'''Yocto 1.6 - Daisy'''
https://www.yoctoproject.org/downloads/core/daisy16

Security

2015-03-10T06:40:46Z

SonaSarmadi: /* Yocto Security Team */

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

poky/recipes-connectivity/bind/bind_9.9.5.bb

SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://conf.patch \
...
file://bind9_9_5-CVE-2014-8500.patch \

We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

== Yocto Security Team ==

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

'''The team's main responsibilities among others are:'''

* Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
* Responsible for fixing CVEs in the Yocto releases & maintained branches
* Evaluation of tools for security tests
* Responsible for security related info in the Yocto documentations
* Hardening of Yocto release

'''How to Contact Yocto's security team Securely'''
---------------------------------------------
We have set up two security-related mailing lists:
* '''Public List'''
: yocto [dash] security [at] yoctoproject[dot] com
: This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches.

* '''Private List'''
: security [at] yoctoprojct [dot] org (Forwards to the following addresses)

: - '''sona [dot] sarmadi [at] enea [dot] com'''
: - '''mhalstead [at] linuxfoundation [dot] org'''
: For secure communications, please send your messages encrypted to both using the following GPG keys.
: Remember message headers are not encrypted so do not include sensitive information in the subject line.

: Download public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x773EF6EF68716A14 Sona Sarmadi] [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead]

Anyone can contribute Yocto with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility

'''What you should do if you find a security vulnerability'''
---------------------------------------------
If you find a security flaw; a crash, an information leakage or anything that can have a security impact if exploited in any Open Source packages used by Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please copy security team at Yocto as well.
If you believe this is a sensitive information, please report the vulnerability in a secure way, i.e. encrypt email and send it to the private list. This ensures that the exploit is not leaked and exploited before a
response/fix has been generated.

'''What Yocto Security Team do/does when they receive a security vulnerability'''
---------------------------------------------
The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects, analyzes the problem. If they deem that it is a real security problem in their software, the project then mail the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros then can agree on a release date when the flaw should be made public.
There’s also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy other Opens Source Security mailing lists to inform the whole world of vulnerability.

'''If an upstream project does not respond quickly'''
---------------------------------------------
If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible.
Normally big Linux vendors fix the problem if the problem affects their products.
Chances are that everyone from the enterprise distros to the commercial
Yocto vendors will get fixes done first, but it is nice to have saftey net for
issues that really are specific to oe and embedded.

== Branches maintained with security fixes ==

{| class="wikitable"
! Major version
! Current Version
! Branch name
! BitBake version
! Maintainer
|-
|1.7
|1.7
|dizzy
|1.24
|Armin Kuster <akuster808@gmail.com>
|-
|1.6
|1.6.1
|daisy
|1.22
|Saul Wold <sgw@linux.intel.com>
|-
|1.5
|1.5.3
|dora
|1.20
|Robert Yang <liezhi.yang@windriver.com>
|- style="color: slategray;"
|1.4
|1.4.3[https://lists.yoctoproject.org/pipermail/yocto/2014-July/020699.html *]
|dylan
|1.18
|Paul Eggleton <paul.eggleton@linux.intel.com>
|- style="color: slategray;"
|1.3
|1.3.2
|danny
|1.16
|Ross Burton <ross.burton@intel.com>
|- style="color: slategray;"
|}

All CVEs (security patches) should be backported to all branches above (if at all possible).
Versions in grey are no longer actively maintained, but well-tested security patches may still be accepted for them.)

See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch

== Kernel security patches ==

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Ross Burton)

=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (maintainer: xxx)
* meta-fsl-arm (maintainer: xxx)
* meta-xilinx (maintainer: xxx)
* meta-ti (maintainer: xxx)
* etc

== How to test ==

If there is any test case for the vulnerability by the upstream project or community
- Run the test to reproduce the problem and verify the correction.
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase
- Run the regressions test

'''Regression test'''

* Build the core image for at least two architectures (preferably one big-endian and one little-endian)
* Run ptest (for those branches/packages that there is ptest mechanism)

== Patch name convention and commit message ==
Security patches should have reference to the CVE identifier both in the patch file/s and the commit comment.

Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit comment:

bash: CVE-2014-6278

<short description>

<[YOCTO #xxx] if there is any>

References
E.g. [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278 link to CVE] or other useful info/blog/advisory.

Signed-off-by:

For additional guidelines refer to: [http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines]

== Some security related links/useful tools ==

* [http://www.cvedetails.com CVE details]
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html CVE list, Linux kernel 2014]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]

== Security Issues Addressed in Yocto Releases ==
'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171

'''Yocto 1.7 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy17

'''Yocto 1.6 - Daisy'''
https://www.yoctoproject.org/downloads/core/daisy16

Security

2015-03-02T11:20:22Z

SonaSarmadi: /* Yocto Security Team */

Security

2015-03-02T11:09:08Z

SonaSarmadi: /* Yocto Security Team */

Security

2015-03-02T11:07:10Z

SonaSarmadi: /* Yocto Security Team */

Security

2015-02-26T09:37:52Z

SonaSarmadi: /* Yocto Security Team */

Security

2015-02-26T09:36:00Z

SonaSarmadi: /* Yocto Security Team */

Security

2015-02-25T12:50:21Z

SonaSarmadi: /* Yocto Security Team */

Security

2015-02-25T12:49:55Z

SonaSarmadi: /* Yocto Security Team */

Security

2015-02-25T12:49:37Z

SonaSarmadi: /* Yocto Security Team */

Security

2015-02-25T12:47:08Z

SonaSarmadi: /* Yocto Security Team */

Security

2015-02-25T12:46:16Z

SonaSarmadi: /* Yocto Security Team */

Security

2015-02-25T12:45:28Z

SonaSarmadi: /* Yocto Security Team */

Security

2015-02-25T12:44:02Z

SonaSarmadi: /* Yocto Security Team */

Security

2015-02-25T12:43:27Z

SonaSarmadi: /* yocto Security Team */

Security

2015-02-25T12:43:02Z

SonaSarmadi: /* yocto Security Team */

Security

2015-02-25T12:41:29Z

SonaSarmadi: