[Buildroot] [NEXT 00/26] Package CVE Reporting

[Buildroot] [NEXT 00/26] Package CVE Reporting

[Matt Weber]

This series adds new infrastructure to report
a packages CPE identifier in a similar way
that the legal info is currently reported.

The addition of CPE IDs to the packages is a
manual process, but in a later patchset
additions are planned to the pkg-stats script
to automate maintenance the process.

Matt Weber (26):
  cpe-info: new make target
  cpe-info: update manual for new pkg vars
  cpe-info: id prefix/suffix
  cpe-info: only report target pkgs
  bash: add CPE id
  boa: add CPE id
  boost: add CPE id
  busybox: add CPE id
  bzip2: add CPE id
  dhcp: add CPE id
  e2fsprogs: add CPE id
  gdb: add CPE id
  glibc: add CPE id
  gnupg: add CPE id
  gzip: add CPE id
  iproute2: add CPE id
  libgcrypt: add CPE id
  libopenssl: add CPE id
  libzlib: add CPE id
  linux: add CPE id
  linux-headers: add CPE id
  openssh: add CPE id
  rsyslog: add CPE id
  tcpdump: add CPE id
  util-linux: add CPE id
  xerces: add CPE id

 Makefile                                | 17 ++++++++++++++++-
 docs/manual/adding-packages-generic.txt | 15 +++++++++++++++
 linux/linux.mk                          |  1 +
 package/bash/bash.mk                    |  1 +
 package/boa/boa.mk                      |  2 +-
 package/boost/boost.mk                  |  1 +
 package/busybox/busybox.mk              |  1 +
 package/bzip2/bzip2.mk                  |  2 ++
 package/dhcp/dhcp.mk                    |  1 +
 package/e2fsprogs/e2fsprogs.mk          |  1 +
 package/gdb/gdb.mk                      |  1 +
 package/glibc/glibc.mk                  |  2 ++
 package/gnupg/gnupg.mk                  |  1 +
 package/gzip/gzip.mk                    |  1 +
 package/iproute2/iproute2.mk            |  1 +
 package/libgcrypt/libgcrypt.mk          |  1 +
 package/libopenssl/libopenssl.mk        |  1 +
 package/libzlib/libzlib.mk              |  1 +
 package/linux-headers/linux-headers.mk  |  1 +
 package/openssh/openssh.mk              |  2 ++
 package/pkg-generic.mk                  | 26 ++++++++++++++++++++++++++
 package/pkg-utils.mk                    |  8 ++++++++
 package/rsyslog/rsyslog.mk              |  1 +
 package/tcpdump/tcpdump.mk              |  1 +
 package/util-linux/util-linux.mk        |  2 ++
 package/xerces/xerces.mk                |  1 +
 26 files changed, 91 insertions(+), 2 deletions(-)

-- 
1.9.1

[Buildroot] [NEXT 01/26] cpe-info: new make target

[Matt Weber]

Similar to make legal-info, produce a csv delimited
file containing all selected packages CPE
identification.

Signed-off-by: Matt Weber <matthew.weber@rockwellcollins.com>
---
 Makefile               | 17 ++++++++++++++++-
 package/pkg-generic.mk | 12 ++++++++++++
 package/pkg-utils.mk   |  8 ++++++++
 3 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index ec39bcd..7eda990 100644
--- a/Makefile
+++ b/Makefile
@@ -146,7 +146,7 @@ nobuild_targets := source %-source \
 	clean distclean help show-targets graph-depends \
 	%-graph-depends %-show-depends %-show-version \
 	graph-build graph-size list-defconfigs \
-	savedefconfig printvars
+	savedefconfig printvars cpe-info %-cpe-info
 ifeq ($(MAKECMDGOALS),)
 BR_BUILDING = y
 else ifneq ($(filter-out $(nobuild_targets),$(MAKECMDGOALS)),)
@@ -230,6 +230,7 @@ LEGAL_MANIFEST_CSV_TARGET = $(LEGAL_INFO_DIR)/manifest.csv
 LEGAL_MANIFEST_CSV_HOST = $(LEGAL_INFO_DIR)/host-manifest.csv
 LEGAL_WARNINGS = $(LEGAL_INFO_DIR)/.warnings
 LEGAL_REPORT = $(LEGAL_INFO_DIR)/README
+CPE_MANIFEST_CSV = $(BASE_DIR)/cpe-manifest.csv
 
 ################################################################################
 #
@@ -788,6 +789,19 @@ legal-info: dirs legal-info-clean legal-info-prepare $(foreach p,$(PACKAGES),$(p
 		mv .legal-info.sha256 legal-info.sha256)
 	@echo "Legal info produced in $(LEGAL_INFO_DIR)"
 
+.PHONY: cpe-info-clean
+cpe-info-clean:
+	@rm -f $(CPE_MANIFEST_CSV)
+
+.PHONY: cpe-info-prepare
+cpe-info-prepare:
+	@$(call MESSAGE,"Gathering CPE info")
+	@$(call cpe-manifest,CPE ID,CVE PATCHED,PACKAGE,VERSION,SOURCE SITE)
+
+.PHONY: cpe-info
+cpe-info: cpe-info-clean cpe-info-prepare $(foreach p,$(PACKAGES),$(p)-cpe-info)
+	@echo "CPE info produced in $(CPE_MANIFEST_CSV)"
+
 .PHONY: show-targets
 show-targets:
 	@echo $(sort $(PACKAGES)) $(sort $(TARGETS_ROOTFS))
@@ -1047,6 +1061,7 @@ help:
 	@echo '  source                 - download all sources needed for offline-build'
 	@echo '  external-deps          - list external packages used'
 	@echo '  legal-info             - generate info about license compliance'
+	@echo '  cpe-info               - generate info about security CPE identification'
 	@echo '  printvars              - dump all the internal variables'
 	@echo
 	@echo '  make V=0|1             - 0 => quiet build (default), 1 => verbose build'
diff --git a/package/pkg-generic.mk b/package/pkg-generic.mk
index a2a12e7..8622787 100644
--- a/package/pkg-generic.mk
+++ b/package/pkg-generic.mk
@@ -830,6 +830,17 @@ else
 $(2)_KCONFIG_VAR = BR2_PACKAGE_$(2)
 endif
 
+$(1)-cpe-info: PKG=$(2)
+$(1)-cpe-info:
+ifneq ($$(call qstrip,$$($(2)_SOURCE)),)
+	@$$(call MESSAGE,"Collecting cpe info")
+ifeq ($$(call qstrip,$$($(2)_CPE_ID)),)
+	$(Q)$$(call cpe-manifest,"unknown",$$($(2)_CVE_PATCHED),$$($(2)_RAWNAME),$$($(2)_VERSION),$$($(2)_ACTUAL_SOURCE_SITE))
+else
+	$(Q)$$(foreach id,$$($(2)_CPE_ID),$$(call cpe-manifest,$$(id),$$($(2)_CVE_PATCHED),$$($(2)_RAWNAME),$$($(2)_VERSION),$$($(2)_ACTUAL_SOURCE_SITE))$$(sep))
+endif
+endif
+
 # legal-info: declare dependencies and set values used later for the manifest
 ifneq ($$($(2)_LICENSE_FILES),)
 $(2)_MANIFEST_LICENSE_FILES = $$($(2)_LICENSE_FILES)
@@ -972,6 +983,7 @@ DL_TOOLS_DEPENDENCIES += $$(call extractor-dependency,$$($(2)_SOURCE))
 	$(1)-clean-for-reconfigure \
 	$(1)-clean-for-reinstall \
 	$(1)-configure \
+	$(1)-cpe-info \
 	$(1)-depends \
 	$(1)-dirclean \
 	$(1)-external-deps \
diff --git a/package/pkg-utils.mk b/package/pkg-utils.mk
index c3acc22..11a2457 100644
--- a/package/pkg-utils.mk
+++ b/package/pkg-utils.mk
@@ -95,3 +95,11 @@ define legal-license-file # pkgname, pkgname-pkgver, pkgdir, filename, file-full
 	} && \
 	cp $(5) $(LICENSE_FILES_DIR_$(6))/$(2)/$(4)
 endef
+
+#
+# cpe-info helper functions
+#
+
+define cpe-manifest # cpe, cve patched, pkg name, version, url
+	echo '"$(1)","$(2)","$(3)","$(4)","$(5)"' >>$(CPE_MANIFEST_CSV)
+endef
-- 
1.9.1

[Buildroot] [NEXT 02/26] cpe-info: update manual for new pkg vars

[Matt Weber]

Provide guidance on setting up the <pkgname>_CPE_ID
and <pkgname>_CVE_PATCHED variables.
---
 docs/manual/adding-packages-generic.txt | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/docs/manual/adding-packages-generic.txt b/docs/manual/adding-packages-generic.txt
index 63ea51b..635c5d2 100644
--- a/docs/manual/adding-packages-generic.txt
+++ b/docs/manual/adding-packages-generic.txt
@@ -453,6 +453,21 @@ information is (assuming the package name is +libfoo+) :
   FLAT binary format is only 4k bytes. If the application consumes more stack,
   append the required number here.
 
+* +LIBFOO_CPE_ID+ is a space-separated list of the package's Common Product
+  Enumeration (CPE) identification string(s).
+  +make cpe-info+ copies all of these into a +cpe-manifest.csv+ file.
+  This variable is optional. If it is not defined, +unknown+ will appear in
+  the +CPI ID+ field of the manifest file for this package.
+  To identify a package's possible CPE(s), the National Vunerability
+  Database can be searched at https://nvd.nist.gov/products/cpe/search.
+
+* +LIBFOO_CVE_PATCHED+ is a space-separated list of the package's Common
+  Vunerability Enumeration (CVE) identification strings.  This list
+  represents patches applied to the package beyond the current version,
+  which may fix CVEs.  It's used as part of the +make cpe-info+ reporting.
+  This variable is optional. If it is not defined, the +CVE PATCHED+ field
+  will appear empty in the manifest file for this package.
+
 The recommended way to define these variables is to use the following
 syntax:
 
-- 
1.9.1

[Buildroot] [NEXT 03/26] cpe-info: id prefix/suffix

[Matt Weber]

There are two types of software cpe prefixes, one for
applications and one for operating systems. Note: There
is a third type for hardware.

This patchset determines which should be used and stores
that information with the package for later use when
assembling the CPE report.

There is also a suffix which we just default to wildcards
at this point.

Refs:
   https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7695.pdf
   https://cpe.mitre.org/specification/

Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
---
 package/pkg-generic.mk | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/package/pkg-generic.mk b/package/pkg-generic.mk
index 8622787..8b80de7 100644
--- a/package/pkg-generic.mk
+++ b/package/pkg-generic.mk
@@ -550,6 +550,10 @@ ifndef $(2)_LICENSE_FILES
  endif
 endif
 
+CPE_PREFIX_OS = cpe:2.3:o
+CPE_PREFIX_APP = cpe:2.3:a
+CPE_SUFFIX = *:*:*:*:*:*:*
+
 ifndef $(2)_REDISTRIBUTE
  ifdef $(3)_REDISTRIBUTE
   $(2)_REDISTRIBUTE = $$($(3)_REDISTRIBUTE)
@@ -829,6 +833,14 @@ $(2)_KCONFIG_VAR = BR2_$(2)
 else
 $(2)_KCONFIG_VAR = BR2_PACKAGE_$(2)
 endif
