Skip to contentSkip to conversation

Crypto dependency fixes

PATCH In review Jussi Kukkonen 5 participants 14 messages Feb 9, 2016 – Feb 10, 2016

lore
Share & tools
lore

Jussi Kukkonen

author
#0 lore raw

cover Crypto dependency fixes

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(-)
Signature · 1 line
2.1.4
author
#1 lore raw

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

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

Signed-off-by Jussi Kukkonen <[email protected]>
---
 meta/recipes-core/systemd/systemd_228.bb | 3 ---
 1 file changed, 3 deletions(-)
meta/recipes-core/systemd/systemd_228.bb +0 -3
index a110f0c..73338e3 100644
@@ -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"
Signature · 1 line
2.1.4
author
#2 lore raw

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

Signed-off-by Jussi Kukkonen <[email protected]>
---
 meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.5.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.5.bb +2 -2
index 2126377..935c8af 100644
@@ -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
Signature · 1 line
2.1.4
author
#3 lore raw

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

In reply to Jussi Kukkonen

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

Signed-off-by Jussi Kukkonen <[email protected]>
---
 meta/recipes-support/libsoup/libsoup-2.4_2.52.2.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
meta/recipes-support/libsoup/libsoup-2.4_2.52.2.bb +1 -1
index 407f247..3215ff1 100644
@@ -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"
Signature · 1 line
2.1.4
author
#4 lore raw

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

In reply to Jussi Kukkonen

Default to libcrypto (openssl) as before.

Signed-off-by Jussi Kukkonen <[email protected]>
---
 meta/recipes-graphics/xorg-xserver/xserver-xorg.inc | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)
meta/recipes-graphics/xorg-xserver/xserver-xorg.inc +9 -3
index 6648cd3..f4c5469 100644
@@ -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/
Signature · 1 line
2.1.4
Reviewed-by on v1 4/4
#5 lore raw

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

Quoted 3 lines · Jussi Kukkonen

Default to libcrypto (openssl) as before.

Signed-off-by Jussi Kukkonen <[email protected]>

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 <[email protected]>
#6 lore raw

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

Quoted 12 lines · Nicolas Dechesne
Quoted 3 lines · Jussi Kukkonen

Default to libcrypto (openssl) as before.

Signed-off-by Jussi Kukkonen <[email protected]>

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.

Quoted 9 lines

should we get any review feedback.. but
in any case:

Reviewed-by Nicolas Dechesne <[email protected]>

--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

#7 lore raw

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

Quoted 6 lines · Khem Raj
Quoted 3 lines

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

#8 lore raw

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

Quoted 8 lines · Ross
Quoted 5 lines · Khem Raj
Quoted 4 lines

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,

Quoted 5 lines
Quoted 2 lines

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

Quoted 2 lines

Ross

#9 lore raw

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

Quoted 1 line · Khem Raj

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.

#10 lore raw

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

Quoted 6 lines · Nicolas Dechesne
Quoted 1 line · Khem Raj

Think of crypto policy point of view

Quoted 7 lines

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.

#11 lore raw

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

In reply to Khem Raj
Quoted 7 lines · Khem Raj
Quoted 7 lines · Nicolas Dechesne
Quoted 2 lines · Jussi Kukkonen

Default to libcrypto (openssl) as before.

Quoted 8 lines
Quoted 5 lines
Quoted 1 line
Signed-off-by Jussi Kukkonen <[email protected]>

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

Quoted 12 lines
Quoted 9 lines

should we get any review feedback.. but
in any case:

Reviewed-by Nicolas Dechesne <[email protected]>

--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

author
#12 lore raw

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

Quoted 24 lines · Mark Hatle
Quoted 2 lines · Khem Raj
Quoted 2 lines

On Feb 9, 2016, at 1:39 AM, Nicolas Dechesne <

Quoted 5 lines · [email protected]> wrote:
Quoted 5 lines
Quoted 2 lines · Jussi Kukkonen

Default to libcrypto (openssl) as before.

Quoted 8 lines
Quoted 5 lines
Quoted 1 line
Signed-off-by Jussi Kukkonen <[email protected]>

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.

Quoted 6 lines

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

Quoted 23 lines

here..)

--Mark

Quoted 12 lines
Quoted 9 lines

should we get any review feedback.. but
in any case:

Reviewed-by Nicolas Dechesne <[email protected]>

--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

#13 lore raw

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

Quoted 30 lines · Jussi Kukkonen

On 9 February 2016 at 20:04, Mark Hatle <[email protected] <mailto:[email protected]>> wrote:

On 2/9/16 11:54 AM, Khem Raj wrote:
>
>> On Feb 9, 2016, at 1:39 AM, Nicolas Dechesne <[email protected] <mailto:[email protected]>> wrote:
>>
>> On Tue, Feb 9, 2016 at 10:24 AM, Jussi Kukkonen
>> <[email protected] <mailto:[email protected]>> wrote:
>>> Default to libcrypto (openssl) as before.
>>>
>>> Signed-off-by: Jussi Kukkonen <[email protected] <mailto:[email protected]>>
>>
>> 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.

Quoted 7 lines

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

Quoted 35 lines

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 <[email protected]
    <mailto:[email protected]>>
    >> --
    >> _______________________________________________
    >> Openembedded-core mailing list
    >> [email protected]
    <mailto:[email protected]>
    >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
    >
    >
    >

    --
    _______________________________________________
    Openembedded-core mailing list
    [email protected]
    <mailto:[email protected]>
    http://lists.openembedded.org/mailman/listinfo/openembedded-core