[PATCH 0/4] Crypto dependency fixes

[PATCH 0/4] Crypto dependency fixes

[Jussi Kukkonen]

This is a followup to (but does not strictly depend on) Nicholas'
"[PATCH v2] mesa: upgrade 10.6.3 -> 11.1.1" patch.

It adds packageconfig for xorg-xserver SHA1 implementation, and removes
some unnecessary crypto dependencies.

 - Jussi


The following changes since commit 7d5d8d0cd985edf507c8d00e2e162d1b9fff3589:

  scripts/lib/bsp/engine: trailing whitespace cleanup (2016-02-08 10:54:56 +0000)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib jku/crypto
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=jku/crypto

Jussi Kukkonen (4):
  systemd: Don't depend on gcrypt unnecessarily
  wpa-supplicant: Only depend on libgcrypt when needed
  libsoup-2.4: Remove unnecessary gnutls dependency
  xserver-xorg: Add PACKAGECONFIG for crypto libraries

 .../wpa-supplicant/wpa-supplicant_2.5.bb                     |  4 ++--
 meta/recipes-core/systemd/systemd_228.bb                     |  3 ---
 meta/recipes-graphics/xorg-xserver/xserver-xorg.inc          | 12 +++++++++---
 meta/recipes-support/libsoup/libsoup-2.4_2.52.2.bb           |  2 +-
 4 files changed, 12 insertions(+), 9 deletions(-)

-- 
2.1.4

[PATCH 1/4] systemd: Don't depend on gcrypt unnecessarily

[Jussi Kukkonen]

Since upstream commit 79e8bde40 it's no longer necessary to depend
on gcrypt when --disable-gcrypt is used.

Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
---
 meta/recipes-core/systemd/systemd_228.bb | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/meta/recipes-core/systemd/systemd_228.bb b/meta/recipes-core/systemd/systemd_228.bb
index a110f0c..73338e3 100644
--- a/meta/recipes-core/systemd/systemd_228.bb
+++ b/meta/recipes-core/systemd/systemd_228.bb
@@ -68,9 +68,6 @@ PACKAGECONFIG ??= "compat xz ldconfig \
 PACKAGECONFIG[journal-upload] = "--enable-libcurl,--disable-libcurl,curl"
 # Sign the journal for anti-tampering
 PACKAGECONFIG[gcrypt] = "--enable-gcrypt,--disable-gcrypt,libgcrypt"
-# regardless of PACKAGECONFIG, libgcrypt is always required to expand
-# the AM_PATH_LIBGCRYPT autoconf macro
-DEPENDS += "libgcrypt"
 PACKAGECONFIG[cryptsetup] = "--enable-libcryptsetup,--disable-libcryptsetup,cryptsetup"
 PACKAGECONFIG[microhttpd] = "--enable-microhttpd,--disable-microhttpd,libmicrohttpd"
 PACKAGECONFIG[elfutils] = "--enable-elfutils,--disable-elfutils,elfutils"
-- 
2.1.4

[PATCH 2/4] wpa-supplicant: Only depend on libgcrypt when needed

[Jussi Kukkonen]

Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
---
 meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.5.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.5.bb b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.5.bb
index 2126377..935c8af 100644
--- a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.5.bb
+++ b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.5.bb
@@ -6,11 +6,11 @@ LICENSE = "BSD"
 LIC_FILES_CHKSUM = "file://COPYING;md5=36b27801447e0662ee0138d17fe93880 \
                     file://README;beginline=1;endline=56;md5=7f393579f8b109fe91f3b9765d26c7d3 \
                     file://wpa_supplicant/wpa_supplicant.c;beginline=1;endline=12;md5=3430fda79f2ba1dd545f0b3c4d6e4d24"
-DEPENDS = "dbus libnl libgcrypt"
+DEPENDS = "dbus libnl"
 RRECOMMENDS_${PN} = "wpa-supplicant-passphrase wpa-supplicant-cli"
 
 PACKAGECONFIG ??= "gnutls"
