openembedded-core.git/meta/recipes-connectivity, branch master

bind: Security fix CVE-2016-6170

2017-04-28T10:26:07+00:00

CVE-2016-6170: ISC BIND through 9.9.9-P1, 9.10.x through 9.10.4-P1, and
9.11.x through 9.11.0b1 allows primary DNS servers to cause a denial of
service (secondary DNS server crash) via a large AXFR response, and
possibly allows IXFR servers to cause a denial of service (IXFR client
crash) via a large IXFR response and allows remote authenticated users
to cause a denial of service (primary DNS server crash) via a large
UPDATE message.

External References:
https://nvd.nist.gov/vuln/detail/CVE-2016-6170

Patch from:
https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=commit;h=1bbcfe2fc84f57b1e4e075fb3bc2a1dd0a3a851f

Signed-off-by: Yi Zhao 
Signed-off-by: Ross Burton

bind: Security fix CVE-2016-8864

2017-04-28T10:26:07+00:00

CVE-2016-8864: named in ISC BIND 9.x before 9.9.9-P4, 9.10.x before
9.10.4-P4, and 9.11.x before 9.11.0-P1 allows remote attackers to cause
a denial of service (assertion failure and daemon exit) via a DNAME
record in the answer section of a response to a recursive query,
related to db.c and resolver.c.

External References:
https://nvd.nist.gov/vuln/detail/CVE-2016-8864

Patch from:
https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=commit;h=c1d0599a246f646d1c22018f8fa09459270a44b8

Signed-off-by: Yi Zhao 
Signed-off-by: Ross Burton

openssl: Bump SONAME to match the ABI

2017-04-21T07:22:03+00:00

Commit 7933fbbc637 "Security fix Drown via 1.0.2g update" included
a version-script change from Debian that was an ABI change. It did
not include the soname change that Debian did so we have been calling
our ABI 1.0.0 but it really matches what others call 1.0.2.

Bump SONAME to match the ABI. In practice this changes both libcrypto
and libssl sonames from 1.0.0 to 1.0.2.

For background: Upstream does not do sonames so these are set by
distros. In this case the ABI changes based on a build time
configuration! Debian took the ABI changing configuration and bumped
soname but e.g. Ubuntu kept the deprecated API and just made it not
work, keeping soname. So both have same version of openssl but support
different ABI (and expose different SONAME).

Fixes [YOCTO #11396].

Thanks to Alexander Larsson et al for detective work.

Signed-off-by: Jussi Kukkonen 
Signed-off-by: Ross Burton

Revert "openssl: Fix symlink creation"

2017-04-19T09:16:41+00:00

This reverts commit 991620f3962a9917fa99abb5582f4b72ebd42a3d.

The commit breaks openssl-native (you can no longer generate keys
because it can't find the configuration file). Also the idea that we
would install configuration files normally but then add the symlinks
pointing to them in a postinstall feels wrong.

Fixes [YOCTO #11296]. The bug contains an alternative fix but I'm
sending a revert as I cannot fully understand the motive of the
original patch. See also discussion in
http://lists.openembedded.org/pipermail/openembedded-core/2017-April/135176.html

Signed-off-by: Jussi Kukkonen 
Signed-off-by: Ross Burton

openssl: fix the reference to native perl in ptests

2017-04-11T17:09:20+00:00

This was causing a couple of ptest failures.

[YOCTO #10840]

Signed-off-by: Alexander Kanavin 
Signed-off-by: Richard Purdie

openssl: add a "openssl10" PROVIDES

2017-03-31T11:07:40+00:00

In 2.4 development cycle openssl 1.1 will replace openssl 1.0 as the
default openssl version. Openssl 1.0 will stay but will be renamed
to openssl10, and eventually it will be removed (hopefully much
sooner than the official end of support date of Dec 2019, as we do not
want an unsupported openssl version in supported Yocto releases).

There are several recipes that are not API compatible with 1.1; some
of them will eventually be fixed, but others will never be (such as Qt4).
To avoid breaking such recipes when openssl 1.1 is added to oe-core,
let's provide "openssl10" already now and change the recipes to depend
on that where necessary; Qt4 is a particularly pressing issue as it is
causing failures on the autobuilder with my work in progress
openssl 1.1 branch, and so I'm not able to see what else would fail
later in the build process.

Signed-off-by: Alexander Kanavin 
Signed-off-by: Richard Purdie

openssl: Fix regression when building for thumb2

2017-03-31T09:09:58+00:00

Commit 'c8da8ce openssl: Fix build with clang' introduced a regression.
do_compile fails when building with gcc/thumb2.

Note that I did not test if it still builds with clang.

Prevents the following when building with thumb2:

| ghash-armv4.S: Assembler messages:
| ghash-armv4.S:88: Error: thumb conditional instruction should be in IT block -- `ldrplb r12,[r2,r3]'
| ghash-armv4.S:98: conditional infixes are deprecated in unified syntax
| ghash-armv4.S:98: Error: thumb conditional instruction should be in IT block -- `ldrplb r8,[r0,r3]'
| ghash-armv4.S:105: Error: thumb conditional instruction should be in IT block -- `eorpl r12,r12,r8'
| ghash-armv4.S:107: Error: thumb conditional instruction should be in IT block -- `andpl r14,r12,#0xf0'
| ghash-armv4.S:108: Error: thumb conditional instruction should be in IT block -- `andpl r12,r12,#0x0f'
| ghash-armv4.S:144: conditional infixes are deprecated in unified syntax
| ghash-armv4.S:144: Error: thumb conditional instruction should be in IT block -- `ldrneb r12,[r2,#15]'
| ghash-armv4.S:231: conditional infixes are deprecated in unified syntax
| ghash-armv4.S:231: Error: thumb conditional instruction should be in IT block -- `ldrplb r12,[r0,r3]'
| ghash-armv4.S:248: Error: thumb conditional instruction should be in IT block -- `andpl r14,r12,#0xf0'
| ghash-armv4.S:249: Error: thumb conditional instruction should be in IT block -- `andpl r12,r12,#0x0f'

Signed-off-by: Max Krummenacher 
Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie

openssl: Fix build with clang

2017-03-21T22:43:03+00:00

Signed-off-by: Khem Raj 
Signed-off-by: Ross Burton

neard: Fix parallel build issue

2017-03-17T16:56:02+00:00

This only started showing up now for some reason but it does seem like
a legitimate bug in Makefile.am.

Signed-off-by: Jussi Kukkonen 
Signed-off-by: Richard Purdie

openssl: Disable make's -e flag without breaking ${AR}

2017-03-17T15:37:05+00:00

The OpenSSL recipe tried to workaround the -e make flag (overriding
variables from the environment). And when the -e flag was dropped as
the global default, it was specifically added for OpenSSL. This is
unnecessary, as only the value of ${AR} seems to be affected, and that
can be handled correctly by OpenSSL's build system if we just let it.

Signed-off-by: Olof Johansson 
Signed-off-by: Peter Kjellerstedt 
Signed-off-by: Ross Burton