[OE-core] [PATCH] cve-check: allow filtering out patched issues

2019-02-14 Thread Dan Dedrick
It can be useful to filter out patched issues since they are no longer
vulnerable. This makes it easier to sift through what CVEs still might
need to be fixed.

Signed-off-by: Dan Dedrick 
---
 meta/classes/cve-check.bbclass | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index 743bc08a4f..a486d686ae 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -35,6 +35,7 @@ CVE_CHECK_DIR ??= "${DEPLOY_DIR}/cve"
 CVE_CHECK_MANIFEST ?= 
"${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.cve"
 CVE_CHECK_COPY_FILES ??= "1"
 CVE_CHECK_CREATE_MANIFEST ??= "1"
+CVE_CHECK_EXCLUDE_PATCHED ??= "0"
 
 # Whitelist for packages (PN)
 CVE_CHECK_PN_WHITELIST = "\
@@ -54,6 +55,8 @@ python do_cve_check () {
 if os.path.exists(d.getVar("CVE_CHECK_TMP_FILE")):
 patched_cves = get_patches_cves(d)
 patched, unpatched = check_cves(d, patched_cves)
+if d.getVar("CVE_CHECK_EXCLUDE_PATCHED") == "1":
+patched = []
 if patched or unpatched:
 cve_data = get_cve_info(d, patched + unpatched)
 cve_write_data(d, patched, unpatched, cve_data)
-- 
2.20.1

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


[OE-core] [PATCH] devtool: improve git repo checks before check_commits logic

2019-01-21 Thread Dan Dedrick
The check_commits logic assumes that both devtool-base and args.branch
exist in the git repo that it is operating on. In order to prevent
errors at that point it's best to first ensure that both of these refs
actually exist. If they don't both exist then the check_commits logic
should just be skipped, as it would be if the repo wasn't originally
checked out by devtool.

Previously if a user removed the args.branch branch from their devtool
cloned repo this code would crash on adding the repo with -n. The crash
would look like this:

Traceback (most recent call last):
  File "/home/ddedrick/src/poky/scripts/devtool", line 344, in 
ret = main()
  File "/home/ddedrick/src/poky/scripts/devtool", line 331, in main
ret = args.func(args, config, basepath, workspace)
  File "/home/ddedrick/src/poky/scripts/lib/devtool/standard.py", line 812, in 
modify
(stdout, _) = bb.process.run('git log devtool-base..%s' % branch, 
cwd=srctree)
  File "/home/ddedrick/src/poky/bitbake/lib/bb/process.py", line 178, in run
raise ExecutionError(cmd, pipe.returncode, stdout, stderr)
bb.process.ExecutionError: Execution of 'git log devtool-base..devtool' failed 
with exit code 128:
fatal: ambiguous argument 'devtool-base..devtool': unknown revision or path not 
in the working tree.
Use '--' to separate paths from revisions, like this:
'git  [...] -- [...]'
---
 scripts/lib/devtool/standard.py | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
index d14b7a6543..328b5cf02e 100644
--- a/scripts/lib/devtool/standard.py
+++ b/scripts/lib/devtool/standard.py
@@ -769,9 +769,13 @@ def modify(args, config, basepath, workspace):
 check_commits = True
 else:
 if os.path.exists(os.path.join(srctree, '.git')):