+ifeq ($(1),linux)
+	$(2)_CPE_PREFIX = $(CPE_PREFIX_OS)
+else ifeq ($(1),linux-headers)
+	$(2)_CPE_PREFIX = $(CPE_PREFIX_OS)
+else
+	$(2)_CPE_PREFIX = $(CPE_PREFIX_APP)
+endif
+
 
 $(1)-cpe-info: PKG=$(2)
 $(1)-cpe-info:
@@ -837,9 +849,9 @@ ifneq ($$(call qstrip,$$($(2)_SOURCE)),)
 ifeq ($$(call qstrip,$$($(2)_CPE_ID)),)
 	$(Q)$$(call cpe-manifest,"unknown",$$($(2)_CVE_PATCHED),$$($(2)_RAWNAME),$$($(2)_VERSION),$$($(2)_ACTUAL_SOURCE_SITE))
 else
-	$(Q)$$(foreach id,$$($(2)_CPE_ID),$$(call cpe-manifest,$$(id),$$($(2)_CVE_PATCHED),$$($(2)_RAWNAME),$$($(2)_VERSION),$$($(2)_ACTUAL_SOURCE_SITE))$$(sep))
-endif
-endif
+	$(Q)$$(foreach id,$$($(2)_CPE_ID),$$(call cpe-manifest,$$($(2)_CPE_PREFIX):$$(id):$(CPE_SUFFIX),$$($(2)_CVE_PATCHED),$$($(2)_RAWNAME),$$($(2)_VERSION),$$($(2)_ACTUAL_SOURCE_SITE))$$(sep))
+endif # ifeq ($$(call qstrip,$$($(2)_CPE_ID)),)
+endif # ifneq ($$(call qstrip,$$($(2)_SOURCE)),)
 
 # legal-info: declare dependencies and set values used later for the manifest
 ifneq ($$($(2)_LICENSE_FILES),)
-- 
1.9.1

[Buildroot] [NEXT 04/26] cpe-info: only report target pkgs

[Matt Weber]

The reporting of host packages causes some duplication
and complicates what is really in the targets configuration.
For the purpose of the first version of this patchset,
its assumed that host packages aren't relevant for the
configuration and we only report the target's contents.

Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
---
 package/pkg-generic.mk | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/package/pkg-generic.mk b/package/pkg-generic.mk
index 8b80de7..21d62a5 100644
--- a/package/pkg-generic.mk
+++ b/package/pkg-generic.mk
@@ -842,6 +842,7 @@ else
 endif
 
 
+ifneq ($$($(2)_TYPE),host)
 $(1)-cpe-info: PKG=$(2)
 $(1)-cpe-info:
 ifneq ($$(call qstrip,$$($(2)_SOURCE)),)
@@ -852,6 +853,7 @@ else
 	$(Q)$$(foreach id,$$($(2)_CPE_ID),$$(call cpe-manifest,$$($(2)_CPE_PREFIX):$$(id):$(CPE_SUFFIX),$$($(2)_CVE_PATCHED),$$($(2)_RAWNAME),$$($(2)_VERSION),$$($(2)_ACTUAL_SOURCE_SITE))$$(sep))
 endif # ifeq ($$(call qstrip,$$($(2)_CPE_ID)),)
 endif # ifneq ($$(call qstrip,$$($(2)_SOURCE)),)
+endif # ifeq ($$($(2)_TYPE),target)
 
 # legal-info: declare dependencies and set values used later for the manifest
 ifneq ($$($(2)_LICENSE_FILES),)
-- 
1.9.1

[Buildroot] [NEXT 05/26] bash: add CPE id

[Matt Weber]

Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
---
 package/bash/bash.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/bash/bash.mk b/package/bash/bash.mk
index e938491..b787b14 100644
--- a/package/bash/bash.mk
+++ b/package/bash/bash.mk
@@ -12,6 +12,7 @@ BASH_DEPENDENCIES = ncurses readline host-bison \
 BASH_CONF_OPTS = --with-installed-readline --without-bash-malloc
 BASH_LICENSE = GPL-3.0+
 BASH_LICENSE_FILES = COPYING
+BASH_CPE_ID = gnu:$(BASH_NAME):$(BASH_VERSION)
 
 BASH_CONF_ENV += \
 	ac_cv_rl_prefix="$(STAGING_DIR)" \
-- 
1.9.1

[Buildroot] [NEXT 06/26] boa: add CPE id

[Matt Weber]

Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
---
 package/boa/boa.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/boa/boa.mk b/package/boa/boa.mk
index d8bcaa1..1ded702 100644
--- a/package/boa/boa.mk
+++ b/package/boa/boa.mk
@@ -8,7 +8,7 @@ BOA_VERSION = 0.94.14rc21
 BOA_SITE = http://www.boa.org
 BOA_LICENSE = GPL-2.0+
 BOA_LICENSE_FILES = COPYING
-
+BOA_CPE_ID = $(BOE_NAME):$(BOE_NAME):$(BOE_VERSION)
 define BOA_INSTALL_TARGET_CMDS
 	$(INSTALL) -D -m 755 $(@D)/src/boa $(TARGET_DIR)/usr/sbin/boa
 	$(INSTALL) -D -m 755 $(@D)/src/boa_indexer $(TARGET_DIR)/usr/lib/boa/boa_indexer
-- 
1.9.1

[Buildroot] [NEXT 07/26] boost: add CPE id

[Matt Weber]

Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
---
 package/boost/boost.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/boost/boost.mk b/package/boost/boost.mk
index 9ad83d5..f905d98 100644
--- a/package/boost/boost.mk
+++ b/package/boost/boost.mk
@@ -10,6 +10,7 @@ BOOST_SITE = http://downloads.sourceforge.net/project/boost/boost/$(BOOST_VERSIO
 BOOST_INSTALL_STAGING = YES
 BOOST_LICENSE = BSL-1.0
 BOOST_LICENSE_FILES = LICENSE_1_0.txt
+BOOST_CPE_ID = $(BOOST_NAME):$(BOOST_NAME):$(BOOST_VERSION)
 
 # keep host variant as minimal as possible
 HOST_BOOST_FLAGS = --without-icu --with-toolset=gcc \
-- 
1.9.1

[Buildroot] [NEXT 08/26] busybox: add CPE id

[Matt Weber]

Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
---
 package/busybox/busybox.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/busybox/busybox.mk b/package/busybox/busybox.mk
index d0bbd3f..1f84649 100644
--- a/package/busybox/busybox.mk
+++ b/package/busybox/busybox.mk
@@ -9,6 +9,7 @@ BUSYBOX_SITE = http://www.busybox.net/downloads
 BUSYBOX_SOURCE = busybox-$(BUSYBOX_VERSION).tar.bz2
 BUSYBOX_LICENSE = GPL-2.0
 BUSYBOX_LICENSE_FILES = LICENSE
+BUSYBOX_CPE_ID = $(BUSYBOX_NAME):$(BUSYBOX_NAME):$(BUSYBOX_VERSION)
 
 define BUSYBOX_HELP_CMDS
 	@echo '  busybox-menuconfig     - Run BusyBox menuconfig'
-- 
1.9.1

[Buildroot] [NEXT 09/26] bzip2: add CPE id

[Matt Weber]

Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
---
 package/bzip2/bzip2.mk | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/package/bzip2/bzip2.mk b/package/bzip2/bzip2.mk
index e435330..c81f587 100644
--- a/package/bzip2/bzip2.mk
+++ b/package/bzip2/bzip2.mk
@@ -10,6 +10,8 @@ BZIP2_INSTALL_STAGING = YES
 BZIP2_LICENSE = bzip2 license
 BZIP2_LICENSE_FILES = LICENSE
 
+BZIP2_CPE_ID=bzip:$(BZIP2_NAME):$(BZIP2_VERSION)
+
 ifeq ($(BR2_STATIC_LIBS),)
 define BZIP2_BUILD_SHARED_CMDS
 	$(TARGET_MAKE_ENV) \
-- 
1.9.1

[Buildroot] [NEXT 10/26] dhcp: add CPE id

[Matt Weber]

Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
---
 package/dhcp/dhcp.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/dhcp/dhcp.mk b/package/dhcp/dhcp.mk
index a128518..59a6597 100644
--- a/package/dhcp/dhcp.mk
+++ b/package/dhcp/dhcp.mk
@@ -9,6 +9,7 @@ DHCP_SITE = http://ftp.isc.org/isc/dhcp/$(DHCP_VERSION)
 DHCP_INSTALL_STAGING = YES
 DHCP_LICENSE = ISC
 DHCP_LICENSE_FILES = LICENSE
+DHCP_CPE_ID = isc:$(DHCP_NAME):$(DHCP_VERSION)
 DHCP_CONF_ENV = \
 	CPPFLAGS='-D_PATH_DHCPD_CONF=\"/etc/dhcp/dhcpd.conf\" \
 		-D_PATH_DHCLIENT_CONF=\"/etc/dhcp/dhclient.conf\"' \
-- 
1.9.1

[Buildroot] [NEXT 11/26] e2fsprogs: add CPE id

[Matt Weber]

Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
---
 package/e2fsprogs/e2fsprogs.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/e2fsprogs/e2fsprogs.mk b/package/e2fsprogs/e2fsprogs.mk
