Re: [PATCH 4/4] gstreamer-plugins-bad: replace openssl dependency with nettle for hls plugin

[Mark Hatle <mark.hatle@windriver.com>]

On 8/8/17 2:14 PM, Burton, Ross wrote:
> On 8 August 2017 at 18:35, Alexander Kanavin <alexander.kanavin@linux.intel.com
> <mailto:alexander.kanavin@linux.intel.com>> wrote:
> 
>     On 08/08/2017 06:58 PM, Mark Hatle wrote:
> 
>         Can we somehow make openssl(10) or nettle a choice when compiling?
> 
>         I ask because I've worked on a few systems where people seem to want one
>         encryption engine for as much of the system as possible (usually openssl).
>         While gstreamer has not been a problem in such systems, I could see it being
>         something that would need to be considered.
> 
> 
>     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.
> 
> 
> 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.

Getting a bit off-topic here, but...

I do expect that at some point in the future someone will come along and offer a
distribution wide setting for preferred (and alternative) encryption and make
the associated changes to the various recipes to enforce this.

Many of the systems I am working with are starting to have those types of needs.
 A preferred encryption resource that everything that can - should use.  Along
with alternatives that are 'acceptable' if the primary isn't available.
Otherwise other encryption would be prohibited and should trigger an automatic
blacklist or failure.

(In this case, there is a lot of work to be done, and potentially any encryption
user/provider [even internal] needs to be audited.  This is not an 'over night'
process... thus I doubt you'll be seeing it tomorrow from anyone here.)

So don't necessarily dismiss the idea -- but I do think it's outside of the
immediate scope for the Yocto Project itself, but I would expect something to
eventually be presented by a member of the larger OpenEmbedded community.

--Mark

> 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.
> 
> Ross