-PACKAGECONFIG[gnutls] = ",,gnutls"
+PACKAGECONFIG[gnutls] = ",,gnutls libgcrypt"
 PACKAGECONFIG[openssl] = ",,openssl"
 
 inherit systemd
-- 
2.1.4

[PATCH 3/4] libsoup-2.4: Remove unnecessary gnutls dependency

[Jussi Kukkonen]

Gnutls is not required: glib-networking handles TLS when it is
installed.

Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
---
 meta/recipes-support/libsoup/libsoup-2.4_2.52.2.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-support/libsoup/libsoup-2.4_2.52.2.bb b/meta/recipes-support/libsoup/libsoup-2.4_2.52.2.bb
index 407f247..3215ff1 100644
--- a/meta/recipes-support/libsoup/libsoup-2.4_2.52.2.bb
+++ b/meta/recipes-support/libsoup/libsoup-2.4_2.52.2.bb
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=5f30f0716dfdd0d91eb439ebec522ec2"
 
 SECTION = "x11/gnome/libs"
 
-DEPENDS = "glib-2.0 glib-2.0-native gnutls libxml2 sqlite3 intltool-native"
+DEPENDS = "glib-2.0 glib-2.0-native libxml2 sqlite3 intltool-native"
 
 EXTRA_OECONF = "--disable-vala"
 
-- 
2.1.4

[PATCH 4/4] xserver-xorg: Add PACKAGECONFIG for crypto libraries

[Jussi Kukkonen]

Default to libcrypto (openssl) as before.

Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
---
 meta/recipes-graphics/xorg-xserver/xserver-xorg.inc | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
index 6648cd3..f4c5469 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
@@ -27,7 +27,7 @@ inherit distro_features_check
 REQUIRED_DISTRO_FEATURES = "x11"
 
 PROTO_DEPS = "randrproto renderproto fixesproto damageproto xextproto xproto xf86dgaproto xf86miscproto xf86vidmodeproto compositeproto recordproto resourceproto videoproto scrnsaverproto  xineramaproto fontsproto kbproto inputproto bigreqsproto xcmiscproto presentproto"
-LIB_DEPS = "pixman libxfont xtrans libxau libxext libxdmcp libdrm libxkbfile libpciaccess openssl libgcrypt"
+LIB_DEPS = "pixman libxfont xtrans libxau libxext libxdmcp libdrm libxkbfile libpciaccess"
 DEPENDS = "${PROTO_DEPS} ${LIB_DEPS} font-util"
 
 # Split out some modules and extensions from the main package
@@ -117,10 +117,10 @@ EXTRA_OECONF += "--with-fop=no \
                  --sysconfdir=/etc/X11 \
                  --localstatedir=/var \
                  --with-xkb-output=/var/lib/xkb \
-                 --with-sha1=libcrypto \
 "
 
-PACKAGECONFIG ??= "dri2 udev ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'dri glx', '', d)} \
+PACKAGECONFIG ??= "dri2 udev ${XORG_CRYPTO} \
+                   ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'dri glx', '', d)} \
                    ${@bb.utils.contains("DISTRO_FEATURES", "wayland", "xwayland", "", d)} \
                    ${@bb.utils.contains("DISTRO_FEATURES", "systemd", "systemd", "", d)} \
 "
@@ -139,6 +139,12 @@ PACKAGECONFIG[systemd] = "--with-systemd-daemon,--without-systemd-daemon,systemd
 PACKAGECONFIG[xinerama] = "--enable-xinerama,--disable-xinerama,xineramaproto"
 PACKAGECONFIG[xwayland] = "--enable-xwayland,--disable-xwayland,wayland libepoxy"
 