index 99019c7..05915ca 100644
--- a/package/e2fsprogs/e2fsprogs.mk
+++ b/package/e2fsprogs/e2fsprogs.mk
@@ -10,6 +10,7 @@ E2FSPROGS_SITE = $(BR2_KERNEL_MIRROR)/linux/kernel/people/tytso/e2fsprogs/v$(E2F
 E2FSPROGS_LICENSE = GPL-2.0, MIT-like with advertising clause (libss and libet)
 E2FSPROGS_LICENSE_FILES = NOTICE lib/ss/mit-sipb-copyright.h lib/et/internal.h
 E2FSPROGS_INSTALL_STAGING = YES
+E2FSPROGS_CPE_ID = e2fsprogs_project:$(E2FSPROGS_NAME):$(E2FSPROGS_VERSION)
 
 # Use libblkid and libuuid from util-linux for host and target packages.
 # This prevents overriding them with e2fsprogs' ones, which may cause
-- 
1.9.1

[Buildroot] [NEXT 12/26] gdb: add CPE id

[Matt Weber]

Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
---
 package/gdb/gdb.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/gdb/gdb.mk b/package/gdb/gdb.mk
index 5ca464a..966957f 100644
--- a/package/gdb/gdb.mk
+++ b/package/gdb/gdb.mk
@@ -16,6 +16,7 @@ endif
 
 GDB_LICENSE = GPL-2.0+, LGPL-2.0+, GPL-3.0+, LGPL-3.0+
 GDB_LICENSE_FILES = COPYING COPYING.LIB COPYING3 COPYING3.LIB
+GDB_CPE_ID = gnu:$(GDB_NAME):$(GDB_VERSION)
 
 # We only want gdbserver and not the entire debugger.
 ifeq ($(BR2_PACKAGE_GDB_DEBUGGER),)
-- 
1.9.1

[Buildroot] [NEXT 13/26] glibc: add CPE id

[Matt Weber]

Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
---
 package/glibc/glibc.mk | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/package/glibc/glibc.mk b/package/glibc/glibc.mk
index 0351433..8553cd6 100644
--- a/package/glibc/glibc.mk
+++ b/package/glibc/glibc.mk
@@ -25,6 +25,8 @@ GLIBC_SRC_SUBDIR = .
 GLIBC_LICENSE = GPL-2.0+ (programs), LGPL-2.1+, BSD-3-Clause, MIT (library)
 GLIBC_LICENSE_FILES = $(addprefix $(GLIBC_SRC_SUBDIR)/,COPYING COPYING.LIB LICENSES)
 
+GLIBC_CPE_ID = gnu:$(GLIBC_NAME):$(GLIBC_VERSION)
+
 # glibc is part of the toolchain so disable the toolchain dependency
 GLIBC_ADD_TOOLCHAIN_DEPENDENCY = NO
 
-- 
1.9.1

[Buildroot] [NEXT 14/26] gnupg: add CPE id

[Matt Weber]

Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
---
 package/gnupg/gnupg.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/gnupg/gnupg.mk b/package/gnupg/gnupg.mk
index 3ff202b..1f73214 100644
--- a/package/gnupg/gnupg.mk
+++ b/package/gnupg/gnupg.mk
@@ -9,6 +9,7 @@ GNUPG_SOURCE = gnupg-$(GNUPG_VERSION).tar.bz2
 GNUPG_SITE = https://gnupg.org/ftp/gcrypt/gnupg
 GNUPG_LICENSE = GPL-3.0+
 GNUPG_LICENSE_FILES = COPYING
+GNUPG_CPE_ID = $(GNUPG_NAME):$(GNUPG_NAME):$(GNUPG_VERSION)
 GNUPG_DEPENDENCIES = zlib ncurses $(if $(BR2_PACKAGE_LIBICONV),libiconv)
 GNUPG_CONF_ENV = ac_cv_sys_symbol_underscore=no
 GNUPG_CONF_OPTS = \
-- 
1.9.1

[Buildroot] [NEXT 15/26] gzip: add CPE id

[Matt Weber]

Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
---
 package/gzip/gzip.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/gzip/gzip.mk b/package/gzip/gzip.mk
index 26fc8ec..1e40429 100644
--- a/package/gzip/gzip.mk
+++ b/package/gzip/gzip.mk
@@ -13,6 +13,7 @@ GZIP_CONF_OPTS = --exec-prefix=/
 GZIP_DEPENDENCIES = $(if $(BR2_PACKAGE_BUSYBOX),busybox)
 GZIP_LICENSE = GPL-3.0+
 GZIP_LICENSE_FILES = COPYING
+GZIP_CPE_ID = gnu:$(GZIP_NAME):$(GZIP_VERSION)
 GZIP_CONF_ENV += gl_cv_func_fflush_stdin=yes
 # configure substitutes $(SHELL) for the shell shebang in scripts like
 # gzexe. Unfortunately, the same $(SHELL) variable will also be used by
-- 
1.9.1

[Buildroot] [NEXT 16/26] iproute2: add CPE id

[Matt Weber]

Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
---
 package/iproute2/iproute2.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/iproute2/iproute2.mk b/package/iproute2/iproute2.mk
index 15bb132..9d9fdb1 100644
--- a/package/iproute2/iproute2.mk
+++ b/package/iproute2/iproute2.mk
@@ -11,6 +11,7 @@ IPROUTE2_DEPENDENCIES = host-bison host-flex host-pkgconf \
 	$(if $(BR2_PACKAGE_LIBMNL),libmnl)
 IPROUTE2_LICENSE = GPL-2.0+
 IPROUTE2_LICENSE_FILES = COPYING
+IPROUTE2_CPE_ID = iproute2_project:$(IPROUTE2_NAME):$(IPROUTE2_VERSION)
 
 # If both iproute2 and busybox are selected, make certain we win
 # the fight over who gets to have their utils actually installed.
-- 
1.9.1

[Buildroot] [NEXT 17/26] libgcrypt: add CPE id

[Matt Weber]

Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
---
 package/libgcrypt/libgcrypt.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/libgcrypt/libgcrypt.mk b/package/libgcrypt/libgcrypt.mk
index 00e864e..3e92ff3 100644
--- a/package/libgcrypt/libgcrypt.mk
+++ b/package/libgcrypt/libgcrypt.mk
@@ -12,6 +12,7 @@ LIBGCRYPT_SITE = https://gnupg.org/ftp/gcrypt/libgcrypt
 LIBGCRYPT_INSTALL_STAGING = YES
 LIBGCRYPT_DEPENDENCIES = libgpg-error
 LIBGCRYPT_CONFIG_SCRIPTS = libgcrypt-config
+LIBGCRYPT_CPE_ID = gnupg:$(LIBGCRYPT_NAME):$(LIBGCRYPT_VERSION)
 
 LIBGCRYPT_CONF_ENV = \
 	ac_cv_sys_symbol_underscore=no
-- 
1.9.1

[Buildroot] [NEXT 18/26] libopenssl: add CPE id

[Matt Weber]

Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
---
 package/libopenssl/libopenssl.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/libopenssl/libopenssl.mk b/package/libopenssl/libopenssl.mk
index 5a78676..ec466eb 100644
--- a/package/libopenssl/libopenssl.mk
+++ b/package/libopenssl/libopenssl.mk
@@ -15,6 +15,7 @@ HOST_LIBOPENSSL_DEPENDENCIES = host-zlib
 LIBOPENSSL_TARGET_ARCH = generic32
 LIBOPENSSL_CFLAGS = $(TARGET_CFLAGS)
 LIBOPENSSL_PROVIDES = openssl
+LIBOPENSSL_CPE_ID = openssl:openssl:$(LIBOPENSSL_VERSION)
 LIBOPENSSL_PATCH = \
 	https://gitweb.gentoo.org/repo/gentoo.git/plain/dev-libs/openssl/files/openssl-1.0.2d-parallel-build.patch?id=c8abcbe8de5d3b6cdd68c162f398c011ff6e2d9d \
 	https://gitweb.gentoo.org/repo/gentoo.git/plain/dev-libs/openssl/files/openssl-1.0.2a-parallel-obj-headers.patch?id=c8abcbe8de5d3b6cdd68c162f398c011ff6e2d9d \
-- 
1.9.1

[Buildroot] [NEXT 19/26] libzlib: add CPE id

[Matt Weber]

Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
---
 package/libzlib/libzlib.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/libzlib/libzlib.mk b/package/libzlib/libzlib.mk
index eea0c12..b94a1d7 100644
--- a/package/libzlib/libzlib.mk
+++ b/package/libzlib/libzlib.mk
@@ -11,6 +11,7 @@ LIBZLIB_LICENSE = Zlib
 LIBZLIB_LICENSE_FILES = README
 LIBZLIB_INSTALL_STAGING = YES
 LIBZLIB_PROVIDES = zlib
+LIBZLIB_CPE_ID = gnu:zlib:$(LIBZLIB_VERSION)
 
 # It is not possible to build only a shared version of zlib, so we build both
 # shared and static, unless we only want the static libs, and we eventually
-- 
1.9.1

[Buildroot] [NEXT 20/26] linux: add CPE id

[Matt Weber]

Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
---
 linux/linux.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/linux/linux.mk b/linux/linux.mk
index 5300b9c..7afd9b5 100644
--- a/linux/linux.mk
+++ b/linux/linux.mk
@@ -7,6 +7,7 @@
 LINUX_VERSION = $(call qstrip,$(BR2_LINUX_KERNEL_VERSION))
 LINUX_LICENSE = GPL-2.0
 LINUX_LICENSE_FILES = COPYING
+LINUX_CPE_ID = $(LINUX_NAME):$(LINUX_NAME)_kernel:$(LINUX_VERSION)
 
 define LINUX_HELP_CMDS
 	@echo '  linux-menuconfig       - Run Linux kernel menuconfig'
-- 
1.9.1

[Buildroot] [NEXT 21/26] linux-headers: add CPE id

[Matt Weber]

This package will report with the same CPE as the
linux package.  As such, depending on the toolchain
approach, there will be a duplicate record with the
same information.

Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
---
 package/linux-headers/linux-headers.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/linux-headers/linux-headers.mk b/package/linux-headers/linux-headers.mk
index f1e3790..2e3e531 100644
--- a/package/linux-headers/linux-headers.mk
+++ b/package/linux-headers/linux-headers.mk
@@ -84,6 +84,7 @@ endif # ! BR2_KERNEL_HEADERS_AS_KERNEL
 
 LINUX_HEADERS_LICENSE = GPL-2.0
 LINUX_HEADERS_LICENSE_FILES = COPYING
+LINUX_HEADERS_CPE_ID = linux:linux_kernel:$(LINUX_HEADERS_VERSION)
 
 LINUX_HEADERS_INSTALL_STAGING = YES
 
-- 
1.9.1

[Buildroot] [NEXT 22/26] openssh: add CPE id

[Matt Weber]

Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
---
 package/openssh/openssh.mk | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/package/openssh/openssh.mk b/package/openssh/openssh.mk
index 6b7ac22..d01d8f5 100644
--- a/package/openssh/openssh.mk
+++ b/package/openssh/openssh.mk
@@ -8,6 +8,8 @@ OPENSSH_VERSION = 7.6p1
 OPENSSH_SITE = http://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable
 OPENSSH_LICENSE = BSD-3-Clause, BSD-2-Clause, Public Domain
 OPENSSH_LICENSE_FILES = LICENCE
+OPENSSH_CPE_ID = openbsd:$(OPENSSH_NAME):$(OPENSSH_VERSION)
+
 # Autoreconf needed due to the following patches modifying configure.ac:
 # 0001-configure-ac-detect-mips-abi.patch
 # 0002-configure-ac-properly-set-seccomp-audit-arch-for-mips64.patch
-- 
1.9.1

[Buildroot] [NEXT 23/26] rsyslog: add CPE id

[Matt Weber]

Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
---
 package/rsyslog/rsyslog.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/rsyslog/rsyslog.mk b/package/rsyslog/rsyslog.mk
index e32505b..60e9ad1 100644
--- a/package/rsyslog/rsyslog.mk
+++ b/package/rsyslog/rsyslog.mk
@@ -8,6 +8,7 @@ RSYSLOG_VERSION = 8.22.0
 RSYSLOG_SITE = http://rsyslog.com/files/download/rsyslog
 RSYSLOG_LICENSE = GPL-3.0, LGPL-3.0, Apache-2.0
 RSYSLOG_LICENSE_FILES = COPYING COPYING.LESSER COPYING.ASL20
+RSYSLOG_CPE_ID = $(RSYSLOG_NAME):$(RSYSLOG_NAME):$(RSYSLOG_VERSION)
 RSYSLOG_DEPENDENCIES = zlib libestr liblogging libfastjson host-pkgconf
 RSYSLOG_CONF_ENV = ac_cv_prog_cc_c99='-std=c99'
 RSYSLOG_PLUGINS = imdiag imfile impstats imptcp \
-- 
1.9.1

[Buildroot] [NEXT 24/26] tcpdump: add CPE id

[Matt Weber]

Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
---
 package/tcpdump/tcpdump.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/tcpdump/tcpdump.mk b/package/tcpdump/tcpdump.mk
index 2a6d095..3c6220b 100644
--- a/package/tcpdump/tcpdump.mk
+++ b/package/tcpdump/tcpdump.mk
@@ -8,6 +8,7 @@ TCPDUMP_VERSION = 4.9.2
 TCPDUMP_SITE = http://www.tcpdump.org/release
 TCPDUMP_LICENSE = BSD-3-Clause
 TCPDUMP_LICENSE_FILES = LICENSE
+TCPDUMP_CPE_ID = $(TCPDUMP_NAME):$(TCPDUMP_NAME):$(TCPDUMP_VERSION)
 TCPDUMP_CONF_ENV = \
 	ac_cv_linux_vers=2 \
 	td_cv_buggygetaddrinfo=no \
-- 
1.9.1

[Buildroot] [NEXT 25/26] util-linux: add CPE id

[Matt Weber]

Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
---
 package/util-linux/util-linux.mk | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/package/util-linux/util-linux.mk b/package/util-linux/util-linux.mk
index 72a6d18..c8d0b00 100644
--- a/package/util-linux/util-linux.mk
+++ b/package/util-linux/util-linux.mk
@@ -15,6 +15,8 @@ UTIL_LINUX_SITE = $(BR2_KERNEL_MIRROR)/linux/utils/util-linux/v$(UTIL_LINUX_VERS
 UTIL_LINUX_LICENSE = GPL-2.0+, BSD-4-Clause, LGPL-2.1+ (libblkid, libfdisk, libmount), BSD-3-Clause (libuuid) ISC (rfkill)
 UTIL_LINUX_LICENSE_FILES = README.licensing Documentation/licenses/COPYING.GPLv2 Documentation/licenses/COPYING.UCB Documentation/licenses/COPYING.LGPLv2.1 Documentation/licenses/COPYING.BSD-3 Documentation/licenses/COPYING.ISC
 UTIL_LINUX_INSTALL_STAGING = YES
+UTIL_LINUX_CPE_ID = util-linux_project:$(UTIL_LINUX_NAME):$(UTIL_LINUX_VERSION)
+
 UTIL_LINUX_DEPENDENCIES = host-pkgconf $(TARGET_NLS_DEPENDENCIES)
 # uClibc needs NTP_LEGACY for sys/timex.h -> ntp_gettime() support
 # (used in logger.c), and the common default is N.
-- 
1.9.1

[Buildroot] [NEXT 26/26] xerces: add CPE id

[Matt Weber]

Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
---
 package/xerces/xerces.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/xerces/xerces.mk b/package/xerces/xerces.mk
index a25641f..153b8eb 100644
--- a/package/xerces/xerces.mk
+++ b/package/xerces/xerces.mk
@@ -9,6 +9,7 @@ XERCES_SOURCE = xerces-c-$(XERCES_VERSION).tar.xz
 XERCES_SITE = http://archive.apache.org/dist/xerces/c/3/sources
 XERCES_LICENSE = Apache-2.0
 XERCES_LICENSE_FILES = LICENSE
+XERCES_CPE_ID = apache:$(XERCES_NAME)-c\+\+:$(XERCES_VERSION)
 XERCES_INSTALL_STAGING = YES
 XERCES_CONF_OPTS = \
 	--disable-threads \
-- 
1.9.1

[Buildroot] [NEXT 00/26] Package CVE Reporting

[Thomas Petazzoni]

Hello,

On Mon, 26 Feb 2018 20:10:15 -0600, Matt Weber wrote:
> This series adds new infrastructure to report
> a packages CPE identifier in a similar way
> that the legal info is currently reported.
> 
> The addition of CPE IDs to the packages is a
> manual process, but in a later patchset
> additions are planned to the pkg-stats script
> to automate maintenance the process.

Thanks for working on this and coming up with a proposal!

While I'm fine with the package annotations, I am not yet sure that a
"make cpe-info" is what we want here.

In particular, I'm thinking about the interaction with pkg-stats, and
the work I've done to make pkg-stats query release-monitoring.org to
check for new upstream versions. Ideally, pkg-stats should also query
the CPE information and add it to its report.

For now, pkg-stats reports about all packages in Buildroot, but I'm
hoping to improve that and make it possible for pkg-stats to only
generate a report about the list of packages selected in the current
Buildroot configuration.

So I don't have a very clear cut answer, but I see some overlap between
cpe-info and pkg-stats, and I'd like to have a common view on what is
the mid/long-term direction we want to take.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

[Buildroot] [NEXT 01/26] cpe-info: new make target

[Thomas Petazzoni]

Hello,

On Mon, 26 Feb 2018 20:10:16 -0600, Matt Weber wrote:
> Similar to make legal-info, produce a csv delimited
> file containing all selected packages CPE
> identification.
> 
> Signed-off-by: Matt Weber <matthew.weber@rockwellcollins.com>
> ---
>  Makefile               | 17 ++++++++++++++++-
>  package/pkg-generic.mk | 12 ++++++++++++
>  package/pkg-utils.mk   |  8 ++++++++
>  3 files changed, 36 insertions(+), 1 deletion(-)
> 
> diff --git a/Makefile b/Makefile
> index ec39bcd..7eda990 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -146,7 +146,7 @@ nobuild_targets := source %-source \
>  	clean distclean help show-targets graph-depends \
>  	%-graph-depends %-show-depends %-show-version \
>  	graph-build graph-size list-defconfigs \
> -	savedefconfig printvars
> +	savedefconfig printvars cpe-info %-cpe-info
>  ifeq ($(MAKECMDGOALS),)
>  BR_BUILDING = y
>  else ifneq ($(filter-out $(nobuild_targets),$(MAKECMDGOALS)),)
> @@ -230,6 +230,7 @@ LEGAL_MANIFEST_CSV_TARGET = $(LEGAL_INFO_DIR)/manifest.csv
>  LEGAL_MANIFEST_CSV_HOST = $(LEGAL_INFO_DIR)/host-manifest.csv
>  LEGAL_WARNINGS = $(LEGAL_INFO_DIR)/.warnings
>  LEGAL_REPORT = $(LEGAL_INFO_DIR)/README
> +CPE_MANIFEST_CSV = $(BASE_DIR)/cpe-manifest.csv
>  
>  ################################################################################
>  #
> @@ -788,6 +789,19 @@ legal-info: dirs legal-info-clean legal-info-prepare $(foreach p,$(PACKAGES),$(p
>  		mv .legal-info.sha256 legal-info.sha256)
>  	@echo "Legal info produced in $(LEGAL_INFO_DIR)"
>  
> +.PHONY: cpe-info-clean
> +cpe-info-clean:
> +	@rm -f $(CPE_MANIFEST_CSV)
> +
> +.PHONY: cpe-info-prepare
> +cpe-info-prepare:
> +	@$(call MESSAGE,"Gathering CPE info")
> +	@$(call cpe-manifest,CPE ID,CVE PATCHED,PACKAGE,VERSION,SOURCE SITE)
> +
> +.PHONY: cpe-info
> +cpe-info: cpe-info-clean cpe-info-prepare $(foreach p,$(PACKAGES),$(p)-cpe-info)
> +	@echo "CPE info produced in $(CPE_MANIFEST_CSV)"
> +
>  .PHONY: show-targets
>  show-targets:
>  	@echo $(sort $(PACKAGES)) $(sort $(TARGETS_ROOTFS))
> @@ -1047,6 +1061,7 @@ help:
>  	@echo '  source                 - download all sources needed for offline-build'
>  	@echo '  external-deps          - list external packages used'
>  	@echo '  legal-info             - generate info about license compliance'
> +	@echo '  cpe-info               - generate info about security CPE identification'
>  	@echo '  printvars              - dump all the internal variables'
>  	@echo
>  	@echo '  make V=0|1             - 0 => quiet build (default), 1 => verbose build'
> diff --git a/package/pkg-generic.mk b/package/pkg-generic.mk
> index a2a12e7..8622787 100644
> --- a/package/pkg-generic.mk
> +++ b/package/pkg-generic.mk
> @@ -830,6 +830,17 @@ else
>  $(2)_KCONFIG_VAR = BR2_PACKAGE_$(2)
>  endif
>  
> +$(1)-cpe-info: PKG=$(2)
> +$(1)-cpe-info:
> +ifneq ($$(call qstrip,$$($(2)_SOURCE)),)
> +	@$$(call MESSAGE,"Collecting cpe info")
> +ifeq ($$(call qstrip,$$($(2)_CPE_ID)),)
> +	$(Q)$$(call cpe-manifest,"unknown",$$($(2)_CVE_PATCHED),$$($(2)_RAWNAME),$$($(2)_VERSION),$$($(2)_ACTUAL_SOURCE_SITE))
> +else
> +	$(Q)$$(foreach id,$$($(2)_CPE_ID),$$(call cpe-manifest,$$(id),$$($(2)_CVE_PATCHED),$$($(2)_RAWNAME),$$($(2)_VERSION),$$($(2)_ACTUAL_SOURCE_SITE))$$(sep))
> +endif
> +endif

A question is: do we need a new make target, or can an external script
do the same thing ?

After all, "make printvars" gives you pretty much the needed
information. All what is missing is that you can't easily get the list
of selected packages in the current configuration, but that would be
useful for me for the pkg-stats script as well. So a "make
show-packages" or "make list-packages" could be useful.

Perhaps that's how we can make our two different needs converge: by
having external scripts rather than adding more stuff to the package
infrastructure. A ./utils/cpe-report script could do pretty much what
you've done here.

Thoughts ?

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

[Buildroot] [NEXT 02/26] cpe-info: update manual for new pkg vars

[Thomas Petazzoni]

Hello,

On Mon, 26 Feb 2018 20:10:17 -0600, Matt Weber wrote:
> Provide guidance on setting up the <pkgname>_CPE_ID
> and <pkgname>_CVE_PATCHED variables.
> ---
>  docs/manual/adding-packages-generic.txt | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/docs/manual/adding-packages-generic.txt b/docs/manual/adding-packages-generic.txt
> index 63ea51b..635c5d2 100644
> --- a/docs/manual/adding-packages-generic.txt
> +++ b/docs/manual/adding-packages-generic.txt
> @@ -453,6 +453,21 @@ information is (assuming the package name is +libfoo+) :
>    FLAT binary format is only 4k bytes. If the application consumes more stack,
>    append the required number here.
>  
> +* +LIBFOO_CPE_ID+ is a space-separated list of the package's Common Product
> +  Enumeration (CPE) identification string(s).

So you can have mutiple entries in this list ? In which cases ?

> +  +make cpe-info+ copies all of these into a +cpe-manifest.csv+ file.
> +  This variable is optional. If it is not defined, +unknown+ will appear in
> +  the +CPI ID+ field of the manifest file for this package.

Side question: is this manifest.csv file generated in some standardized
format, or is it just some CSV format you can up with, just like we did
for legal-info ?

> +  To identify a package's possible CPE(s), the National Vunerability
> +  Database can be searched at https://nvd.nist.gov/products/cpe/search.
> +
> +* +LIBFOO_CVE_PATCHED+ is a space-separated list of the package's Common
> +  Vunerability Enumeration (CVE) identification strings.  This list
> +  represents patches applied to the package beyond the current version,
> +  which may fix CVEs.

I find this description a bit unclear. Indeed LIBFOO_CVE_PATCHED
doesn't "represents patches". Instead it "Enumerates CVEs that are
fixed by patches added in Buildroot". We can perhaps expand and say
that it allows the CPE reporting mechanism to know that a given CVE is
fixed, even if Buildroot is not using an upstream release that has the
CVE fixed.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

[Buildroot] [NEXT 03/26] cpe-info: id prefix/suffix

[Thomas Petazzoni]

Hello,

On Mon, 26 Feb 2018 20:10:18 -0600, Matt Weber wrote:

> +ifeq ($(1),linux)
> +	$(2)_CPE_PREFIX = $(CPE_PREFIX_OS)
> +else ifeq ($(1),linux-headers)
> +	$(2)_CPE_PREFIX = $(CPE_PREFIX_OS)

You can also do:

ifneq ($(filter linux linux-headers,$(1)),)
$(2)_CPE_PREFIX = $(CPE_PREFIX_OS)
else
$(2)_CPE_PREFIX = $(CPE_PREFIX_APP)
endif

But OK, it's not a big difference :)

>  $(1)-cpe-info: PKG=$(2)
>  $(1)-cpe-info:
> @@ -837,9 +849,9 @@ ifneq ($$(call qstrip,$$($(2)_SOURCE)),)
>  ifeq ($$(call qstrip,$$($(2)_CPE_ID)),)
>  	$(Q)$$(call cpe-manifest,"unknown",$$($(2)_CVE_PATCHED),$$($(2)_RAWNAME),$$($(2)_VERSION),$$($(2)_ACTUAL_SOURCE_SITE))
>  else
> -	$(Q)$$(foreach id,$$($(2)_CPE_ID),$$(call cpe-manifest,$$(id),$$($(2)_CVE_PATCHED),$$($(2)_RAWNAME),$$($(2)_VERSION),$$($(2)_ACTUAL_SOURCE_SITE))$$(sep))
> -endif
> -endif
> +	$(Q)$$(foreach id,$$($(2)_CPE_ID),$$(call cpe-manifest,$$($(2)_CPE_PREFIX):$$(id):$(CPE_SUFFIX),$$($(2)_CVE_PATCHED),$$($(2)_RAWNAME),$$($(2)_VERSION),$$($(2)_ACTUAL_SOURCE_SITE))$$(sep))
> +endif # ifeq ($$(call qstrip,$$($(2)_CPE_ID)),)
> +endif # ifneq ($$(call qstrip,$$($(2)_SOURCE)),)

These two comments after the endif's are good, but should have been
part of a previous commit, which was adding the endif's.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

[Buildroot] [NEXT 04/26] cpe-info: only report target pkgs

[Thomas Petazzoni]

Hello,

On Mon, 26 Feb 2018 20:10:19 -0600, Matt Weber wrote:

> +ifneq ($$($(2)_TYPE),host)

Why not:

ifeq ($$($(2)_TYPE),target)

>  $(1)-cpe-info: PKG=$(2)
>  $(1)-cpe-info:
>  ifneq ($$(call qstrip,$$($(2)_SOURCE)),)
> @@ -852,6 +853,7 @@ else
>  	$(Q)$$(foreach id,$$($(2)_CPE_ID),$$(call cpe-manifest,$$($(2)_CPE_PREFIX):$$(id):$(CPE_SUFFIX),$$($(2)_CVE_PATCHED),$$($(2)_RAWNAME),$$($(2)_VERSION),$$($(2)_ACTUAL_SOURCE_SITE))$$(sep))
>  endif # ifeq ($$(call qstrip,$$($(2)_CPE_ID)),)
>  endif # ifneq ($$(call qstrip,$$($(2)_SOURCE)),)
> +endif # ifeq ($$($(2)_TYPE),target)

... just like your endif comment shows ? :-)

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

[Buildroot] [NEXT 06/26] boa: add CPE id

[Thomas Petazzoni]

Hello,

On Mon, 26 Feb 2018 20:10:21 -0600, Matt Weber wrote:
> Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
> ---
>  package/boa/boa.mk | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/package/boa/boa.mk b/package/boa/boa.mk
> index d8bcaa1..1ded702 100644
> --- a/package/boa/boa.mk
> +++ b/package/boa/boa.mk
> @@ -8,7 +8,7 @@ BOA_VERSION = 0.94.14rc21
>  BOA_SITE = http://www.boa.org
>  BOA_LICENSE = GPL-2.0+
>  BOA_LICENSE_FILES = COPYING
> -
> +BOA_CPE_ID = $(BOE_NAME):$(BOE_NAME):$(BOE_VERSION)

Typo: BOE -> BOA

Also, please keep an empty line before BOA_INSTALL_TARGET_CMDS.

Now, a more general discussion about <pkg>_CPE_ID. Here is the list of
CPE_ID you have added:

BASH_CPE_ID = gnu:$(BASH_NAME):$(BASH_VERSION)
BOA_CPE_ID = $(BOE_NAME):$(BOE_NAME):$(BOE_VERSION)
BOOST_CPE_ID = $(BOOST_NAME):$(BOOST_NAME):$(BOOST_VERSION)
BUSYBOX_CPE_ID = $(BUSYBOX_NAME):$(BUSYBOX_NAME):$(BUSYBOX_VERSION)
BZIP2_CPE_ID=bzip:$(BZIP2_NAME):$(BZIP2_VERSION)
DHCP_CPE_ID = isc:$(DHCP_NAME):$(DHCP_VERSION)
E2FSPROGS_CPE_ID = e2fsprogs_project:$(E2FSPROGS_NAME):$(E2FSPROGS_VERSION)
GDB_CPE_ID = gnu:$(GDB_NAME):$(GDB_VERSION)
GLIBC_CPE_ID = gnu:$(GLIBC_NAME):$(GLIBC_VERSION)
GNUPG_CPE_ID = $(GNUPG_NAME):$(GNUPG_NAME):$(GNUPG_VERSION)
GZIP_CPE_ID = gnu:$(GZIP_NAME):$(GZIP_VERSION)
IPROUTE2_CPE_ID = iproute2_project:$(IPROUTE2_NAME):$(IPROUTE2_VERSION)
LIBGCRYPT_CPE_ID = gnupg:$(LIBGCRYPT_NAME):$(LIBGCRYPT_VERSION)
LIBOPENSSL_CPE_ID = openssl:openssl:$(LIBOPENSSL_VERSION)
LIBZLIB_CPE_ID = gnu:zlib:$(LIBZLIB_VERSION)
LINUX_CPE_ID = $(LINUX_NAME):$(LINUX_NAME)_kernel:$(LINUX_VERSION)
LINUX_HEADERS_CPE_ID = linux:linux_kernel:$(LINUX_HEADERS_VERSION)
OPENSSH_CPE_ID = openbsd:$(OPENSSH_NAME):$(OPENSSH_VERSION)
RSYSLOG_CPE_ID = $(RSYSLOG_NAME):$(RSYSLOG_NAME):$(RSYSLOG_VERSION)
TCPDUMP_CPE_ID = $(TCPDUMP_NAME):$(TCPDUMP_NAME):$(TCPDUMP_VERSION)
UTIL_LINUX_CPE_ID = util-linux_project:$(UTIL_LINUX_NAME):$(UTIL_LINUX_VERSION)
XERCES_CPE_ID = apache:$(XERCES_NAME)-c\+\+:$(XERCES_VERSION)

There is clearly a pattern, no?

Does it make sense to define in the infra:

$(2)_CPE_ID_VENDOR ?= $$($(2)_NAME)
$(2)_CPE_ID_NAME ?= $$($(2)_NAME)
$(2)_CPE_ID_VERSION ?= $$($(2)_VERSION)
$(2)_CPE_ID ?= $($(2)_CPE_ID_VENDOR):$($(2)_CPE_ID_NAME):$($(2)_CPE_ID_VERSION)

With this, in many packages, you can avoid <pkg>_CPE_ID completely. In
a few other packages you'll have to do:

LIBZLIB_CPE_ID_VENDOR = gnu
LIBZLIB_CPE_ID_NAME = zlib

The drawback is obviously that all packages will suddenly have a
<pkg>_CPE_ID value, even if this value may potentially be incorrect
because it hasn't been checked. And this may be a real problem, so
probably your solution is better, I just wanted to point out the
(admittedly limited) duplication.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

[Buildroot] [NEXT 20/26] linux: add CPE id

[Thomas Petazzoni]

Hello,

On Mon, 26 Feb 2018 20:10:35 -0600, Matt Weber wrote:

> +LINUX_CPE_ID = $(LINUX_NAME):$(LINUX_NAME)_kernel:$(LINUX_VERSION)

How is the CPE database reacting when LINUX_VERSION is some random Git
SHA1, from a private Git tree that nobody has access to ?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

[Buildroot] [NEXT 06/26] boa: add CPE id

[Matthew Weber]

Thomas,

On Tue, Feb 27, 2018 at 4:17 PM, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
> Hello,
>
> On Mon, 26 Feb 2018 20:10:21 -0600, Matt Weber wrote:
>> Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
>> ---
>>  package/boa/boa.mk | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/package/boa/boa.mk b/package/boa/boa.mk
>> index d8bcaa1..1ded702 100644
>> --- a/package/boa/boa.mk
>> +++ b/package/boa/boa.mk
>> @@ -8,7 +8,7 @@ BOA_VERSION = 0.94.14rc21
>>  BOA_SITE = http://www.boa.org
>>  BOA_LICENSE = GPL-2.0+
>>  BOA_LICENSE_FILES = COPYING
>> -
>> +BOA_CPE_ID = $(BOE_NAME):$(BOE_NAME):$(BOE_VERSION)
>
> Typo: BOE -> BOA
>
> Also, please keep an empty line before BOA_INSTALL_TARGET_CMDS.
>

Noted, will fix in v2

[snip]
> There is clearly a pattern, no?
>
> Does it make sense to define in the infra:
>
> $(2)_CPE_ID_VENDOR ?= $$($(2)_NAME)
> $(2)_CPE_ID_NAME ?= $$($(2)_NAME)
> $(2)_CPE_ID_VERSION ?= $$($(2)_VERSION)
> $(2)_CPE_ID ?= $($(2)_CPE_ID_VENDOR):$($(2)_CPE_ID_NAME):$($(2)_CPE_ID_VERSION)
>
> With this, in many packages, you can avoid <pkg>_CPE_ID completely. In
> a few other packages you'll have to do:
>
> LIBZLIB_CPE_ID_VENDOR = gnu
> LIBZLIB_CPE_ID_NAME = zlib
>

Where it gets difficult is when a package has multiple CPEs so that
you catch all possible combinations that could be relevant for the
package.  Eventually there shouldn't be multiple once the dictionary
at NIST is cleaned up......

One thing I didn't think about with the multiple CPEs is the logic to
detect if a CPE needs updating in the CPE dictionary.  We'd have to
look at all possible CPE id options to see if any match.  This may
lead to us wanting to push to update the primary CPE ID sooner then
later and align all our packages to use it instead of supporting
multiple.  Then we could use the logic of having all packages set the
LIBZLIB_CPE_ID_VENDOR and key off that to know we report that packages
info.

> The drawback is obviously that all packages will suddenly have a
> <pkg>_CPE_ID value, even if this value may potentially be incorrect
> because it hasn't been checked. And this may be a real problem, so
> probably your solution is better, I just wanted to point out the
> (admittedly limited) duplication.

Yeah, eventually I'd argue we could revert back to infra logic and
clean it all up once there is a baseline or majority of packages with
valid CPE IDs.    However for now, I default those we don't have to
unknown so it's clear for a developer to go research or request a new
CPE.

Matt

[Buildroot] [NEXT 20/26] linux: add CPE id

[Matthew Weber]

Thomas,

On Tue, Feb 27, 2018 at 4:18 PM, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
> Hello,
>
> On Mon, 26 Feb 2018 20:10:35 -0600, Matt Weber wrote:
>
>> +LINUX_CPE_ID = $(LINUX_NAME):$(LINUX_NAME)_kernel:$(LINUX_VERSION)
>
> How is the CPE database reacting when LINUX_VERSION is some random Git
> SHA1, from a private Git tree that nobody has access to ?

I brought this up to one of my security guys and he had a good point.
He pointed out that since we keep the reporting seperate from any
proposed automated CVE analysis.  The user specific analysis could
manage taking the hash and manually doing the effort to tie that to a
linux version.  Then looking at the individual CVEs on top of that
version.  There isn't a good way to include that in the buildsystem
that we can see but most analysis tools have a way to keep notes with
a configuration.  For any buildroot automated CVE reporting I don't
think you'd run into this hash case for linux as there wouldn't be a
default version selected as a hash (so far at least that I know of)

For packages which use hashes, the suggestion was made to use the
major and minor syntax where we state the version to be the last
release and the next wildcard field is the minor version and set we
that to the hash.  So for validating a CPE is correct (pkg-stats
maintenance), we would just look at the major version.  However for
the analysis activity where a target CPE report is used to find CVEs,
they would take into account the major and also go look at the hash
manually to determine where that falls past the  major.  On the
buildroot side we could also add CVE_PATCHED items covering that delta
if we know what they are.  I should do an example of this in my next
patchset (one of the github packages).

Matt

[Buildroot] [NEXT 04/26] cpe-info: only report target pkgs

[Matthew Weber]

Thomas,

On Tue, Feb 27, 2018 at 3:45 PM, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
> Hello,
>
> On Mon, 26 Feb 2018 20:10:19 -0600, Matt Weber wrote:
>
>> +ifneq ($$($(2)_TYPE),host)
>
> Why not:
>
> ifeq ($$($(2)_TYPE),target)
>

Will include in v2  :)

Matt

[Buildroot] [NEXT 03/26] cpe-info: id prefix/suffix

[Matthew Weber]

Thomas,

On Tue, Feb 27, 2018 at 3:45 PM, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
> Hello,
>
> On Mon, 26 Feb 2018 20:10:18 -0600, Matt Weber wrote:
>
>> +ifeq ($(1),linux)
>> +     $(2)_CPE_PREFIX = $(CPE_PREFIX_OS)
>> +else ifeq ($(1),linux-headers)
>> +     $(2)_CPE_PREFIX = $(CPE_PREFIX_OS)
>
> You can also do:
>
> ifneq ($(filter linux linux-headers,$(1)),)
> $(2)_CPE_PREFIX = $(CPE_PREFIX_OS)
> else
> $(2)_CPE_PREFIX = $(CPE_PREFIX_APP)
> endif
>
> But OK, it's not a big difference :)

Cleaner though if there are any others.  Will update in v2.

>
>>  $(1)-cpe-info: PKG=$(2)
>>  $(1)-cpe-info:
>> @@ -837,9 +849,9 @@ ifneq ($$(call qstrip,$$($(2)_SOURCE)),)
>>  ifeq ($$(call qstrip,$$($(2)_CPE_ID)),)
>>       $(Q)$$(call cpe-manifest,"unknown",$$($(2)_CVE_PATCHED),$$($(2)_RAWNAME),$$($(2)_VERSION),$$($(2)_ACTUAL_SOURCE_SITE))
>>  else
>> -     $(Q)$$(foreach id,$$($(2)_CPE_ID),$$(call cpe-manifest,$$(id),$$($(2)_CVE_PATCHED),$$($(2)_RAWNAME),$$($(2)_VERSION),$$($(2)_ACTUAL_SOURCE_SITE))$$(sep))
>> -endif
>> -endif
>> +     $(Q)$$(foreach id,$$($(2)_CPE_ID),$$(call cpe-manifest,$$($(2)_CPE_PREFIX):$$(id):$(CPE_SUFFIX),$$($(2)_CVE_PATCHED),$$($(2)_RAWNAME),$$($(2)_VERSION),$$($(2)_ACTUAL_SOURCE_SITE))$$(sep))
>> +endif # ifeq ($$(call qstrip,$$($(2)_CPE_ID)),)
>> +endif # ifneq ($$(call qstrip,$$($(2)_SOURCE)),)
>
> These two comments after the endif's are good, but should have been
> part of a previous commit, which was adding the endif's.
>

Will update in v2.

Matt

[Buildroot] [NEXT 02/26] cpe-info: update manual for new pkg vars

[Matthew Weber]

Thomas,

On Tue, Feb 27, 2018 at 3:43 PM, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
> Hello,
>
> On Mon, 26 Feb 2018 20:10:17 -0600, Matt Weber wrote:
>> Provide guidance on setting up the <pkgname>_CPE_ID
>> and <pkgname>_CVE_PATCHED variables.
>> ---
>>  docs/manual/adding-packages-generic.txt | 15 +++++++++++++++
>>  1 file changed, 15 insertions(+)
>>
>> diff --git a/docs/manual/adding-packages-generic.txt b/docs/manual/adding-packages-generic.txt
>> index 63ea51b..635c5d2 100644
>> --- a/docs/manual/adding-packages-generic.txt
>> +++ b/docs/manual/adding-packages-generic.txt
>> @@ -453,6 +453,21 @@ information is (assuming the package name is +libfoo+) :
>>    FLAT binary format is only 4k bytes. If the application consumes more stack,
>>    append the required number here.
>>
>> +* +LIBFOO_CPE_ID+ is a space-separated list of the package's Common Product
>> +  Enumeration (CPE) identification string(s).
>
> So you can have mutiple entries in this list ? In which cases ?

Yeah, there is a trend toward a single but at this point (at least
where I currently work) we don't take the chance of missing a miss
mapped CVE because someone updated the old one.  Eventually this will
end up as a single ID longterm.

Few I've ran into so far: gzip, e2fsprogs, util-linux, hostapd,
wpa_supplicant, libzip, nginx

>
>> +  +make cpe-info+ copies all of these into a +cpe-manifest.csv+ file.
>> +  This variable is optional. If it is not defined, +unknown+ will appear in
>> +  the +CPI ID+ field of the manifest file for this package.
>
> Side question: is this manifest.csv file generated in some standardized
> format, or is it just some CSV format you can up with, just like we did
> for legal-info ?

CSV similar to legal-info with enough metadata to go produce a CPE if
the ID is set to unknown.

From your other email about using the infra, maybe we still build the
CPE ID in the pkg .mk but I could add a infra helper to build the
default pkg name and version piece to simplify the duplication.  Maybe
one for that and another for the default vendor, name and version
where they just match the buildroot values.

>
>> +  To identify a package's possible CPE(s), the National Vunerability
>> +  Database can be searched at https://nvd.nist.gov/products/cpe/search.
>> +
>> +* +LIBFOO_CVE_PATCHED+ is a space-separated list of the package's Common
>> +  Vunerability Enumeration (CVE) identification strings.  This list
>> +  represents patches applied to the package beyond the current version,
>> +  which may fix CVEs.
>
> I find this description a bit unclear. Indeed LIBFOO_CVE_PATCHED
> doesn't "represents patches". Instead it "Enumerates CVEs that are
> fixed by patches added in Buildroot". We can perhaps expand and say
> that it allows the CPE reporting mechanism to know that a given CVE is
> fixed, even if Buildroot is not using an upstream release that has the
> CVE fixed.

My original statement is unclear, I'll update per the suggestion.

Matt

[Buildroot] [NEXT 01/26] cpe-info: new make target

[Matthew Weber]

On Tue, Feb 27, 2018 at 3:40 PM, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
> Hello,
>
> On Mon, 26 Feb 2018 20:10:16 -0600, Matt Weber wrote:
>> Similar to make legal-info, produce a csv delimited
>> file containing all selected packages CPE
>> identification.
>>
>> Signed-off-by: Matt Weber <matthew.weber@rockwellcollins.com>
[snip]
>
> A question is: do we need a new make target, or can an external script
> do the same thing ?
>
> After all, "make printvars" gives you pretty much the needed
> information. All what is missing is that you can't easily get the list
> of selected packages in the current configuration, but that would be
> useful for me for the pkg-stats script as well. So a "make
> show-packages" or "make list-packages" could be useful.
>
> Perhaps that's how we can make our two different needs converge: by
> having external scripts rather than adding more stuff to the package
> infrastructure. A ./utils/cpe-report script could do pretty much what
> you've done here.
>
> Thoughts ?

I was on the fence when I looked at where to make the change.  I went
the infra route because it ended up being really simple to generate
that data and the whole process seamed clean.  I could see after
creating some of the CPE maintaining scripting we could easily convert
to your suggested approach for the report generation as well.  I just
didn't want the creation of the CPE scripting holding up the reporting
function, as I can get more developers to focus on improving the CPE
information across a few products over the next quarter if I have the
reports.

We have been looking at the pkg-stats script and thinking about the
impl steps to take.  hoping to get more time on them next month.

Matt

[Buildroot] [NEXT 00/26] Package CVE Reporting

[Matthew Weber]

Thomas,

On Tue, Feb 27, 2018 at 3:37 PM, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
> Hello,
>
> On Mon, 26 Feb 2018 20:10:15 -0600, Matt Weber wrote:
[snip]
> While I'm fine with the package annotations, I am not yet sure that a
> "make cpe-info" is what we want here.
>
> In particular, I'm thinking about the interaction with pkg-stats, and
> the work I've done to make pkg-stats query release-monitoring.org to
> check for new upstream versions. Ideally, pkg-stats should also query
> the CPE information and add it to its report.

Agreed, but I see that as a seperate function and a next step after
this patchset.  I see the basic report as the first step to get others
to contribute more CPE information to packages.  I'm sure others using
Buildroot have external tools they use to take the CPEs and do their
analysis.  We can passively get the benefit of those efforts finding
the CPEs which need updates util the pkg-stats is ready.  Hopefully
we'd have a pkg-stats solution in place not to long after the
reporting has been in use.

>
> For now, pkg-stats reports about all packages in Buildroot, but I'm
> hoping to improve that and make it possible for pkg-stats to only
> generate a report about the list of packages selected in the current
> Buildroot configuration.

I do agree that if the cpe-info using infra is merged, the long term
plan would be to move that to a script once the pkg-stats CPE checking
and CPE helper functions it uses exist to build a comparable CPE
report.

In general, I'd advocate for an incremental approach so some of the
benefits can start to be realized while the automation is matured.

Matt

[Buildroot] [NEXT 06/26] boa: add CPE id

[Thomas Petazzoni]

Hello,

On Tue, 27 Feb 2018 22:00:31 -0600, Matthew Weber wrote:

> > LIBZLIB_CPE_ID_VENDOR = gnu
> > LIBZLIB_CPE_ID_NAME = zlib
> >  
> 
> Where it gets difficult is when a package has multiple CPEs so that
> you catch all possible combinations that could be relevant for the
> package.  Eventually there shouldn't be multiple once the dictionary
> at NIST is cleaned up......

Well, my proposal contained:

$(2)_CPE_ID ?= $($(2)_CPE_ID_VENDOR):$($(2)_CPE_ID_NAME):$($(2)_CPE_ID_VERSION)

Notice the ?=, which still allows a given package to override its
<pkg>_CPE_ID value entirely, potentially with a list of multiple values.

> One thing I didn't think about with the multiple CPEs is the logic to
> detect if a CPE needs updating in the CPE dictionary.  We'd have to
> look at all possible CPE id options to see if any match.  This may
> lead to us wanting to push to update the primary CPE ID sooner then
> later and align all our packages to use it instead of supporting
> multiple.  Then we could use the logic of having all packages set the
> LIBZLIB_CPE_ID_VENDOR and key off that to know we report that packages
> info.

I am not sure what is the story being multiple CPE IDs. Is it the NIST
database having two entries for what is essentially the same upstream
software ? If that's the case, then it really is a bug in the NIST
database, which should rather be fixed in the database rather than
worked around on our side by supporting CPE IDs, no ?

Of course, fixing the NIST database is the ideal situation, but it is
only reasonable if the NIST people are interested in fixing those
issues in a timely fashion. If they are not, then I'd say it's fine to
support multiple CPE IDs in Buildroot for the time being.

> > The drawback is obviously that all packages will suddenly have a
> > <pkg>_CPE_ID value, even if this value may potentially be incorrect
> > because it hasn't been checked. And this may be a real problem, so
> > probably your solution is better, I just wanted to point out the
> > (admittedly limited) duplication.  
> 
> Yeah, eventually I'd argue we could revert back to infra logic and
> clean it all up once there is a baseline or majority of packages with
> valid CPE IDs.    However for now, I default those we don't have to
> unknown so it's clear for a developer to go research or request a new
> CPE.

Yes, that is a possibility. As I said, I do realize that my proposal
has the significant drawback of not allowing to identify clearly which
package has a correct CPE_ID (voluntarily added by a developer) vs.
some potentially random CPE_ID (set by default by the package
infrastructure).

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

[Buildroot] [NEXT 01/26] cpe-info: new make target

[Arnout Vandecappelle]

On 28-02-18 05:30, Matthew Weber wrote:
> On Tue, Feb 27, 2018 at 3:40 PM, Thomas Petazzoni
> <thomas.petazzoni@bootlin.com> wrote:
>> Hello,
>>
>> On Mon, 26 Feb 2018 20:10:16 -0600, Matt Weber wrote:
>>> Similar to make legal-info, produce a csv delimited
>>> file containing all selected packages CPE
>>> identification.
>>>
>>> Signed-off-by: Matt Weber <matthew.weber@rockwellcollins.com>
> [snip]
>>
>> A question is: do we need a new make target, or can an external script
>> do the same thing ?
>>
>> After all, "make printvars" gives you pretty much the needed
>> information.

 Indeed. and other things that are currently in the infra could also work that
way. E.g. graph-depends would speed up dramatically if it could make use of
printvars.

 One limitation, however: we currently have quite a few where something like
'make foo-cpe-info' is a useful feature. In the infra, it comes for free; in a
script, it needs special treatment.

 On the positive side, however, it should be possible to write a python module
that generalizes all this: gather of packages, doing printvars, filtering the
output.

 Oh, one more thing: if we go that route, then I think printvars should gain a
feature to do output a Python dictionary. Or a JSON object. Or something like
that. Now, the QUOTED_VARS is OK for shell but not for Python. And it doesn't
fully work in shell eval, because some variable names (e.g. 4TH_xxx) are not
valid shell variable names.


>> All what is missing is that you can't easily get the list
>> of selected packages in the current configuration, but that would be
>> useful for me for the pkg-stats script as well. So a "make
>> show-packages" or "make list-packages" could be useful.

 PACKAGES comes pretty close - but since we don't have full Config.in.host it's
incomplete, of course. So we indeed need a recursive list-packages rule.


>> Perhaps that's how we can make our two different needs converge: by
>> having external scripts rather than adding more stuff to the package
>> infrastructure. A ./utils/cpe-report script could do pretty much what
>> you've done here.
>>
>> Thoughts ?
> 
> I was on the fence when I looked at where to make the change.  I went
> the infra route because it ended up being really simple to generate
> that data and the whole process seamed clean.

 That is indeed true: make basically has the infra already to do the recursive
expansion we need. We'd have to duplicate that into Python. But as I said, it
can be done once and then used by several scripts.

 There is one reason why I would really prefer things to move to scripts: every
additional inner-generic-package variable and rule slows down make a little bit.
It's not by a huge amount, but I think I once tested that removing all those
extra rules and their variables from inner-generic-packages sped up 'make -qp'
by about 10%.


> I could see after
> creating some of the CPE maintaining scripting we could easily convert
> to your suggested approach for the report generation as well.

 I agree.

 Regards,
 Arnout

> I just
> didn't want the creation of the CPE scripting holding up the reporting
> function, as I can get more developers to focus on improving the CPE
> information across a few products over the next quarter if I have the
> reports.
> 
> We have been looking at the pkg-stats script and thinking about the
> impl steps to take.  hoping to get more time on them next month.
> 
> Matt
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [NEXT 03/26] cpe-info: id prefix/suffix

[Arnout Vandecappelle]

On 27-02-18 03:10, Matt Weber wrote:
> diff --git a/package/pkg-generic.mk b/package/pkg-generic.mk
> index 8622787..8b80de7 100644
> --- a/package/pkg-generic.mk
> +++ b/package/pkg-generic.mk
> @@ -550,6 +550,10 @@ ifndef $(2)_LICENSE_FILES
>   endif
>  endif
>  
> +CPE_PREFIX_OS = cpe:2.3:o
> +CPE_PREFIX_APP = cpe:2.3:a
> +CPE_SUFFIX = *:*:*:*:*:*:*

 Since this is inside inner-generic-package, you are re-defining these variables
for every package. That's not what you want to do :-)

 All (or most) of the common variables are currently defined in
package/Makefile.in. For specific infras they are defined in that specific infra
file, but not so for the generic infra. So I guess these should also be defined
in package/Makefile.in.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [NEXT 03/26] cpe-info: id prefix/suffix

[Arnout Vandecappelle]

On 28-02-18 05:14, Matthew Weber wrote:
> Thomas,
> 
> On Tue, Feb 27, 2018 at 3:45 PM, Thomas Petazzoni
> <thomas.petazzoni@bootlin.com> wrote:
>> Hello,
>>
>> On Mon, 26 Feb 2018 20:10:18 -0600, Matt Weber wrote:
>>
>>> +ifeq ($(1),linux)
>>> +     $(2)_CPE_PREFIX = $(CPE_PREFIX_OS)
>>> +else ifeq ($(1),linux-headers)
>>> +     $(2)_CPE_PREFIX = $(CPE_PREFIX_OS)
>>
>> You can also do:
>>
>> ifneq ($(filter linux linux-headers,$(1)),)
>> $(2)_CPE_PREFIX = $(CPE_PREFIX_OS)
>> else
>> $(2)_CPE_PREFIX = $(CPE_PREFIX_APP)
>> endif
>>
>> But OK, it's not a big difference :)
> 
> Cleaner though if there are any others.  Will update in v2.

 Yeah, like, what about bootloaders?

 Regards,
 Arnout

[snip]
-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [NEXT 06/26] boa: add CPE id

[Arnout Vandecappelle]

On 28-02-18 07:38, Thomas Petazzoni wrote:
>>> The drawback is obviously that all packages will suddenly have a
>>> <pkg>_CPE_ID value, even if this value may potentially be incorrect
>>> because it hasn't been checked. And this may be a real problem, so
>>> probably your solution is better, I just wanted to point out the
>>> (admittedly limited) duplication.  
>> Yeah, eventually I'd argue we could revert back to infra logic and
>> clean it all up once there is a baseline or majority of packages with
>> valid CPE IDs.    However for now, I default those we don't have to
>> unknown so it's clear for a developer to go research or request a new
>> CPE.
> Yes, that is a possibility. As I said, I do realize that my proposal
> has the significant drawback of not allowing to identify clearly which
> package has a correct CPE_ID (voluntarily added by a developer) vs.
> some potentially random CPE_ID (set by default by the package
> infrastructure).

 Well, this in the end boils down to the question: what are you going to do with
that cpe-manifest.csv? I think that whatever script is going to use that file,
it will have to be robust against CPE_IDs that don't actually exist in the CPE
database. Indeed, when someone bumps a package, will they have to verify if the
new CPE ID is still valid? If it isn't, what should be done? Report to NIST, of
course, but while the database isn't updated, should we just remove the CPE_ID
or what?

 To help a bit with deciding on this, it could be nice if you could add an RFC
patch with a script that takes the cpe-manifest.csv and outputs something real -
i.e., a list of open and closed CVEs. The latter will also help to evaluate to
what extent this whole thing is useful. In other words, how accurate is that
generated list? It's a question we had ad the BR developer meeting and which
still remains unanswered IMO.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [NEXT 06/26] boa: add CPE id

[Matthew Weber]

Arnout,

On Thu, Mar 1, 2018 at 2:47 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
>
>
>
> On 28-02-18 07:38, Thomas Petazzoni wrote:
> >>> The drawback is obviously that all packages will suddenly have a
> >>> <pkg>_CPE_ID value, even if this value may potentially be incorrect
> >>> because it hasn't been checked. And this may be a real problem, so
> >>> probably your solution is better, I just wanted to point out the
> >>> (admittedly limited) duplication.
> >> Yeah, eventually I'd argue we could revert back to infra logic and
> >> clean it all up once there is a baseline or majority of packages with
> >> valid CPE IDs.    However for now, I default those we don't have to
> >> unknown so it's clear for a developer to go research or request a new
> >> CPE.
> > Yes, that is a possibility. As I said, I do realize that my proposal
> > has the significant drawback of not allowing to identify clearly which
> > package has a correct CPE_ID (voluntarily added by a developer) vs.
> > some potentially random CPE_ID (set by default by the package
> > infrastructure).
>
>  Well, this in the end boils down to the question: what are you going to do with
> that cpe-manifest.csv? I think that whatever script is going to use that file,
> it will have to be robust against CPE_IDs that don't actually exist in the CPE
> database.

Correct, from our experience so far, the free and paid tools which use
this data are flexible on duplicate or invalid entries.  The key is
how they store the analysis and the manual updates you put in after
the fact.  Most take that manual adjustment and help produce a better
analysis on the next run.  If we're looking at making a script to do a
CPE to CVE analysis as part of buildroot, I'd argue (at this point)
that is a fairly involved task to get good data out.  Which is why
I've focused just on getting an initial cpe report and then mechanisms
to automate the upkeep and NIST version bump requests.


> Indeed, when someone bumps a package, will they have to verify if the
> new CPE ID is still valid? If it isn't, what should be done? Report to NIST, of
> course, but while the database isn't updated, should we just remove the CPE_ID
> or what?

We did walk this discussion a bit a developer day.  I think the
feeling was we document the process of suggesting a update to NIST.
We may catch that the version bump doesn't have a CPE before merge but
if we don't, we have a nightly/weekly script which runs to check
current buildroot CPEs vs their pkg versions for validity.  Then send
an email to the DEVELOPERS asking them to submit the update to NIST
(we can have the templated for them to just cut/paste/send).  There
will be gaps between when a version bumps and the CPE is invalid, that
should be ok.  We could make it a goal to have the LTS/releases all
have valid CPEs before they go out (pks-stats helping us).

So in retrospect (even against my v2), I'd argue we should just report
everything as the script we'll propose soon with find the CPEs without
a NIST entry and we can choose to email the DEVELOPER or catch that as
part of a pkg-stats like activity.

>
>  To help a bit with deciding on this, it could be nice if you could add an RFC
> patch with a script that takes the cpe-manifest.csv and outputs something real -
> i.e., a list of open and closed CVEs.

Ok but the goal I'm shooting for is just a mostly accurate list and a
way to try and improve that metadata over time.  It won't be perfect.
A good example of this are the duplicate CPEs, over time they can be
discarded as we validate they are legacy and no one is cataloguing
things against them.  Until they're removed, we will have no-hits on
most of the duplicates in whichever tool a person uses to do their CVE
checking.

> The latter will also help to evaluate to
> what extent this whole thing is useful. In other words, how accurate is that
> generated list? It's a question we had ad the BR developer meeting and which
> still remains unanswered IMO.

The CPE list will be as accurate as people using it update the NIST
entries, either manually or as Buildroot nudges them to send an email.
The CVEs those CPEs will find is another complete story and most open
ways of searching for those don't concluded clean results without a
good amount of manual intervention.


Matt

[Buildroot] [NEXT 06/26] boa: add CPE id

[Arnout Vandecappelle]

On 01-03-18 23:55, Matthew Weber wrote:
> Arnout,
> 
> On Thu, Mar 1, 2018 at 2:47 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
[snip]
>> Indeed, when someone bumps a package, will they have to verify if the
>> new CPE ID is still valid? If it isn't, what should be done? Report to NIST, of
>> course, but while the database isn't updated, should we just remove the CPE_ID
>> or what?
> 
> We did walk this discussion a bit a developer day.  I think the
> feeling was we document the process of suggesting a update to NIST.
> We may catch that the version bump doesn't have a CPE before merge but
> if we don't, we have a nightly/weekly script which runs to check
> current buildroot CPEs vs their pkg versions for validity.  Then send
> an email to the DEVELOPERS asking them to submit the update to NIST
> (we can have the templated for them to just cut/paste/send).  There
> will be gaps between when a version bumps and the CPE is invalid, that
> should be ok.  We could make it a goal to have the LTS/releases all
> have valid CPEs before they go out (pks-stats helping us).
> 
> So in retrospect (even against my v2), I'd argue we should just report
> everything as the script we'll propose soon with find the CPEs without
> a NIST entry and we can choose to email the DEVELOPER or catch that as
> part of a pkg-stats like activity.

 Just to be clear about what you're saying here: in v3, you'll making it so that
nothing has to be done explicitly in the package to get a CPE ID, but it may be
(and probably will be) invalid? So that the initial report will contain a huge
amount of invalid entries, and we can fix them one by one?

 I realize I'm contradicting myself, but that still leaves us with a problem (or
rather, limitation). We have no way of keeping track of which packages have been
checked and which haven't, so we have no way of keeping track of which ones are
broken.

 Or perhaps the pkg-stats script could eventually check the entry in the CPE
