Re: [OE-core] [PATCH 2/5] security_flags: pass ssp-buffer-size param to stack protector

[Joshua G Lock]

On Fri, 2016-08-19 at 10:07 -0700, Khem Raj wrote:
> > 
> > On Aug 19, 2016, at 8:34 AM, Joshua Lock 
> > wrote:
> > 
> > This tells the compiler to use a canary to protect any function
> > which
> > declares a character array of 4 or more bytes on its stack, rather
> > than the default of 8 or more bytes.
> 
> Thats fine, however, it slows down the code, strong option was a
> compromise
> otherwise we could just use fstack-protector-all

It's my understanding that the ssp-buffer-size parameter changes the
size of buffer the base, fstack-protector, protections affect and that
the performance impact is less significant than adding protections to
all functions via stack-protector-all?

FWIW, the related options in Fedora and Ubuntu:

* Ubuntu: -fstack-protector --param=ssp-buffer-size=4 (default in
hardened builds)
* Fedora: -fstack-protector-strong --param=ssp-buffer-size=4 (default
in all builds)

Regards,

Joshua

> > 
> > 
> > Signed-off-by: Joshua Lock 
> > ---
> > meta/conf/distro/include/security_flags.inc | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/meta/conf/distro/include/security_flags.inc
> > b/meta/conf/distro/include/security_flags.inc
> > index 77fade6..691cea1 100644
> > --- a/meta/conf/distro/include/security_flags.inc
> > +++ b/meta/conf/distro/include/security_flags.inc
> > @@ -12,8 +12,8 @@ lcl_maybe_fortify = "${@base_conditional('DEBUG_B
> > UILD','1','','-D_FORTIFY_SOURCE
> > # Error on use of format strings that represent possible security
> > problems
> > SECURITY_STRINGFORMAT ?= "-Wformat -Wformat-security
> > -Werror=format-security"
> > 
> > -SECURITY_CFLAGS ?= "-fstack-protector-strong -pie -fpie
> > ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
> > -SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong
> > ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
> > +SECURITY_CFLAGS ?= "-fstack-protector-strong --param ssp-buffer-
> > size=4 -pie -fpie ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
> > +SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong --param ssp-
> > buffer-size=4 ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
> > 
> > SECURITY_LDFLAGS ?= "-Wl,-z,relro,-z,now"
> > SECURITY_X_LDFLAGS ?= "-Wl,-z,relro"
> > --
> > 2.7.4
> > 
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/5] security_flags: remove invalid linker option

[Joshua G Lock]

On Fri, 2016-08-19 at 10:05 -0700, Khem Raj wrote:
> > 
> > On Aug 19, 2016, at 8:34 AM, Joshua Lock 
> > wrote:
> > 
> > -fstack-protector-* is a compiler option, not a linker option.
> 
> IIRC There are packages
> who do not use CFLAGS in linker cmdline which case this fails
> 
> what issues do you see with this option appearing in ldflags ?
> 
> This should be tested with world builds on both musl and glibc

I wasn't sure why it appeared in ldflags, none of the (admittedly only
glibc) builds I did seemed to have any related failures.

I'll drop this patch and add a comment as to the intent of including
that in ldflags.

Thanks,

Joshua

> > 
> > 
> > [YOCTO #9948]
> > 
> > Signed-off-by: Joshua Lock 
> > ---
> > meta/conf/distro/include/security_flags.inc | 9 ++---
> > 1 file changed, 2 insertions(+), 7 deletions(-)
> > 
> > diff --git a/meta/conf/distro/include/security_flags.inc
> > b/meta/conf/distro/include/security_flags.inc
> > index 20f48de..77fade6 100644
> > --- a/meta/conf/distro/include/security_flags.inc
> > +++ b/meta/conf/distro/include/security_flags.inc
> > @@ -15,8 +15,8 @@ SECURITY_STRINGFORMAT ?= "-Wformat -Wformat-
> > security -Werror=format-security"
> > SECURITY_CFLAGS ?= "-fstack-protector-strong -pie -fpie
> > ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
> > SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong
> > ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
> > 
> > -SECURITY_LDFLAGS ?= "-fstack-protector-strong -Wl,-z,relro,-z,now"
> > -SECURITY_X_LDFLAGS ?= "-fstack-protector-strong -Wl,-z,relro"
> > +SECURITY_LDFLAGS ?= "-Wl,-z,relro,-z,now"
> > +SECURITY_X_LDFLAGS ?= "-Wl,-z,relro"
> > 
> > # powerpc does not get on with pie for reasons not looked into as
> > yet
> > SECURITY_CFLAGS_powerpc = "-fstack-protector-strong
> > ${lcl_maybe_fortify}"
> > @@ -100,11 +100,6 @@ SECURITY_STRINGFORMAT_pn-oh-puzzles = ""
> > TARGET_CFLAGS_append_class-target = " ${SECURITY_CFLAGS}"
> > TARGET_LDFLAGS_append_class-target = " ${SECURITY_LDFLAGS}"
> > 
> > -SECURITY_LDFLAGS_remove_pn-gcc-runtime = "-fstack-protector-
> > strong"
> > -SECURITY_LDFLAGS_remove_pn-glibc = "-fstack-protector-strong"
> > -SECURITY_LDFLAGS_remove_pn-glibc-initial = "-fstack-protector-
> > strong"
> > -SECURITY_LDFLAGS_remove_pn-uclibc = "-fstack-protector-strong"
> > -SECURITY_LDFLAGS_remove_pn-uclibc-initial = "-fstack-protector-
> > strong"
> > SECURITY_LDFLAGS_pn-xf86-video-fbdev = "${SECURITY_X_LDFLAGS}"
> > SECURITY_LDFLAGS_pn-xf86-video-intel = "${SECURITY_X_LDFLAGS}"
> > SECURITY_LDFLAGS_pn-xf86-video-omapfb = "${SECURITY_X_LDFLAGS}"
> > --
> > 2.7.4
> > 
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 5/5] security_flags: ensure changes to SHARED_OBJECTS cause recompile

[Joshua G Lock]

On Fri, 2016-08-19 at 10:11 -0700, Khem Raj wrote:
> > 
> > On Aug 19, 2016, at 9:02 AM, Richard Purdie  > undation.org> wrote:
> > 
> > On Fri, 2016-08-19 at 16:34 +0100, Joshua Lock wrote:
> > > 
> > > Add the SHARED_OBJECTS variable to SECURITY_LDFLAGS vardeps so
> > > that
> > > changing SHARED_OBJECTS causes do_compile to re-run.
> > > 
> > > Signed-off-by: Joshua Lock 
> > > ---
> > > meta/conf/distro/include/security_flags.inc | 1 +
> > > 1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/meta/conf/distro/include/security_flags.inc
> > > b/meta/conf/distro/include/security_flags.inc
> > > index 295c733..901c841 100644
> > > --- a/meta/conf/distro/include/security_flags.inc
> > > +++ b/meta/conf/distro/include/security_flags.inc
> > > @@ -24,6 +24,7 @@ SECURITY_CFLAGS ?= "-fstack-protector-strong -
> > > -param ssp-buffer-size=4 -pie -fpi
> > > SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong --param ssp
> > > -buffer-size=4 ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
> > > 
> > > SECURITY_LDFLAGS ?= "-Wl,-z,relro,-z,now${pie_ld}"
> > > +SECURITY_LDFLAGS[vardeps] += "SHARED_OBJECTS"
> > 
> > Surely you want:
> > 
> > pid_ld[vardeps] += "SHARED_OBJECTS"
> > 
> > ?
> > 
> > Also, you mention SHARED_OBJECTS defaults to "0", where is that? I
> > am a
> > little worried the variable name is also a bit generic? Setting
> > this in
> > the following way:
> > 
> > SECURITY_SHARED_OBJECTS = "-fpie"
> > SECURITY_SHARED_OBJECTS_pn-XXX = ""
> > 
> > may be more in keeping with the way the rest of the file is written
> > and
> > avoids games with base_conditional and vardeps?
> > 
> > I am also worried about trying to maintain a large list like this,
> > the
> > idea was to reduce the number of exceptions, not build lists which
> > will
> > ever increase :(. I can't see this scaling.
> 
> I agree with you here. I am mulling over a proposal for architecture
> change in 2.3
> where we harden the toolchain by default and then dont have to keep
> the securiry
> band-aid. Opinion?

It is my intention to make a proposal in 2.3 that we provide more
hardening by default. I'm in favour.

Regards,

Joshua
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 5/5] security_flags: ensure changes to SHARED_OBJECTS cause recompile

[Joshua G Lock]

On Fri, 2016-08-19 at 17:02 +0100, Richard Purdie wrote:
> On Fri, 2016-08-19 at 16:34 +0100, Joshua Lock wrote:
> > 
> > Add the SHARED_OBJECTS variable to SECURITY_LDFLAGS vardeps so that
> > changing SHARED_OBJECTS causes do_compile to re-run.
> > 
> > Signed-off-by: Joshua Lock 
> > ---
> >  meta/conf/distro/include/security_flags.inc | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/meta/conf/distro/include/security_flags.inc
> > b/meta/conf/distro/include/security_flags.inc
> > index 295c733..901c841 100644
> > --- a/meta/conf/distro/include/security_flags.inc
> > +++ b/meta/conf/distro/include/security_flags.inc
> > @@ -24,6 +24,7 @@ SECURITY_CFLAGS ?= "-fstack-protector-strong -
> > -param ssp-buffer-size=4 -pie -fpi
> >  SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong --param ssp
> > -buffer-size=4 ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
> >  
> >  SECURITY_LDFLAGS ?= "-Wl,-z,relro,-z,now${pie_ld}"
> > +SECURITY_LDFLAGS[vardeps] += "SHARED_OBJECTS"
> 
> Surely you want:
> 
> pid_ld[vardeps] += "SHARED_OBJECTS"
> 
> ?
> 
> Also, you mention SHARED_OBJECTS defaults to "0", where is that?

At the top of the exceptions list in this patch.

>  I am a
> little worried the variable name is also a bit generic? Setting this
> in
> the following way:
> 
> SECURITY_SHARED_OBJECTS = "-fpie"
> SECURITY_SHARED_OBJECTS_pn-XXX = ""
> 
> may be more in keeping with the way the rest of the file is written
> and
> avoids games with base_conditional and vardeps?

Indeed, much cleaner.

> I am also worried about trying to maintain a large list like this,
> the
> idea was to reduce the number of exceptions, not build lists which
> will
> ever increase :(. I can't see this scaling.

Nor can I, to be honest. When I started down this path I hadn't quite
realised how large the exception list would be, however as I'd done the
work I wanted to at least get some feedback on it.
I did wonder about an inheritable class to set the variable, but it
didn't seem clean to require that class be inherited when the
security_flags aren't on by default. I should probably have tagged this
patch RFC…

Regards,

Joshua
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 20/20] oeqa.utils.readconfig: Read self-test configuration file

[Joshua G Lock]

On Mon, 2016-08-08 at 09:23 -0700, Jose Lamego wrote:
> Improve oeqa-selftest capabilities and UX by placing
> test configuration features and variables into a separate
> configuration file.
> This library reads a configuration file located at the
> oeqa/selftest/conf directory with same name as the caller
> file and the conf extension.

This patch to add the oeqa.utils.readconfig module should really be
applied before all of the changes which make use it. It's a relatively
minor niggle, but this should really be 1/20.

> 
> [Yocto 9389]
> 
> Signed-off-by: Jose Lamego 
> ---
>  meta/lib/oeqa/utils/readconfig.py | 18 ++
>  1 file changed, 18 insertions(+)
>  create mode 100644 meta/lib/oeqa/utils/readconfig.py
> 
> diff --git a/meta/lib/oeqa/utils/readconfig.py
> b/meta/lib/oeqa/utils/readconfig.py
> new file mode 100644
> index 000..1534ce7
> --- /dev/null
> +++ b/meta/lib/oeqa/utils/readconfig.py
> @@ -0,0 +1,18 @@
> +import os
> +import re
> +import configparser
> +
> +
> +def conffile(codefile):
> +# Get test configurations from configuration file
> +f = re.compile(r'(pyc?$)')
> +fn = os.path.basename(codefile)
> +configfile = os.path.join(os.path.dirname(codefile), 'conf',
> +  f.sub('conf', fn))

This seems like it would be simpler with os.path.splitext()[1] ?

> +config = configparser.SafeConfigParser()

Since Python 3.2 that's just ConfigParser()[2]. As we require Python
3.4 or newer for BitBake you can just use configparser.ConfigParser()
here.

> +read_result = config.read(configfile)
> +if read_result == []:
> +raise configparser.Error("Failed to get test configuration
> from \
> +\"%s\". Verify that file exists and format is correct."
> + % configfile)
> +return config
> -- 
> 1.8.3.1
> 

Regards,

Joshua

1. https://docs.python.org/3/library/os.path.html#os.path.splitext
2. https://docs.python.org/3/whatsnew/3.2.html
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/2] perf: enable man pages for 'help' functionality

[Joshua G Lock]

On Tue, 2016-08-02 at 17:56 +0100, Burton, Ross wrote:
> Hi,
> 
> > On 27 July 2016 at 06:02, Dengke Du  wrote:
> > > > When using 'perf help ', it can't find 'man' command
and pages for
> > perf.
> > 
> > > > The perf man pages depends on the xmlto-native and asciidoc-native, 
so we just
> > 
> > > > need to add the two packages to the DEPENDS variable and add
'man'to
> > 
> > RDEPENDS_perf-doc.
> > 
> 
> > > > Whilst I like the idea of supporting more documentation, and have
long wanted to integrate doxygen/gtk-doc/etc into Yocto for building
SDKs with API documentation, I'm not sure we should be making random
packages depend on tooling to always generate documentation.
> 
> > > > > > What do people think of a distro feature / global environment
variable for "recipe should build the documentation"?  For perf this
would mean adding asciidoc so it can build the man pages, for GLib it
would mean depending on gtk-doc so the API docs can be generated, and
so on.  But if they're not needed then they can be disabled to
improve build speeds.
> 
> 

I like the idea. I've had a similar one in mind for a while now as it
would be a nice feature to be able to provide the documentation for an
image as an output of the system.

Regards,

Joshua
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] systemd: split systemd-container

[Joshua G Lock]

