Re: [yocto] Is there a "yocto way" to rebuild sqlite amalgamation?

2018-09-21 Thread Henrik Lindblom 
Alexander Kanavin  writes:

> These two are orthogonal. "amalgamation" is building sqlite from a
> single source file for performance and simplicity reasons, which is
> what yocto does as well, despite there being no mention of it in the
> recipe. Enabling or disabling specific sqlite features can be done
> regardless of whether amalgamation or original source code file bunch
> is in use.
>
> Alex
>

This is true for most features, but not necessarily for
SQLITE_ENABLE_UPDATE_DELETE_LIMIT. Since said feature affects the
supported SQL syntax (e.g. "DELETE FROM foo LIMIT 1" results in a parse
error without the extension) the parser needs to be configured &
generated to support this. The amalgamated version contains a
preconfigured parser, which may or may not have been configured with
SQLITE_ENABLE_UPDATE_DELETE_LIMIT. See
https://www.sqlite.org/howtocompile.html#building_the_amalgamation for
details. So the presence of the feature in the amalgamated sqlite3.c
really depends how the file was generated in the first place.

Cheers,
Henrik

> 2018-09-12 16:54 GMT+02:00 Brian Hutchinson :
>> I need to enable SQLITE_ENABLE_UPDATE_DELETE_LIMIT and while
>> researching how
>> to do that I read the "amalgamation" needs to be rebuilt.  Sqlite
>> site gives
>> instructions on how to do that but I was wondering if this is really
>> necessary in a yocto environment.  I did some searches in recipies
>> and the
>> work directory where sqlite3 was built and do not get any hits at
>> all on
>> "amalgamation".
>>
>> Any words of wisdom?  I never heard of sqlite amalgamation or had to
>> deal
>> with it before so this is a new one on me.
>>
>> Regards,
>>
>> Brian
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH v1 3/3] sqlite3: CVE-2018-8740

2018-09-21 Thread Sinan Kaya 
* CVE-2018-8740
In SQLite through 3.22.0, databases whose schema is corrupted
using a CREATE TABLE AS statement could cause a NULL pointer dereference,
related to build.c and prepare.c.

Affects sqlite3 <= 3.22.0

