<div dir="ltr">On 8 August 2017 at 18:35, Alexander Kanavin <span dir="ltr"><<a href="mailto:alexander.kanavin@linux.intel.com" target="_blank">alexander.kanavin@linux.intel.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 08/08/2017 06:58 PM, Mark Hatle wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Can we somehow make openssl(10) or nettle a choice when compiling?<br>
<br>
I ask because I've worked on a few systems where people seem to want one<br>
encryption engine for as much of the system as possible (usually openssl).<br>
While gstreamer has not been a problem in such systems, I could see it being<br>
something that would need to be considered.<br>
</blockquote>
<br></span>
This would need to be done across all recipes where such choice is supported, as a 'preferred crypto engine' distro feature. There's been talk of doing this, but I don't remember what was the outcome.<br></blockquote><div><br></div><div>There was a bug for this but I literally closed it earlier today on the grounds that it would mean patching every user of a crypto library to add an abstraction and alternative codepaths. If you don't patch every instance then there is no point in a global option.</div><div><br></div><div>We can have packageconfigs, and expose the choice if the upstream does, but I think the only sane option is to leave it to the user to set the options. It's trivial enough to blacklist openssl if you never want to use it.</div><div><br></div><div>Ross</div></div></div></div>