On Thu, 2016-07-14 at 11:25 +0800, Chen Qi wrote:
> Split container/vm related units into a new package, systemd-
> container.
> 
> The split mainly references Fedora 24, with a few differences.
> Apart from the bash and zsh completion files, the differences include
> adding systemd-spawn@.service into the systemd-container package.
> 
> [YOCTO #9835]
> 
> Signed-off-by: Chen Qi 
> ---
>  meta/recipes-core/systemd/systemd_230.bb | 35
> +---
>  1 file changed, 32 insertions(+), 3 deletions(-)
> 
> diff --git a/meta/recipes-core/systemd/systemd_230.bb b/meta/recipes-
> core/systemd/systemd_230.bb
> index 374a197..cf8aec1 100644
> --- a/meta/recipes-core/systemd/systemd_230.bb
> +++ b/meta/recipes-core/systemd/systemd_230.bb
> @@ -291,6 +291,7 @@ PACKAGES =+ "\
>  ${PN}-pam \
>  ${PN}-zsh-completion \
>  ${PN}-xorg-xinitrc \
> +${PN}-container \
>  ${PN}-extra-utils \
>  "
>  
> @@ -348,6 +349,37 @@ RRECOMMENDS_${PN}-binfmt = "kernel-module-
> binfmt-misc"
>  
>  RRECOMMENDS_${PN}-vconsole-setup = "kbd kbd-consolefonts kbd-
> keymaps"

It would be nice to provide more information about systemd-container to
package managers with a SUMMARY_${PN}-container and DESCRIPTION_${PN}-
container

>  
> +FILES_${PN}-container = "${sysconfdir}/dbus-
> 1/system.d/org.freedesktop.import1.conf \
> + ${sysconfdir}/dbus-
> 1/system.d/org.freedesktop.machine1.conf \
> + ${base_bindir}/machinectl \
> + ${bindir}/systemd-nspawn \
> + ${exec_prefix}/lib/systemd/import-
> pubring.gpg \

any reason you didn't use ${libdir}/systemd/import-pubring.gpg or
${nonarch_libdir} if the files is always installed in /usr/lib
regardless of whether libdir is i.e. /usr/lib64

> + ${systemd_unitdir}/system/busnames.target.w
> ants/org.freedesktop.import1.busname \
> + ${systemd_unitdir}/system/busnames.target.w
> ants/org.freedesktop.machine1.busname \
> + ${systemd_unitdir}/system/local-
> fs.target.wants/var-lib-machines.mount \
> + ${systemd_unitdir}/system/machine.slice \
> + ${systemd_unitdir}/system/machines.target \
> + ${systemd_unitdir}/system/org.freedesktop.i
> mport1.busname \
> + ${systemd_unitdir}/system/org.freedesktop.m
> achine1.busname \
> + ${systemd_unitdir}/system/systemd-
> importd.service \
> + ${systemd_unitdir}/system/systemd-
> machined.service \
> + ${systemd_unitdir}/system/var-lib-
> machines.mount \

I realise these are probably copy/pasted, but you could replace all of
the ${systemd_unitdir}/system with ${systemd_system_unitdir}

Otherwise this change looks good, thanks!

Joshua

> + ${rootlibexecdir}/systemd/systemd-import \
> + ${rootlibexecdir}/systemd/systemd-importd \
> + ${rootlibexecdir}/systemd/systemd-journal-
> gatewayd \
> + ${rootlibexecdir}/systemd/systemd-journal-
> remote \
> + ${rootlibexecdir}/systemd/systemd-journal-
> upload \
> + ${rootlibexecdir}/systemd/systemd-machined
> \
> + ${rootlibexecdir}/systemd/systemd-pull
> \+ ${exec_prefix}/lib/tmpfiles.d/systemd-
> nspawn.conf \
> + ${systemd_unitdir}/system/systemd-
> nspawn@.service \
> + ${libdir}/libnss_mymachines.so.2 \
> + ${datadir}/dbus-1/system-
> services/org.freedesktop.import1.service \
> + ${datadir}/dbus-1/system-
> services/org.freedesktop.machine1.service \
> + ${datadir}/polkit-
> 1/actions/org.freedesktop.import1.policy \
> + ${datadir}/polkit-
> 1/actions/org.freedesktop.machine1.policy \
> +"
> +



>  FILES_${PN}-extra-utils = "\
>  ${base_bindir}/systemd-escape \
>  ${base_bindir}/systemd-inhibit \
> @@ -371,9 +403,6 @@ FILES_${PN}-extra-utils = "\
>  ${rootlibexecdir}/systemd/systemd-resolve-
> host \
>  ${rootlibexecdir}/systemd/systemd-ac-power \
>  ${rootlibexecdir}/systemd/systemd-activate \
> -${bindir}/systemd-nspawn \
> -${exec_prefix}/lib/tmpfiles.d/systemd-
> nspawn.conf \
> -${systemd_unitdir}/system/systemd-
> nspawn@.service \
>  ${rootlibexecdir}/systemd/systemd-bus-proxyd 
> \
>  ${systemd_unitdir}/system/systemd-bus-
> proxyd.service \
>  ${systemd_unitdir}/system/systemd-bus-
> proxyd.socket \
> -- 

Re: [OE-core] [PATCHv2 1/2] oeqa/oetest.py: Allow to export packages using symlinks

[Joshua G Lock]

On Tue, 2016-07-26 at 09:38 +, mariano.lo...@linux.intel.com wrote:
> From: Mariano Lopez 
> 
> Currently packages that contains symlinks can't be extracted
> and exported. This allows to export extracted such packages.
> 
> A nice side effect is improved readability.
> 
> [YOCTO #9932]
> 
> Signed-off-by: Mariano Lopez 
> ---
>  meta/classes/testexport.bbclass | 24 +---
>  meta/lib/oeqa/oetest.py | 17 +
>  2 files changed, 18 insertions(+), 23 deletions(-)
> 
> diff --git a/meta/classes/testexport.bbclass
> b/meta/classes/testexport.bbclass
> index 15fa470..5147020 100644
> --- a/meta/classes/testexport.bbclass
> +++ b/meta/classes/testexport.bbclass
> @@ -47,6 +47,7 @@ def exportTests(d,tc):
>  import shutil
>  import pkgutil
>  import re
> +import oe.path
>  
>  exportpath = d.getVar("TEST_EXPORT_DIR", True)
>  
> @@ -103,7 +104,7 @@ def exportTests(d,tc):
>  isfolder = True
>  target_folder = os.path.join(exportpath, "oeqa",
> "runtime", os.path.basename(foldername))
>  if not os.path.exists(target_folder):
> -shutil.copytree(foldername, target_folder)
> +oe.path.copytree(foldername, target_folder)
>  if not isfolder:
>  shutil.copy2(mod.path, os.path.join(exportpath,
> "oeqa/runtime"))
>  json_file = "%s.json" % mod.path.rsplit(".", 1)[0]
> @@ -132,27 +133,12 @@ def exportTests(d,tc):
>  create_tarball(d, "testexport.tar.gz",
> d.getVar("TEST_EXPORT_DIR", True))
>  
>  # Copy packages needed for runtime testing
> -export_pkg_dir = os.path.join(d.getVar("TEST_EXPORT_DIR", True),
> "packages")
>  test_pkg_dir = d.getVar("TEST_NEEDED_PACKAGES_DIR", True)
> -need_pkg_dir = False
> -for root, subdirs, files in os.walk(test_pkg_dir):
> -for subdir in subdirs:
> -tmp_dir = os.path.join(root.replace(test_pkg_dir,
> "").lstrip("/"), subdir)
> -new_dir = os.path.join(export_pkg_dir, tmp_dir)
> -bb.utils.mkdirhier(new_dir)
> -
> -for f in files:
> -need_pkg_dir = True
> -src_f = os.path.join(root, f)
> -dst_f = os.path.join(export_pkg_dir,
> root.replace(test_pkg_dir, "").lstrip("/"), f)
> -shutil.copy2(src_f, dst_f)
> -
> -if need_pkg_dir:
> +if os.listdir(test_pkg_dir):
> +export_pkg_dir = os.path.join(d.getVar("TEST_EXPORT_DIR",
> True), "packages")
> +oe.path.copytree(test_pkg_dir, export_pkg_dir)
>  # Create tar file for packages needed by the DUT
>  create_tarball(d, "testexport_packages_%s.tar.gz" %
> d.getVar("MACHINE", True), export_pkg_dir)
> -else:
> -# Remov packages dir from exported test
> -bb.utils.remove(export_pkg_dir, True)
>  
>  # Copy SDK
>  if d.getVar("TEST_EXPORT_SDK_ENABLED", True) == "1":
> diff --git a/meta/lib/oeqa/oetest.py b/meta/lib/oeqa/oetest.py
> index e63ca56..3bf3643 100644
> --- a/meta/lib/oeqa/oetest.py
> +++ b/meta/lib/oeqa/oetest.py
> @@ -447,6 +447,8 @@ class RuntimeTestContext(TestContext):
>  modules = self.getTestModules()
>  bbpaths = self.d.getVar("BBPATH", True).split(":")
>  
> +shutil.rmtree(self.d.getVar("TEST_EXTRACTED_DIR", True))
> +shutil.rmtree(self.d.getVar("TEST_PACKAGED_DIR", True))

Do we use the shutil module anywhere else in oetest.py? Could we drop
it completely if we use oe.path.remove() rather than shutil.rmtree()?
Perhaps you could send a follow-on patch?

>  for module in modules:
>  json_file = self._getJsonFile(module)
>  if json_file:
> @@ -458,6 +460,8 @@ class RuntimeTestContext(TestContext):
>  Extract packages that will be needed during runtime.
>  """
>  
> +import oe.path
> +
>  extracted_path = self.d.getVar("TEST_EXTRACTED_DIR", True)
>  packaged_path = self.d.getVar("TEST_PACKAGED_DIR", True)
>  
> @@ -481,13 +485,18 @@ class RuntimeTestContext(TestContext):
>  dst_dir = os.path.join(packaged_path)
>  
>  # Extract package and copy it to TEST_EXTRACTED_DIR
> -if extract and not os.path.exists(dst_dir):
> -pkg_dir = self._extract_in_tmpdir(pkg)
> -shutil.copytree(pkg_dir, dst_dir)
> +pkg_dir = self._extract_in_tmpdir(pkg)
> +if extract:
> +
> +# Same package used for more than one test,
> +# don't need to extract again.
> +if os.path.exists(dst_dir):
> +continue
> +oe.path.copytree(pkg_dir, dst_dir)
>  shutil.rmtree(pkg_dir)
>  
>  # Copy package to TEST_PACKAGED_DIR
> -elif not extract:
> +

Re: [OE-core] [PATCH 0/3] Allows to copy symlinks to DUTs with testimage

[Joshua G Lock]

On Tue, 2016-07-26 at 07:39 +, mariano.lo...@linux.intel.com wrote:
> From: Mariano Lopez 
> 
> Currently when using the install functionality in the DUT without
> package
> manager, if you copy a symlink the function will fail.
> 
> These series will change the behaviour and will allow to recreate the
> symlinks in the DUT.
> 
> [YOCTO #9932]


Would oe.path.copytree() work instead of using shutil.copytree()?
copytree() was added because shutil was quite slow for our usage.

Regards,

Joshua
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/2] pseudo: upgrade to 1.8.0

[Joshua G Lock]

On Mon, 2016-07-04 at 14:36 +0300, Alexander Kanavin wrote:
> On 07/01/2016 10:30 PM, Joshua Lock wrote:
> > * drop patches where the changes exist upstream
> > * fetch from git as no tarball is available for 1.8.0
> 
> > diff --git a/meta/recipes-devtools/pseudo/pseudo_1.8.0.bb
> > b/meta/recipes-devtools/pseudo/pseudo_1.8.0.bb
> > new file mode 100644
> > index 000..08477ff
> > --- /dev/null
> > +++ b/meta/recipes-devtools/pseudo/pseudo_1.8.0.bb
> > @@ -0,0 +1,14 @@
> > +require pseudo.inc
> > +
> > +SRCREV = "786c6d3813622d18e12d36c4aa722af6a417c8fa"
> > +PV = "1.8.0+git${SRCPV}"
> > +
> > +SRC_URI = "git://git.yoctoproject.org/pseudo \
> 
> This commit id refers to version 1.7.5, and version 1.8.0 is not
> tagged 
> at all in the git repository. Can you fix that please?

Thanks for catching this, I failed badly at merging some local changes.

I will send a v2 with the correct SRCREV. I'll also see whether I can
convince someone to tag the repo.

Regards,

Joshua
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 09/28] oeqa.buildperf: add BuildPerfTest class

[Joshua G Lock]

On Fri, 2016-06-24 at 13:37 +0300, Markus Lehtonen wrote:
> The new class will be used as an abstract base class for build
> performance tests. This implementation contains some common
> functionality used in multiple tests, "copied" from the
> build-perf-test.sh shell script.
> 
> Signed-off-by: Markus Lehtonen 
> ---
>  meta/lib/oeqa/buildperf/__init__.py |  2 +-
>  meta/lib/oeqa/buildperf/base.py | 78
> -
>  2 files changed, 78 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/lib/oeqa/buildperf/__init__.py
> b/meta/lib/oeqa/buildperf/__init__.py
> index bab122e..3bee5b9 100644
> --- a/meta/lib/oeqa/buildperf/__init__.py
> +++ b/meta/lib/oeqa/buildperf/__init__.py
> @@ -10,4 +10,4 @@
>  # more details.
>  #
>  """Build performance tests"""
> -from .base import KernelDropCaches
> +from .base import BuildPerfTest, KernelDropCaches
> diff --git a/meta/lib/oeqa/buildperf/base.py
> b/meta/lib/oeqa/buildperf/base.py
> index 3cbdfa7..3ef0384 100644
> --- a/meta/lib/oeqa/buildperf/base.py
> +++ b/meta/lib/oeqa/buildperf/base.py
> @@ -10,7 +10,16 @@
>  # more details.
>  #
>  """Build performance test base classes and functionality"""
> -from oeqa.utils.commands import runCmd
> +import logging
> +import os
> +import shutil
> +import time
> +from datetime import datetime
> +
> +from oeqa.utils.commands import runCmd, get_bb_vars
> +
> +# Get logger for this module
> +log = logging.getLogger('build-perf')
>  
>  
>  class KernelDropCaches(object):
> @@ -44,3 +53,70 @@ class KernelDropCaches(object):
>  cmd += ['tee', '/proc/sys/vm/drop_caches']
>  input_data += b'3'
>  runCmd(cmd, data=input_data)
> +
> +
> +class BuildPerfTest(object):
> +"""Base class for build performance tests"""
> +name = None
> +description = None
> +
> +def __init__(self, out_dir):
> +self.out_dir = out_dir
> +self.results = {'name':self.name,
> +'description': self.description,
> +'status': 'NOTRUN',
> +'start_time': None,
> +'elapsed_time': None,
> +'measurements': []}
> +if not os.path.exists(self.out_dir):
> +os.makedirs(self.out_dir)
> +if not self.name:
> +self.name = self.__class__.__name__
> +self.bb_vars = get_bb_vars()
> +
> +def run(self):
> +"""Run test"""
> +self.results['status'] = 'FAILED'
> +self.results['start_time'] = datetime.now()
> +self._run()
> +self.results['elapsed_time'] = (datetime.now() -
> +self.results['start_time'])
> +# Test is regarded as completed if it doesn't raise an
> exception
> +self.results['status'] = 'COMPLETED'
> +
> +def _run(self):
> +"""Actual test payload"""
> +raise NotImplementedError
> +
> +@staticmethod
> +def force_rm(path):
> +"""Equivalent of 'rm -rf'"""

we have oe.path.remove() which does similar.

> +if os.path.isfile(path) or os.path.islink(path):
> +os.unlink(path)
> +elif os.path.isdir(path):
> +shutil.rmtree(path)
> +
> +def rm_tmp(self):
> +"""Cleanup temporary/intermediate files and directories"""
> +log.debug("Removing temporary and cache files")
> +for name in ['bitbake.lock', 'conf/sanity_info',
> + self.bb_vars['TMPDIR']]:
> +self.force_rm(name)
> +
> +def rm_sstate(self):
> +"""Remove sstate directory"""
> +log.debug("Removing sstate-cache")
> +self.force_rm(self.bb_vars['SSTATE_DIR'])
> +
> +def rm_cache(self):
> +"""Drop bitbake caches"""
> +self.force_rm(self.bb_vars['PERSISTENT_DIR'])
> +
> +@staticmethod
> +def sync():
> +"""Sync and drop kernel caches"""
> +log.debug("Syncing and dropping kernel caches""")
> +KernelDropCaches.drop()
> +os.sync()
> +# Wait a bit for all the dirty blocks to be written onto
> disk
> +time.sleep(3)
> -- 
> 2.6.6
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/2] rootfs-postcommands: don't hard-code .rootfs in manifest filename

[Joshua G Lock]

On Wed, 2016-06-22 at 11:22 +0100, Joshua Lock wrote:
> The .rootfs suffix of a generated image can be overridden by setting
> IMAGE_NAME_SUFFIX, to ensure manifest filenames match the associated
> image make use of this variable in the manifest filename.

This change will break a few external layers so probably isn't worth it
for a minor cosmetic change?

Regards,

Joshua

> 
> Signed-off-by: Joshua Lock 
> ---
>  meta/classes/rootfs-postcommands.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/classes/rootfs-postcommands.bbclass
> b/meta/classes/rootfs-postcommands.bbclass
> index db8b551..c413389 100644
> --- a/meta/classes/rootfs-postcommands.bbclass
> +++ b/meta/classes/rootfs-postcommands.bbclass
> @@ -15,7 +15,7 @@ ROOTFS_POSTPROCESS_COMMAND +=
> "rootfs_update_timestamp ; "
>  ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("IMAGE_FEATURES"
> , "read-only-rootfs", "read_only_rootfs_hook; ", "",d)}'
>  
>  # Write manifest
> -IMAGE_MANIFEST = "${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.manifest"
> +IMAGE_MANIFEST =
> "${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.manifest"
>  ROOTFS_POSTUNINSTALL_COMMAND =+ "write_image_manifest ; "
>  # Set default postinst log file
>  POSTINST_LOGFILE ?= "${localstatedir}/log/postinstall.log"
> -- 
> 2.7.4
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] image: add mechanism to run QA checks on the image once it's built

[Joshua G Lock]

On Tue, 2016-06-07 at 17:59 +0100, Richard Purdie wrote:
> On Tue, 2016-06-07 at 15:50 +0100, Joshua Lock wrote:
> > Add a mechanism to run QA checks on a constructed image once it's
> > complete. All checks will be run with any one failure resulting in
> > a failed build.
> 
> How is that different to the testimage class (which tests images
> after
> they're built)?

The intended purpose of this task is to run checks on the contents of
the image before it's booted.

I implemented a similar task in meta-swupd to run various checks such
as ensuring a generated image doesn't contain dangling symlinks (a sign
of unexpected consequences from alternatives configuration).

Another check one might run is ensuring /etc and /var are empty in a
stateless distro, or checking /bin, /lib and /sbin are links in a
distro with a merged /usr.

When I have a v2 of this which addresses some of Chris' concerns I'll
try and improve the commit message, variable naming, etc to avoid
confusion.

Regards,

Joshua
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] image: add mechanism to run QA checks on the image once it's built

[Joshua G Lock]

On Tue, 2016-06-07 at 08:48 -0700, Christopher Larson wrote:
On Tue, Jun 7, 2016 at 7:50 AM, Joshua Lock 
wrote:
> Add a mechanism to run QA checks on a constructed image once it's> 

> complete. All checks will be run with any one failure resulting in> 

> a failed build.> 
> 
> 

> QA checks should be > bitbake>  functions which throw a> 

> NotImplementedError when the check QA fails, with any error> 

> messages passed to the exception.> 
> 
> 

> Specify which checks to run by adding them to IMAGE_QA_COMMANDS.> 
> 
> 

> i.e.> 
> 
> 

> IMAGE_QA_COMMANDS += " \> 

>     image_check_everything_ok \> 

> "> 
> 
> 

> python image_check_everything_ok () {> 

>     raise NotImplementedError('This check always fails')> 

> }> 
> 
> 

> This code is based heavily on the configuration upgrade code in> 

> sanity.> bbclass> .> 
> 
> 

> [YOCTO #9448]> 
> 
> 

> Signed-off-by: Joshua Lock 

> > Add a mechanism to run QA checks on a constructed image once it's
> > complete. All checks will be run with any one failure resulting in
> > a failed build.
> > 
> > QA checks should be bitbake functions which throw a
> > NotImplementedError when the check QA fails, with any error
> > messages passed to the exception.
> > 
> > Specify which checks to run by adding them to IMAGE_QA_COMMANDS.
> > 
> > i.e.
> > 
> > IMAGE_QA_COMMANDS += " \
> >     image_check_everything_ok \
> > "
> > 
> > python image_check_everything_ok () {
> >     raise NotImplementedError('This check always fails')
> > }
> > 
> > This code is based heavily on the configuration upgrade code in
> > sanity.bbclass.
> > 
> > [YOCTO #9448]
> > 
> > Signed-off-by: Joshua Lock 
> > 
> 
> 
> What's the behavior if your qa function fails with a different
> exception? What if a user writes a shell qa check function, what's
> the behavior? Also, this seems like overloading the purpose of
> NotImplementedError. IMO It'd be cleaner to either use a custom
> exception or re-use python unit testing bits / use assert rather than
> subverting this one to a different purpose.
> 
> 
> 
> 
> 
> What's the behavior if your qa function fails with a different
> exception? What if a user writes a shell qa check function, what's
> the behavior? Also, this seems like overloading the purpose of
> NotImplementedError. IMO It'd be cleaner to either use a custom
> exception or re-use python unit testing bits / use assert rather than
> subverting this one to a different purpose.
> 
> 
> 
Different exceptions to NotImplementedError result in a backtrace… 
The python exception pattern using NotImplementedError I copied from
the configuration upgrade code in sanity.bbclass, because I want to
replicate that same behaviour where the checks are able to pass a
reason back to the task which calls the check functions.
Shell functions are a good point, not least of all because I suspect
many checks could be much more concise with sh.
I'll go back to the drawing board for a more generic solution that
supports both sh and python tasks.
Thanks for the review,
Joshua
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] PRServer's problem

[Joshua G Lock]

On Thu, 2016-05-19 at 18:12 +0800, Robert Yang wrote:
> 
> On 05/19/2016 05:45 PM, Richard Purdie wrote:
> > Users are free to set their own policies, the system was designed
> > to do
> > that. If WindRiver wants to have a much more permissive policy, I'm
> > more than happy for them to do so.
> Thanks, frankly speaking, not only WindRiver wants this. After cloud
> computing and virtualization gets hot, more and more users want to
> customize their own images (for saving disk space, memory and
> security
> reason), oe/yocto is very good at customizing images, so more and
> more people try to use it to build their own distros, where live
> upgrades becomes very important.
> 

The desire for this is well understood, which is why work began on the
packagefeed-stability class. 

Paul's initial effort is solid and works for simple cases, I had a
brief look at it and tried to identify some of the issues and wrote
some minor patches (for things like versioned depends and copying all
packages for a recipe as soon as a difference is found) but
unfortunately I haven't had time to finish the work.

The main piece we're missing is to define tests (in the test suite) to
validate the class works as expected with each of the package backends
and through those tests identify areas where it doesn't work (and of
course fix them).

Regards,

Joshua

https://bugzilla.yoctoproject.org/show_bug.cgi?id=8318


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] PRServer's problem

[Joshua G Lock]

Hi Robert,

On Wed, 2016-05-18 at 14:09 +0800, Robert Yang wrote:
> The PRServer bumps PR according to do_package's task hash, that
> causes it bumps *all* packages' PR when recipes like pseudo-native
> and rpm-native is changed. It is a very bad user experience when we
> run "smart/opkg upgrade" on running target, for example, when we
> apply
> a CVE patch to pseudo-native or rpm-native, or do some slight changes
> in their do_compile, "smart/opkg upgrade" will download/install *all*
> the packages since all of the packages' PR are bumped.

Paul began working to address the package feed churn issue some time
back using the tool build-compare from the openSUSE project.

You can find links to various trees and a summary of the progress so
far in this bugzilla entry:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=8318

It still needs some more work; most notably I'd like to see some tests
that validates the functionality.

Regards,

Joshua
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] package_manager.py: Add extract() method for RPM package manager

[Joshua G Lock]

