GnuPG hard-codes $bindir etc and uses them to find the helper binaries, such as
gpg-agent. This breaks if gnupg-native is reused from sstate for a different
build directory and GPG signing of packages is required.
Patch in getenv() checks for gnupg-native when returning the hardcoded paths,
and create a wrapper script which overrides GNUPG_BINDIR. There are more paths
that can be overridden, but this one is sufficient to make GnuPG work.
(From OE-Core rev: dfd69ff889ed78bf137116583d8ae351859ee203)
(From OE-Core rev: ddaf41f210f80556eca1d0acaee1e3f9cbf80122)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Two unrelated lines were extracted from apu_version.h for the license
information.
License-Update: Only extract the relevant part from apu_version.h
(From OE-Core rev: 2edb0f24a13f27b2fae94fb447221ad2ddb924a0)
(From OE-Core rev: 6aebc3a4452d1422cf2ba59dd9b381f89e2fefcc)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Two unrelated lines were extracted from apr_lib.h for the license
information.
License-Update: Only extract the relevant part from apr_lib.h
(From OE-Core rev: 90ab83ecc509c2fdc1f6083d771031decdcaad63)
(From OE-Core rev: f7883a0fae697eefffccd56a45e013f24e20ba5c)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For some reason, the copyright part was left out of the license
information included in LIC_FILES_CHKSUM, preventing it from being
used in, e.g., documentation to satisfy the requirements of the
license.
License-Update: Include the complete license information
(From OE-Core rev: 390becd2dcf4fe791ec3715a74e34a46bd457e7a)
(From OE-Core rev: 015f65b5c391c75fe96f927a007a8be04db70a63)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are both "curl" and "libcurl" CPEs in NVD.
All "curl" CVEs are now missed in the reports.
Hence, switch "CVE_PRODUCT" to a space separated list
of the items.
(From OE-Core rev: 69ff709c2450c42139fd9705e3a74464221ad754)
(From OE-Core rev: 5df0d75fe63a0e1ada396f5ecfa953ac63f65354)
Signed-off-by: Grygorii Tertychnyi <gtertych@cisco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* CVE-2017-7961
The cr_tknzr_parse_rgb function in cr-tknzr.c in libcroco has an
"outside the range of representable values of type long" undefined
behavior issue, which might allow remote attackers to cause a denial
of service (application crash) or possibly have unspecified other
impact via a crafted CSS file.
CVE: CVE-2017-7961
Ref: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-7961
(From OE-Core rev: 9b321cf141c3fa18d5b85f17ffe1710f4555ca49)
Signed-off-by: Sinan Kaya <okaya@kernel.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* CVE-2018-9234
GnuPG 2.2.4 and 2.2.5 does not enforce a configuration in which key
certification requires an offline master Certify key, which results
in apparently valid certifications that occurred only with access to
a signing subkey.
Affects gnupg <= 2.2.5
CVE: CVE-2018-9234
Ref: https://access.redhat.com/security/cve/cve-2018-9234
(From OE-Core rev: af920831ed1ef607db195372f135cc56e9f53b41)
Signed-off-by: Sinan Kaya <okaya@kernel.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* CVE-2018-8740
In SQLite through 3.22.0, databases whose schema is corrupted
using a CREATE TABLE AS statement could cause a NULL pointer dereference,
related to build.c and prepare.c.
Affects sqlite3 <= 3.22.0
CVE: CVE-2018-8740
Ref: https://access.redhat.com/security/cve/cve-2018-8740
(From OE-Core rev: 0469c075d904026ec37214fb39397bb1cb07ab43)
Signed-off-by: Sinan Kaya <okaya@kernel.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Test suite test_dbm failed after gdbm upgrtade to 13.1,
from 13.1, return value of some function are changed.
* gdbm_fetch, gdbm_firstkey, and gdbm_nextkey behavior
If the requested key was not found, these functions return datum with
dptr pointing to NULL and set gdbm_errno to GDBM_ITEM_NOT_FOUND (in
prior releases, gdbm_errno was set to GDBM_NO_ERROR),
(From OE-Core rev: 0952c190fc6aec333676ce3883e8232fa8595551)
(From OE-Core rev: a8cb9b68e91db42a17bfb54591e3ea91565f9241)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The original FTP server, alioth.debian.org has been permanently taken down by the Debian Project and replaced with salsa.debian.org.
(From OE-Core rev: 565394d69925837c0d6f2140bc9489b68dc39474)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These packages use hand-grown makefiles which don't handle cleans as they can
invoke /usr/bin/gmake directly which may not exist. Until new upstream releases
are made (which have ported to automake) set CLEANBROKEN to work around this.
[ YOCTO #12775 ]
(From OE-Core rev: eb924bc684f92fc2d806715872667f241e54b365)
(From OE-Core rev: 1ff55b8810ec2ed61dc6b7c73464a97d7088839d)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit bd0d7c7ed5)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Enable use of pread() and enable column metadata API for nativesdk builds.
This brings nativesdk in line with target and native builds.
(From OE-Core rev: 7c8b85e1c3d852975cd5961a297aa939bf4c7fe7)
(From OE-Core rev: b476119fb72511fb384600db659c73c9bd6486e8)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 086610faf0)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The freedesktop.org.xml data and the update-mime-database tool are both GPLv2 as
per COPYING, so change LICENSE to GPLv2.
test-mime-magic.c is LGPLv2+ but we don't install that so isn't relevant.
(From OE-Core rev: 4ca838097c43755e19f8ffc66436f9ad773fcd39)
(From OE-Core rev: a590642af4d0d93b1d380409f45f5ef7e1793466)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since v7.51.0, libidn2 is the only available option, libidn
support was dropped.
The configure option was renamed as of v7.53.0
Therefore, curl unconditionally tries to build against libidn2,
which in particular is a problem for curl-native, as that might
or might not build against the build-machine's libidn2 now,
which furthermore causes problems when trying to share sstate
between multiple build machines.
We therefore see the following in the config log:
...
checking whether to build with libidn2... (assumed) yes
...
checking for libidn2 options with pkg-config... no
configure: IDN_LIBS: "-lidn2"
configure: IDN_LDFLAGS: ""
configure: IDN_CPPFLAGS: ""
configure: IDN_DIR: ""
checking if idn2_lookup_ul can be linked... yes
checking idn2.h usability... yes
checking idn2.h presence... yes
checking for idn2.h... yes
...
IDN support: enabled (libidn2)
...
even though this recipe tries to disable that.
While libidn2 isn't available in OE, this change at least:
* prevents curl-native to silently build against libidn2 if
that is installed on build machine, even if not requested
* alerts people who use the PACKAGECONFIG option that it's
not actually doing what they intend to do
(From OE-Core rev: 705eaea991622bdbb2ee83eefa8df8e665e3efe4)
Signed-off-by: André Draszik <andre.draszik@jci.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since gnomebase class already inherits autotools and pkgconfig,
there is no need to repeat it here.
(From OE-Core rev: 301d153781c7ddb6e38178c56f960e18d62788ab)
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a fr_FR locale is found, it is automatically tested. The test
will fail if the locale is UTF-8, as the test blindly assumes
(and expects) a non-UTF fr_FR locale.
The remedy is to skip the test.
[YOCTO #12215]
(From OE-Core rev: 4cedddb83623c79980b354642dfeaf78218ca4b7)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
update-ca-certificates symlinks (trusted) certificates
from $CERTSDIR or $LOCALCERTSDIR into $ETCCERTSDIR.
update-ca-certificates can call hook scripts installed
into /etc/ca-certificates/update.d. Those scripts are
passed the pem file in /etc/ssl/certs/ that was added or
removed in this run and those pem files are absolute
symlinks into $CERTSDIR or $LOCALCERTSDIR at the moment.
When running update-ca-certificates during image build
time, they thusly all point into the host's file system,
not into the $SYSROOT. This means:
* the host's file system layout must match the one
produced by OE, and
* it also means that the host must have installed the same
(or more) certificates as the target in $CERTSDIR and
$LOCALCERTSDIR
This is a problem when wanting to execute hook scripts,
because they all need to be taught about $SYSROOT, and
behave differently depending on whether they're called
at image build time, or on the target, as otherwise they
will be trying to actually read the host's certificates
from $CERTSDIR or $LOCALCERTSDIR.
This also is a problem when running anything else during
image build time that depends on the trusted CA
certificates.
Changing the symlink to be relative solves all of these
problems. At the same time, we have to make sure to add
$CERTSDIR to SYSROOT_DIRS, so that the symlinks are still
valid when somebody DEPENDS on ca-certificates-native. As
a side-effect, this also fixes a problem in meta-java,
where some recipes (e.g. openjdk-8-native) try to access
certificates from $CERTSDIR to generate the java trustStore
at build time.
Do so.
Upstream-Status: Inappropriate [OE-specific]
(From OE-Core rev: 09bb7718d74573be9a5db4d0737fb14126f6489c)
Signed-off-by: André Draszik <andre.draszik@jci.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fies security warnings
| sign.c:86:31: error: 'sprintf' may write a terminating nul past the end of the destination [-Werror=format-overflow=]
| sprintf(fullfn, "%s/%s", tree, tempfn);
(From OE-Core rev: 7171e96f3a5f54c63674cf5282aea31bcb9cd7f9)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
patch 0001-include-stdint.h-for-SSIZE_MAX-and-SIZE_MAX-definiti.patch remove
as it is included in update
(From OE-Core rev: 3f203582ac646f96e6b86ec4b19721e7a78d55f8)
Signed-off-by: Armin Kuster <akuster@mvista.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Debian anonscm service in Alioth is shutdown and thus
fetching ca-certificates sources fails.
https://wiki.debian.org/Alioth
"Alioth is broken, and there is nobody around to fix it. Don't ask the remaining people who give it life support to implement fixes and changes. It is being replaced by a cocktail of ?GitLab (see Salsa), read-only repos and keep-alive mechanisms. See below for more information."
(From OE-Core rev: fc20ff2003cee7ee3b78ba3bc236a60a8caabc35)
Signed-off-by: Mikko Rapeli <mikko.rapeli@bmw.de>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Nativesdk package has a special arrangement where the same thing is done
in do_install(). It was assumed (in the comment) that postinsts don't run when
installing nativesdk packages, but this was incorrect: they are run, but
any failures were previously silently ignored. Now this missing failure reporting has
been fixed, and so we get to see the failures.
(From OE-Core rev: 8ebb695c1429f8d57d655072a362a4f176258699)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
(From OE-Core rev: 9a0465bd26a8359c8b432595589a13f295f2de2d)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
(From OE-Core rev: 268186429d10047796a4801baf95ae8a8f722658)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some architectures e.g. riscv gcc does not add -D_REENTRANT
when enabling pthreads. Help it here by adding these options
while gcc gets fixed
(From OE-Core rev: 784f4418259fe441060c134a7dcf305f4e0d4e2d)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
(From OE-Core rev: f413ae03a61ad8593cc3c0dda11f2bb02cd96c25)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
(From OE-Core rev: 7ae4ce08071c02beaf09675c2c1ed70617b797dd)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
(From OE-Core rev: ca9c8fe634ca91fe1825fae7ebb0d00021ca480b)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
(From OE-Core rev: 9adf817a638229d69d866fd6f8f48ee23caa6864)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
(From OE-Core rev: 91e54d9967d8237abf0cc9aab408bad9bbb4c0b7)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
(From OE-Core rev: 684a2533a2b25b900e12f7da912a2c729d60b69d)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
(From OE-Core rev: e88a184fbefa69233e0cc86134808bce7b06d6cf)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ross Burton
Peter Kjellerstedt
Changqing Li
Zhixiong Chi
Grygorii Tertychnyi
Richard Purdie
Armin Kuster
Sinan Kaya
Khem Raj
Yi Zhao
Jagadeesh Krishnanjanappa
Andre McCurdy
Alex Kiernan
S. Lockwood-Childs
Armin Kuster
André Draszik
Maxin B. John
Juro Bystricky
Mikko Rapeli
Alexander Kanavin
Zhang Xiao