-# Check if it's a tree previously extracted by us
+# Check if it's a tree previously extracted by us. This is done
+# by ensuring that devtool-base and args.branch (devtool) 
exist.
+# The check_commits logic will cause an exception if either one
+# of these doesn't exist
 try:
 (stdout, _) = bb.process.run('git branch --contains 
devtool-base', cwd=srctree)
+bb.process.run('git rev-parse %s' % args.branch, 
cwd=srctree)
 except bb.process.ExecutionError:
 stdout = ''
 if stdout:
-- 
2.20.1

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


[OE-core] [PATCH] devtool: remove duplicate overrides

2019-01-21 Thread Dan Dedrick
DEVTOOL_EXTRA_OVERRIDES only needs one entry for each instance of
overrides. Previous to these changes it would find every override to
SRC_URI and add it to the list. This would duplicate instances where
SRC_URI is modified multiple times with the same override like:
SRC_URI_append_foo += "file://0001-foo.patch"
SRC_URI_append_foo += "file://0002-bar.patch"

A bbappend might also overwrite a SRC_URI override, which would also
cause multiple instances to occur.

When there are multiple instances of the same override in
DEVTOOL_EXTRA_OVERRIDES it causes devtool modify to fail when creating
override branches. The failure occurs when attempting to create the same
override branch a second time and looks like this:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
 0001:
 *** 0002:devtool_post_patch(d)
 0003:
File: '/build/poky/meta/classes/devtool-source.bbclass', lineno: 202, function: 
devtool_post_patch
 0198:
 0199:for override in extra_override_list:
 0200:localdata = bb.data.createCopy(d)
 0201:if override in default_overrides:
 *** 0202:bb.process.run('git branch devtool-override-%s %s' % 
(override, devbranch), cwd=srcsubdir)
 0203:else:
 0204:# Reset back to the initial commit on a new branch
 0205:bb.process.run('git checkout %s -b 
devtool-override-%s' % (initial_rev, override), cwd=srcsubdir)
 0206:# Run do_patch function with the override applied
File: '/build/poky/bitbake/lib/bb/process.py', lineno: 178, function: run
 0174:if not stderr is None:
 0175:stderr = stderr.decode("utf-8")
 0176:
 0177:if pipe.returncode != 0:
 *** 0178:raise ExecutionError(cmd, pipe.returncode, stdout, stderr)
 0179:return stdout, stderr
Exception: bb.process.ExecutionError: Execution of 'git branch 
devtool-override-foo devtool' failed with exit code 128:
fatal: A branch named 'devtool-override-foo' already exists.

Signed-off-by: Dan Dedrick 
---
 scripts/lib/devtool/standard.py | 5 +
 1 file changed, 5 insertions(+)

diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
index d14b7a6543..a45ad36812 100644
--- a/scripts/lib/devtool/standard.py
+++ b/scripts/lib/devtool/standard.py
@@ -509,6 +509,11 @@ def _extract_source(srctree, keep_temp, devbranch, sync, 
config, basepath, works
 if not 'flag' in event:
 if event['op'].startswith(('_append[', '_prepend[')):
 
extra_overrides.append(event['op'].split('[')[1].split(']')[0])
+# We want to remove duplicate overrides. If a recipe had multiple
+# SRC_URI_override += values it would cause mulitple instances of
+# overrides. This doesn't play nicely with things like creating a
+# branch for every instance of DEVTOOL_EXTRA_OVERRIDES.
+extra_overrides = list(set(extra_overrides))
 if extra_overrides:
 logger.info('SRC_URI contains some conditional appends/prepends - 
will create branches to represent these')
 
-- 
2.20.1

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


Re: [OE-core] [PATCH 1/7] allarch: only enable allarch when multilib is not used

2019-01-17 Thread Dan Dedrick
I'm resurrecting this thread because this change negatively affects our use
of multilib. The use case that this is fixing seems to be a a case that
would be a better fit for multiconfig than it would multilib. My
interpretation of the use cases of multilib and multiconfig is as follows
and someone can correct me if this is wrong.

Multilib allows images to be built that support multiple architectures on
the same image. Specifically this use case is interesting for cases where
some library or tool has to be 32-bit (for whatever reason might apply) but
the rest of the image is 64-bit. For example we have a 32-bit library from
a third party vendor and that vendor won't provide us with a 64-bit
version. So we want the majority of our system to be 64-bit but need
multilib to support the subset of our image that needs to be 32-bit. The
result is that some portion of our image has to be 32-bit but whenever
possible we'd like to be using the 64-bit packages to reduce duplicating
packages between 32 and 64 bit.

Multiconfig allows for multiple configs and seems well suited to cases
where there are separate images for each config. So you could have a 32-bit
image from one config and a 64-bit image from another config. If no image
cross-contamination is required, as seems to be the intent of the request
here, then multiconfig can ensure that while not reducing the usefulness of
allarch. The original scenario seemed to follow this pattern where there is
a lib32-core-image-sato and a core-image-sato.

In our multilib case we want the behavior from before this change. So in
the specific use case of 'lib32-curl -> ca-certificate -> openssl' we
actually want this. The reason behind this being the desired behavior is
that the main architecture would certainly already require openssl so
adding the 32-bit version would cause duplication and therefore increase
our images size unnecessarily. In the past we had actually found that
installing some duplicate things that overlapped like "/usr/bin/openssl"
would cause racey behavior where sometimes we got the 32-bit version and
others we got the 64-bit version.

Additionally the removal of allarch from all multilib builds also seem like
a poor choice as multilib builds now lose all of the benefits that are
generally available from allarch.

On Sun, Sep 16, 2018 at 10:27 PM Kang Kai  wrote:

> On 2018年09月14日 22:12, Martin Jansa wrote:
> > On Fri, Sep 14, 2018 at 01:25:12PM +0200, Martin Jansa wrote:
> >> On Thu, Sep 13, 2018 at 10:10:46PM +0200, Martin Jansa wrote:
> >>> On Thu, Sep 13, 2018 at 08:20:07PM +0200, Martin Jansa wrote:
>  On Thu, Sep 06, 2018 at 11:52:24PM +0800, kai.k...@windriver.com
> wrote:
> > From: Kai Kang 
> >
> > Some allarch packages rdepends non-allarch packages. when multilib is
> > used, it doesn't expand the dependency chain correctly, e.g.
> >
> > core-image-sato -> ca-certificates(allarch) -> openssl
> >
> > we expect dependency chain for lib32-core-image-sato:
> >
> > lib32-core-image-sato -> ca-certificates(allarch) -> lib32-openssl
> >
> > it should install lib32-openssl for ca-certificates but openssl is
> still
> > wrongly required.
> >
> > Only enable allarch when multilib is not used to fix the issue.
> >
> > signed-off-by: kai kang 
> > ---
> >   meta/classes/allarch.bbclass | 12 +++-
> >   meta/classes/icecc.bbclass   |  2 +-
> >   meta/classes/multilib.bbclass|  3 ++-
> >   meta/classes/multilib_global.bbclass |  4 +---
> >   meta/classes/package.bbclass |  9 ++---
> >   5 files changed, 21 insertions(+), 9 deletions(-)
> >
> > diff --git a/meta/classes/allarch.bbclass
> b/meta/classes/allarch.bbclass
> > index 1eebe0bf2e..45f62a5939 100644
> > --- a/meta/classes/allarch.bbclass
> > +++ b/meta/classes/allarch.bbclass
> > @@ -2,7 +2,17 @@
> >   # This class is used for architecture independent recipes/data
> files (usually scripts)
> >   #
> >
> > -PACKAGE_ARCH = "all"
> > +python allarch_package_arch_handler () {
> > +if bb.data.inherits_class("nativesdk", d) or
> bb.data.inherits_class("crosssdk", d):
> > +return
> > +
> > +variants = d.getVar("MULTILIB_VARIANTS")
> > +if not variants:
> > +d.setVar("PACKAGE_ARCH", "all" )
> > +}
> > +
> > +addhandler allarch_package_arch_handler
> > +allarch_package_arch_handler[eventmask] =
> "bb.event.RecipePreFinalise"
>  Maybe I'm overlooking something, but doesn't this overwrite whatever
>  PACKAGE_ARCH as set before this?
> 
>  I have some recipes where the PACKAGE_ARCH is set to MACHINE_ARCH
> through
>  another bbclass, but then overwritten with "all" by
> allarch_package_arch_handler:
> 
>  # $PACKAGE_ARCH [5 operations]
>  #   set oe-core/meta/conf/bitbake.conf:150
>  # [_defaultval] "${TUNE_PKGARCH}"
>  

[OE-core] [PATCH] kernel-devicetree: build DTBs in parallel

2018-08-24 Thread Dan Dedrick
When building more than one device tree it's inefficient to serially
build them in multiple make calls. It's much faster and efficient to
build them in one call where they can run in parallel.

Signed-off-by: Dan Dedrick 
---
 meta/classes/kernel-devicetree.bbclass | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/classes/kernel-devicetree.bbclass 
b/meta/classes/kernel-devicetree.bbclass
index 867b776aa7..83270c4511 100644
--- a/meta/classes/kernel-devicetree.bbclass
+++ b/meta/classes/kernel-devicetree.bbclass
@@ -50,10 +50,14 @@ do_configure_append() {
 }
 
 do_compile_append() {
+   alldtb=""
for dtbf in ${KERNEL_DEVICETREE}; do
dtb=`normalize_dtb "$dtbf"`
-   oe_runmake $dtb
+   alldtb="${alldtb} ${dtb}"
done
+   if [ -n "${alldtb}" ]; then
+   oe_runmake ${alldtb}
+   fi
 }
 
 do_install_append() {
-- 
2.17.1

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


[OE-core] [PATCH] staging: fix up multilib destsysroot path

2017-11-08 Thread Dan Dedrick
The issues here was that WORKDIR changes based on the multilib variant
and the WORKDIR is used in the RECIPE_SYSROOT path. We need to use the
same WORKDIR that everything else is using so reset it before we expand
RECIPE_SYSROOT.

Signed-off-by: Dan Dedrick 
---
 meta/classes/staging.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/staging.bbclass b/meta/classes/staging.bbclass
index c479bd93ea..bd2ecd4776 100644
--- a/meta/classes/staging.bbclass
+++ b/meta/classes/staging.bbclass
@@ -479,6 +479,7 @@ python extend_recipe_sysroot() {
 if variant not in multilibs:
 multilibs[variant] = get_multilib_datastore(variant, d)
 d2 = multilibs[variant]
+d2.setVar("WORKDIR", d.getVar("WORKDIR"))
 destsysroot = d2.getVar("RECIPE_SYSROOT")
 
 native = False
-- 
2.13.6

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


[OE-core] [PATCH] dhcp: use ${BPN} instead of ${PN} for user

2017-11-07 Thread Dan Dedrick
${PN} will include additional prefixes, such as lib32-, which are not
actually a part of the user that is being added. This was creating an unused
user and possibly missing the actually intended user. By using ${BPN} this
will remove all additional extra information and consistently be "dhcp".

Signed-off-by: Dan Dedrick 
---
 meta/recipes-connectivity/dhcp/dhcp.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/dhcp/dhcp.inc 
b/meta/recipes-connectivity/dhcp/dhcp.inc
index 58f4a6fd24..e94370786a 100644
--- a/meta/recipes-connectivity/dhcp/dhcp.inc
+++ b/meta/recipes-connectivity/dhcp/dhcp.inc
@@ -27,7 +27,7 @@ UPSTREAM_CHECK_REGEX = "(?P\d+\.\d+\.(\d+?))/"
 inherit autotools systemd useradd update-rc.d
 
 USERADD_PACKAGES = "${PN}-server"
-USERADD_PARAM_${PN}-server = "--system --no-create-home --home-dir 
/var/run/${PN} --shell /bin/false --user-group ${PN}"
+USERADD_PARAM_${PN}-server = "--system --no-create-home --home-dir 
/var/run/${BPN} --shell /bin/false --user-group ${BPN}"
 
 SYSTEMD_PACKAGES = "${PN}-server ${PN}-relay ${PN}-client"
 SYSTEMD_SERVICE_${PN}-server = "dhcpd.service dhcpd6.service"
-- 
2.13.6

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