Upstream-Status: Backport [ 
https://www.sqlite.org/cgi/src/vdiff?from=1774f1c3baf0bc3d=d75e67654aa9620b=1]
CVE: CVE-2018-8740
Ref: https://access.redhat.com/security/cve/cve-2018-8740
Signed-off-by: Sinan Kaya 
---
 .../sqlite/files/CVE-2018-8740.patch  | 52 +++
 meta/recipes-support/sqlite/sqlite3_3.22.0.bb |  1 +
 2 files changed, 53 insertions(+)
 create mode 100644 meta/recipes-support/sqlite/files/CVE-2018-8740.patch

diff --git a/meta/recipes-support/sqlite/files/CVE-2018-8740.patch 
b/meta/recipes-support/sqlite/files/CVE-2018-8740.patch
new file mode 100644
index 00..7cec1f489c
--- /dev/null
+++ b/meta/recipes-support/sqlite/files/CVE-2018-8740.patch
@@ -0,0 +1,52 @@
+From 19aed4d2be46c4516caf2bee31f79044bbd1d57d Mon Sep 17 00:00:00 2001
+From: Sinan Kaya 
+Date: Fri, 21 Sep 2018 16:22:01 +
+Subject: [PATCH] sqlite3: CVE-2018-8740
+
+port from:
+https://www.sqlite.org/cgi/src/vdiff?from=1774f1c3baf0bc3d=d75e67654aa9620b=1
+
+CVE detail:
+https://nvd.nist.gov/vuln/detail/CVE-2018-8740
+
+Signed-off-by: Sinan Kaya 
+---
+ sqlite3.c | 8 +---
+ 1 file changed, 5 insertions(+), 3 deletions(-)
+
+diff --git a/sqlite3.c b/sqlite3.c
+index 73c69ef..6863bc6 100644
+--- a/sqlite3.c
 b/sqlite3.c
+@@ -103474,8 +103474,6 @@ SQLITE_PRIVATE void sqlite3EndTable(
+   p = pParse->pNewTable;
+   if( p==0 ) return;
+ 
+-  assert( !db->init.busy || !pSelect );
+-
+   /* If the db->init.busy is 1 it means we are reading the SQL off the
+   ** "sqlite_master" or "sqlite_temp_master" table on the disk.
+   ** So do not write to the disk again.  Extract the root page number
+@@ -103486,6 +103484,10 @@ SQLITE_PRIVATE void sqlite3EndTable(
+   ** table itself.  So mark it read-only.
+   */
+   if( db->init.busy ){
++if( pSelect ){
++ sqlite3ErrorMsg(pParse, "");
++ return;
++}
+ p->tnum = db->init.newTnum;
+ if( p->tnum==1 ) p->tabFlags |= TF_Readonly;
+   }
+@@ -117813,7 +117815,7 @@ static void corruptSchema(
+ char *z;
+ if( zObj==0 ) zObj = "?";
+ z = sqlite3MPrintf(db, "malformed database schema (%s)", zObj);
+-if( zExtra ) z = sqlite3MPrintf(db, "%z - %s", z, zExtra);
++if( zExtra && zExtra[0] ) z = sqlite3MPrintf(db, "%z - %s", z, zExtra);
+ sqlite3DbFree(db, *pData->pzErrMsg);
+ *pData->pzErrMsg = z;
+   }
+-- 
+2.19.0
+
diff --git a/meta/recipes-support/sqlite/sqlite3_3.22.0.bb 
b/meta/recipes-support/sqlite/sqlite3_3.22.0.bb
index ef88659e97..b90f89886a 100644
--- a/meta/recipes-support/sqlite/sqlite3_3.22.0.bb
+++ b/meta/recipes-support/sqlite/sqlite3_3.22.0.bb
@@ -5,6 +5,7 @@ LIC_FILES_CHKSUM = 
"file://sqlite3.h;endline=11;md5=786d3dc581eff03f4fd9e4a77ed0
 
 SRC_URI = "\
   http://www.sqlite.org/2018/sqlite-autoconf-${SQLITE_PV}.tar.gz \
+  file://CVE-2018-8740.patch \
   "
 SRC_URI[md5sum] = "96b5648d542e8afa6ab7ffb8db8ddc3d"
 SRC_URI[sha256sum] = 
"2824ab1238b706bc66127320afbdffb096361130e23291f26928a027b885c612"
-- 
2.19.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH v1 2/3] libpng: CVE-2018-13785

2018-09-21 Thread Sinan Kaya 
* CVE-2018-13785
In libpng 1.6.34, a wrong calculation of row_factor in the
png_check_chunk_length function (pngrutil.c) may trigger an
integer overflow and resultant divide-by-zero while processing
a crafted PNG file, leading to a denial of service.

(cherry picked from 8a05766cb74af05c04c53e6c9d60c13fc4d59bf2)

Affects libpng <= 1.6.34

CVE: CVE-2018-13785
Upstream-Status: Backport 
[https://github.com/glennrp/libpng/commit/8a05766cb74af05c04c53e6c9d60c13fc4d59bf2]
Ref: https://access.redhat.com/security/cve/cve-2018-13785
Signed-off-by: Sinan Kaya 
---
 .../libpng/files/CVE-2018-13785.patch | 35 +++
 .../libpng/libpng_1.6.34.bb   |  4 ++-
 2 files changed, 38 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-multimedia/libpng/files/CVE-2018-13785.patch

diff --git a/meta/recipes-multimedia/libpng/files/CVE-2018-13785.patch 
b/meta/recipes-multimedia/libpng/files/CVE-2018-13785.patch
new file mode 100644
index 00..3ffbe0813e
--- /dev/null
+++ b/meta/recipes-multimedia/libpng/files/CVE-2018-13785.patch
@@ -0,0 +1,35 @@
+From 8a05766cb74af05c04c53e6c9d60c13fc4d59bf2 Mon Sep 17 00:00:00 2001
+From: Cosmin Truta 
+Date: Sun, 17 Jun 2018 22:56:29 -0400
+Subject: [PATCH] [libpng16] Fix the calculation of row_factor in
+ png_check_chunk_length
+
+(Bug report by Thuan Pham, SourceForge issue #278)
+---
+ pngrutil.c | 9 ++---
+ 1 file changed, 6 insertions(+), 3 deletions(-)
+
+diff --git a/pngrutil.c b/pngrutil.c
+index 95571b517..5ba995abf 100644
+--- a/pngrutil.c
 b/pngrutil.c
+@@ -3167,10 +3167,13 @@ png_check_chunk_length(png_const_structrp png_ptr, 
const png_uint_32 length)
+{
+   png_alloc_size_t idat_limit = PNG_UINT_31_MAX;
+   size_t row_factor =
+- (png_ptr->width * png_ptr->channels * (png_ptr->bit_depth > 8? 2: 1)
+-  + 1 + (png_ptr->interlaced? 6: 0));
++ (size_t)png_ptr->width
++ * (size_t)png_ptr->channels
++ * (png_ptr->bit_depth > 8? 2: 1)
++ + 1
++ + (png_ptr->interlaced? 6: 0);
+   if (png_ptr->height > PNG_UINT_32_MAX/row_factor)
+- idat_limit=PNG_UINT_31_MAX;
++ idat_limit = PNG_UINT_31_MAX;
+   else
+  idat_limit = png_ptr->height * row_factor;
+   row_factor = row_factor > 32566? 32566 : row_factor;
+-- 
+2.19.0
+
diff --git a/meta/recipes-multimedia/libpng/libpng_1.6.34.bb 
b/meta/recipes-multimedia/libpng/libpng_1.6.34.bb
index e52d032289..3877d6cbf0 100644
--- a/meta/recipes-multimedia/libpng/libpng_1.6.34.bb
+++ b/meta/recipes-multimedia/libpng/libpng_1.6.34.bb
@@ -8,7 +8,9 @@ DEPENDS = "zlib"
 
 LIBV = "16"
 
-SRC_URI = 
"${SOURCEFORGE_MIRROR}/project/${BPN}/${BPN}${LIBV}/${PV}/${BP}.tar.xz"
+SRC_URI = 
"${SOURCEFORGE_MIRROR}/project/${BPN}/${BPN}${LIBV}/${PV}/${BP}.tar.xz \
+   file://CVE-2018-13785.patch \
+"
 SRC_URI[md5sum] = "c05b6ca7190a5e387b78657dbe5536b2"
 SRC_URI[sha256sum] = 
"2f1e960d92ce3b3abd03d06dfec9637dfbd22febf107a536b44f7a47c60659f6"
 
-- 
2.19.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH v1 1/3] busybox: CVE-2017-15874

2018-09-21 Thread Sinan Kaya 
* CVE-2017-15874
busybox: Integer underflow in archival/libarchive/decompress_unlzma.c

(cherry picked from 9ac42c500586fa5f10a1f6d22c3f797df11b1f6b)

Affects busybox <= 1.27.2

Upstream-Status: Backport [ 
https://git.busybox.net/busybox/commit/?id=9ac42c500586fa5f10a1f6d22c3f797df11b1f6b]
CVE: CVE-2017-15874
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-15874
Signed-off-by: Sinan Kaya 
---
 .../busybox/busybox/CVE-2017-15874.patch  | 28 +++
 meta/recipes-core/busybox/busybox_1.27.2.bb   |  1 +
 2 files changed, 29 insertions(+)
 create mode 100644 meta/recipes-core/busybox/busybox/CVE-2017-15874.patch

diff --git a/meta/recipes-core/busybox/busybox/CVE-2017-15874.patch 
b/meta/recipes-core/busybox/busybox/CVE-2017-15874.patch
new file mode 100644
index 00..dece92c160
--- /dev/null
+++ b/meta/recipes-core/busybox/busybox/CVE-2017-15874.patch
@@ -0,0 +1,28 @@
+From e75c01bb3249df16201b482b79bb24bec3b58188 Mon Sep 17 00:00:00 2001
+From: Denys Vlasenko 
+Date: Fri, 27 Oct 2017 15:37:03 +0200
+Subject: [PATCH] unlzma: fix SEGV, closes 10436
+
+Signed-off-by: Denys Vlasenko 
+---
+ archival/libarchive/decompress_unlzma.c | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/archival/libarchive/decompress_unlzma.c 
b/archival/libarchive/decompress_unlzma.c
+index 29eee2a..41e492f 100644
+--- a/archival/libarchive/decompress_unlzma.c
 b/archival/libarchive/decompress_unlzma.c
+@@ -353,6 +353,10 @@ unpack_lzma_stream(transformer_state_t *xstate)
+   pos = buffer_pos - rep0;
+   if ((int32_t)pos < 0) {
+   pos += header.dict_size;
++  /* bug 10436 has an 
example file where this triggers: */
++  if ((int32_t)pos < 0)
++  goto bad;
++
+   /* see 
unzip_bad_lzma_2.zip: */
+   if (pos >= buffer_size)
+   goto bad;
+-- 
+2.19.0
+
diff --git a/meta/recipes-core/busybox/busybox_1.27.2.bb 
b/meta/recipes-core/busybox/busybox_1.27.2.bb
index 1ce4823d47..bab29728ee 100644
--- a/meta/recipes-core/busybox/busybox_1.27.2.bb
+++ b/meta/recipes-core/busybox/busybox_1.27.2.bb
@@ -47,6 +47,7 @@ SRC_URI = 
"http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
file://busybox-CVE-2017-16544.patch \
file://busybox-fix-lzma-segfaults.patch \
file://umount-ignore-c.patch \
+   file://CVE-2017-15874.patch \
 "
 SRC_URI_append_libc-musl = " file://musl.cfg "
 
-- 
2.19.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][PATCH] libselinux: Fix build with musl libc.

2018-09-21 Thread Piotr Tworek 
From: Piotr Tworek 

Musl libc does not implement file traversal functions from fts.h.
Oe-core provides fts library which implements those. Libselinux makefile
allows us to use such additional library by specifying required linker
flags via FTS_LDLIBS variable.

Signed-off-by: Piotr Tworek 
---
 recipes-security/selinux/libselinux.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/recipes-security/selinux/libselinux.inc 
b/recipes-security/selinux/libselinux.inc
index 28c437f..33621cc 100644
--- a/recipes-security/selinux/libselinux.inc
+++ b/recipes-security/selinux/libselinux.inc
@@ -8,6 +8,7 @@ LICENSE = "PD"
 inherit lib_package pythonnative
 
 DEPENDS += "libsepol python libpcre swig-native"
+DEPENDS_append_libc-musl = " fts"
 RDEPENDS_${PN}-python += "python-core"
 
 PACKAGES += "${PN}-python"
@@ -23,6 +24,7 @@ def get_policyconfigarch(d):
 EXTRA_OEMAKE += "${@get_policyconfigarch(d)}"
 
 EXTRA_OEMAKE += "LDFLAGS='${LDFLAGS} -lpcre' 
LIBSEPOLA='${STAGING_LIBDIR}/libsepol.a'"
+EXTRA_OEMAKE_append_libc-musl = " FTS_LDLIBS=-lfts"
 
 do_compile_append() {
 oe_runmake pywrap -j1 \
-- 
2.16.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][PATCH] setools: Add missing python runtime deps.

2018-09-21 Thread Piotr Tworek 
From: Piotr Tworek 

The package needs logging, json and argparse modules to start.
Additionaly, it also needs libselinux-python in order to really work.
Without it it'll just print an error message instructing the user to
install it.

Signed-off-by: Piotr Tworek 
---
 recipes-security/setools/setools_4.1.1.bb | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/recipes-security/setools/setools_4.1.1.bb 
b/recipes-security/setools/setools_4.1.1.bb
index 5b6d47d..c5a2d34 100644
--- a/recipes-security/setools/setools_4.1.1.bb
+++ b/recipes-security/setools/setools_4.1.1.bb
@@ -23,7 +23,8 @@ LIC_FILES_CHKSUM = 
"file://${S}/COPYING;md5=83a5eb6974c11f30785e90d0eeccf40c \
 
 DEPENDS += "bison-native flex-native swig-native python libsepol"
 
-RDEPENDS_${PN} += "python-networkx python-enum34 python-decorator 
python-setuptools"
+RDEPENDS_${PN} += "python-networkx python-enum34 python-decorator 
python-setuptools \
+   python-logging python-json python-argparse 
libselinux-python"
 
 RPROVIDES_${PN} += "${PN}-console"
 
-- 
2.16.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [RFC] CVEs on sumo branch

2018-09-21 Thread Sinan Kaya 

On 9/21/2018 4:35 PM, akuster808 wrote:

I already have in my sumo-next
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=stable/sumo-next
libcroco: patch for CVE-2017-7960


libarchive: CVE-2017-14501


For the rest can you sent them to the proper mailing list
openembedded-c...@lists.openembedded.org  via git send-patch.


Actually, I took this from open-embedded master branch.

https://github.com/openembedded/openembedded-core/commit/b9b254da08c1db94ac9ded5f67d7e2e82e3b9be7

commit b9b254da08c1db94ac9ded5f67d7e2e82e3b9be7
Author: Zheng Ruoqin 
Date:   Tue Jun 26 13:44:17 2018 +0800

glibc: fix CVE-2018-11237

glibc: fix CVE-2018-11237

Signed-off-by: Zheng Ruoqin 
Signed-off-by: Richard Purdie 

What does it take to move this in the right direction?

I'll take care of the remaining 3.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [RFC] CVEs on sumo branch

2018-09-21 Thread Sinan Kaya 

On 9/21/2018 4:35 PM, akuster808 wrote:

For the rest can you sent them to the proper mailing list
openembedded-c...@lists.openembedded.org  via git send-patch.

I noticed a few of the patches for recipes need some addition information:
please review
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines

In general, we need to make sure Master is not affected before I can
take them into Sumo.


Sure, I'll work on it. I'm fairly new to working with the yocto upstream.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [RFC] CVEs on sumo branch

2018-09-21 Thread akuster808 
Sinan,


On 09/21/2018 12:43 PM, Sinan Kaya wrote:
> I'm sure this has been discussed recently but I wanted to raise this
> question
> one more time as I have seen a lot of CVEs patches getting pulled into
> the sumo
> branch recently.
>
> We started enabling the cve-check feature and are triaging the results
> of CVE
> reports. We think that the following CVEs need attention and need to
> be pulled
> into the sumo branch.
Nice to see another user of this tool.

>
> There are two approaches to solve this problem:
> 1. upgrade these packages to the respective versions:
>
> CVE-2018-13785:
> https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=3b847972b8c6135a695b4a16c836ad2dd1cbb350
> CVE-2018-8740:
> https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=a6646df0cab4bd191974fde33ed8a87b9720557e
> CVE-2017-15874:
> https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=29108755c1c5a23855ab4dda59ea728781b9d75e
> CVE-2017-14501:
> https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=381f016dccb78a8cf52ffde05459ff084b2f15fd
> CVE-2018-11237:
> https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=fb535ac046697db5923575bb23ee419fe7cfbab2
> CVE-2017-7960:
> https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=26d1f906258e1d5a933830ee0e4f051d29ee7585

Typically we do not upgrade packages in stable unless the upgrade is a
bug fix only and it does not break things and it is at the desecration
of the stable branch maintainer.

>
> 2. Apply the attached patches to sumo branch.

I already have in my sumo-next
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=stable/sumo-next
libcroco: patch for CVE-2017-7960


libarchive: CVE-2017-14501


For the rest can you sent them to the proper mailing list
openembedded-c...@lists.openembedded.org via git send-patch.

I noticed a few of the patches for recipes need some addition information:
please review
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines

In general, we need to make sure Master is not affected before I can
take them into Sumo.

Thank you for backporting fixes.

regards,
Armin
>
> We'd like to hear the community opinion.
>
> Sinan
>
>
>
>

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [RFC] CVEs on sumo branch

2018-09-21 Thread Alexander Kanavin 
2018-09-21 21:43 GMT+02:00 Sinan Kaya :
> 2. Apply the attached patches to sumo branch.
>
> We'd like to hear the community opinion.

For stable branches the yocto project tends to be on the conservative
side. Which means option 2: backport the cve fixes.

For the master branch, version upgrades are preferable, unless a
pre-release freeze is in effect.

Alex
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [RFC] CVEs on sumo branch

2018-09-21 Thread Sinan Kaya 

I'm sure this has been discussed recently but I wanted to raise this question
one more time as I have seen a lot of CVEs patches getting pulled into the sumo
branch recently.

We started enabling the cve-check feature and are triaging the results of CVE
reports. We think that the following CVEs need attention and need to be pulled
into the sumo branch.

There are two approaches to solve this problem:
1. upgrade these packages to the respective versions:

CVE-2018-13785: 
https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=3b847972b8c6135a695b4a16c836ad2dd1cbb350
CVE-2018-8740: 
https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=a6646df0cab4bd191974fde33ed8a87b9720557e
CVE-2017-15874: 
https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=29108755c1c5a23855ab4dda59ea728781b9d75e
CVE-2017-14501: 
https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=381f016dccb78a8cf52ffde05459ff084b2f15fd
CVE-2018-11237: 
https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=fb535ac046697db5923575bb23ee419fe7cfbab2
CVE-2017-7960: 
https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=26d1f906258e1d5a933830ee0e4f051d29ee7585


2. Apply the attached patches to sumo branch.

We'd like to hear the community opinion.

Sinan


From e486e61f26c9d0fd2851a2b1056071b34be65e7d Mon Sep 17 00:00:00 2001
From: Changqing Li 
Date: Tue, 28 Aug 2018 17:39:23 +0800
Subject: [PATCH 1/6] libcroco: patch for CVE-2017-7960

Signed-off-by: Changqing Li 
Signed-off-by: Richard Purdie 
---
 .../libcroco/libcroco/CVE-2017-7960.patch | 56 +++
 .../libcroco/libcroco_0.6.12.bb   |  2 +
 2 files changed, 58 insertions(+)
 create mode 100644 meta/recipes-support/libcroco/libcroco/CVE-2017-7960.patch

diff --git a/meta/recipes-support/libcroco/libcroco/CVE-2017-7960.patch 
b/meta/recipes-support/libcroco/libcroco/CVE-2017-7960.patch
new file mode 100644
index 00..f6f43c3d26
--- /dev/null
+++ b/meta/recipes-support/libcroco/libcroco/CVE-2017-7960.patch
@@ -0,0 +1,56 @@
+input: check end of input before reading a byte
+
+When reading bytes we weren't check that the index wasn't
+out of bound and this could produce an invalid read which
+could deal to a security bug.
+
+Upstream-Status: Backport[https://gitlab.gnome.org/GNOME/libcroco/
+ commit/898e3a8c8c0314d2e6b106809a8e3e93cf9d4394]
+
+CVE: CVE-2017-7960 
+
+Signed-off-by: Changqing Li 
+
+diff --git a/src/cr-input.c b/src/cr-input.c
+index 
49000b1f5f07fe057135f1b8fc69bdcf9613e300..3b63a88ee3b1c56778e58172d147d958951bf099
 100644
+--- a/src/cr-input.c
 b/src/cr-input.c
+@@ -256,7 +256,7 @@ cr_input_new_from_uri (const gchar * a_file_uri, enum 
CREncoding a_enc)
+  *we should  free buf here because it's own by CRInput.
+  *(see the last parameter of cr_input_new_from_buf().
+  */
+-buf = NULL ;
++buf = NULL;
+ }
+ 
+  cleanup:
+@@ -404,6 +404,8 @@ cr_input_get_nb_bytes_left (CRInput const * a_this)
+ enum CRStatus
+ cr_input_read_byte (CRInput * a_this, guchar * a_byte)
+ {
++gulong nb_bytes_left = 0;
++
+ g_return_val_if_fail (a_this && PRIVATE (a_this)
+   && a_byte, CR_BAD_PARAM_ERROR);
+ 
+@@ -413,6 +415,12 @@ cr_input_read_byte (CRInput * a_this, guchar * a_byte)
+ if (PRIVATE (a_this)->end_of_input == TRUE)
+ return CR_END_OF_INPUT_ERROR;
+ 
++nb_bytes_left = cr_input_get_nb_bytes_left (a_this);
++
++if (nb_bytes_left < 1) {
++return CR_END_OF_INPUT_ERROR;
++}
++
+ *a_byte = PRIVATE (a_this)->in_buf[PRIVATE (a_this)->next_byte_index];
+ 
+ if (PRIVATE (a_this)->nb_bytes -
+@@ -477,7 +485,6 @@ cr_input_read_char (CRInput * a_this, guint32 * a_char)
+ if (*a_char == '\n') {
+ PRIVATE (a_this)->end_of_line = TRUE;
+ }
+-
+ }
+ 
+ return status;
diff --git a/meta/recipes-support/libcroco/libcroco_0.6.12.bb 
b/meta/recipes-support/libcroco/libcroco_0.6.12.bb
index d86ddd6464..5b962ee738 100644
--- a/meta/recipes-support/libcroco/libcroco_0.6.12.bb
+++ b/meta/recipes-support/libcroco/libcroco_0.6.12.bb
@@ -16,5 +16,7 @@ BINCONFIG = "${bindir}/croco-0.6-config"
 
 inherit gnomebase gtk-doc binconfig-disabled
 
+SRC_URI += "file://CVE-2017-7960.patch"
+
 SRC_URI[archive.md5sum] = "bc0984fce078ba2ce29f9500c6b9ddce"
 SRC_URI[archive.sha256sum] = 
"ddc4b5546c9fb4280a5017e2707fbd4839034ed1aba5b7d4372212f34f84f860"
-- 
2.19.0

From 297a200543cafe043b870c668acd14b2e21381fd Mon Sep 17 00:00:00 2001
From: Zheng Ruoqin 
Date: Tue, 26 Jun 2018 13:44:17 +0800
Subject: [PATCH 2/6] glibc: fix CVE-2018-11237

glibc: fix CVE-2018-11237

Signed-off-by: Zheng Ruoqin 
Signed-off-by: Richard Purdie 
---
 .../glibc/glibc/CVE-2018-11237.patch  | 82 +++
 meta/recipes-core/glibc/glibc_2.27.bb |  1 +
 2 files changed, 83

Re: [yocto] remove unneeded files from update-alternatives packages

2018-09-21 Thread Alexander Kanavin 
You can probably have a .bbappend file which removes all the unneeded files in
do_install_append()

Alex

2018-09-21 19:29 GMT+02:00 Matthias Schoepfer
:
> Hi!
>
> In my case, I am using coreutils and busybox. But I only need one
> program of coreutils. Now, I have plenty binaries with .coreutils
> installed in my image, which bloats the image (every byte counts ;) ).
> Its a read-only-image, update-alternatives or package management is not
> used. Is there a better way to remove the unneeded files then manually
> removing them in a ROOTFS_POSTPROCESS_COMMAND?!
>
> Thanks and Regards,
>
> Matthias
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] remove unneeded files from update-alternatives packages

2018-09-21 Thread Matthias Schoepfer 
Hi!

In my case, I am using coreutils and busybox. But I only need one
program of coreutils. Now, I have plenty binaries with .coreutils
installed in my image, which bloats the image (every byte counts ;) ).
Its a read-only-image, update-alternatives or package management is not
used. Is there a better way to remove the unneeded files then manually
removing them in a ROOTFS_POSTPROCESS_COMMAND?!

Thanks and Regards,

    Matthias



pEpkey.asc
Description: application/pgp-keys
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-security][PATCH] samhain: update to 4.3.0

2018-09-21 Thread Armin Kuster 
Signed-off-by: Armin Kuster 
---
 .../{samhain-client_4.2.4.bb => samhain-client_4.3.0.bb}  | 0
 .../{samhain-server_4.2.4.bb => samhain-server_4.3.0.bb}  | 0
 ...amhain-standalone_4.2.4.bb => samhain-standalone_4.3.0.bb} | 0
 recipes-security/samhain/samhain.inc  | 4 ++--
 4 files changed, 2 insertions(+), 2 deletions(-)
 rename recipes-security/samhain/{samhain-client_4.2.4.bb => 
samhain-client_4.3.0.bb} (100%)
 rename recipes-security/samhain/{samhain-server_4.2.4.bb => 
samhain-server_4.3.0.bb} (100%)
 rename recipes-security/samhain/{samhain-standalone_4.2.4.bb => 
samhain-standalone_4.3.0.bb} (100%)