database, and add a column to indicate that it's valid or not?


>>  To help a bit with deciding on this, it could be nice if you could add an RFC
>> patch with a script that takes the cpe-manifest.csv and outputs something real -
>> i.e., a list of open and closed CVEs.
> 
> Ok but the goal I'm shooting for is just a mostly accurate list and a
> way to try and improve that metadata over time.  It won't be perfect.
> A good example of this are the duplicate CPEs, over time they can be
> discarded as we validate they are legacy and no one is cataloguing
> things against them.  Until they're removed, we will have no-hits on
> most of the duplicates in whichever tool a person uses to do their CVE
> checking.
> 
>> The latter will also help to evaluate to
>> what extent this whole thing is useful. In other words, how accurate is that
>> generated list? It's a question we had ad the BR developer meeting and which
>> still remains unanswered IMO.
> 
> The CPE list will be as accurate as people using it update the NIST
> entries, either manually or as Buildroot nudges them to send an email.
> The CVEs those CPEs will find is another complete story and most open
> ways of searching for those don't concluded clean results without a
> good amount of manual intervention.

 Yes, I do realize that this is a kind of catch-22 situation, if nobody uses the
database then obviously it will not be up-to-date. But to be honest, right now I
don't even really understand what kind of information you can get from it even
in the ideal case. That's why I asked to post an RFC script, so we can get some
idea of what the end goal is (and ultimately, whether this is worth the effort).

 Instead of posting a script (e.g. if you don't have that script, or you're not
allowed to redistribute it), you could also describe in the cover letter what
additional steps you have taken to get your final CVE list, and some statistics
about e.g. how many additional CVEs you find with manual checking. And maybe
also mention the commercial tools you've used (if you're allowed to do that). Or
even better, if there are any FLOSS tools, point to them.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [NEXT 06/26] boa: add CPE id

