<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 9 February 2016 at 20:04, Mark Hatle <span dir="ltr"><<a href="mailto:mark.hatle@windriver.com" target="_blank">mark.hatle@windriver.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 2/9/16 11:54 AM, Khem Raj wrote:<br>
><br>
>> On Feb 9, 2016, at 1:39 AM, Nicolas Dechesne <<a href="mailto:nicolas.dechesne@linaro.org" target="_blank">nicolas.dechesne@linaro.org</a>> wrote:<br>
>><br>
>> On Tue, Feb 9, 2016 at 10:24 AM, Jussi Kukkonen<br>
>> <<a href="mailto:jussi.kukkonen@intel.com" target="_blank">jussi.kukkonen@intel.com</a>> wrote:<br>
>>> Default to libcrypto (openssl) as before.<br>
>>><br>
>>> Signed-off-by: Jussi Kukkonen <<a href="mailto:jussi.kukkonen@intel.com" target="_blank">jussi.kukkonen@intel.com</a>><br>
>><br>
>> Looks good to me. this is the same implementation I used in the mesa<br>
>> patch.. so we need to make sure that any review feedback is applied to<br>
>> both before merging the too,<br>
><br>
> since its spans multiple recipes would it be better to control it with<br>
> a global knob instead of packageconfig.<br>
<br>
</span>I'm not sure it makes sense in -this- case.. but I've more then once thought<br>
that it would be nice for a global distro "this is the preferred crypto engine"<br>
setting.<br>
<br>
That way you could do things like default to openssl, libgcrypt, libnss, etc..<br>
whatever is appropriate for the system you are building. It wouldn't promise<br>
that everything would just use that crypto backend, but things that could -- should.</blockquote><div><br></div><div>I was wondering if something like this was possible as well: that's how I got into reviewing the reverse dependencies of openssl & gnutls. </div><div><br></div><div>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*.</div><div><br></div><div>Jussi</div><div><br></div><div><br></div><div>*) There's a "wip/openssl" branch of glib-networking so this might get fixed in future releases .</div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(This is certainly a more extensive patch then what's being discussed here..)<br>
<span><font color="#888888"><br>
--Mark<br>
</font></span><div><div><br>
>> should we get any review feedback.. but<br>
>> in any case:<br>
>><br>
>> Reviewed-by: Nicolas Dechesne <<a href="mailto:nicolas.dechesne@linaro.org" target="_blank">nicolas.dechesne@linaro.org</a>><br>
>> --<br>
>> _______________________________________________<br>
>> Openembedded-core mailing list<br>
>> <a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openembedded.org</a><br>
>> <a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
><br>
><br>
><br>
<br>
--<br>
_______________________________________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
</div></div></blockquote></div><br></div></div>