diff --git a/recipes-security/samhain/samhain-client_4.2.4.bb 
b/recipes-security/samhain/samhain-client_4.3.0.bb
similarity index 100%
rename from recipes-security/samhain/samhain-client_4.2.4.bb
rename to recipes-security/samhain/samhain-client_4.3.0.bb
diff --git a/recipes-security/samhain/samhain-server_4.2.4.bb 
b/recipes-security/samhain/samhain-server_4.3.0.bb
similarity index 100%
rename from recipes-security/samhain/samhain-server_4.2.4.bb
rename to recipes-security/samhain/samhain-server_4.3.0.bb
diff --git a/recipes-security/samhain/samhain-standalone_4.2.4.bb 
b/recipes-security/samhain/samhain-standalone_4.3.0.bb
similarity index 100%
rename from recipes-security/samhain/samhain-standalone_4.2.4.bb
rename to recipes-security/samhain/samhain-standalone_4.3.0.bb
diff --git a/recipes-security/samhain/samhain.inc 
b/recipes-security/samhain/samhain.inc
index e127e91..944bf0d 100644
--- a/recipes-security/samhain/samhain.inc
+++ b/recipes-security/samhain/samhain.inc
@@ -19,8 +19,8 @@ SRC_URI = 
"http://la-samhna.de/archive/samhain_signed-${PV}.tar.gz \
file://samhain.service \
"
 