[Thomas Petazzoni]

Hello,

On Fri, 2 Mar 2018 09:19:25 +0100, Arnout Vandecappelle wrote:

>  Just to be clear about what you're saying here: in v3, you'll making it so that
> nothing has to be done explicitly in the package to get a CPE ID, but it may be
> (and probably will be) invalid? So that the initial report will contain a huge
> amount of invalid entries, and we can fix them one by one?
> 
>  I realize I'm contradicting myself, but that still leaves us with a problem (or
> rather, limitation). We have no way of keeping track of which packages have been
> checked and which haven't, so we have no way of keeping track of which ones are
> broken.
> 
>  Or perhaps the pkg-stats script could eventually check the entry in the CPE
> database, and add a column to indicate that it's valid or not?

Yes, that would be the idea.

> > The CPE list will be as accurate as people using it update the NIST
> > entries, either manually or as Buildroot nudges them to send an email.
> > The CVEs those CPEs will find is another complete story and most open
> > ways of searching for those don't concluded clean results without a
> > good amount of manual intervention.  
> 
>  Yes, I do realize that this is a kind of catch-22 situation, if nobody uses the
> database then obviously it will not be up-to-date. But to be honest, right now I
> don't even really understand what kind of information you can get from it even
> in the ideal case. That's why I asked to post an RFC script, so we can get some
> idea of what the end goal is (and ultimately, whether this is worth the effort).