On Wed, 2016-05-11 at 12:31 +, mariano.lo...@linux.intel.com wrote:
> From: Mariano Lopez 
> 
> This new method extract the content of RPM file to a tmpdir,
> without actually installing the package.
> 
> [YOCTO #9569]
> 
> Signed-off-by: Mariano Lopez 
> ---
>  meta/lib/oe/package_manager.py | 80
> ++
>  1 file changed, 80 insertions(+)
> 
> diff --git a/meta/lib/oe/package_manager.py
> b/meta/lib/oe/package_manager.py
> index 0830da9..d95564a 100644
> --- a/meta/lib/oe/package_manager.py
> +++ b/meta/lib/oe/package_manager.py
> @@ -1404,6 +1404,86 @@ class RpmPM(PackageManager):
>  for f in rpm_db_locks:
>  bb.utils.remove(f, True)
>  
> +"""
> +Returns a dictionary with the package info.
> +"""
> +def package_info(self, pkg):
> +cmd = "%s %s info --urls %s" % (self.smart_cmd,
> self.smart_opt, pkg)
> +try:
> +output = subprocess.check_output(cmd,
> stderr=subprocess.STDOUT, shell=True)
> +except subprocess.CalledProcessError as e:
> +bb.fatal("Unable to list available packages. Command
> '%s' "
> + "returned %d:\n%s" % (cmd, e.returncode,
> e.output))
> +
> +#Parse output
> +for line in output.splitlines():
> +line = line.rstrip()
> +if line.startswith("Name:"):
> +pkg = line.split(": ")[1]
> +elif line.startswith("Version:"):
> +tmp_str = line.split(": ")[1]
> +ver, arch = tmp_str.split("@")
> +break

Could pkg, ver and arch be potentially undefined here?

> +
> +# Get filename
> +index = re.search("^URLs", output, re.MULTILINE)
> +tmp_str = output[index.end():]
> +for line in tmp_str.splitlines():
> +if "/" in line:
> +line = line.lstrip()
> +filename = line.split(" ")[0]
> +break
> +
> +# To have the same data type than other package_info methods
> +pkg_dict = {}
> +pkg_dict[pkg] = {"arch":arch, "ver":ver,
> "filename":filename}
> +
> +return pkg_dict
> +
> +"""
> +Returns the path to a tmpdir where resides the contents of a
> package.
> +
> +Deleting the tmpdir is responsability of the caller.
> +
> +"""
> +def extract(self, pkg):
> +pkg_info = self.package_info(pkg)
> +if not pkg_info:
> +bb.fatal("Unable to get information for package '%s'
> while "
> + "trying to extract the package."  % pkg)
> +
> +pkg_arch = pkg_info[pkg]["arch"]
> +pkg_filename = pkg_info[pkg]["filename"]
> +pkg_path = os.path.join(self.deploy_dir, pkg_arch,
> pkg_filename)
> +
> +cpio_cmd = bb.utils.which(os.getenv("PATH"), "cpio")
> +rpm2cpio_cmd = bb.utils.which(os.getenv("PATH"), "rpm2cpio")
> +
> +if not os.path.isfile(pkg_path):
> +bb.fatal("Unable to extract package for '%s'."
> + "File %s doesn't exists" % (pkg, pkg_path))
> +
> +tmp_dir = tempfile.mkdtemp()
> +current_dir = os.getcwd()
> +os.chdir(tmp_dir)
> +
> +try:
> +cmd = "%s %s | %s -idmv" % (rpm2cpio_cmd, pkg_path,
> cpio_cmd)
> +output = subprocess.check_output(cmd,
> stderr=subprocess.STDOUT, shell=True)
> +except subprocess.CalledProcessError as e:
> +bb.utils.remove(tmp_dir, recurse=True)
> +bb.fatal("Unable to extract %s package. Command '%s' "
> + "returned %d:\n%s" % (pkg_path, cmd,
> e.returncode, e.output))
> +except OSError as e:
> +bb.utils.remove(tmp_dir, recurse=True)
> +bb.fatal("Unable to extract %s package. Command '%s' "
> + "returned %d:\n%s at %s" % (pkg_path, cmd,
> e.errno, e.strerror, e.filename))
> +
> +bb.note("Extracted %s to %s" % (pkg_path, tmp_dir))
> +os.chdir(current_dir)
> +
> +return tmp_dir
> +
>  
>  class OpkgDpkgPM(PackageManager):
>  """
> -- 
> 2.6.6
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/3] package_manager.py: Move opkg_query() outside of Indexer class

[Joshua G Lock]

On Wed, 2016-05-11 at 12:31 +, mariano.lo...@linux.intel.com wrote:
> From: Mariano Lopez 
> 
> When using the opkg and apt-get package managers the function
> opkg_query() can be useful when query for package information.
> 
> This change moves the function outside the Indexer class so
> the Indexer, OpkgPM, DpkgPM can benefit from it.
> 
> [YOCTO #9569]
> 
> Signed-off-by: Mariano Lopez 
> ---
>  meta/lib/oe/package_manager.py | 104 ---
> --
>  1 file changed, 51 insertions(+), 53 deletions(-)
> 
> diff --git a/meta/lib/oe/package_manager.py
> b/meta/lib/oe/package_manager.py
> index b4b359a..427518d 100644
> --- a/meta/lib/oe/package_manager.py
> +++ b/meta/lib/oe/package_manager.py
> @@ -27,6 +27,55 @@ def create_index(arg):
>  
>  return None
>  
> +"""
> +This method parse the output from the package managerand return
> +a dictionary with the information of the packages. This is used
> +when the packages are in deb or ipk format.
> +"""
> +def opkg_query(cmd_output):
> +verregex = re.compile(' \([=<>]* [^ )]*\)')
> +output = dict()
> +filename = ""
> +dep = []
> +pkg = ""

Here we assign a default value for dep, pkg and filename but not arch
and ver. 

I feel it's safest we assign defaults for all of the variables that are
otherwise only created if a matching line is found, otherwise we might
run into unexpected UnboundLocalError's which cause nasty crashes.

> +for line in cmd_output.splitlines():
> +line = line.rstrip()
> +if ':' in line:
> +if line.startswith("Package: "):
> +pkg = line.split(": ")[1]
> +elif line.startswith("Architecture: "):
> +arch = line.split(": ")[1]
> +elif line.startswith("Version: "):
> +ver = line.split(": ")[1]
> +elif line.startswith("File: "):
> +filename = line.split(": ")[1]
> +elif line.startswith("Depends: "):
> +depends = verregex.sub('', line.split(": ")[1])
> +for depend in depends.split(", "):
> +dep.append(depend)
> +elif line.startswith("Recommends: "):
> +recommends = verregex.sub('', line.split(": ")[1])
> +for recommend in recommends.split(", "):
> +dep.append("%s [REC]" % recommend)
> +else:
> +# IPK doesn't include the filename
> +if not filename:
> +filename = "%s_%s_%s.ipk" % (pkg, ver, arch)
> +if pkg:
> +output[pkg] = {"arch":arch, "ver":ver,
> +"filename":filename, "deps": dep }
> +pkg = ""
> +filename = ""
> +dep = []
> +
> +if pkg:
> +if not filename:
> +filename = "%s_%s_%s.ipk" % (pkg, ver, arch)
> +output[pkg] = {"arch":arch, "ver":ver,
> +"filename":filename, "deps": dep }
> +
> +return output
> +
>  
>  class Indexer(object):
>  __metaclass__ = ABCMeta
> @@ -293,57 +342,6 @@ class PkgsList(object):
>  pass
>  
>  
> -"""
> -This method parse the output from the package manager
> -and return a dictionary with the information of the
> -installed packages. This is used whne the packages are
> -in deb or ipk format
> -"""
> -def opkg_query(self, cmd_output):
> -verregex = re.compile(' \([=<>]* [^ )]*\)')
> -output = dict()
> -filename = ""
> -dep = []
> -pkg = ""
> -for line in cmd_output.splitlines():
> -line = line.rstrip()
> -if ':' in line:
> -if line.startswith("Package: "):
> -pkg = line.split(": ")[1]
> -elif line.startswith("Architecture: "):
> -arch = line.split(": ")[1]
> -elif line.startswith("Version: "):
> -ver = line.split(": ")[1]
> -elif line.startswith("File: "):
> -filename = line.split(": ")[1]
> -elif line.startswith("Depends: "):
> -depends = verregex.sub('', line.split(": ")[1])
> -for depend in depends.split(", "):
> -dep.append(depend)
> -elif line.startswith("Recommends: "):
> -recommends = verregex.sub('', line.split(":
> ")[1])
> -for recommend in recommends.split(", "):
> -dep.append("%s [REC]" % recommend)
> -else:
> -# IPK doesn't include the filename
> -if not filename:
> -filename = "%s_%s_%s.ipk" % (pkg, ver, arch)
> -if pkg:
> -output[pkg] = {"arch":arch, "ver":ver,
> -"filename":filename, "deps": dep }
> - 

Re: [OE-core] [PATCH 2/3] package_manager.py: Add extract() method for opkg and dpkg

[Joshua G Lock]

On Wed, 2016-05-11 at 12:31 +, mariano.lo...@linux.intel.com wrote:
> From: Mariano Lopez 
> 
> Sometimes it is needed to have the content of a package outside
> the recipe context.  This new method extract the content of an
> IPK/DEB file to a tmpdir, without actually installing the package.
> 
> A new OpkgDpkgPM class was added to share the code for opkg and dpkg.
> 
> There were need some changes to opkg_query() in order to use it
> with apt-cache output.
> 
> [YOCTO #9569]
> 
> Signed-off-by: Mariano Lopez 
> ---
>  meta/lib/oe/package_manager.py | 134
> +++--
>  1 file changed, 129 insertions(+), 5 deletions(-)
> 
> diff --git a/meta/lib/oe/package_manager.py
> b/meta/lib/oe/package_manager.py
> index 427518d..0830da9 100644
> --- a/meta/lib/oe/package_manager.py
> +++ b/meta/lib/oe/package_manager.py
> @@ -38,6 +38,7 @@ def opkg_query(cmd_output):
>  filename = ""
>  dep = []
>  pkg = ""
> +pkgarch = ""

Hard to tell from the context here but it looks like arch and ver don't
have default values? Potential UnboundLocalError?

>  for line in cmd_output.splitlines():
>  line = line.rstrip()
>  if ':' in line:
> @@ -47,8 +48,10 @@ def opkg_query(cmd_output):
>  arch = line.split(": ")[1]
>  elif line.startswith("Version: "):
>  ver = line.split(": ")[1]
> -elif line.startswith("File: "):
> +elif line.startswith("File: ") or
> line.startswith("Filename:"):
>  filename = line.split(": ")[1]
> +if "/" in filename:
> +filename = os.path.basename(filename)
>  elif line.startswith("Depends: "):
>  depends = verregex.sub('', line.split(": ")[1])
>  for depend in depends.split(", "):
> @@ -57,15 +60,20 @@ def opkg_query(cmd_output):
>  recommends = verregex.sub('', line.split(": ")[1])
>  for recommend in recommends.split(", "):
>  dep.append("%s [REC]" % recommend)
> -else:
> +elif line.startswith("PackageArch: "):
> +pkgarch = line.split(": ")[1]
> +
> +# When there is a blank line save the package information
> +elif not line:
>  # IPK doesn't include the filename
>  if not filename:
>  filename = "%s_%s_%s.ipk" % (pkg, ver, arch)
>  if pkg:
>  output[pkg] = {"arch":arch, "ver":ver,
> -"filename":filename, "deps": dep }
> +"filename":filename, "deps": dep,
> "pkgarch":pkgarch }
>  pkg = ""
>  filename = ""
> +pkgarch = ""
>  dep = []
>  
>  if pkg:
> @@ -1397,7 +1405,70 @@ class RpmPM(PackageManager):
>  bb.utils.remove(f, True)
>  
>  
> -class OpkgPM(PackageManager):
> +class OpkgDpkgPM(PackageManager):
> +"""
> +This is an abstract class. Do not instantiate this directly.
> +"""
> +def __init__(self, d):
> +super(OpkgDpkgPM, self).__init__(d)
> +
> +"""
> +Returns a dictionary with the package info.
> +
> +This method extracts the common parts for Opkg and Dpkg
> +"""
> +def package_info(self, pkg, cmd):
> +
> +try:
> +output = subprocess.check_output(cmd,
> stderr=subprocess.STDOUT, shell=True)
> +except subprocess.CalledProcessError as e:
> +bb.fatal("Unable to list available packages. Command
> '%s' "
> + "returned %d:\n%s" % (cmd, e.returncode,
> e.output))
> +return opkg_query(output)
> +
> +"""
> +Returns the path to a tmpdir where resides the contents of a
> package.
> +
> +Deleting the tmpdir is responsability of the caller.
> +
> +This method extracts the common parts for Opkg and Dpkg
> +"""
> +def extract(self, pkg, pkg_path):
> +
> +ar_cmd = bb.utils.which(os.getenv("PATH"), "ar")
> +tar_cmd = bb.utils.which(os.getenv("PATH"), "tar")
> +
> +if not os.path.isfile(pkg_path):
> +bb.fatal("Unable to extract package for '%s'."
> + "File %s doesn't exists" % (pkg, pkg_path))
> +
> +tmp_dir = tempfile.mkdtemp()
> +current_dir = os.getcwd()
> +os.chdir(tmp_dir)
> +
> +try:
> +cmd = "%s x %s" % (ar_cmd, pkg_path)
> +output = subprocess.check_output(cmd,
> stderr=subprocess.STDOUT, shell=True)
> +cmd = "%s xf data.tar.*" % tar_cmd
> +output = subprocess.check_output(cmd,
> stderr=subprocess.STDOUT, shell=True)
> +except subprocess.CalledProcessError as e:
> +bb.utils.remove(tmp_dir, recurse=True)
> +bb.fatal("Unable to extract %s package. Command '%s' "
> + "returned %d:\n%s" % (pkg_path, cmd,
> e.returncode, 

Re: [OE-core] [master][krogoth][PATCH 1/2] qemu: Security fix CVE-2016-2857

[Joshua G Lock]

On Mon, 2016-05-09 at 14:27 -0700, akuster808 wrote:
> On 5/6/16 8:51 AM, Alexander Kanavin wrote:
> > 
> > On 05/06/2016 06:47 PM, akuster808 wrote:
> > 
> > > 
> > > I can not reproduce this issue. I have used two different build
> > > systems.
> > > I have another I will try.
> > > 
> > > so the testcase be?
> > > 
> > > 1) bitbake core-image-sato
> > > 2) runqemu qemux86
> > 3) verify that you have a bunch of .gir and .typelib files on that
> > image (or in target sysroot)
> yeah. they are there. wonder how to reproduce this issue?? host os
> release??

I discovered this issue on an Ubuntu 14.04.4 host (gcc 4.8.4) where
neither qemu-native nor gobject-introspection were available in the
sstate-cache. I can revert the qemu upgrade and attempt to reproduce
again if it would help?

Joshua

> 
> - armin
> > 
> > 
> > 
> > Alex
> > 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [Fido][PATCH 00/21] Consolidated pull request

[Joshua G Lock]

On Fri, 2016-05-06 at 16:46 +0200, Martin Jansa wrote:
> On Fri, May 06, 2016 at 03:34:11PM +0100, Joshua Lock wrote:

> > Ross Burton (5):
> >   Revert "libsdl: depends on libglu when x11"
> Why do you want to backport the change and also its revert?

Good catch, removed in the repos on *-contrib.

Thanks,

Joshua
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [master][krogoth][PATCH 1/2] qemu: Security fix CVE-2016-2857

[Joshua G Lock]

On Wed, 2016-05-04 at 07:16 -0700, akuster wrote:
> 
> On 05/04/2016 02:52 AM, Joshua G Lock wrote:
> > 
> > Hi Armin,
> > 
> > On Thu, 2016-04-28 at 11:23 -0700, Armin Kuster wrote:
> > > 
> > > From: Armin Kuster <akus...@mvista.com>
> > > 
> > I've been seeing:
> > 
> > "qemu: uncaught target signal 11 (Segmentation fault) - core
> > dumped"
> > 
> > when trying to build gobject-introspection for qemux86 recently and
> > narrowed it down to this change, if I revert this patch the use of
> > qemu-native by gobject-introspection no longer causes a
> > segmentation
> > fault.
> well that is not good. To be clear, this is a build issue not an
> execution issue? I would like to better understand what went wrong to
> tighten up my processes.

It's an execution issue for qemu-native, the segmentation error occurs
when trying to build gobject-introspection (which calls qemu-native).

I didn't try calling qemu-native any other way (runqemu, etc) to see
whether it was something specific to the way gobject-introspection
calls qemu.

> > 
> > 
> > Are we missing some related patches for this CVE fix? 
> The only commit identified for is the on this patch came from.
> 
> I haven't dug
> > 
> > into the details, but noticed that Fedora's CVE-2016-2857
> > diffstat[1]
> > is much larger than ours[2].
> The Fedora change includes several other CVE fixes
> +# CVE-2016-2538: Integer overflow in usb module (bz #1305815)
> +Patch0103: 0103-usb-check-RNDIS-message-length.patch
> +Patch0104: 0104-usb-check-RNDIS-buffer-offsets-length.patch
> +# CVE-2016-2841: ne2000: infinite loop (bz #1304047)
> +Patch0105: 0105-net-ne2000-check-ring-buffer-control-registers.patch
> +# CVE-2016-2857: net: out of bounds read (bz #1309564)
> +Patch0106: 0106-net-check-packet-payload-length.patch
> +# CVE-2016-2392: usb: null pointer dereference (bz #1307115)
> +Patch0107: 0107-usb-check-USB-configuration-descriptor-object.patch
> +# Fix external snapshot any more after active committing (bz
> #1300209)
> +Patch0108: 0108-block-set-device_list.tqe_prev-to-NULL-on-BDS-
> remova.patch
> 
> which we seem to be missing some as well.

Several (possibly all) of those are in the 2.5.1 upgrade I proposed. 

Regards,

Joshua
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [master][krogoth][PATCH 1/2] qemu: Security fix CVE-2016-2857

[Joshua G Lock]

On Wed, 2016-05-04 at 10:52 +0100, Joshua G Lock wrote:
> Hi Armin,
> 
> On Thu, 2016-04-28 at 11:23 -0700, Armin Kuster wrote:
> > 
> > From: Armin Kuster <akus...@mvista.com>
> > 
> I've been seeing:
> 
> "qemu: uncaught target signal 11 (Segmentation fault) - core dumped"
> 
> when trying to build gobject-introspection for qemux86 recently and
> narrowed it down to this change, if I revert this patch the use of
> qemu-native by gobject-introspection no longer causes a segmentation
> fault.
> 
> Are we missing some related patches for this CVE fix? I haven't dug
> into the details, but noticed that Fedora's CVE-2016-2857 diffstat[1]
> is much larger than ours[2].

If I apply the 5 patches from Fedora's CVE-2016-2857 fix (with our
patch reverted) qemu-native's use during a gobject-introspection build
no longer causes segmentation faults.

I've sent a patch proposing an upgrade to 2.5.1 for krogoth and master,
which includes the 5 patch series mentioned above and several other
fixes.

Regards,

Joshua

> 1. http://pkgs.fedoraproject.org/cgit/rpms/qemu.git/commit/?id=54cb13
> 01
> c61f0be7b96e343902bb09be081b34fe
> 2. http://git.openembedded.org/openembedded-core/commit/?id=d1b972a55
> c5
> 9a3f3336b3ebd309532dc204ea97b
> 
> > 
> > ---
> >  .../recipes-devtools/qemu/qemu/CVE-2016-2857.patch | 51
> > ++
> >  meta/recipes-devtools/qemu/qemu_2.5.0.bb   |  1 +
> >  2 files changed, 52 insertions(+)
> >  create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2016-
> > 2857.patch
> > 
> > diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2016-2857.patch
> > b/meta/recipes-devtools/qemu/qemu/CVE-2016-2857.patch
> > new file mode 100644
> > index 000..73cfa2a
> > --- /dev/null
> > +++ b/meta/recipes-devtools/qemu/qemu/CVE-2016-2857.patch
> > @@ -0,0 +1,51 @@
> > +From 362786f14a753d8a5256ef97d7c10ed576d6572b Mon Sep 17 00:00:00
> > 2001
> > +From: Prasad J Pandit <p...@fedoraproject.org>
> > +Date: Wed, 2 Mar 2016 17:29:58 +0530
> > +Subject: [PATCH] net: check packet payload length
> > +
> > +While computing IP checksum, 'net_checksum_calculate' reads
> > +payload length from the packet. It could exceed the given 'data'
> > +buffer size. Add a check to avoid it.
> > +
> > +Reported-by: Liu Ling <liuling...@360.cn>
> > +Signed-off-by: Prasad J Pandit <p...@fedoraproject.org>
> > +Signed-off-by: Jason Wang <jasow...@redhat.com>
> > +
> > +Upstream-Status: Backport
> > +CVE: CVE-2016-2857
> > +
> > +http://git.qemu.org/?p=qemu.git;a=commit;h=362786f14a753d8a5256ef9
> > 7d
> > 7c10ed576d6572b
> > +Signed-off-by: Armin Kuster <akus...@mvista.com>
> > +
> > +---
> > + net/checksum.c | 10 --
> > + 1 file changed, 8 insertions(+), 2 deletions(-)
> > +
> > +Index: qemu-2.5.0/net/checksum.c
> > +==
> > =
> > +--- qemu-2.5.0.orig/net/checksum.c
> >  qemu-2.5.0/net/checksum.c
> > +@@ -59,6 +59,11 @@ void net_checksum_calculate(uint8_t *dat
> > + int hlen, plen, proto, csum_offset;
> > + uint16_t csum;
> > + 
> > ++/* Ensure data has complete L2 & L3 headers. */
> > ++if (length < 14 + 20) {
> > ++return;
> > ++}
> > ++
> > + if ((data[14] & 0xf0) != 0x40)
> > +   return; /* not IPv4 */
> > + hlen  = (data[14] & 0x0f) * 4;
> > +@@ -76,8 +81,9 @@ void net_checksum_calculate(uint8_t *dat
> > +   return;
> > + }
> > + 
> > +-if (plen < csum_offset+2)
> > +-  return;
> > ++if (plen < csum_offset + 2 || 14 + hlen + plen > length) {
> > ++return;
> > ++}
> > + 
> > + data[14+hlen+csum_offset]   = 0;
> > + data[14+hlen+csum_offset+1] = 0;
> > diff --git a/meta/recipes-devtools/qemu/qemu_2.5.0.bb
> > b/meta/recipes-
> > devtools/qemu/qemu_2.5.0.bb
> > index e9d9a8d..7622386 100644
> > --- a/meta/recipes-devtools/qemu/qemu_2.5.0.bb
> > +++ b/meta/recipes-devtools/qemu/qemu_2.5.0.bb
> > @@ -11,6 +11,7 @@ SRC_URI += "file://configure-fix-Darwin-target-de
> > te
> > ction.patch \
> >  file://CVE-2016-2197.patch \
> >  file://CVE-2016-2198.patch \
> >  file://pathlimit.patch \
> > +file://CVE-2016-2857.patch \
> > "
> >  SRC_URI_prepend = "http://wiki.qemu-project.org/download/${BP}.tar
> > .b
> > z2"
> >  SRC_URI[md5sum] = "f469f2330bbe76e3e39db10e9ac4f8db"
> > -- 
> > 2.3.5
> > 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [master][krogoth][PATCH 1/2] qemu: Security fix CVE-2016-2857

[Joshua G Lock]

Hi Armin,

On Thu, 2016-04-28 at 11:23 -0700, Armin Kuster wrote:
> From: Armin Kuster 
> 

I've been seeing:

"qemu: uncaught target signal 11 (Segmentation fault) - core dumped"

when trying to build gobject-introspection for qemux86 recently and
narrowed it down to this change, if I revert this patch the use of
qemu-native by gobject-introspection no longer causes a segmentation
fault.

Are we missing some related patches for this CVE fix? I haven't dug
into the details, but noticed that Fedora's CVE-2016-2857 diffstat[1]
is much larger than ours[2].

Regards,

Joshua

1. http://pkgs.fedoraproject.org/cgit/rpms/qemu.git/commit/?id=54cb1301
c61f0be7b96e343902bb09be081b34fe
2. http://git.openembedded.org/openembedded-core/commit/?id=d1b972a55c5
9a3f3336b3ebd309532dc204ea97b

> ---
>  .../recipes-devtools/qemu/qemu/CVE-2016-2857.patch | 51
> ++
>  meta/recipes-devtools/qemu/qemu_2.5.0.bb   |  1 +
>  2 files changed, 52 insertions(+)
>  create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2016-
> 2857.patch
> 
> diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2016-2857.patch
> b/meta/recipes-devtools/qemu/qemu/CVE-2016-2857.patch
> new file mode 100644
> index 000..73cfa2a
> --- /dev/null
> +++ b/meta/recipes-devtools/qemu/qemu/CVE-2016-2857.patch
> @@ -0,0 +1,51 @@
> +From 362786f14a753d8a5256ef97d7c10ed576d6572b Mon Sep 17 00:00:00
> 2001
> +From: Prasad J Pandit 
> +Date: Wed, 2 Mar 2016 17:29:58 +0530
> +Subject: [PATCH] net: check packet payload length
> +
> +While computing IP checksum, 'net_checksum_calculate' reads
> +payload length from the packet. It could exceed the given 'data'
> +buffer size. Add a check to avoid it.
> +
> +Reported-by: Liu Ling 
> +Signed-off-by: Prasad J Pandit 
> +Signed-off-by: Jason Wang 
> +
> +Upstream-Status: Backport
> +CVE: CVE-2016-2857
> +
> +http://git.qemu.org/?p=qemu.git;a=commit;h=362786f14a753d8a5256ef97d
> 7c10ed576d6572b
> +Signed-off-by: Armin Kuster 
> +
> +---
> + net/checksum.c | 10 --
> + 1 file changed, 8 insertions(+), 2 deletions(-)
> +
> +Index: qemu-2.5.0/net/checksum.c
> +===
> +--- qemu-2.5.0.orig/net/checksum.c
>  qemu-2.5.0/net/checksum.c
> +@@ -59,6 +59,11 @@ void net_checksum_calculate(uint8_t *dat
> + int hlen, plen, proto, csum_offset;
> + uint16_t csum;
> + 
> ++/* Ensure data has complete L2 & L3 headers. */
> ++if (length < 14 + 20) {
> ++return;
> ++}
> ++
> + if ((data[14] & 0xf0) != 0x40)
> + return; /* not IPv4 */
> + hlen  = (data[14] & 0x0f) * 4;
> +@@ -76,8 +81,9 @@ void net_checksum_calculate(uint8_t *dat
> + return;
> + }
> + 
> +-if (plen < csum_offset+2)
> +-return;
> ++if (plen < csum_offset + 2 || 14 + hlen + plen > length) {
> ++return;
> ++}
> + 
> + data[14+hlen+csum_offset]   = 0;
> + data[14+hlen+csum_offset+1] = 0;
> diff --git a/meta/recipes-devtools/qemu/qemu_2.5.0.bb b/meta/recipes-
> devtools/qemu/qemu_2.5.0.bb
> index e9d9a8d..7622386 100644
> --- a/meta/recipes-devtools/qemu/qemu_2.5.0.bb
> +++ b/meta/recipes-devtools/qemu/qemu_2.5.0.bb
> @@ -11,6 +11,7 @@ SRC_URI += "file://configure-fix-Darwin-target-dete
> ction.patch \
>  file://CVE-2016-2197.patch \
>  file://CVE-2016-2198.patch \
>  file://pathlimit.patch \
> +file://CVE-2016-2857.patch \
> "
>  SRC_URI_prepend = "http://wiki.qemu-project.org/download/${BP}.tar.b
> z2"
>  SRC_URI[md5sum] = "f469f2330bbe76e3e39db10e9ac4f8db"
> -- 
> 2.3.5
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] trying to reconcile OE builds with rpm4-format rpm files built on centos 6

[Joshua G Lock]

On Thu, 2016-04-21 at 08:24 -0400, Robert P. J. Day wrote:
> On Thu, 21 Apr 2016, Burton, Ross wrote:
> > 
> > On 21 April 2016 at 13:06, Robert P. J. Day 
> > wrote:
> >     next bit of muttering is, "can we downgrade the OE build to
> > use
> >   rpm4-format packages?", which is not a path down which i want
> > to walk.
> > 
> > 
> > Assuming that the obviously correct option of "build the packages
> > inside OE" really is being written off for mysterious reasons, rpm4
> > was only just removed from oe-core (though depending on what
> > releases you're using you may have never noticed it be added and
> > removed again).  So you could just recover that from history
> > (oe-core a6e7a86f1635be9a688c56c25e9d215ea4d2cc84 removed it) and
> > fix it up.
>   under the circumstances, that sounds like the simplest approach.
> would we be losing any significant functionality downgrading to rpm4?
> it's not my first choice, but if all that's required is to do basic
> installs and upgrades, i suspect it will work just fine.

On the topic of RPM4 vs. RPM5 you should be able to find more details
in the list archives, I easily found a brief summary by Mark Hatle in
the Yocto Project mailing list archive:

"There are some specific uses of RPM 4 in the YP, but I do caution
against people just using it "because".  The RPM 5 version is generally
better suited for the embedded world.  (There are been posts on more
reasons on the oe-core lists in the past.  But as quick summary --
dynamic architecture support, better cross compilation support, cross-
endian support, more configurable for custom distributions, etc.)"
http://article.gmane.org/gmane.linux.embedded.yocto.general/28654/

We ended up removing RPM4 support because it was clear that it was
broken when using SMART as a package manager and we didn't have the
resources to fix it, nor any objections to its removal.

Some recent examples of the kinds of breakage:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=8968
https://bugzilla.yoctoproject.org/show_bug.cgi?id=8969

Regards,

Joshua
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][fido] bind: CVE-2016-1285 CVE-2016-1286

[Joshua G Lock]

On Fri, 2016-04-08 at 07:12 +0200, Sona Sarmadi wrote:
> CVE-2016-1285 bind: malformed packet sent to rndc can trigger
> assertion failure
> CVE-2016-1286 bind: malformed signature records for DNAME records can
> trigger assertion failure

Unfortunately I can't build bind with this patch applied:

| cc.c: In function 'verify':  
| cc.c:293:27: error: 'hmac' undeclared (first use in this function)  
|   if (!isccc_sexpr_binaryp(hmac))  
|^  
| cc.c:293:27: note: each undeclared identifier is reported only once
for each function it appears in  
| make[2]: *** [cc.o] Error 1

Based on a quick skim read of the patches I think this is caused
by CVE-2016-1285.patch:



> --- /dev/null
> +++ b/meta/recipes-connectivity/bind/bind/CVE-2016-1285.patch



> +diff --git a/lib/isccc/cc.c b/lib/isccc/cc.c
> +index 9915568..ffcd584 100644
> +--- a/lib/isccc/cc.c
>  b/lib/isccc/cc.c
> +@@ -284,10 +284,10 @@ verify(isccc_sexpr_t *alist, unsigned char
> *data, unsigned int length,
> +  * Extract digest.
> +  */
> + _auth = isccc_alist_lookup(alist, "_auth");
> +-if (_auth == NULL)
> ++if (!isccc_alist_alistp(_auth))
> + return (ISC_R_FAILURE);
> + hmd5 = isccc_alist_lookup(_auth, "hmd5");
> +-if (hmd5 == NULL)
> ++if (!isccc_sexpr_binaryp(hmac))

I believe this is the root of the compilation error. Should this be:

if (!isccc_sexpr_binaryp(hmd5))

?



Regards,

Joshua
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] coreutils: correct the case for class-native

[Joshua G Lock]

On Wed, 2016-04-06 at 12:50 +0800, Robert Yang wrote:
> 
> On 04/06/2016 12:45 PM, Dengke Du wrote:
> > 
> > The function of do_install_append_class-native for class-native
> > had alread exist,so exclude the class-native in function
> > do_install_append.
> > 
> > Signed-off-by: Dengke Du 
> > ---
> >   meta/recipes-core/coreutils/coreutils_8.25.bb | 4 
> >   1 file changed, 4 insertions(+)
> > 
> > diff --git a/meta/recipes-core/coreutils/coreutils_8.25.bb
> > b/meta/recipes-core/coreutils/coreutils_8.25.bb
> > index 419a693..e8e269a 100644
> > --- a/meta/recipes-core/coreutils/coreutils_8.25.bb
> > +++ b/meta/recipes-core/coreutils/coreutils_8.25.bb
> > @@ -70,6 +70,10 @@ do_compile_prepend () {
> >   }
> > 
> >   do_install_append() {
> > +   if [ "${CLASSOVERRIDE}" = "class-native" ]; then
> > +   return
> > +   fi
> > +

If the do_install_append is only valid for the target it'd be cleaner
to use a target-specific override i.e.

do_install_append_class-target () {
}

Thanks,

Joshua
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] psmisc: Remove including sys/user.h and __WORDSIZE

[Joshua G Lock]

On Tue, 2016-03-29 at 23:02 +, Khem Raj wrote:
> We can replace __WORDSIZE with UINTPTR_MAX
> sys/user.h is in conflict with asm/ptrace.h on musl

psmisc is failing to build on the autobuilder with this patch included:

https://autobuilder.yoctoproject.org/main/builders/nightly-no-x11/build
s/65/steps/BuildImages/logs/stdio

https://autobuilder.yoctoproject.org/main/builders/nightly-non-
gpl3/builds/721/steps/BuildImages/logs/stdio

> 
> Signed-off-by: Khem Raj 
> ---
>  ...001-Use-UINTPTR_MAX-instead-of-__WORDSIZE.patch | 49
> ++
>  meta/recipes-extended/psmisc/psmisc_22.21.bb   |  8 ++--
>  2 files changed, 54 insertions(+), 3 deletions(-)
>  create mode 100644 meta/recipes-extended/psmisc/psmisc/0001-Use-
> UINTPTR_MAX-instead-of-__WORDSIZE.patch
> 
> diff --git a/meta/recipes-extended/psmisc/psmisc/0001-Use-
> UINTPTR_MAX-instead-of-__WORDSIZE.patch b/meta/recipes-
> extended/psmisc/psmisc/0001-Use-UINTPTR_MAX-instead-of-
> __WORDSIZE.patch
> new file mode 100644
> index 000..2e70d5e
> --- /dev/null
> +++ b/meta/recipes-extended/psmisc/psmisc/0001-Use-UINTPTR_MAX-
> instead-of-__WORDSIZE.patch
> @@ -0,0 +1,49 @@
> +From 004de754e8b2c3cbfaf3aeba511a1c4149b23eb4 Mon Sep 17 00:00:00
> 2001
> +From: Khem Raj 
> +Date: Thu, 24 Mar 2016 15:46:14 +
> +Subject: [PATCH] Use UINTPTR_MAX instead of __WORDSIZE
> +
> +Do not include sys/user.h since it conflicts with
> +pt_regs struct from kernel APIs in asm/ptrace.h
> +
> +Signed-off-by: Khem Raj 
> +---
> +Upstream-Status: Pending
> +
> + src/peekfd.c | 12 ++--
> + 1 file changed, 6 insertions(+), 6 deletions(-)
> +
> +diff --git a/src/peekfd.c b/src/peekfd.c
> +index cba2130..e2c39cd 100644
> +--- a/src/peekfd.c
>  b/src/peekfd.c
> +@@ -30,8 +30,8 @@
> + #include 
> + #include 
> + #include 
> +-#include 
> + #include 
> ++#include 
> + #include 
> + #include 
> + 
> +@@ -228,11 +228,11 @@ int main(int argc, char **argv)
> + if (WIFSTOPPED(status)) {
> + #ifdef PPC
> + struct pt_regs regs;
> +-regs.gpr[0] = ptrace(PTRACE_PEEKUSER, pid,
> __WORDSIZE/8 * PT_R0, 0);
> +-regs.gpr[3] = ptrace(PTRACE_PEEKUSER, pid,
> __WORDSIZE/8 * PT_R3, 0);
> +-regs.gpr[4] = ptrace(PTRACE_PEEKUSER, pid,
> __WORDSIZE/8 * PT_R4, 0);
> +-regs.gpr[5] = ptrace(PTRACE_PEEKUSER, pid,
> __WORDSIZE/8 * PT_R5, 0);
> +-regs.orig_gpr3 = ptrace(PTRACE_PEEKUSER,
> pid, __WORDSIZE/8 * PT_ORIG_R3, 0);
> ++regs.gpr[0] = ptrace(PTRACE_PEEKUSER, pid,
> UINTPTR_MAX/8 * PT_R0, 0);
> ++regs.gpr[3] = ptrace(PTRACE_PEEKUSER, pid,
> UINTPTR_MAX/8 * PT_R3, 0);
> ++regs.gpr[4] = ptrace(PTRACE_PEEKUSER, pid,
> UINTPTR_MAX/8 * PT_R4, 0);
> ++regs.gpr[5] = ptrace(PTRACE_PEEKUSER, pid,
> UINTPTR_MAX/8 * PT_R5, 0);
> ++regs.orig_gpr3 = ptrace(PTRACE_PEEKUSER,
> pid, UINTPTR_MAX/8 * PT_ORIG_R3, 0);
> + #elif defined(ARM)
> + struct pt_regs regs;
> + ptrace(PTRACE_GETREGS, pid, 0, );
> +-- 
> +1.8.3.1
> +
> diff --git a/meta/recipes-extended/psmisc/psmisc_22.21.bb
> b/meta/recipes-extended/psmisc/psmisc_22.21.bb
> index 66aba9e..1c6473e 100644
> --- a/meta/recipes-extended/psmisc/psmisc_22.21.bb
> +++ b/meta/recipes-extended/psmisc/psmisc_22.21.bb
> @@ -5,6 +5,8 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=0636e73ff0215e
> 8d672dc4c32c317bb3"
>  SRC_URI[md5sum] = "935c0fd6eb208288262b385fa656f1bf"
>  SRC_URI[sha256sum] =
> "97323cad619210845b696d7d722c383852b2acb5c49b5b0852c4f29c77a8145a"
>  
> -SRC_URI += "file://0001-Typo-in-fuser-makes-M-on-all-the-time.patch
> \
> -file://0002-Include-limits.h-for-PATH_MAX.patch \
> -"
> +SRC_URI = "${SOURCEFORGE_MIRROR}/psmisc/psmisc-${PV}.tar.gz \
> +   file://0001-Typo-in-fuser-makes-M-on-all-the-time.patch \
> +   file://0002-Include-limits.h-for-PATH_MAX.patch \
> +   file://0001-Use-UINTPTR_MAX-instead-of-__WORDSIZE.patch \
> +   "
> -- 
> 1.9.1
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [jethro][PATCH] bluez5: allow D-Bus to spawn obexd in systems without systemd

[Joshua G Lock]

Hi Robert,

On Mon, 2016-03-21 at 12:36 +0100, Javier Viguera wrote:
> Hi Joshua
> 
> On 03/03/16 12:30, Joshua G Lock wrote:
> > Ah, I hadn't seen that patch as I was only looking at patches
> > tagged
> > jethro. We can consider this change for jethro once it lands in
> > master.
> > 
> This has been finally merged into master.
> 
> Would you now consider cherry-picking it into *jethro* ?

Could you consider cherry-picking this fix for Jethro?

http://git.openembedded.org/openembedded-core/commit/?id=75c5dc8d4a5506
bf5b89292a96c7b9f91e9d71c8

---

bluez5: allow D-Bus to spawn obexd in systems without systemd
This includes a proper D-Bus service file for obexd in systems that do
not support systemd.

Signed-off-by: Javier Viguera <javier.vigu...@digi.com>
Signed-off-by: Ross Burton <ross.bur...@intel.com>

---

Thanks,

Joshua
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC PATCH 0/3] Remove RPM 4

[Joshua G Lock]

On Fri, 2016-03-11 at 17:41 +, Richard Purdie wrote:
> On Fri, 2016-03-11 at 14:07 +, Joshua Lock wrote:
> > 
> > This series removes RPM 4 and code to support it from OE Core.
> > There
> > are
> > several known issues with using RPM 4 and it seems better to
> > acknowledge it's
> > unsupported by removing it from OE-Core than to leave  it in a non
> > -functional
> > state.
> > 
> > Please review the following changes for suitability for inclusion.
> > If
> > you have
> > any objections or suggestions for improvement, please respond to
> > the
> > patches. If
> > you agree with the changes, please provide your Acked-by.
> I think I'm in favour of removing it at this point as its not getting
> much attention.
> 
> I'd note that we need to remove the QA test for it:
> 
> selftest/imagefeatures.py:def
> test_rpm_version_4_support_on_image(self):

Right, thanks for catching this. I've pushed a patch to remove this to
the same branch, I'll submit a v2 with this removal included once the
RFC has had another day or so to collect comments.


Regards,

Joshua
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2][fido] dhcp: CVE-2015-8605

[Joshua G Lock]

On Fri, 2016-03-11 at 08:47 +, mariano.lo...@linux.intel.com wrote:
> From: Mariano Lopez 
> 
> ISC DHCP allows remote attackers to cause a denial of
> service (application crash) via an invalid length field
> in a UDP IPv4 packet.

Thanks Mariano,

I've queued this in my fido-next branch.

Regards,

Joshua

> 
> Signed-off-by: Mariano Lopez 
> ---
>  .../dhcp/dhcp/CVE-2015-8605.patch  | 101
> 
>  .../dhcp/dhcp/CVE-2015-8605_1.patch| 131
> +
>  meta/recipes-connectivity/dhcp/dhcp_4.3.1.bb   |   2 +
>  3 files changed, 234 insertions(+)
>  create mode 100644 meta/recipes-connectivity/dhcp/dhcp/CVE-2015-
> 8605.patch
>  create mode 100644 meta/recipes-connectivity/dhcp/dhcp/CVE-2015-
> 8605_1.patch
> 
> diff --git a/meta/recipes-connectivity/dhcp/dhcp/CVE-2015-8605.patch
> b/meta/recipes-connectivity/dhcp/dhcp/CVE-2015-8605.patch
> new file mode 100644
> index 000..05f1fa9
> --- /dev/null
> +++ b/meta/recipes-connectivity/dhcp/dhcp/CVE-2015-8605.patch
> @@ -0,0 +1,101 @@
> +Solves CVE-2015-8605 that caused DoS when an invalid length field in
> IPv4 UDP
> +was received by the server.
> +
> +Upstream-Status: Backport (v4.3.3p1)
> +CVE: CVE-2015-8605
> +
> +From: https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=commit;
> h=4ce21cb6301d665de01c1a6209e40f5f35072c0c
> +
> +Signed-off-by: Mariano Lopez 
> +
> +
> ===
> +diff --git a/common/packet.c b/common/packet.c
> +index b530432..e600e37 100644
> +--- a/common/packet.c
>  b/common/packet.c
> +@@ -220,7 +220,28 @@ ssize_t decode_hw_header (interface, buf,
> bufix, from)
> + }
> + }
> + 
> +-/* UDP header and IP header decoded together for convenience. */
> ++/*!
> ++ *
> ++ * \brief UDP header and IP header decoded together for
> convenience.
> ++ *
> ++ * Attempt to decode the UDP and IP headers and, if necessary,
> checksum
> ++ * the packet.
> ++ *
> ++ * \param inteface - the interface on which the packet was recevied
> ++ * \param buf - a pointer to the buffer for the received packet
> ++ * \param bufix - where to start processing the buffer, previous
> ++ *routines may have processed parts of the buffer
> already
> ++ * \param from - space to return the address of the packet sender
> ++ * \param buflen - remaining length of the buffer, this will have
> been
> ++ * decremented by bufix by the caller
> ++ * \param rbuflen - space to return the length of the payload from
> the udp
> ++ *  header
> ++ * \param csum_ready - indication if the checksum is valid for use
> ++ * non-zero indicates the checksum should be
> validated
> ++ *
> ++ * \return - the index to the first byte of the udp payload (that
> is the
> ++ *   start of the DHCP packet
> ++ */
> + 
> + ssize_t
> + decode_udp_ip_header(struct interface_info *interface,
> +@@ -231,7 +252,7 @@ decode_udp_ip_header(struct interface_info
> *interface,
> +   unsigned char *data;
> +   struct ip ip;
> +   struct udphdr udp;
> +-  unsigned char *upp, *endbuf;
> ++  unsigned char *upp;
> +   u_int32_t ip_len, ulen, pkt_len;
> +   static unsigned int ip_packets_seen = 0;
> +   static unsigned int ip_packets_bad_checksum = 0;
> +@@ -241,11 +262,8 @@ decode_udp_ip_header(struct interface_info
> *interface,
> +   static unsigned int udp_packets_length_overflow = 0;
> +   unsigned len;
> + 
> +-  /* Designate the end of the input buffer for bounds checks. */
> +-  endbuf = buf + bufix + buflen;
> +-
> +   /* Assure there is at least an IP header there. */
> +-  if ((buf + bufix + sizeof(ip)) > endbuf)
> ++  if (sizeof(ip) > buflen)
> +   return -1;
> + 
> +   /* Copy the IP header into a stack aligned structure for
> inspection.
> +@@ -257,13 +275,17 @@ decode_udp_ip_header(struct interface_info
> *interface,
> +   ip_len = (*upp & 0x0f) << 2;
> +   upp += ip_len;
> + 
> +-  /* Check the IP packet length. */
> ++  /* Check packet lengths are within the buffer:
> ++   * first the ip header (ip_len)
> ++   * then the packet length from the ip header (pkt_len)
> ++   * then the udp header (ip_len + sizeof(udp)
> ++   * We are liberal in what we accept, the udp payload should fit
> within
> ++   * pkt_len, but we only check against the full buffer size.
> ++   */
> +   pkt_len = ntohs(ip.ip_len);
> +-  if (pkt_len > buflen)
> +-return -1;
> +-
> +-  /* Assure after ip_len bytes that there is enough room for a UDP
> header. */
> +-  if ((upp + sizeof(udp)) > endbuf)
> ++  if ((ip_len > buflen) ||
> ++  (pkt_len > buflen) ||
> ++  ((ip_len + sizeof(udp)) > buflen))
> +   return -1;
> + 
> +   /* Copy the UDP header into a stack aligned structure for
> inspection. */
> +@@ -284,7 +306,8 @@ decode_udp_ip_header(struct interface_info
> *interface,
> + return -1;
> + 
> +   

Re: [OE-core] [meta-oe][PATCH v2] nettle: The variable named p in the patch file was incorrectly named.

[Joshua G Lock]

On Wed, 2016-03-09 at 09:17 -0700, ngutzmann wrote:
> The variable in question should have been called ecc->p. The patch
> has been updated
> so that the compilation of the nettle recipe would complete
> successfully. The backport
> originated from this commit
> https://git.lysator.liu.se/nettle/nettle/commit/c71d2c9d20eeebb985e38
> 72e4550137209e3ce4d

Thanks a lot for this patch, I've just proposed it for inclusion in the
Fido branch.

I missed this originally because it's not tagged fido, for future it's
worth pointing out that in order to be sure patches for stable branches
are noticed by the maintainers we request the subject is prefixed with
[branchname].

Thanks again for your contribution.

Joshua
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] dhcp: CVE-2015-8605

[Joshua G Lock]

Hi Mariano,

Thanks for the patch.

On Tue, 2016-03-08 at 10:26 +, mariano.lo...@linux.intel.com wrote:
> From: Mariano Lopez 
> 
> ISC DHCP allows remote attackers to cause a denial of
> service (application crash) via an invalid length field
> in a UDP IPv4 packet.
> 
> Signed-off-by: Mariano Lopez 
> ---
>  .../dhcp/dhcp/CVE-2015-8605.patch  |  99
> 
>  .../dhcp/dhcp/CVE-2015-8605_1.patch| 131
> +
>  meta/recipes-connectivity/dhcp/dhcp_4.3.1.bb   |   2 +
>  3 files changed, 232 insertions(+)
>  create mode 100644 meta/recipes-connectivity/dhcp/dhcp/CVE-2015-
> 8605.patch
>  create mode 100644 meta/recipes-connectivity/dhcp/dhcp/CVE-2015-
> 8605_1.patch
> 
> diff --git a/meta/recipes-connectivity/dhcp/dhcp/CVE-2015-8605.patch
> b/meta/recipes-connectivity/dhcp/dhcp/CVE-2015-8605.patch
> new file mode 100644
> index 000..923d5d5
> --- /dev/null
> +++ b/meta/recipes-connectivity/dhcp/dhcp/CVE-2015-8605.patch
> @@ -0,0 +1,99 @@
> +Solves CVE-2015-8605 that caused DoS when an invalid lenght field in

lenght -> length

> IPv4 UDP
> +was recived by the server.
> +
> +Upstream-Status: Backport

Can you include some more information about the backport, i.e. the
version the patch was backported from, in the Upstream-Status: field so
that it's easier to determine why this patch isn't required in jethro
and master?

> +CVE: CVE-2015-8605
> +
> +Signed-off-by: Mariano Lopez 
> +
> +
> ===
> +diff --git a/common/packet.c b/common/packet.c



> new file mode 100644
> index 000..37a3d72
> --- /dev/null
> +++ b/meta/recipes-connectivity/dhcp/dhcp/CVE-2015-8605_1.patch
> @@ -0,0 +1,131 @@
> +This patch is needed for the CVE-2015-8605 that caused DoS when an
> invalid lenght field in IPv4 UDP

lenght -> length

> +was recived by the server.

recived -> received

> +
> +Upstream-Status: Backport

Same again, what version was this backported from?

Thanks,

Joshua
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [jethro][PATCH] bluez5: allow D-Bus to spawn obexd in systems without systemd

[Joshua G Lock]

On Thu, 2016-03-03 at 11:22 +, Viguera, Javier wrote:
> Hi Joshua,
> 
> > 
> > -Original Message-
> > From: Joshua G Lock [mailto:joshua.g.l...@linux.intel.com] 
> > Sent: Thursday, March 03, 2016 12:08 PM
> > To: Viguera, Javier; openembedded-core@lists.openembedded.org
> > Subject: Re: [OE-core] [jethro][PATCH] bluez5: allow D-Bus to spawn
> > obexd in systems without systemd
> > 
> > This looks like a valid patch for the master branch too?
> Absolutely. That's why I sent both patches together, one for master
> and this one for Jethro.
> 
> See the one for master: 
> 
> http://patchwork.openembedded.org/patch/116389/

Ah, I hadn't seen that patch as I was only looking at patches tagged
jethro. We can consider this change for jethro once it lands in master.

> 
> By the way, for Jethro I sent also a different patch (master
> backport):
> 
> http://patchwork.openembedded.org/patch/116661/
> 
> This last one is already in master and it would be great to have it
> in Jethro as well.

I just included this patch in a consolidated Jethro pull request.

Regards,

Joshua
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [jethro][PATCH] bluez5: allow D-Bus to spawn obexd in systems without systemd

[Joshua G Lock]

Hi Javier,

On Wed, 2016-02-24 at 19:14 +0100, Javier Viguera wrote:
> This includes a proper D-Bus service file for obexd in systems that
> do
> not support systemd.
> 

This looks like a valid patch for the master branch too?

The development process we try to follow is for patches to go into the
master branch first, then be backported into the release branches.

Regards,

Joshua

> Signed-off-by: Javier Viguera 
> ---
>  meta/recipes-connectivity/bluez5/bluez5.inc|  1 +
>  ...-obexd-without-systemd-in-the-user-sessio.patch | 63
> ++
>  2 files changed, 64 insertions(+)
>  create mode 100644 meta/recipes-connectivity/bluez5/bluez5/0001-
> Allow-using-obexd-without-systemd-in-the-user-sessio.patch
> 
> diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc
> b/meta/recipes-connectivity/bluez5/bluez5.inc
> index df42c88b9da3..d1af31ea45cd 100644
> --- a/meta/recipes-connectivity/bluez5/bluez5.inc
> +++ b/meta/recipes-connectivity/bluez5/bluez5.inc
> @@ -18,6 +18,7 @@ PACKAGECONFIG[experimental] = "--enable-
> experimental,--disable-experimental,"
>  
>  SRC_URI = "\
>  ${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.xz \
> +${@bb.utils.contains('DISTRO_FEATURES', 'systemd', '', 'file://0
> 001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch', d)}
> \
>  "
>  S = "${WORKDIR}/bluez-${PV}"
>  
> diff --git a/meta/recipes-connectivity/bluez5/bluez5/0001-Allow-
> using-obexd-without-systemd-in-the-user-sessio.patch b/meta/recipes-
> connectivity/bluez5/bluez5/0001-Allow-using-obexd-without-systemd-in-
> the-user-sessio.patch
> new file mode 100644
> index ..2fde7bc06923
> --- /dev/null
> +++ b/meta/recipes-connectivity/bluez5/bluez5/0001-Allow-using-obexd-
> without-systemd-in-the-user-sessio.patch
> @@ -0,0 +1,63 @@
> +From: Giovanni Campagna  ne.org>
> +Date: Sat, 12 Oct 2013 17:45:25 +0200
> +Subject: [PATCH] Allow using obexd without systemd in the user
> session
> +
> +Not all sessions run systemd --user (actually, the majority
> +doesn't), so the dbus daemon must be able to spawn obexd
> +directly, and to do so it needs the full path of the daemon.
> +
> +Upstream-Status: Denied
> +
> +Not accepted by upstream maintainer for being a distro specific
> +configuration. See thread:
> +
> +http://thread.gmane.org/gmane.linux.bluez.kernel/38725/focus=38843
> +
> +Signed-off-by: Javier Viguera 
> +---
> + Makefile.obexd  | 4 ++--
> + obexd/src/org.bluez.obex.service| 4 
> + obexd/src/org.bluez.obex.service.in | 4 
> + 3 files changed, 6 insertions(+), 6 deletions(-)
> + delete mode 100644 obexd/src/org.bluez.obex.service
> + create mode 100644 obexd/src/org.bluez.obex.service.in
> +
> +diff --git a/Makefile.obexd b/Makefile.obexd
> +index 2e33cbc72f2b..d5d858c857b4 100644
> +--- a/Makefile.obexd
>  b/Makefile.obexd
> +@@ -2,12 +2,12 @@
> + if SYSTEMD
> + systemduserunitdir = @SYSTEMD_USERUNITDIR@
> + systemduserunit_DATA = obexd/src/obex.service
> ++endif
> + 
> + dbussessionbusdir = @DBUS_SESSIONBUSDIR@
> + dbussessionbus_DATA = obexd/src/org.bluez.obex.service
> +-endif
> + 
> +-EXTRA_DIST += obexd/src/obex.service.in
> obexd/src/org.bluez.obex.service
> ++EXTRA_DIST += obexd/src/obex.service.in
> obexd/src/org.bluez.obex.service.in
> + 
> + obex_plugindir = $(libdir)/obex/plugins
> + 
> +diff --git a/obexd/src/org.bluez.obex.service
> b/obexd/src/org.bluez.obex.service
> +deleted file mode 100644
> +index a53808884554..
> +--- a/obexd/src/org.bluez.obex.service
>  /dev/null
> +@@ -1,4 +0,0 @@
> +-[D-BUS Service]
> +-Name=org.bluez.obex
> +-Exec=/bin/false
> +-SystemdService=dbus-org.bluez.obex.service
> +diff --git a/obexd/src/org.bluez.obex.service.in
> b/obexd/src/org.bluez.obex.service.in
> +new file mode 100644
> +index ..9c815f246b77
> +--- /dev/null
>  b/obexd/src/org.bluez.obex.service.in
> +@@ -0,0 +1,4 @@
> ++[D-BUS Service]
> ++Name=org.bluez.obex
> ++Exec=@libexecdir@/obexd
> ++SystemdService=dbus-org.bluez.obex.service
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 00/10] Integrate swupd software updater

[Joshua G Lock]

On Wed, 2016-02-24 at 19:49 +0100, Patrick Ohly wrote:
> On Wed, 2016-02-24 at 16:09 +, Lock, Joshua G wrote:
> > 
> > On Wed, 2016-02-24 at 16:37 +0100, Patrick Ohly wrote:
> > > 
> > > Hello!
> > > 
> > > I haven't had a chance to play with the actual code yet and I
> > > don't
> > > know
> > > yet when I'll be able to. Let me ask for some clarifications
> > > about
> > > the
> > > approach first anyway.
> > > 
> > > On Wed, 2016-02-24 at 14:52 +, Joshua Lock wrote:
> > > > 
> > > > 
> > > > Approach:
> > > > An image that inherits the swupd-image bbclass will
> > > > automatically
> > > > have bundle
> > > > 'chroots' created which contain the filesystem contents of the
> > > > specified
> > > > bundles, with the contents of the inheriting image forming the
> > > > default os-core
> > > > bundle.
> > > > 
> > > > The mechanism to achieve this is that several virtual image
> > > > recipes
> > > > are created
> > > > using the swupdbundle class, one for each defined bundle plus a
> > > > 'mega' image
> > > > recipe. The 'mega' image contains the base image plus the
> > > > contents
> > > > of all of the
> > > > bundles, whilst bundle images contain only the base image plus
> > > > the
> > > > contents of a
> > > > single bundle.
> > > Just to be sure, the actual "content" (a term that is a bit too
> > > overloaded to be used precisely in all cases) of a file and its
> > > meta
> > > attributes will come from the mega image, and the virtual image
> > > recipes,
> > > including the base image, are merely used to generate file lists?
> > That's not currently true, no — the file contents for a bundle come
> > from the bundle image and the file contents for os-core come from
> > the
> > base image. It shouldn't be too difficult a change to make, I'll
> > take a
> > look now.
> The prime example that needs to be handled correctly is where
> installing
> additional packages for one of the extra bundles adds a system user
> to /etc/passwd (*). The content of /etc/passwd must come from the
> mega
> rootfs.

Indeed,  I'm working on that issue now and have filed a ticket to keep
track: https://bugzilla.yoctoproject.org/show_bug.cgi?id=9193

> (*) Except that swupd assumes that the distro is stateless and thus
> automatically excludes /etc from bundles. The example is still valid
> because preparing bundles does not need to care about that.

One of the patches I developed for swupd was to turn this into a
configure time option for swupd-server, see: 

http://git.yoctoproject.org/cgit/cgit.cgi/meta-swupd/tree/recipes-core/
swupd-server/swupd-server/0002-Add-configure-option-to-re-enable-
config-files-in-ma.patch

Regards,

Joshua
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 05/10] swupdbundle: new class to generate virtual images for swupd-image

[Joshua G Lock]

Hi Patrick,

Apologies for the delayed response.

On Thu, 2016-02-25 at 18:06 +0100, Patrick Ohly wrote:
> On Wed, 2016-02-24 at 14:52 +, Joshua Lock wrote:
> > 
> > Our initial strategy to generate bundles for consumption by swupd
> > is to generate images which contain the base image (os-core) plus
> > the additional contents of the bundle, then prune out the core
> > contents. By generating images in this manner we hope to accomodate
> > packages which modify the rootfs outside of installing files, i.e.
> > with postinsts.
> > 
> > To that end this class, to be used via BBCLASSEXTEND, will generate
> > virtual image recipes that add extra packages to the extended
> > image.
> Can this be combined with an image recipe which itself uses
> BBCLASSEXTEND to generate virtual image recipes, i.e. create a
> virtual
> recipes based on a virtual recipe?

Currently this doesn't work, but I've just filed a bug to handle this
scenario: https://bugzilla.yoctoproject.org/show_bug.cgi?id=9192

Regards,

Joshua

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] wpa-supplicant: Fix CVE-2015-8041

[Joshua G Lock]

On Mon, 2016-02-22 at 17:15 +1300, Paul Eggleton wrote:
> Hi Robert,
> 
> I just noticed this never got merged into jethro. Could you take care
> of that? 
> The original patch is here:
> 
> http://patchwork.openembedded.org/patch/107625/
> 
> Joshua, looks like we could use this one in fido as well.

I was hoping to backport this from Jethro but I haven't seen it land
there yet, I've queued it for fido so I don't forget.

Robert, I have a branch for jethro with this patch included — should I
submit it?

Regards,

Joshua
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [fido][PATCH 0/7] fido Security fixes pull request

[Joshua G Lock]

On Tue, 2016-02-23 at 07:58 -0800, Armin Kuster wrote:
> From: Armin Kuster 
> 
> Please consider these for the next fido 
> 
> This is to meet our obligation for Yocto compatibility
> 
> The following changes since commit
> 06d9c894636352a6c93711c7284d02b0c794a527:
> 
>   libbsd: Security fix CVE-2016-2090 (2016-02-18 11:03:10 +)
> 
> are available in the git repository at:
> 
>   git://git.yoctoproject.org/poky-contrib akuster/fido_cve_fixes
>   http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akuster/fi
> do_cve_fixes
> 
> Armin Kuster (7):
>   qemu: Security fix CVE-2016-2198
>   foomatic-filters: Security fix CVE-2015-8560
>   foomatic-filters: Security fixes CVE-2015-8327
>   tiff: Security fix CVE-2015-8781
>   tiff: Security fix CVE-2015-8784
>   librsvg: Security fix CVE-2015-7558
>   gdk-pixbuf: Security fix CVE-2015-7674

Queued in joshuagl/fido-next

Regards,

Joshua
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [fido][PATCH 00/11] Fido Security fixes #2

[Joshua G Lock]

On Tue, 2016-02-23 at 17:48 -0800, Armin Kuster wrote:
> From: Armin Kuster 
> 
> please consider these changes for the next fido update.
> 
> This is to meet our obligation for Yocto compatibility
> 
> The following changes since commit
> 9037f2c7c797367c2d09b87f344ecf749d28cb41:
> 
>   gdk-pixbuf: Security fix CVE-2015-7674 (2016-02-22 19:08:53 -0800)
> 
> are available in the git repository at:
> 
>   git://git.yoctoproject.org/poky-contrib akuster/fido_cve_fixes
>   http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akuster/fi
> do_cve_fixes
> 
> Armin Kuster (10):
>   busybox: Security fix CVE-2011-5325

This doesn't appear to actually fix anything, it just adds this patch
which notes a potential security issue:

https://git.busybox.net/busybox/commit/?id=a116552869db5e7793ae10968eb3
c962c69b3d8c

>   libpng: Security fix CVE-2015-8126
>   libpng: Security fix CVE-2015-8472
>   libgcrypt: Security fix CVE-2015-7511
>   curl: Security fix CVE-2016-0754
>   curl: Secuirty fix CVE-2016-0755
>   bind: Security fix CVE-2015-8461
>   nettle: Security fix CVE-2015-8803 and CVE-2015-8805
>   nettle: Security fix CVE-2015-8804
>   git: Security fixes CVE-2015-7545
> 
> Li Zhou (1):
>   rpcbind: Security Advisory - rpcbind - CVE-2015-7236

Queued in joshuagl/fido-next

Regards,

Joshua
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 00/10] Integrate swupd software updater

[Joshua G Lock]

On Wed, 2016-02-24 at 15:40 -0500, Philip Balister wrote:
> On 02/24/2016 02:51 PM, Paul Eggleton wrote:
> > 
> > On Wed, 24 Feb 2016 11:35:25 Philip Balister wrote:
> > > 
> > > On 02/24/2016 11:06 AM, Trevor Woerner wrote:
> > > > 
> > > > Ideally the work done here and the work done on meta-
> > > > swupdate[1] would
> > > > be somehow merged so people creating images/distros would only
> > > > have to
> > > > learn and integrate one software update solution, instead of
> > > > having to
> > > > evaluate and choose between the two (or more?).
> > > > 
> > > > [1] https://github.com/sbabic/meta-swupdate
> > > Amen. I had the same thoughts reading the patch set intro.
> > I think it would be hard to integrate these two, since they operate
> > quite 
> > differently to eachother.
> >  
> > > 
> > > Maybe the swupd should go in a seperate layer so we can see which
> > > project works best for oe users before moving something directly
> > > into
> > > oe-core?
> > This makes sense to me too though FWIW. The os-release patch should
> > probably 
> > go straight in, but everything else looks like it could comfortably
> > live in a 
> > separate layer without making things too difficult.
> It also makes it easier to update as problems in swupd are resolved
> since you do not need to go through the entire oe-core testing cycle.

I've pushed the series, including a couple of metadata fixes suggested
in reply, as a layer here: http://git.yoctoproject.org/cgit/cgit.cgi/me
ta-swupd/

Regards,

Joshua
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 03/10] hardlink: add new recipe

[Joshua G Lock]

On Thu, 2016-02-25 at 11:13 -0600, Mark Hatle wrote:
> I just noticed this, any reason to use this over fdupes?

No reason other than that hardlink is what the Clear Linux team, who
authored swupd, are using. Is there a compelling reason to look at
fdupes instead?

Thanks,

Joshua

> 
> I've used fdupes in the past for this exact thing -- primarily with
> shrinking
> the size of multilib SDKs with a lot of locales.
> 
> --Mark
> 
> On 2/24/16 8:52 AM, Joshua Lock wrote:
> > 
> > ---
> >  meta/recipes-extended/hardlink/hardlink_0.3.0.bb | 19
> > +++
> >  1 file changed, 19 insertions(+)
> >  create mode 100644 meta/recipes-
> > extended/hardlink/hardlink_0.3.0.bb
> > 
> > diff --git a/meta/recipes-extended/hardlink/hardlink_0.3.0.bb
> > b/meta/recipes-extended/hardlink/hardlink_0.3.0.bb
> > new file mode 100644
> > index 000..2e06ac2
> > --- /dev/null
> > +++ b/meta/recipes-extended/hardlink/hardlink_0.3.0.bb
> > @@ -0,0 +1,19 @@
> > +SUMMARY = "hardlink is a tool which replaces multiple copies of a
> > file with hardlinks."
> > +LICENSE = "MIT"
> > +LIC_FILES_CHKSUM =
> > "file://hardlink.c;endline=22;md5=168464a4fc92fa7389c53b0755b39fbb"
> > +
> > +SRC_URI = "http://jak-linux.org/projects/hardlink/${BPN}_${PV}.tar
> > .xz"
> > +SRC_URI[md5sum] = "72f1a460adb6874c151deab766e434ad"
> > +SRC_URI[sha256sum] =
> > "e8c93dfcb24aeb44a75281ed73757cb862cc63b225d565db1c270af9dbb7300f"
> > +
> > +DEPENDS = "libpcre attr"
> > +
> > +do_compile () {
> > +   oe_runmake 'DESTDIR=${D}' 'PREFIX=${prefix}'
> > BINDIR='${bindir}'
> > +}
> > +
> > +do_install () {
> > +   oe_runmake install 'DESTDIR=${D}' 'PREFIX=${prefix}'
> > BINDIR='${bindir}'
> > +}
> > +
> > +BBCLASSEXTEND = "native nativesdk"
> > 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 02/10] swupd-server: initial recipe 2.53

[Joshua G Lock]

On Thu, 2016-02-25 at 09:11 +0100, Maciej Borzecki wrote:
> On 02/24 14:52, Joshua Lock wrote:
> > +SRC_URI = "\
> > +https://download.clearlinux.org/releases/5940/clear/source/SRP
> > MS/${BPN}-${PV}-4.src.rpm;extract=${BP}.tar.gz \
> I'm going throught he patches in reverse order, but IIRC you used
> release 5700 for swupd-client, here it's release 5940. Is there a
> chance
> that client and server might be out of sync?

Well spotted! This combination do work together, both from my own
testing and that of colleagues using swupd, but I would like to sync up
on the same version soon.

Regards,

Joshua

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 04/10] swupd-client: Add recipe

[Joshua G Lock]

On Thu, 2016-02-25 at 09:07 +0100, Maciej Borzecki wrote:
> On 02/24 14:52, Joshua Lock wrote:
> > 
> > From: Mariano Lopez 
> > 
> > This commit adds the Clear Linux client updater.
> > This is experimental and bleeding edge, including the comments on
> > the recipe.
> > 
> > Signed-off-by: Mariano Lopez 
> > Signed-off-by: Joshua Lock 
> > ---
> >  .../0001-Tolerate-quotes-in-os-release-files.patch | 59
> > ++
> >  ...hange-systemctl-path-to-OE-systemctl-path.patch | 31
> > 
> >  .../swupd-client/Fix-build-failure-on-Yocto.patch  | 36
> > +
> >  .../Right-usage-of-AC_ARG_ENABLE-on-bzip2.patch| 38
> > ++
> >  meta/recipes-devtools/swupd/swupd-client_2.87.bb   | 49
> > ++
> >  5 files changed, 213 insertions(+)
> >  create mode 100644 meta/recipes-devtools/swupd/swupd-client/0001-
> > Tolerate-quotes-in-os-release-files.patch
> >  create mode 100644 meta/recipes-devtools/swupd/swupd-
> > client/Change-systemctl-path-to-OE-systemctl-path.patch
> >  create mode 100644 meta/recipes-devtools/swupd/swupd-client/Fix-
> > build-failure-on-Yocto.patch
> >  create mode 100644 meta/recipes-devtools/swupd/swupd-client/Right-
> > usage-of-AC_ARG_ENABLE-on-bzip2.patch
> >  create mode 100644 meta/recipes-devtools/swupd/swupd-
> > client_2.87.bb
> > 
> > diff --git a/meta/recipes-devtools/swupd/swupd-client/0001-
> > Tolerate-quotes-in-os-release-files.patch b/meta/recipes-
> > devtools/swupd/swupd-client/0001-Tolerate-quotes-in-os-release-
> > files.patch
> > new file mode 100644
> > index 000..49c71ae
> > --- /dev/null
> > +++ b/meta/recipes-devtools/swupd/swupd-client/0001-Tolerate-
> > quotes-in-os-release-files.patch
> > @@ -0,0 +1,59 @@
> > +From 586e7b927461f6604ee3a3159cd7a6d4ac22ef30 Mon Sep 17 00:00:00
> > 2001
> > +From: Dmitry Rozhkov 
> > +Date: Thu, 11 Feb 2016 13:29:57 +0200
> > +Subject: [PATCH 1/2] Tolerate quotes in os-release files
> > +
> > +Some systems like Yocto or OpenSUSE prefer to wrap values in
> > +/etc/os-release file with quotes always and that still conforms
> > +to the format defined in systemd.
> > +
> > +This patch removes quotes from the values before trying to
> > +transform them into integer version id.
> > +
> > +Signed-off-by: Dmitry Rozhkov 
> > +
> > +Upstream-Status: Backport (v3.0.0+)
> > +
> > +---
> > + src/version.c | 18 +-
> > + 1 file changed, 17 insertions(+), 1 deletion(-)
> > +
> > +diff --git a/src/version.c b/src/version.c
> > +index 0e09cd9..83d6ad4 100644
> > +--- a/src/version.c
> >  b/src/version.c
> > +@@ -88,6 +88,7 @@ int read_version_from_subvol_file(char
> > *path_prefix)
> > +   FILE *file;
> > +   int v = -1;
> > +   char *buildstamp;
> > ++  char *src, *dest;
> > +
> > +   string_or_die(, "%s/usr/lib/os-release",
> > path_prefix);
> > +   file = fopen(buildstamp, "rm");
> > +@@ -106,7 +107,22 @@ int read_version_from_subvol_file(char
> > *path_prefix)
> > +   break;
> > +   }
> > +
> > +-  if (strncmp(line,"VERSION_ID=", 11) == 0) {
> > ++  if (strncmp(line, "VERSION_ID=", 11) == 0) {
> > ++  src = [11];
> > ++
> > ++  /* Drop quotes and newline in value */
> > ++  dest = src;
> > ++  while (*src) {
> > ++  if (*src == '\'' || *src == '"'
> > || *src == '\n') {
> > ++  ++src;
> > ++  } else {
> > ++  *dest = *src;
> > ++  ++dest;
> > ++  ++src;
> > ++  }
> > ++  }
> > ++  *dest = 0;
> > ++
> > +   v = strtoull([11], NULL, 10);
> > +   break;
> > +   }
> > +--
> > +2.5.0
> > +
> > diff --git a/meta/recipes-devtools/swupd/swupd-client/Change-
> > systemctl-path-to-OE-systemctl-path.patch b/meta/recipes-
> > devtools/swupd/swupd-client/Change-systemctl-path-to-OE-systemctl-
> > path.patch
> > new file mode 100644
> > index 000..5ca6373
> > --- /dev/null
> > +++ b/meta/recipes-devtools/swupd/swupd-client/Change-systemctl-
> > path-to-OE-systemctl-path.patch
> > @@ -0,0 +1,31 @@
> > +From 259d86e64146c3156eccfcce0351a9cdc4714766 Mon Sep 17 00:00:00
> > 2001
> > +From: Jaska Uimonen 
> > +Date: Thu, 14 Jan 2016 10:17:43 +0200
> > +Subject: [PATCH] change systemctl path to OE systemctl path
> > +
> > +Upstream-Status: Inappropriate
> > +
> > +---
> > + src/scripts.c | 4 ++--
> > + 1 file changed, 2 insertions(+), 2 deletions(-)
> > +
> > +diff --git a/src/scripts.c b/src/scripts.c
> > +index e426272..9bec0f5 100644
> > +--- a/src/scripts.c
> >  b/src/scripts.c
> > +@@ -84,10 +84,10 @@ static void update_triggers(void)
> > +   

Re: [OE-core] [PATCH 03/10] hardlink: add new recipe

[Joshua G Lock]

On Wed, 2016-02-24 at 14:57 -0800, Andre McCurdy wrote:
> On Wed, Feb 24, 2016 at 6:52 AM, Joshua Lock  > wrote:
> > 
> > ---
> >  meta/recipes-extended/hardlink/hardlink_0.3.0.bb | 19
> > +++
> >  1 file changed, 19 insertions(+)
> >  create mode 100644 meta/recipes-
> > extended/hardlink/hardlink_0.3.0.bb
> > 
> > diff --git a/meta/recipes-extended/hardlink/hardlink_0.3.0.bb
> > b/meta/recipes-extended/hardlink/hardlink_0.3.0.bb
> > new file mode 100644
> > index 000..2e06ac2
> > --- /dev/null
> > +++ b/meta/recipes-extended/hardlink/hardlink_0.3.0.bb
> > @@ -0,0 +1,19 @@
> > +SUMMARY = "hardlink is a tool which replaces multiple copies of a
> > file with hardlinks."
> > +LICENSE = "MIT"
> > +LIC_FILES_CHKSUM =
> > "file://hardlink.c;endline=22;md5=168464a4fc92fa7389c53b0755b39fbb"
> > +
> > +SRC_URI = "http://jak-linux.org/projects/hardlink/${BPN}_${PV}.tar
> > .xz"
> > +SRC_URI[md5sum] = "72f1a460adb6874c151deab766e434ad"
> > +SRC_URI[sha256sum] =
> > "e8c93dfcb24aeb44a75281ed73757cb862cc63b225d565db1c270af9dbb7300f"
> > +
> > +DEPENDS = "libpcre attr"
> According to the style guide, DEPENDS should come between
> LIC_FILES_CHKSUM and SRC_URI.

Good catch, I'll re-order.

Thanks,

Joshua

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 05/10] swupdbundle: new class to generate virtual images for swupd-image

[Joshua G Lock]

On Thu, 2016-02-25 at 09:19 +0100, Maciej Borzecki wrote:
> On 02/24 14:52, Joshua Lock wrote:
> > 
> > Our initial strategy to generate bundles for consumption by swupd
> > is to generate images which contain the base image (os-core) plus
> > the additional contents of the bundle, then prune out the core
> > contents. By generating images in this manner we hope to accomodate
> > packages which modify the rootfs outside of installing files, i.e.
> > with postinsts.
> > 
> > To that end this class, to be used via BBCLASSEXTEND, will generate
> > virtual image recipes that add extra packages to the extended
> > image.
> > 
> > Only extensions matching entries in a SWUPD_BUNDLES variable are
> > valid and the bundle contents should be listed in a varFlag
> > matching the bundle's name on the BUNDLE_CONTENTS variable.
> > 
> > An example of usage in an image recipe follows:
> > 
> > SWUPD_BUNDLES = "foo bar"
> > BUNDLE_CONTENTS[foo] = "foo foo-bar foobaz"
> > BUNDLE_CONTENTS[bar] = "bar baz quux"
> > 
> > BBCLASSEXTEND = "swupdbundle:foo"
> > 
> > Signed-off-by: Joshua Lock 
> > ---
> >  meta/classes/swupdbundle.bbclass | 59
> > 
> >  1 file changed, 59 insertions(+)
> >  create mode 100644 meta/classes/swupdbundle.bbclass
> > 
> > diff --git a/meta/classes/swupdbundle.bbclass
> > b/meta/classes/swupdbundle.bbclass
> > new file mode 100644
> > index 000..897666d
> > --- /dev/null
> > +++ b/meta/classes/swupdbundle.bbclass
> > @@ -0,0 +1,59 @@
> > +# Our initial strategy to generate bundles for consumption by
> > swupd is to
> > +# generate images which contain the base image (os-core) plus the
> > additional
> > +# contents of the bundle, then prune out the core contents. By
> > generating
> > +# images in this manner we hope to accomodate packages which
> > modify the rootfs
> > +# outside of installing files, i.e.with postinsts.
> > +#
> > +# To that end this class, to be used via BBCLASSEXTEND, will
> > generate virtual
> > +# image recipes that add extra packages to the extended image.
> > +#
> > +# Only extensions matching entries in a SWUPD_BUNDLES variable are
> > valid and
> > +# the bundle contents should be listed in a varFlag matching the
> > bundle's name
> > +# on the BUNDLE_CONTENTS variable. i.e in foo-image.bb:
> > +#
> > +# SWUPD_BUNDLES = "foo bar"
> > +# BUNDLE_CONTENTS[foo] = "foo foo-bar foobaz"
> > +# BUNDLE_CONTENTS[bar] = "bar baz quux"
> > +# BBCLASSEXTEND = "swupdbundle:foo"
> > +
> > +python swupdbundle_virtclass_handler () {
> > +pn = e.data.getVar("PN", True)
> > +cls = e.data.getVar("BBEXTENDCURR", True)
> > +bundle = e.data.getVar("BBEXTENDVARIANT", True)
> > +
> > +if cls != 'swupdbundle':
> > +return
> > +
> > +if not bundle:
> > +bb.fatal('swupdbundle must be used with a parameter i.e.
> > BBCLASSEXTEND="swupdbundle:foo"')
> > +
> > +# Rename the virtual recipe to create the desired image bundle
> > variant.
> > +e.data.setVar("PN_BASE", pn)
> > +pn = pn + '-' + bundle
> > +e.data.setVar("PN", pn)
> > +e.data.setVar("BUNDLE_NAME", bundle)
> > +
> > +bundles = (e.data.getVar('SWUPD_BUNDLES', True) or "").split()
> > +if not bundles:
> > +bb.fatal('SWUPD_BUNDLES is not defined, this variable
> > should list bundles for the image.')
> > +
> > +curr_install = (e.data.getVar('IMAGE_INSTALL', True) or
> > "").split()
> > +
> > +def get_bundle_contents(bndl):
> > +contents = e.data.getVarFlag('BUNDLE_CONTENTS', bndl,
> > True)
> > +if contents:
> > +return contents.split()
> > +else:
> > +bb.fatal('BUNDLE_CONTENTS[%s] is not set, this should
> > list the packages to be included in the bundle.' % bndl)
> > +
> > +if bundle == 'mega':
> > +for bndl in bundles:
> > +curr_install += get_bundle_contents(bndl)
> Bundle named 'mega' seems to be very specific (a bundle of bundles)
> but
> is not documented as a reserved name.

Good point, I'll be sure to document that. I'll also add some code to
raise an error if one of SWUPD_BUNDLES (user-defined bundles) is mega.

Thanks for the review.

Regards,

Joshua

> > 
> > +else:
> > +curr_install += get_bundle_contents(bundle)
> > +
> > +e.data.setVar('IMAGE_INSTALL', ' '.join(curr_install))
> > +}
> > +
> > +addhandler swupdbundle_virtclass_handler
> > +swupdbundle_virtclass_handler[eventmask] =
> > "bb.event.RecipePreFinalise"
> > --
> > 2.5.0
> > 
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> --
> Maciej Borzęcki
> Senior Software Developer at Open-RnD Sp. z o.o., Poland
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org

Re: [OE-core] [PATCH 00/10] Integrate swupd software updater

[Joshua G Lock]

On Wed, 2016-02-24 at 16:37 +0100, Patrick Ohly wrote:
> Hello!
> 
> I haven't had a chance to play with the actual code yet and I don't
> know
> yet when I'll be able to. Let me ask for some clarifications about
> the
> approach first anyway.
> 
> On Wed, 2016-02-24 at 14:52 +, Joshua Lock wrote:
> > 
> > Approach:
> > An image that inherits the swupd-image bbclass will automatically
> > have bundle
> > 'chroots' created which contain the filesystem contents of the
> > specified
> > bundles, with the contents of the inheriting image forming the
> > default os-core
> > bundle.
> > 
> > The mechanism to achieve this is that several virtual image recipes
> > are created
> > using the swupdbundle class, one for each defined bundle plus a
> > 'mega' image
> > recipe. The 'mega' image contains the base image plus the contents
> > of all of the
> > bundles, whilst bundle images contain only the base image plus the
> > contents of a
> > single bundle.
> Just to be sure, the actual "content" (a term that is a bit too
> overloaded to be used precisely in all cases) of a file and its meta
> attributes will come from the mega image, and the virtual image
> recipes,
> including the base image, are merely used to generate file lists?

That's not currently true, no — the file contents for a bundle come
from the bundle image and the file contents for os-core come from the
base image. It shouldn't be too difficult a change to make, I'll take a
look now.

> What is the content of the actual image that gets created? It has to
> match the content (= file content and meta information) of the mega
> image and not of the base image, otherwise there can be
> inconsistencies
> between the actual running image and the core os bundle. I suppose
> swupd
> will be able to fix that, but I'm not sure.
> 
> It sounds like this bundle creation is completely separated from the
> regular image creation; if so, then I suspect that this may have to
> change.

Right, currently bundle creation happens after image creation and as
above bundles are populated from the rootfs of the bundle images.

You're right, of course, we'll need to construct the running image from
the bundle contents for more complex images.

> > 
> > We took the approach of building images, rather than populating the
> > chroot-like
> > bundle directories with a package manager, because various layers
> > and recipes
> > make changes to the rootfs contents outside of the package manager,
> > particularly
> > with IMAGE_POSTPROCESS_COMMAND, etc.
> Makes sense to me.
> 
> Have you considered generating the file lists more efficiently? I can
> think of some alternatives, but all have downsides.
> 

I did consider a couple of other approaches but with a goal of
submitting this for M3 this approach felt like the surest route within
the time available. I'd certainly like to find a more efficient method
and if you have any suggestions I'd be happy to hear them.

Regards,

Joshua
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/4] Fido pull request

[Joshua G Lock]

On Tue, 2016-02-16 at 14:30 +, Joshua Lock wrote:
> Please consider the following fixes for inclusion in the Fido branch.
> 
> - libpcre security fix not required in jethro or master because the
> newer
>   version they carry isn't affected
> - backport a fix for some memory leaks in rpmresolve
> - backport a fix for kernel.bbclass which already exists in jethro &
> master
> - remove a stray tzdata file, this change isn't required for jethro
> or master as
>   the file isn't present in those branches

I've added two more changes to the branch since Tuesday:

  - libbsd fix for CVE-2016-2090 backported from Jethro
  - glibc fix for CVE-2015-7547 based on the change in Jethro and
master only with the patch from the 2.21 branch of glibc

Regards,

Joshua
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [jethro][PATCH] glibc CVE-2015-7547

[Joshua G Lock]

On Wed, 2016-02-17 at 10:48 -0800, Armin Kuster wrote:
> This is being submitted to comply to Yocto compatability.
> 
> Master is affected but waiting for 2.23 to be merged before sending
> patches.

I plan to backport this to fido as soon as it's on a branch I can
cherry-pick from.

Regards,

Joshua

> 
> Armin Kuster (1):
>   glibc: Security fix CVE-2015-7547
> 
>  meta/recipes-core/glibc/glibc/CVE-2015-7547.patch | 643
> ++
>  meta/recipes-core/glibc/glibc_2.22.bb |   1 +
>  2 files changed, 644 insertions(+)
>  create mode 100644 meta/recipes-core/glibc/glibc/CVE-2015-7547.patch
> 
> -- 
> 2.3.5
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] os-release: remove double-quotes around VERSION_ID value

[Joshua G Lock]

On Fri, 2016-02-12 at 14:15 +0200, Dmitry Rozhkov wrote:
> man 5 os-release states that VERSION_ID is
> 
> "
> a lower-case string (mostly numeric, no spaces or other
> characters outside of 0-9, a-z, ".", "_" and "-")
> identifying the operating system version
> "
> 
> This becomes crucial when ClearLinux's software
> update mechanism is integrated into builds, because
> its client side ignores VERSION_ID's value if it
> doesn't conform the definition.
> 
> Signed-off-by: Dmitry Rozhkov 

I think we probably want this change, but we will also need to change
the default assignment of VERSION_ID to match the rules:

"Variable assignment values must be enclosed in double or single quotes
if they include spaces, semicolons or other special characters outside
of A-Z, a-z, 0-9."

By default VERSION_ID is assigned DISTRO_VERSION, which contains
invalid characters for this field in both OE Core (defaultsetup distro
uses "nodistro.0") and meta-yocto (poky distro uses something like
"2.0+snapshot-${DATE}" during development and something like "1.8.1" on
a release).

Thoughts on changing these?

Regards,

Joshua

> ---
>  meta/recipes-core/os-release/os-release.bb | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-core/os-release/os-release.bb
> b/meta/recipes-core/os-release/os-release.bb
> index df19ca2..1f0df9e 100644
> --- a/meta/recipes-core/os-release/os-release.bb
> +++ b/meta/recipes-core/os-release/os-release.bb
> @@ -29,7 +29,11 @@ python do_compile () {
>  for field in d.getVar('OS_RELEASE_FIELDS', True).split():
>  value = d.getVar(field, True)
>  if value:
> -f.write('{0}="{1}"\n'.format(field, value))
> +if field == "VERSION_ID":
> +format_str = '{0}={1}\n'
> +else:
> +format_str = '{0}="{1}"\n'
> +f.write(format_str.format(field, value))
>  if d.getVar('RPM_SIGN_PACKAGES', True) == '1':
>  rpm_gpg_pubkey = d.getVar('RPM_GPG_PUBKEY', True)
>  bb.utils.mkdirhier('${B}/rpm-gpg')
> -- 
> 2.5.0
> 
> -
> Intel Finland Oy
> Registered Address: PL 281, 00181 Helsinki 
> Business Identity Code: 0357606 - 4 
> Domiciled in Helsinki 
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] os-release: remove double-quotes around VERSION_ID value

[Joshua G Lock]

On Fri, 2016-02-12 at 13:10 +, Richard Purdie wrote:
> On Fri, 2016-02-12 at 12:28 +0000, Joshua G Lock wrote:
> > On Fri, 2016-02-12 at 14:15 +0200, Dmitry Rozhkov wrote:
> > > man 5 os-release states that VERSION_ID is
> > > 
> > > "
> > > a lower-case string (mostly numeric, no spaces or other
> > > characters outside of 0-9, a-z, ".", "_" and "-")
> > > identifying the operating system version
> > > "
> > > 
> > > This becomes crucial when ClearLinux's software
> > > update mechanism is integrated into builds, because
> > > its client side ignores VERSION_ID's value if it
> > > doesn't conform the definition.
> > > 
> > > Signed-off-by: Dmitry Rozhkov <dmitry.rozh...@intel.com>
> > 
> > I think we probably want this change, but we will also need to
> > change
> > the default assignment of VERSION_ID to match the rules:
> > 
> > "Variable assignment values must be enclosed in double or single
> > quotes
> > if they include spaces, semicolons or other special characters
> > outside
> > of A-Z, a-z, 0-9."
> > 
> > By default VERSION_ID is assigned DISTRO_VERSION, which contains
> > invalid characters for this field in both OE Core (defaultsetup
> > distro
> > uses "nodistro.0") and meta-yocto (poky distro uses something like
> > "2.0+snapshot-${DATE}" during development and something like
> > "1.8.1"
> > on
> > a release).
> > 
> > Thoughts on changing these?
> 
> nodistro.0 is ok isn't it?

It is yes, I wasn't paying enough attention earlier.

> 
> We should probably manipulate the string when writing this, "+" -> "-
> "
> and "A-Z" -> "a-z"?

That sounds like a good solution to me.

Regards,

Joshua
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] os-release: remove double-quotes around VERSION_ID value

[Joshua G Lock]

On Fri, 2016-02-12 at 18:14 +0100, Maciej Borzecki wrote:
> > Dnia 12 luty 2016 o 13:15 Dmitry Rozhkov 
> > napisał(a):
> > 
> > This becomes crucial when ClearLinux's software
> > update mechanism is integrated into builds, because
> > its client side ignores VERSION_ID's value if it
> > doesn't conform the definition.
> 
> Is this integration work already published somewhere? I'm interested
> in trying out swupdate with Yocto, but the lack of publicly available
> repo is kind of holding this back (yes, I'm ware of SRPMs).

I'm working on integrating swupd into OE-Core, it's a work in progress
and so far nothing has been published (the work is not yet in a
functional state).

The recipes we are currently using for swupd-server and swupd-client
use the src.rpm's from clearlinux.org

> Do you mind sharing the some details if there is a larger plan for
> getting Clear closer to Yocto/OE?

We have a couple of tickets in the Yocto Project bugzilla[1][2] which
give an overview of the approach I'm taking for this initial
implementation.

The approach is fairly conservative in an attempt to get something
usable integrated that lets us work with the swupd developers to iron
out issues with utilising swupd from within OE.

Regards,

Joshua

1. https://bugzilla.yoctoproject.org/show_bug.cgi?id=9039
2. https://bugzilla.yoctoproject.org/show_bug.cgi?id=9040


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [jethro][fido] libbsd: Secuirty fix CVE-2016-2090

[Joshua G Lock]

On Thu, 2016-02-11 at 16:20 -0800, Armin Kuster wrote:
> From: Armin Kuster 
> 
> CVE-2016-2090 Heap buffer overflow in fgetwln function of libbsd
> 
> affects libbsd <= 0.8.1

and this not needed in master which has 0.8.2.

I plan to take this in fido once it's merged to jethro.

Regards,

Joshua

> 
> Signed-off-by: Armin Kuster 
> ---
>  .../libbsd/files/CVE-2016-2090.patch   | 50
> ++
>  meta/recipes-support/libbsd/libbsd_0.7.0.bb|  4 +-
>  2 files changed, 53 insertions(+), 1 deletion(-)
>  create mode 100644 meta/recipes-support/libbsd/files/CVE-2016-
> 2090.patch
> 
> diff --git a/meta/recipes-support/libbsd/files/CVE-2016-2090.patch
> b/meta/recipes-support/libbsd/files/CVE-2016-2090.patch
> new file mode 100644
> index 000..2eaae13
> --- /dev/null
> +++ b/meta/recipes-support/libbsd/files/CVE-2016-2090.patch
> @@ -0,0 +1,50 @@
> +From c8f0723d2b4520bdd6b9eb7c3e7976de726d7ff7 Mon Sep 17 00:00:00
> 2001
> +From: Hanno Boeck 
> +Date: Wed, 27 Jan 2016 15:10:11 +0100
> +Subject: [PATCH] Fix heap buffer overflow in fgetwln()
> +
> +In the function fgetwln() there's a 4 byte heap overflow.
> +
> +There is a while loop that has this check to see whether there's
> still
> +enough space in the buffer:
> +
> + if (!fb->len || wused > fb->len) {
> +
> +If this is true more memory gets allocated. However this test won't
> be
> +true if wused == fb->len, but at that point wused already points out
> +of the buffer. Some lines later there's a write to the buffer:
> +
> + fb->wbuf[wused++] = wc;
> +
> +This bug was found with the help of address sanitizer.
> +
> +Warned-by: ASAN
> +Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=93881
> +Signed-off-by: Guillem Jover 
> +
> +Upstream-Status: Backport
> +http://cgit.freedesktop.org/libbsd/commit/?id=c8f0723d2b4520bdd6b9eb
> 7c3e7976de726d7ff7
> +
> +CVE: CVE-2016-2090
> +Signed-off-by: Armin Kuster 
> +
> +---
> + src/fgetwln.c | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/src/fgetwln.c b/src/fgetwln.c
> +index 9ee0776..aa3f927 100644
> +--- a/src/fgetwln.c
>  b/src/fgetwln.c
> +@@ -60,7 +60,7 @@ fgetwln(FILE *stream, size_t *lenp)
> + fb->fp = stream;
> + 
> + while ((wc = fgetwc(stream)) != WEOF) {
> +-if (!fb->len || wused > fb->len) {
> ++if (!fb->len || wused >= fb->len) {
> + wchar_t *wp;
> + 
> + if (fb->len)
> +-- 
> +2.3.5
> +
> diff --git a/meta/recipes-support/libbsd/libbsd_0.7.0.bb
> b/meta/recipes-support/libbsd/libbsd_0.7.0.bb
> index 902666d..8d9a708 100644
> --- a/meta/recipes-support/libbsd/libbsd_0.7.0.bb
> +++ b/meta/recipes-support/libbsd/libbsd_0.7.0.bb
> @@ -13,7 +13,9 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=f1530ea92aea
> a1c5e2547cfd43905d8c"
>  SECTION = "libs"
>  DEPENDS = ""
>  
> -SRC_URI = "http://libbsd.freedesktop.org/releases/${BPN}-${PV}.tar.x
> z"
> +SRC_URI = "http://libbsd.freedesktop.org/releases/${BPN}-${PV}.tar.x
> z \
> +   file://CVE-2016-2090.patch \
> +   "
>  
>  SRC_URI[md5sum] = "fcceb4e66fd448ca4ed42ba22a8babb0"
>  SRC_URI[sha256sum] =
> "0f3b0e17e5c34c038126e0a04351b11e23c6101a7d0ce3beeab29bb6415c10bb"
> -- 
> 2.3.5
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [fido][PATCH] libpcre: Security fixes and package update.

[Joshua G Lock]

On Thu, 2016-02-11 at 18:41 -0800, Armin Kuster wrote:
> From: Armin Kuster 
> 
> this is related to [Yocto # 9008]

Thanks, queued in joshuagl/fido next with the addition of the below
comment to the commit message:

"Jethro and master don't require this patch as they have newer libpcre
which contains these fixes."

Regards,

Joshua

> 
> 8.38:
> The following security fixes are included:
> CVE-2015-3210 pcre: heap buffer overflow in
> pcre_compile2()  compile_regex()
> CVE-2015-3217 pcre: stack overflow in match()
> CVE-2015-5073 CVE-2015-8388 pcre: Buffer overflow caused by certain
> patterns with an unmatched closing parenthesis
> CVE-2015-8380 pcre: Heap-based buffer overflow in pcre_exec
> CVE-2015-8381 pcre: Heap Overflow in compile_regex()
> CVE-2015-8383 pcre: Buffer overflow caused by repeated conditional
> group
> CVE-2015-8384 pcre: Buffer overflow caused by recursive back
> reference by name within certain group
> CVE-2015-8385 pcre: Buffer overflow caused by forward reference by
> name to certain group
> CVE-2015-8386 pcre: Buffer overflow caused by lookbehind assertion
> CVE-2015-8387 pcre: Integer overflow in subroutine calls
> CVE-2015-8389 pcre: Infinite recursion in JIT compiler when
> processing certain patterns
> CVE-2015-8390 pcre: Reading from uninitialized memory when processing
> certain patterns
> CVE-2015-8392 pcre: Buffer overflow caused by certain patterns with
> duplicated named groups
> CVE-2015-8393 pcre: Information leak when running pcgrep -q on
> crafted binary
> CVE-2015-8394 pcre: Integer overflow caused by missing check for
> certain conditions
> CVE-2015-8395 pcre: Buffer overflow caused by certain references
> CVE-2016-1283 pcre: Heap buffer overflow in pcre_compile2 causes DoS
> 
> 8.37:
> The following security fixes are included:
> CVE-2014-8964 pcre: incorrect handling of zero-repeat assertion
> conditions
> CVE-2015-2325 pcre: heap buffer overflow in compile_branch()
> CVE-2015-2326 pcre: heap buffer overflow in pcre_compile2()
> 
> LICENSE file changed do to Copyright date updates.
> 
> Signed-off-by: Armin Kuster 
> ---
>  meta/recipes-support/libpcre/{libpcre_8.36.bb => libpcre_8.38.bb} |
> 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
>  rename meta/recipes-support/libpcre/{libpcre_8.36.bb =>
> libpcre_8.38.bb} (91%)
> 
> diff --git a/meta/recipes-support/libpcre/libpcre_8.36.bb
> b/meta/recipes-support/libpcre/libpcre_8.38.bb
> similarity index 91%
> rename from meta/recipes-support/libpcre/libpcre_8.36.bb
> rename to meta/recipes-support/libpcre/libpcre_8.38.bb
> index a4b7f6d..6ef5d70 100644
> --- a/meta/recipes-support/libpcre/libpcre_8.36.bb
> +++ b/meta/recipes-support/libpcre/libpcre_8.38.bb
> @@ -6,16 +6,15 @@ SUMMARY = "Perl Compatible Regular Expressions"
>  HOMEPAGE = "http://www.pcre.org;
>  SECTION = "devel"
>  LICENSE = "BSD"
> -LIC_FILES_CHKSUM =
> "file://LICENCE;md5=ded617e975f28e15952dc68b84a7ac1a"
> +LIC_FILES_CHKSUM =
> "file://LICENCE;md5=7e4937814aee14758c1c95b59c80c44d"
>  SRC_URI = "${SOURCEFORGE_MIRROR}/project/pcre/pcre/${PV}/pcre-
> ${PV}.tar.bz2 \
> file://pcre-cross.patch \
> file://fix-pcre-name-collision.patch \
> file://run-ptest \
> file://Makefile \
>  "
> -
> -SRC_URI[md5sum] = "b767bc9af0c20bc9c1fe403b0d41ad97"
> -SRC_URI[sha256sum] =
> "ef833457de0c40e82f573e34528f43a751ff20257ad0e86d272ed5637eb845bb"
> +SRC_URI[md5sum] = "00aabbfe56d5a48b270f999b508c5ad2"
> +SRC_URI[sha256sum] =
> "b9e02d36e23024d6c02a2e5b25204b3a4fa6ade43e0a5f869f254f49535079df"
>  
>  S = "${WORKDIR}/pcre-${PV}"
>  
> -- 
> 2.3.5
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] udhcpc: specify full path for ip command calls

[Joshua G Lock]

On Tue, 2016-02-09 at 12:20 +, Mark O'Donovan wrote:
> Running with a restricted environment (e.g. cron) was causing
> issues as we check for the ip command with full path and call
> without full path

This change should probably change the /sbin/ path in the script to a
symbol and use sed to replace it with the expansion of ${sbindir}
rather than hard-coding a path which isn't always correct.

Regards,

Joshua

> ---
>  meta/recipes-core/busybox/files/simple.script | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/meta/recipes-core/busybox/files/simple.script
> b/meta/recipes-core/busybox/files/simple.script
> index 22168b0..e233c3c 100644
> --- a/meta/recipes-core/busybox/files/simple.script
> +++ b/meta/recipes-core/busybox/files/simple.script
> @@ -28,8 +28,8 @@ case "$1" in
>   fi
>   if ! root_is_nfs ; then
>  if [ $have_bin_ip -eq 1 ]; then
> -ip addr flush dev $interface
> -ip link set dev $interface up
> +/sbin/ip addr flush dev $interface
> +/sbin/ip link set dev $interface up
>  else
>  /sbin/ifconfig $interface 0.0.0.0
>  fi
> @@ -38,7 +38,7 @@ case "$1" in
>  
>   renew|bound)
>  if [ $have_bin_ip -eq 1 ]; then
> -ip addr add dev $interface local $ip/$mask
> $BROADCAST
> +/sbin/ip addr add dev $interface local
> $ip/$mask $BROADCAST
>  else
>  /sbin/ifconfig $interface $ip $BROADCAST
> $NETMASK
>  fi
> @@ -59,7 +59,7 @@ case "$1" in
>   metric=10
>   for i in $router ; do
>  if [ $have_bin_ip -eq 1 ]; then
> -ip route add default via $i
> metric $metric
> +/sbin/ip route add default
> via $i metric $metric
>  else
>  route add default gw $i dev
> $interface metric $metric 2>/dev/null
>  fi
> -- 
> 1.9.1
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Stable branch rules [Was: Re: [PATCH][jethro] glibc-locale: fix QA warning]

[Joshua G Lock]

On Tue, 2016-02-09 at 09:50 -0500, Philip Balister wrote:
> On 02/08/2016 10:22 AM, Joshua G Lock wrote:
> > On Sun, 2016-02-07 at 22:43 +, Richard Purdie wrote:
> > > On Sun, 2016-01-31 at 11:55 -0800, Armin Kuster wrote:
> > > > From: Armin Kuster <akus...@mvista.com>
> > > > 
> > > > WARNING: QA Issue: glibc-locale: /glibc-binary-localedata-sd
> > > > -in/usr/lib/locale/sd_IN/LC_CTYPE is owned by uid 1000, which
> > > > is
> > > > the
> > > > same as the user running bitbake. This may be due to host
> > > > contamination [host-user-contaminated]
> > > > 
> > > > fix type
> > > > Signed-off-by: Armin Kuster <akus...@mvista.com>
> > > > ---
> > > >  meta/recipes-core/glibc/glibc-locale.inc | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > Enough is enough.
> > > 
> > > I cannot tell whether these patches are in master or not or
> > > whether
> > > master needs them or not. Master needs this one, its not in
> > > master,
> > > its
> > > only being proposed for jethro. Its a mess.
> > > 
> > > I am therefore not taking any more stable branch patches at all
> > > until
> > > we amend the stable branch rules to state that pull requests and
> > > patches clearly state which branches need a fix, or clearly state
> > > why
> > > they don't.
> > 
> > I made an attempt at starting to documenting that requirement:
> > https://wiki.yoctoproject.org/wiki/index.php?title=Stable_branch_ma
> > inte
> > nance=17480=17028
> > 
> > 'Patches' welcome.
> 
> Does this belong on the Yocto Project or OpenEmbedded wikis? Hunting
> both is getting annoying.

I edited the guidelines where they currently exist. I'll be more than
happy to move this to the OE wiki, but I'd rather do that once we have
something that people can agree.

Regards,

Joshua
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][fido] tzdata: remove 2015d version

[Joshua G Lock]

On Tue, 2016-02-09 at 15:54 +0100, Martin Jansa wrote:
> * this is left-over from upgrade to 2016a
> 
> * it's safer to remove so that .bbappends in other layers really
> apply to version
>   used in build (currently we have bbappend for 2015d and build will
> use 2016a
>   without any warning
> 
> * the same problem was reported with 2015f upgrade:
>   http://lists.openembedded.org/pipermail/openembedded-core/2015-
> August/109708.html

Thanks, I've pushed this change to my joshuagl/fido-next branch.

http://cgit.openembedded.org/openembedded-core-
contrib/log/?h=joshuagl/fido-next

Regards,

Joshua

> 
> Signed-off-by: Martin Jansa 
> ---
>  meta/recipes-extended/tzdata/tzdata_2015d.bb | 6 --
>  1 file changed, 6 deletions(-)
>  delete mode 100644 meta/recipes-extended/tzdata/tzdata_2015d.bb
> 
> diff --git a/meta/recipes-extended/tzdata/tzdata_2015d.bb
> b/meta/recipes-extended/tzdata/tzdata_2015d.bb
> deleted file mode 100644
> index d8e5f24..000
> --- a/meta/recipes-extended/tzdata/tzdata_2015d.bb
> +++ /dev/null
> @@ -1,6 +0,0 @@
> -SRC_URI = "ftp://ftp.iana.org/tz/releases/tzdata${PV}.tar.gz;name=tz
> data"
> -
> -SRC_URI[tzdata.md5sum] = "b595bdc4474b8fc1a15cffc67c66025b"
> -SRC_URI[tzdata.sha256sum] =
> "8b9f5008277f09e251e97dba7813f56168d691115bda90ade4638d72f296d531"
> -
> -require tzdata.inc
> -- 
> 2.7.0
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 00/21][Fido v3] pull request

[Joshua G Lock]

On Sat, 2016-02-06 at 15:14 -0800, Armin Kuster wrote:
> From: Armin Kuster 
> 
> forgot to append a change to bind recipe.
> 
> This includes a miss fire on the glibc request plus many others.
> This supersedes the last tow fido pull request

I've included those which weren't already present in my joshuagl/fido-
next branch.

Per Richard's request we need to document which patches are and aren't
applicable to Jethro/master and why. Can I help with that?

Regards,

Joshua
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Stable branch rules [Was: Re: [PATCH][jethro] glibc-locale: fix QA warning]

[Joshua G Lock]

On Sun, 2016-02-07 at 22:43 +, Richard Purdie wrote:
> On Sun, 2016-01-31 at 11:55 -0800, Armin Kuster wrote:
> > From: Armin Kuster 
> > 
> > WARNING: QA Issue: glibc-locale: /glibc-binary-localedata-sd
> > -in/usr/lib/locale/sd_IN/LC_CTYPE is owned by uid 1000, which is
> > the
> > same as the user running bitbake. This may be due to host
> > contamination [host-user-contaminated]
> > 
> > fix type
> > Signed-off-by: Armin Kuster 
> > ---
> >  meta/recipes-core/glibc/glibc-locale.inc | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Enough is enough.
> 
> I cannot tell whether these patches are in master or not or whether
> master needs them or not. Master needs this one, its not in master,
> its
> only being proposed for jethro. Its a mess.
> 
> I am therefore not taking any more stable branch patches at all until
> we amend the stable branch rules to state that pull requests and
> patches clearly state which branches need a fix, or clearly state why
> they don't.

I made an attempt at starting to documenting that requirement:
https://wiki.yoctoproject.org/wiki/index.php?title=Stable_branch_mainte
nance=17480=17028

'Patches' welcome.

Regards,

Joshua
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] glib-2.0: use the system libpcre

[Joshua G Lock]

On Fri, 2016-02-05 at 11:47 +, Ross Burton wrote:
> Instead of using the internal copy of libpcre, use one that we
> build.  Note that
> this requires libpcre enables Unicode properties.

We could do with a convention for documenting this kind of trap (where
a PACKAGECONFIG in foo requires one in bar). 

Maybe you could a comment here in this case?

Regards,

Joshua

> 
> Signed-off-by: Ross Burton 
> ---
>  meta/recipes-core/glib-2.0/glib.inc | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/meta/recipes-core/glib-2.0/glib.inc b/meta/recipes-
> core/glib-2.0/glib.inc
> index dc88d19..7a6a4ce 100644
> --- a/meta/recipes-core/glib-2.0/glib.inc
> +++ b/meta/recipes-core/glib-2.0/glib.inc
> @@ -31,6 +31,9 @@ inherit autotools gettext gtk-doc pkgconfig ptest-
> gnome upstream-version-is-even
>  
>  S = "${WORKDIR}/glib-${PV}"
>  
> +PACKAGECONFIG ??= "system-pcre"
> +PACKAGECONFIG[system-pcre] = "--with-pcre=system,--with-
> pcre=internal,libpcre"
> +
>  CORECONF = "--disable-dtrace --disable-fam --disable-libelf --
> disable-systemtap --disable-man"
>  
>  PRINTF = "--enable-included-printf=no"
> -- 
> 2.7.0
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 00/16][Fido] Consolidated pull

[Joshua G Lock]

On Mon, 2016-01-18 at 09:18 +, Joshua Lock wrote:
> The following changes since commit
> 3f2701c102e4e5b95fc79a8d967f9c48f8232fc6:
> 
>   grub2: Fix CVE-2015-8370 (2016-01-11 11:10:11 +)
> 
> are available in the git repository at:
> 
>   git://git.openembedded.org/openembedded-core-contrib joshuagl/fido-
> next
>   http://cgit.openembedded.org/cgit.cgi/openembedded-core-
> contrib/log/?h=joshuagl/fido-next

I just pushed another patch from Armin to this same branch which adds
security fixes to OpenSSH for CVE-2016-0777 and CVE-2016-0778.

Regards,

Joshua

> 
> Armin Kuster (13):
>   openssl: fix for CVE-2015-3193
>   openssl: fix for CVE-2015-3194
>   openssl: fix for CVE-2015-3195
>   libxml2: security fix CVE-2015-7941
>   libxml2: security fix CVE-2015-8317
>   libxml2: security fix CVE-2015-7942
>   libxml2: security fix CVE-2015-8035
>   libxml2: security fix CVE-2015-7498
>   libxml2: security fix CVE-2015-7497
>   libxml2: security fix CVE-2015-7499
>   libxml2: security fix CVE-2015-7500
>   libxml2: security fix CVE-2015-8242
>   libxml2: security fix CVE-2015-5312

    openssh: CVE-2016-077x

> 
> Hongxu Jia (1):
>   logrotate: do not move binary logrotate to /usr/bin
> 
> Joshua Lock (1):
>   libxml2: remove files for easier maintenance
> 
> Martin Jansa (1):
>   texinfo: don't create dependency on INHERIT variable
> 
>  .../openssl/0001-Add-test-for-CVE-2015-3194.patch  |  66 ++
>  ...64-mont5.pl-fix-carry-propagating-bug-CVE.patch | 101
> +++
>  .../CVE-2015-3194-1-Add-PSS-parameter-check.patch  |  45 +++
>  ...CVE-2015-3195-Fix-leak-with-ASN.1-combine.patch |  66 ++
>  .../recipes-connectivity/openssl/openssl_1.0.2d.bb |   4 +
>  meta/recipes-core/libxml/libxml2.inc   |  16 ++-
>  ...-2015-5312-Another-entity-expansion-issue.patch |  39 ++
>  ...97-Avoid-an-heap-buffer-overflow-in-xmlDi.patch |  40 ++
>  ...00-Fix-memory-access-error-due-to-incorre.patch | 131
> +++
>  ...015-8035-Fix-XZ-compression-support-loop.patch} |   9 +-
>  ...42-Buffer-overead-with-HTML-parser-in-pus.patch |  49 
>  ...n-name-parsing-at-the-end-of-current-inpu.patch | 138
> +
>  ...ssing-entities-after-encoding-conversion-.patch |  89
> +
>  ...99-1-Add-xmlHaltParser-to-stop-the-parser.patch |  88
> +
>  ...VE-2015-7499-2-Detect-incoherency-on-GROW.patch |  43 +++
>  ...top-parsing-on-entities-boundaries-errors.patch |  39 ++
>  ...eanup-conditional-section-error-handling.patch} |  25 ++--
>  ...ror-in-previous-Conditional-section-patch.patch |  35 ++
>  ...iation-of-overflow-in-Conditional-section.patch |  39 ++
>  ...ng-early-on-if-encoding-conversion-failed.patch |  42 +++
>  meta/recipes-extended/logrotate/logrotate_3.8.8.bb |   2 +-
>  meta/recipes-extended/texinfo/texinfo_5.2.bb   |   2 +-
>  22 files changed, 1086 insertions(+), 22 deletions(-)
>  create mode 100644 meta/recipes-connectivity/openssl/openssl/0001-
> Add-test-for-CVE-2015-3194.patch
>  create mode 100644 meta/recipes-connectivity/openssl/openssl/CVE-
> 2015-3193-bn-asm-x86_64-mont5.pl-fix-carry-propagating-bug-CVE.patch
>  create mode 100644 meta/recipes-connectivity/openssl/openssl/CVE-
> 2015-3194-1-Add-PSS-parameter-check.patch
>  create mode 100644 meta/recipes-connectivity/openssl/openssl/CVE-
> 2015-3195-Fix-leak-with-ASN.1-combine.patch
>  create mode 100644 meta/recipes-core/libxml/libxml2/0001-CVE-2015-
> 5312-Another-entity-expansion-issue.patch
>  create mode 100644 meta/recipes-core/libxml/libxml2/0001-CVE-2015-
> 7497-Avoid-an-heap-buffer-overflow-in-xmlDi.patch
>  create mode 100644 meta/recipes-core/libxml/libxml2/0001-CVE-2015-
> 7500-Fix-memory-access-error-due-to-incorre.patch
>  rename meta/recipes-core/libxml/libxml2/{CVE-2015-8035.patch =>
> 0001-CVE-2015-8035-Fix-XZ-compression-support-loop.patch} (83%)
>  create mode 100644 meta/recipes-core/libxml/libxml2/0001-CVE-2015-
> 8242-Buffer-overead-with-HTML-parser-in-pus.patch
>  create mode 100644 meta/recipes-core/libxml/libxml2/0001-Fix-a-bug-
> on-name-parsing-at-the-end-of-current-inpu.patch
>  create mode 100644 meta/recipes-core/libxml/libxml2/CVE-2015-7498-
> Avoid-processing-entities-after-encoding-conversion-.patch
>  create mode 100644 meta/recipes-core/libxml/libxml2/CVE-2015-7499-1-
> Add-xmlHaltParser-to-stop-the-parser.patch
>  create mode 100644 meta/recipes-core/libxml/libxml2/CVE-2015-7499-2-
> Detect-incoherency-on-GROW.patch
>  create mode 100644 meta/recipes-core/libxml/libxml2/CVE-2015-7941-1-
> Stop-parsing-on-entities-boundaries-errors.patch
>  rename meta/recipes-core/libxml/libxml2/{CVE-2015-7942.patch => CVE-
> 2015-7941-2-Cleanup-conditional-section-error-handling.patch} (68%)
>  create mode 100644 meta/recipes-core/libxml/libxml2/CVE-2015-7942-2-
> Fix-an-error-in-previous-Conditional-section-patch.patch
>  create mode 100644 meta/recipes-core/libxml/libxml2/CVE-2015-7942-
> 

Re: [OE-core] [PATCH][fido] openssh: CVE-2016-077x

[Joshua G Lock]

On Sun, 2016-01-17 at 21:26 -0800, Armin Kuster wrote:
> From: Armin Kuster 
> 
> this address two CVE's.
> CVE-2016-0777 and CVE-2016-0778

Thank you, this is pushed to my joshuagl/fido-next branch.

Regards,

Joshua

> 
> Signed-off-by: Armin Kuster 
> ---
>  .../openssh/openssh/CVE-2016-077x.patch| 56
> ++
>  meta/recipes-connectivity/openssh/openssh_6.7p1.bb |  1 +
>  2 files changed, 57 insertions(+)
>  create mode 100644 meta/recipes-connectivity/openssh/openssh/CVE-
> 2016-077x.patch
> 
> diff --git a/meta/recipes-connectivity/openssh/openssh/CVE-2016-
> 077x.patch b/meta/recipes-connectivity/openssh/openssh/CVE-2016-
> 077x.patch
> new file mode 100644
> index 000..4cc462d
> --- /dev/null
> +++ b/meta/recipes-connectivity/openssh/openssh/CVE-2016-077x.patch
> @@ -0,0 +1,56 @@
> +From e6c85f8889c5c9eb04796fdb76d2807636b9eef5 Mon Sep 17 00:00:00
> 2001
> +From: Damien Miller 
> +Date: Fri, 15 Jan 2016 01:30:36 +1100
> +Subject: [PATCH] forcibly disable roaming support in the client
> +
> +
> +Upstream-Status: Backport
> +CVE: CVE-2016-0777
> +CVE: CVE-2016-0778
> +
> +[Yocto #8935]
> +
> +Signed-off-by: Armin Kuster 
> +
> +---
> + readconf.c | 5 ++---
> + ssh.c  | 3 ---
> + 2 files changed, 2 insertions(+), 6 deletions(-)
> +
> +Index: openssh-6.7p1/readconf.c
> +===
> +--- openssh-6.7p1.orig/readconf.c
>  openssh-6.7p1/readconf.c
> +@@ -1597,7 +1597,7 @@ initialize_options(Options * options)
> + options->tun_remote = -1;
> + options->local_command = NULL;
> + options->permit_local_command = -1;
> +-options->use_roaming = -1;
> ++options->use_roaming = 0;
> + options->visual_host_key = -1;
> + options->ip_qos_interactive = -1;
> + options->ip_qos_bulk = -1;
> +@@ -1768,8 +1768,7 @@ fill_default_options(Options * options)
> + options->tun_remote = SSH_TUNID_ANY;
> + if (options->permit_local_command == -1)
> + options->permit_local_command = 0;
> +-if (options->use_roaming == -1)
> +-options->use_roaming = 1;
> ++options->use_roaming = 0;
> + if (options->visual_host_key == -1)
> + options->visual_host_key = 0;
> + if (options->ip_qos_interactive == -1)
> +Index: openssh-6.7p1/ssh.c
> +===
> +--- openssh-6.7p1.orig/ssh.c
>  openssh-6.7p1/ssh.c
> +@@ -1800,9 +1800,6 @@ ssh_session2(void)
> + fork_postauth();
> + }
> + 
> +-if (options.use_roaming)
> +-request_roaming();
> +-
> + return client_loop(tty_flag, tty_flag ?
> + options.escape_char : SSH_ESCAPECHAR_NONE, id);
> + }
> diff --git a/meta/recipes-connectivity/openssh/openssh_6.7p1.bb
> b/meta/recipes-connectivity/openssh/openssh_6.7p1.bb
> index 9246284..700bf7f 100644
> --- a/meta/recipes-connectivity/openssh/openssh_6.7p1.bb
> +++ b/meta/recipes-connectivity/openssh/openssh_6.7p1.bb
> @@ -26,6 +26,7 @@ SRC_URI = "ftp://ftp.openbsd.org/pub/OpenBSD/OpenSS
> H/portable/openssh-${PV}.tar.
> file://CVE-2015-6564.patch \
> file://CVE-2015-6565.patch \
> file://CVE-2015-5600.patch \
> +   file://CVE-2016-077x.patch \
> "
>  
>  PAM_SRC_URI = "file://sshd"
> -- 
> 1.9.1
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 00/13] Jethro, Fido openssl and libxml security fixes vi git

[Joshua G Lock]

On Tue, 2016-01-12 at 15:25 -0800, Armin Kuster wrote:
> changes in contrib branch for alt integration.
> 
> The following changes since commit
> 0073b234d793099a371b2e529f740987decce756:
> 
>   yocto-bsp: Typo on the file extension (2016-01-07 12:13:55 +)
> 
> are available in the git repository at:
> 

Thanks very much for these Armin. I've included them in my
joshugal/fido-next branch and intend to submit that for merge soon.

Regards,

Joshua

>   git://git.yoctoproject.org/poky-contrib akuster/jethro_sec_fixes
>   http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akuster/je
> thro_sec_fixes
> 
> Armin Kuster (13):
>   openssl: fix for CVE-2015-3193
>   openssl: fix for CVE-2015-3194
>   openssl: fix for CVE-2015-3195
>   libxml2: security fix CVE-2015-7941
>   libxml2: security fix CVE-2015-8317
>   libxml2: security fix CVE-2015-7942
>   libxml2: security fix CVE-2015-8035
>   libxml2: security fix CVE-2015-7498
>   libxml2: security fix CVE-2015-7497
>   libxml2: security fix CVE-2015-7499
>   libxml2: security fix CVE-2015-7500
>   libxml2: security fix CVE-2015-8242
>   libxml2: security fix CVE-2015-5312
> 
>  .../openssl/0001-Add-test-for-CVE-2015-3194.patch  |  66 ++
>  ...64-mont5.pl-fix-carry-propagating-bug-CVE.patch | 101
> +++
>  .../CVE-2015-3194-1-Add-PSS-parameter-check.patch  |  45 +++
>  ...CVE-2015-3195-Fix-leak-with-ASN.1-combine.patch |  66 ++
>  .../recipes-connectivity/openssl/openssl_1.0.2d.bb |   4 +
>  meta/recipes-core/libxml/libxml2.inc   |  14 +++
>  ...-2015-5312-Another-entity-expansion-issue.patch |  39 ++
>  ...97-Avoid-an-heap-buffer-overflow-in-xmlDi.patch |  40 ++
>  ...00-Fix-memory-access-error-due-to-incorre.patch | 131
> +++
>  ...2015-8035-Fix-XZ-compression-support-loop.patch |  38 ++
>  ...42-Buffer-overead-with-HTML-parser-in-pus.patch |  49 
>  ...n-name-parsing-at-the-end-of-current-inpu.patch | 138
> +
>  ...ssing-entities-after-encoding-conversion-.patch |  89
> +
>  ...99-1-Add-xmlHaltParser-to-stop-the-parser.patch |  88
> +
>  ...VE-2015-7499-2-Detect-incoherency-on-GROW.patch |  43 +++
>  ...top-parsing-on-entities-boundaries-errors.patch |  39 ++
>  ...leanup-conditional-section-error-handling.patch |  56 +
>  ...ror-in-previous-Conditional-section-patch.patch |  35 ++
>  ...iation-of-overflow-in-Conditional-section.patch |  39 ++
>  ...ng-early-on-if-encoding-conversion-failed.patch |  42 +++
>  20 files changed, 1162 insertions(+)
>  create mode 100644 meta/recipes-connectivity/openssl/openssl/0001-
> Add-test-for-CVE-2015-3194.patch
>  create mode 100644 meta/recipes-connectivity/openssl/openssl/CVE-
> 2015-3193-bn-asm-x86_64-mont5.pl-fix-carry-propagating-bug-CVE.patch
>  create mode 100644 meta/recipes-connectivity/openssl/openssl/CVE-
> 2015-3194-1-Add-PSS-parameter-check.patch
>  create mode 100644 meta/recipes-connectivity/openssl/openssl/CVE-
> 2015-3195-Fix-leak-with-ASN.1-combine.patch
>  create mode 100644 meta/recipes-core/libxml/libxml2/0001-CVE-2015-
> 5312-Another-entity-expansion-issue.patch
>  create mode 100644 meta/recipes-core/libxml/libxml2/0001-CVE-2015-
> 7497-Avoid-an-heap-buffer-overflow-in-xmlDi.patch
>  create mode 100644 meta/recipes-core/libxml/libxml2/0001-CVE-2015-
> 7500-Fix-memory-access-error-due-to-incorre.patch
>  create mode 100644 meta/recipes-core/libxml/libxml2/0001-CVE-2015-
> 8035-Fix-XZ-compression-support-loop.patch
>  create mode 100644 meta/recipes-core/libxml/libxml2/0001-CVE-2015-
> 8242-Buffer-overead-with-HTML-parser-in-pus.patch
>  create mode 100644 meta/recipes-core/libxml/libxml2/0001-Fix-a-bug-
> on-name-parsing-at-the-end-of-current-inpu.patch
>  create mode 100644 meta/recipes-core/libxml/libxml2/CVE-2015-7498-
> Avoid-processing-entities-after-encoding-conversion-.patch
>  create mode 100644 meta/recipes-core/libxml/libxml2/CVE-2015-7499-1-
> Add-xmlHaltParser-to-stop-the-parser.patch
>  create mode 100644 meta/recipes-core/libxml/libxml2/CVE-2015-7499-2-
> Detect-incoherency-on-GROW.patch
>  create mode 100644 meta/recipes-core/libxml/libxml2/CVE-2015-7941-1-
> Stop-parsing-on-entities-boundaries-errors.patch
>  create mode 100644 meta/recipes-core/libxml/libxml2/CVE-2015-7941-2-
> Cleanup-conditional-section-error-handling.patch
>  create mode 100644 meta/recipes-core/libxml/libxml2/CVE-2015-7942-2-
> Fix-an-error-in-previous-Conditional-section-patch.patch
>  create mode 100644 meta/recipes-core/libxml/libxml2/CVE-2015-7942-
> Another-variation-of-overflow-in-Conditional-section.patch
>  create mode 100644 meta/recipes-core/libxml/libxml2/CVE-2015-8317-
> Fail-parsing-early-on-if-encoding-conversion-failed.patch
> 
> -- 
> 2.3.5
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][fido][RESEND 4/5] texinfo: don't create dependency on INHERIT variable

[Joshua G Lock]

On Fri, 2016-01-15 at 14:41 +0100, Martin Jansa wrote:
> On Thu, Dec 10, 2015 at 02:48:20PM +0100, Martin Jansa wrote:
> > * we don't want the do_package signature depending on INHERIT
> > variable
> > * e.g. just adding the own-mirrors causes texinfo to rebuild:
> >   # bitbake-diffsigs BUILD/sstate-diff/*/*/texinfo/*do_package.sig*
> >   basehash changed from 015df2fd8e396cc1e15622dbac843301 to
> > 9f1d06c4f238c70a99ccb6d8da348b6a
> >   Variable INHERIT value changed from
> >   ' rm_work blacklist blacklist report-error ${PACKAGE_CLASSES}
> > ${USER_CLASSES} ${INHERIT_DISTRO} ${INHERIT_BLACKLIST} sanity'
> >   to
> >   ' rm_work own-mirrors blacklist blacklist report-error
> > ${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO}
> > ${INHERIT_BLACKLIST} sanity'
> 
> Joshua,
> 
> why this one didn't make it to your fido update?

(For the benefit of the list and with apologies to Martin for the spam)

Apologies, that wasn't an intentional omission. I've pushed it to my
joshuagl/fido-next branch and will include it in the next merge request
(hopefully today).

Regards,

Joshua
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core