-SRC_URI[md5sum] = "08863fad583acc7293ef29b4528c837e"
-SRC_URI[sha256sum] = 
"0cd779b3666264e1f370f7ec37891f680b4caa04895fab8c5aa9a52e41ec885d"
+SRC_URI[md5sum] = "a00e99375675fc6e50cca3e208f5207e"
+SRC_URI[sha256sum] = 
"8551dc3b0851889a2b979097e9c02309b40d48b4659f02efe7fe525ce8361a0d"
 
 UPSTREAM_CHECK_URI = "https://www.la-samhna.de/samhain/archive.html;
 UPSTREAM_CHECK_REGEX = "samhain_signed-(?P(\d+(\.\d+)+))\.tar"
-- 
2.17.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto SDK generated - unable to compile application

2018-09-21 Thread Bas Mevissen 

On 2018-09-21 14:34, Evan O'Loughlin wrote:


From: Bas Mevissen [ab...@basmevissen.nl]
Sent: 20 September 2018 23:21
To: Evan O'Loughlin
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto SDK generated - unable to compile 
application


On 9/20/18 3:32 PM, Evan O'Loughlin wrote:



From: Bas Mevissen [ab...@basmevissen.nl]
Sent: 20 September 2018 13:23
To: Evan O'Loughlin
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto SDK generated - unable to compile 
application