Yes, I agree. The current proposal that just adds CPE_ID to packages,
and has a mechanism to generate a CSV based on that isn't very useful
per-se. I would also like to see the tooling that processes those
CPE_ID to query the NIST database, and get some useful data out of it.

Even if the data isn't great for the moment because the NIST database
is limited, it would show how the whole thing would be useful.

Right now the patch series just adds some IDs and generates a CSV with
those IDs, which isn't terribly useful.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

[Buildroot] [NEXT 20/26] linux: add CPE id

[Thomas Petazzoni]

Hello,

On Tue, 27 Feb 2018 22:12:18 -0600, Matthew Weber wrote:

> > How is the CPE database reacting when LINUX_VERSION is some random Git
> > SHA1, from a private Git tree that nobody has access to ?  
> 
> I brought this up to one of my security guys and he had a good point.
> He pointed out that since we keep the reporting seperate from any
> proposed automated CVE analysis.  The user specific analysis could
> manage taking the hash and manually doing the effort to tie that to a
> linux version.

Indeed, you can do it manually, but it kind of removes the whole point
of having automated tools to check which CVEs are applicable to your
system. And the kernel is a very critical part of the system.

> Then looking at the individual CVEs on top of that
> version.  There isn't a good way to include that in the buildsystem
> that we can see but most analysis tools have a way to keep notes with
> a configuration.  For any buildroot automated CVE reporting I don't
> think you'd run into this hash case for linux as there wouldn't be a
> default version selected as a hash (so far at least that I know of)

