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
>