On 2018-09-20 12:28, Evan O'Loughlin wrote:


From: Bas Mevissen [ab...@basmevissen.nl]
Sent: 20 September 2018 10:50
To: Evan O'Loughlin
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto SDK generated - unable to compile
application

On 2018-09-20 11:40, Evan O'Loughlin wrote:

-Original Message-
From: Bas Mevissen [mailto:ab...@basmevissen.nl]
Sent: 20 September 2018 10:12
To: Evan O'Loughlin 
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto SDK generated - unable to compile
application

On 2018-09-20 10:08, Evan O'Loughlin wrote:

Hello,

I’m having an issue when I try to use the SDK generated by my yocto
instance.
Currently I have yocto set-up to correctly build my image – this 
all

works well.

I've built the SDK in the following ways:
   * bitbake {image} –c populate_sdk
   * bitbake meta-toolchain-qt5
   * bitbake {image-sdk} using a separate recipe with the options:
   - require {image}.bb
   - IMAGE_FEATURES += " dev-pkgs tools-sdk tools-debug
eclipse-debug debug-tweaks"
   - IMAGE_INSTALL += "kernel-devsrc"
   - inherit populate_sdk populate_sdk_qt5


When I try to use the generated SDKs I get the error below:
Simple helloworld app:
   #include 
   #include 
   #include 
   #include 

   int main (int argc, char** argv)
   {
  printf("Hello World\n");
  return 0;
   }