I'm sorry, I don't understand this last sentence, could you explain ?

> For packages which use hashes, the suggestion was made to use the
> major and minor syntax where we state the version to be the last
> release and the next wildcard field is the minor version and set we
> that to the hash.

CPE IDs have a concept of major and minor version ?

So we would have something like:

FOO_VERSION = f1d2d2f924e986ac86fdf7b36c94bcdf32beec15
FOO_CPE_ID = foo:foo:2.3:f1d2d2f924e986ac86fdf7b36c94bcdf32beec15

Where 2.3 is the closest "release" to
f1d2d2f924e986ac86fdf7b36c94bcdf32beec15 ?

If that's what you propose, then for Linux, we could have a Config.in
option to fill in what is the Linux official release that is the
closest to the custom version being used.

>  So for validating a CPE is correct (pkg-stats
> maintenance), we would just look at the major version.  However for
> the analysis activity where a target CPE report is used to find CVEs,
> they would take into account the major and also go look at the hash
> manually to determine where that falls past the  major.

Not sure I understand what you're proposing here.

> On the buildroot side we could also add CVE_PATCHED items covering
> that delta if we know what they are.  I should do an example of this
> in my next patchset (one of the github packages).

Yes, please do an example, it would probably be easier for me to
understand what you're proposing :)

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