+# Xorg requires a SHA1 implementation, pick one
+XORG_CRYPTO ??= "openssl"
+PACKAGECONFIG[openssl] = "--with-sha1=libcrypto,,openssl"
+PACKAGECONFIG[nettle] = "--with-sha1=libnettle,,nettle"
+PACKAGECONFIG[gcrypt] = "--with-sha1=libgcrypt,,libgcrypt"
+
 do_install_append () {
 	# Its assumed base-files creates this for us
 	rmdir ${D}${localstatedir}/log/
-- 
2.1.4

Re: [PATCH 4/4] xserver-xorg: Add PACKAGECONFIG for crypto libraries

[Nicolas Dechesne]

On Tue, Feb 9, 2016 at 10:24 AM, Jussi Kukkonen
<jussi.kukkonen@intel.com> wrote:
> Default to libcrypto (openssl) as before.
>
> Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>

Looks good to me. this is the same implementation I used in the mesa
patch.. so we need to make sure that any review feedback is applied to
both before merging the too, should we get any review feedback.. but
in any case:

Reviewed-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>

Re: [PATCH 4/4] xserver-xorg: Add PACKAGECONFIG for crypto libraries

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 921 bytes --]


> On Feb 9, 2016, at 1:39 AM, Nicolas Dechesne <nicolas.dechesne@linaro.org> wrote:
> 
> On Tue, Feb 9, 2016 at 10:24 AM, Jussi Kukkonen
> <jussi.kukkonen@intel.com> wrote:
>> Default to libcrypto (openssl) as before.
>> 
>> Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
> 
> Looks good to me. this is the same implementation I used in the mesa
> patch.. so we need to make sure that any review feedback is applied to
> both before merging the too,

since its spans multiple recipes would it be better to control it with
a global knob instead of packageconfig.

> should we get any review feedback.. but
> in any case:
> 
> Reviewed-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [PATCH 4/4] xserver-xorg: Add PACKAGECONFIG for crypto libraries

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 516 bytes --]

On 9 February 2016 at 17:54, Khem Raj <raj.khem@gmail.com> wrote:

> > Looks good to me. this is the same implementation I used in the mesa
> > patch.. so we need to make sure that any review feedback is applied to
> > both before merging the too,
>
> since its spans multiple recipes would it be better to control it with
> a global knob instead of packageconfig.


Personally I'm not convinced that two recipes currently sharing a small
piece of configure code warrants a global configuration.

Ross

