[OE-core] [PATCH 4/4] xserver-xorg: Add PACKAGECONFIG for crypto libraries
Mark Hatle
mark.hatle at windriver.com
Wed Feb 10 14:44:13 UTC 2016
On 2/10/16 2:25 AM, Jussi Kukkonen wrote:
> On 9 February 2016 at 20:04, Mark Hatle <mark.hatle at windriver.com
> <mailto:mark.hatle at 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 at linaro.org <mailto:nicolas.dechesne at linaro.org>> wrote:
> >>
> >> On Tue, Feb 9, 2016 at 10:24 AM, Jussi Kukkonen
> >> <jussi.kukkonen at intel.com <mailto:jussi.kukkonen at intel.com>> wrote:
> >>> Default to libcrypto (openssl) as before.
> >>>
> >>> Signed-off-by: Jussi Kukkonen <jussi.kukkonen at intel.com <mailto:jussi.kukkonen at 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 at linaro.org
> <mailto:nicolas.dechesne at linaro.org>>
> >> --
> >> _______________________________________________
> >> Openembedded-core mailing list
> >> Openembedded-core at lists.openembedded.org
> <mailto:Openembedded-core at lists.openembedded.org>
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >
> >
> >
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> <mailto:Openembedded-core at lists.openembedded.org>
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
More information about the Openembedded-core
mailing list