Compile error:
   ${CC} helloworld.c
   helloworld.c:4:19: fatal error: cstddef: No such file or 
directory

   #include 
^
   compilation terminated


Have I missed a step in generating the SDK?




No, your SDK looks fine. The solution is to just remove the line

#include 

from your c sources or use the g++ compiler (called ${CXX) in
Makefile) to compile the source.


Regards,
vitalEol



Hi Bas,

I'm using the offending line in helloworld.c to highlight the issue
I'm
seeing.

My main program is a Qt application where I see the same issue when
trying to build in QtCreator.

My issue relates to the fact that several include files are not
readily available after 'sourcing' the environment setup.

Do I need to adjust/include other recipes when building the SDK?



I might be wrong, but this looks like you are using the gcc compiler
instead of the g++ one. See the second part of my answer.

To check your environment, check in your sdk that the file cstddef
exists somewhere in /usr/include. Example from a Fedora Linux system:

$ find /usr/include -name cstddef
/usr/include/c++/8/cstddef

If I compile your example with "gcc" on that system, I get the same
error. With "g++", is is fine. It automatically find the cstddef 
header

file in the /usr/include/c++/8 directory.

Hope this helps,

(and please do not top post as that makes a mail thread unreadable)

-- Bas.



Regards,
Evan



Hi Bas,