[-- Attachment #2: Type: text/html, Size: 906 bytes --]

Re: [PATCH 4/4] xserver-xorg: Add PACKAGECONFIG for crypto libraries

[Mark Hatle]

On 2/9/16 11:54 AM, Khem Raj wrote:
> 
>> On Feb 9, 2016, at 1:39 AM, Nicolas Dechesne <nicolas.dechesne@linaro.org> wrote:
>>
>> On Tue, Feb 9, 2016 at 10:24 AM, Jussi Kukkonen
>> <jussi.kukkonen@intel.com> wrote:
>>> Default to libcrypto (openssl) as before.
>>>
>>> Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
>>
>> Looks good to me. this is the same implementation I used in the mesa
>> patch.. so we need to make sure that any review feedback is applied to
>> both before merging the too,
> 
> since its spans multiple recipes would it be better to control it with
> a global knob instead of packageconfig.

I'm not sure it makes sense in -this- case..  but I've more then once thought
that it would be nice for a global distro "this is the preferred crypto engine"
setting.

That way you could do things like default to openssl, libgcrypt, libnss, etc..
whatever is appropriate for the system you are building.  It wouldn't promise
that everything would just use that crypto backend, but things that could -- should.

(This is certainly a more extensive patch then what's being discussed here..)

--Mark

>> should we get any review feedback.. but
>> in any case:
>>
>> Reviewed-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 
> 
> 

Re: [PATCH 4/4] xserver-xorg: Add PACKAGECONFIG for crypto libraries

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 650 bytes --]

On Feb 9, 2016 9:58 AM, "Burton, Ross" <ross.burton@intel.com> wrote:
>
>
> On 9 February 2016 at 17:54, Khem Raj <raj.khem@gmail.com> wrote:
>>
>> > Looks good to me. this is the same implementation I used in the mesa
>> > patch.. so we need to make sure that any review feedback is applied to
>> > both before merging the too,
>>
>> since its spans multiple recipes would it be better to control it with
>> a global knob instead of packageconfig.
>
>
> Personally I'm not convinced that two recipes currently sharing a small
piece of configure code warrants a global configuration.

Think of crypto policy point of view
>
> Ross

[-- Attachment #2: Type: text/html, Size: 931 bytes --]

Re: [PATCH 4/4] xserver-xorg: Add PACKAGECONFIG for crypto libraries

[Nicolas Dechesne]

On Tue, Feb 9, 2016 at 8:04 PM, Khem Raj <raj.khem@gmail.com> wrote:
> Think of crypto policy point of view

why not. this is probably a good thing. But I don't think we should
block the current patches as they are. If we want to add a
DISTRO_FEATURES the patches we did in mesa and xserver are needed
anyways. Once every possible 'crypto' config are available as
PACKAGECONFIG we simply need to add one line to pick the one we need
based on DISTRO_FEATURE content. So I think we should merge them, and
discuss/plan how to add crypto as a distro policy.

Re: [PATCH 4/4] xserver-xorg: Add PACKAGECONFIG for crypto libraries

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 856 bytes --]


> On Feb 9, 2016, at 11:41 AM, Nicolas Dechesne <nicolas.dechesne@linaro.org> wrote:
> 
> On Tue, Feb 9, 2016 at 8:04 PM, Khem Raj <raj.khem@gmail.com> wrote:
>> Think of crypto policy point of view
> 
> why not. this is probably a good thing. But I don't think we should
> block the current patches as they are. If we want to add a
> DISTRO_FEATURES the patches we did in mesa and xserver are needed
> anyways. Once every possible 'crypto' config are available as
> PACKAGECONFIG we simply need to add one line to pick the one we need
> based on DISTRO_FEATURE content. So I think we should merge them, and
> discuss/plan how to add crypto as a distro policy.

Thats ok. However, if there is a time to do something to consolidate crypto backend
policy then such instances are the right one. I know you have a solution for your problem.


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [PATCH 4/4] xserver-xorg: Add PACKAGECONFIG for crypto libraries

[Jussi Kukkonen]

[-- Attachment #1: Type: text/plain, Size: 2413 bytes --]

On 9 February 2016 at 20:04, Mark Hatle <mark.hatle@windriver.com> wrote:

> On 2/9/16 11:54 AM, Khem Raj wrote:
> >
> >> On Feb 9, 2016, at 1:39 AM, Nicolas Dechesne <
> nicolas.dechesne@linaro.org> wrote:
> >>
> >> On Tue, Feb 9, 2016 at 10:24 AM, Jussi Kukkonen
> >> <jussi.kukkonen@intel.com> wrote:
> >>> Default to libcrypto (openssl) as before.
> >>>
> >>> Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
> >>
> >> Looks good to me. this is the same implementation I used in the mesa
> >> patch.. so we need to make sure that any review feedback is applied to
> >> both before merging the too,
> >
> > since its spans multiple recipes would it be better to control it with
> > a global knob instead of packageconfig.
>
> I'm not sure it makes sense in -this- case..  but I've more then once
> thought
> that it would be nice for a global distro "this is the preferred crypto
> engine"
> setting.
>
> That way you could do things like default to openssl, libgcrypt, libnss,
> etc..
> whatever is appropriate for the system you are building.  It wouldn't
> promise
> that everything would just use that crypto backend, but things that could
> -- should.


I was wondering if something like this was possible as well: that's how I
got into reviewing the reverse dependencies of openssl & gnutls.

There are some cases that might make this effort not worth the trouble:
SHA1 is easy and switching implementations is something upstream projects
want to support but with e.g. TLS it is not always so: An example is
glib-networking with only gnutls for TLS support*.

Jussi


*) There's a "wip/openssl" branch of glib-networking so this might get
fixed in future releases .



(This is certainly a more extensive patch then what's being discussed
> here..)
>
> --Mark
>
> >> should we get any review feedback.. but
> >> in any case:
> >>
> >> Reviewed-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
> >> --
> >> _______________________________________________
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >
> >
> >
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 3961 bytes --]