[Buildroot] [NEXT 06/26] boa: add CPE id

[Matthew Weber]

All,

On Fri, Mar 2, 2018 at 3:49 AM, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
> Hello,
>
> On Fri, 2 Mar 2018 09:19:25 +0100, Arnout Vandecappelle wrote:
>
>>  Just to be clear about what you're saying here: in v3, you'll making it so that
>> nothing has to be done explicitly in the package to get a CPE ID, but it may be
>> (and probably will be) invalid? So that the initial report will contain a huge
>> amount of invalid entries, and we can fix them one by one?
>>
>>  I realize I'm contradicting myself, but that still leaves us with a problem (or
>> rather, limitation). We have no way of keeping track of which packages have been
>> checked and which haven't, so we have no way of keeping track of which ones are
>> broken.
>>
>>  Or perhaps the pkg-stats script could eventually check the entry in the CPE
>> database, and add a column to indicate that it's valid or not?
>
> Yes, that would be the idea.
>
>> > The CPE list will be as accurate as people using it update the NIST
>> > entries, either manually or as Buildroot nudges them to send an email.
>> > The CVEs those CPEs will find is another complete story and most open
>> > ways of searching for those don't concluded clean results without a
>> > good amount of manual intervention.
>>
>>  Yes, I do realize that this is a kind of catch-22 situation, if nobody uses the
>> database then obviously it will not be up-to-date. But to be honest, right now I
>> don't even really understand what kind of information you can get from it even
>> in the ideal case. That's why I asked to post an RFC script, so we can get some
>> idea of what the end goal is (and ultimately, whether this is worth the effort).
>
> Yes, I agree. The current proposal that just adds CPE_ID to packages,
> and has a mechanism to generate a CSV based on that isn't very useful
> per-se. I would also like to see the tooling that processes those
> CPE_ID to query the NIST database, and get some useful data out of it.
>
> Even if the data isn't great for the moment because the NIST database
> is limited, it would show how the whole thing would be useful.
>
> Right now the patch series just adds some IDs and generates a CSV with
> those IDs, which isn't terribly useful.
>

At this point, disregard my current patches and I'll resubmit in a
week or so.  At that point, I'll include scripting and better set of
patch descriptions which cover the dialogue in this email and the
other thread.

Matt

[Buildroot] [NEXT 03/26] cpe-info: id prefix/suffix

[Matthew Weber]

Arnout,

On Thu, Mar 1, 2018 at 2:34 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
>
>
> On 28-02-18 05:14, Matthew Weber wrote:
>> Thomas,
>>
>> On Tue, Feb 27, 2018 at 3:45 PM, Thomas Petazzoni
>> <thomas.petazzoni@bootlin.com> wrote:
>>> Hello,
>>>
>>> On Mon, 26 Feb 2018 20:10:18 -0600, Matt Weber wrote:
>>>
>>>> +ifeq ($(1),linux)
>>>> +     $(2)_CPE_PREFIX = $(CPE_PREFIX_OS)
>>>> +else ifeq ($(1),linux-headers)
>>>> +     $(2)_CPE_PREFIX = $(CPE_PREFIX_OS)
>>>
>>> You can also do:
>>>
>>> ifneq ($(filter linux linux-headers,$(1)),)
>>> $(2)_CPE_PREFIX = $(CPE_PREFIX_OS)
>>> else
>>> $(2)_CPE_PREFIX = $(CPE_PREFIX_APP)
>>> endif
>>>
>>> But OK, it's not a big difference :)
>>
>> Cleaner though if there are any others.  Will update in v2.
>
>  Yeah, like, what about bootloaders?
>

Looks like uboot isn't yet defined.  So that one will need to be
proposed before we'll know os or app.  However grub is listed and is
of app type.

Matt