Apologies for top-posting previously.

using ${CC}, ${CPP} or ${CXX} all show the same error relating to not
finding the required include

cstddef is available in the cross-compiler toolchain:
$ find . -name cstddef
./sysroots/armv7ahf-neon-linux-gnueabi/usr/include/c++/6.2.1/cstddef
./sysroots/armv7ahf-neon-linux-gnueabi/usr/include/boost/compatibility/cpp_c_headers/cstddef



That looks fine.


and is also available on my system:
$ find /usr/include -name cstddef
/usr/include/c++/5/cstddef
/usr/include/c++/4.7/cstddef
/usr/include/c++/4.8/cstddef


${CC} --version && ${CPP} --version && ${CXX} --version
arm-linux-gnueabihf-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There 
is

NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

arm-linux-gnueabihf-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There 
is

NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

arm-linux-gnueabihf-g++ (Linaro GCC 6.2-2016.11) 6.2.1 20161016
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There 
is

NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.



I tried with an Freescale i.MX6 SDK for Sumo and that compiled fine 
with

${CXX}.

It is a bit of guessing now. Maybe somewhat more information might 
help:


What version of Yocto are you using? What

Re: [yocto] [pseudo] Pseudo 1.8+ xattr sqlite corruption

2018-09-21 Thread Burton, Ross 
Wired: I've just sent a patch to update oe-core to use the current
HEAD of pseudo.
Tired: WARNING: glibc-locale-2.28-r0 do_package_qa: QA Issue:
glibc-locale: 
/glibc-binary-localedata-en-za.iso-8859-1/usr/lib/locale/en_ZA.ISO-8859-1/LC_PAPER
is owned by uid 1000, which is the same as the user running bitbake.
This may be due to host contamination [host-user-contaminated]