Re: [PATCH 4/4] xserver-xorg: Add PACKAGECONFIG for crypto libraries

[Mark Hatle]

On 2/10/16 2:25 AM, Jussi Kukkonen wrote:
> On 9 February 2016 at 20:04, Mark Hatle <mark.hatle@windriver.com
> <mailto:mark.hatle@windriver.com>> wrote:
> 
>     On 2/9/16 11:54 AM, Khem Raj wrote:
>     >
>     >> On Feb 9, 2016, at 1:39 AM, Nicolas Dechesne <nicolas.dechesne@linaro.org <mailto:nicolas.dechesne@linaro.org>> wrote:
>     >>
>     >> On Tue, Feb 9, 2016 at 10:24 AM, Jussi Kukkonen
>     >> <jussi.kukkonen@intel.com <mailto:jussi.kukkonen@intel.com>> wrote:
>     >>> Default to libcrypto (openssl) as before.
>     >>>
>     >>> Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com <mailto:jussi.kukkonen@intel.com>>
>     >>
>     >> Looks good to me. this is the same implementation I used in the mesa
>     >> patch.. so we need to make sure that any review feedback is applied to
>     >> both before merging the too,
>     >
>     > since its spans multiple recipes would it be better to control it with
>     > a global knob instead of packageconfig.
> 
>     I'm not sure it makes sense in -this- case..  but I've more then once thought
>     that it would be nice for a global distro "this is the preferred crypto engine"
>     setting.
> 
>     That way you could do things like default to openssl, libgcrypt, libnss, etc..
>     whatever is appropriate for the system you are building.  It wouldn't promise
>     that everything would just use that crypto backend, but things that could --
>     should.
> 
> 
> I was wondering if something like this was possible as well: that's how I got
> into reviewing the reverse dependencies of openssl & gnutls. 
> 
> There are some cases that might make this effort not worth the trouble: SHA1 is
> easy and switching implementations is something upstream projects want to
> support but with e.g. TLS it is not always so: An example is glib-networking
> with only gnutls for TLS support*.

This is why I suggest it isn't an all or nothing, but instead a hint for the
recipes that support multiple crypto backends.

In one of my products, we use OpenSSL (w/ the FIPS module) as the primary crypto
engine for the system.  We had to configure a number of recipes/packageconfig
settings to use OpenSSL as the primary crypto engine.

It would have been much easier to just set a single distribution setting and
then update the recipes to pay attention to the single setting.

--Mark

> Jussi
> 
> 
> *) There's a "wip/openssl" branch of glib-networking so this might get fixed in
> future releases .
> 
> 
> 
>     (This is certainly a more extensive patch then what's being discussed here..)
> 
>     --Mark
> 
>     >> should we get any review feedback.. but
>     >> in any case:
>     >>
>     >> Reviewed-by: Nicolas Dechesne <nicolas.dechesne@linaro.org
>     <mailto:nicolas.dechesne@linaro.org>>
>     >> --
>     >> _______________________________________________
>     >> Openembedded-core mailing list
>     >> Openembedded-core@lists.openembedded.org
>     <mailto:Openembedded-core@lists.openembedded.org>
>     >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>     >
>     >
>     >
> 
>     --
>     _______________________________________________
>     Openembedded-core mailing list
>     Openembedded-core@lists.openembedded.org
>     <mailto:Openembedded-core@lists.openembedded.org>
>     http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 
>