I was *really* hoping this would solve the problem.

Ross

On Thu, 20 Sep 2018 at 21:51, Seebs  wrote:
>
> Nice catch. Merged a patch that applies this also.
>
> -s
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto SDK generated - unable to compile application

2018-09-21 Thread Evan O'Loughlin 



From: Bas Mevissen [ab...@basmevissen.nl]
Sent: 20 September 2018 23:21
To: Evan O'Loughlin
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto SDK generated - unable to compile application

On 9/20/18 3:32 PM, Evan O'Loughlin wrote:
>
> 
> From: Bas Mevissen [ab...@basmevissen.nl]
> Sent: 20 September 2018 13:23
> To: Evan O'Loughlin
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Yocto SDK generated - unable to compile application
>
> On 2018-09-20 12:28, Evan O'Loughlin wrote:
>> 
>> From: Bas Mevissen [ab...@basmevissen.nl]
>> Sent: 20 September 2018 10:50
>> To: Evan O'Loughlin
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] Yocto SDK generated - unable to compile
>> application
>>
>> On 2018-09-20 11:40, Evan O'Loughlin wrote:
>>> -Original Message-
>>> From: Bas Mevissen [mailto:ab...@basmevissen.nl]
>>> Sent: 20 September 2018 10:12
>>> To: Evan O'Loughlin 
>>> Cc: yocto@yoctoproject.org
>>> Subject: Re: [yocto] Yocto SDK generated - unable to compile
>>> application
>>>
>>> On 2018-09-20 10:08, Evan O'Loughlin wrote:
 Hello,

 I’m having an issue when I try to use the SDK generated by my yocto
 instance.
 Currently I have yocto set-up to correctly build my image – this all
 works well.

 I've built the SDK in the following ways:
* bitbake {image} –c populate_sdk
* bitbake meta-toolchain-qt5
* bitbake {image-sdk} using a separate recipe with the options:
- require {image}.bb
- IMAGE_FEATURES += " dev-pkgs tools-sdk tools-debug
 eclipse-debug debug-tweaks"
- IMAGE_INSTALL += "kernel-devsrc"
- inherit populate_sdk populate_sdk_qt5


 When I try to use the generated SDKs I get the error below:
 Simple helloworld app:
#include 
#include 
#include 
#include 

int main (int argc, char** argv)
{
   printf("Hello World\n");
   return 0;
}

 Compile error:
${CC} helloworld.c
helloworld.c:4:19: fatal error: cstddef: No such file or directory
#include 
 ^
compilation terminated


 Have I missed a step in generating the SDK?


>>>
>>> No, your SDK looks fine. The solution is to just remove the line
>>>
>>> #include 
>>>
>>> from your c sources or use the g++ compiler (called ${CXX) in
>>> Makefile) to compile the source.
>>>
 Regards,
 vitalEol
>>
>>> Hi Bas,
>>>
>>> I'm using the offending line in helloworld.c to highlight the issue
>>> I'm
>>> seeing.
>>>
>>> My main program is a Qt application where I see the same issue when
>>> trying to build in QtCreator.
>>>
>>> My issue relates to the fact that several include files are not
>>> readily available after 'sourcing' the environment setup.
>>>
>>> Do I need to adjust/include other recipes when building the SDK?
>>>
>>
>> I might be wrong, but this looks like you are using the gcc compiler
>> instead of the g++ one. See the second part of my answer.
>>
>> To check your environment, check in your sdk that the file cstddef
>> exists somewhere in /usr/include. Example from a Fedora Linux system:
>>
>> $ find /usr/include -name cstddef
>> /usr/include/c++/8/cstddef
>>
>> If I compile your example with "gcc" on that system, I get the same
>> error. With "g++", is is fine. It automatically find the cstddef header
>> file in the /usr/include/c++/8 directory.
>>
>> Hope this helps,
>>
>> (and please do not top post as that makes a mail thread unreadable)
>>
>> -- Bas.
>>
>>
>>> Regards,
>>> Evan
>>>
>>
>> Hi Bas,
>>
>> Apologies for top-posting previously.
>>
>> using ${CC}, ${CPP} or ${CXX} all show the same error relating to not
>> finding the required include
>>
>> cstddef is available in the cross-compiler toolchain:
>> $ find . -name cstddef
>> ./sysroots/armv7ahf-neon-linux-gnueabi/usr/include/c++/6.2.1/cstddef
>> ./sysroots/armv7ahf-neon-linux-gnueabi/usr/include/boost/compatibility/cpp_c_headers/cstddef
>>
>
> That looks fine.
>
>> and is also available on my system:
>> $ find /usr/include -name cstddef
>> /usr/include/c++/5/cstddef
>> /usr/include/c++/4.7/cstddef
>> /usr/include/c++/4.8/cstddef
>>
>>
>> ${CC} --version && ${CPP} --version && ${CXX} --version
>> arm-linux-gnueabihf-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
>> Copyright (C) 2016 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There is
>> NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>> PURPOSE.
>>
>> arm-linux-gnueabihf-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
>> Copyright (C) 2016 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There is
>> NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>> PURPOSE.
>>
>>