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

From: Andre McCurdy <armccurdy@gmail.com>
To: Mark Hatle <mark.hatle@windriver.com>
Cc: OE Core mailing list <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 4/4] gstreamer-plugins-bad: replace openssl dependency with nettle for hls plugin
Date: Tue, 8 Aug 2017 15:54:10 -0700	[thread overview]
Message-ID: <CAJ86T=Xpv9px7d1t9JMieBwO+2AjbEN2xj19ZsjKPTUioZChQQ@mail.gmail.com> (raw)
In-Reply-To: <46243f22-8359-490d-d7fa-aa2ce3280fa8@windriver.com>

On Tue, Aug 8, 2017 at 11:55 AM, Mark Hatle <mark.hatle@windriver.com> wrote:
> On 8/8/17 12:35 PM, Alexander Kanavin 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.
>>
>> Also, the plugin needs to be ported to 1.1 first, as the choice will
>> otherwise be taken away when 1.0 goes EOL.
>
> For now I'm fine with 1.0 support.  So something like:
>
> # ensure OpenSSL is used for HLS AES description instead of nettle
> # (OpenSSL is a shared dependency with dtls)
> PACKAGECONFIG[hls_openssl10]             = "--enable-hls
> --with-hls-crypto=openssl,--disable-hls,openssl10"
>
> PACKAGECONFIG[hls]             = "--enable-hls
> --with-hls-crypto=nettle,--disable-hls,nettle"
>
> But my concern is changing the choice of encryption engine could break various
> existing uses.  (Like I said, -I- don't have that use, but I expect others do..
> perhaps not with gstreamer-plugins-bad though?)

I looked at the gstreamer code briefly and the crypto dependency seems
fairly trivial (basically just AES decryption) so switching between
openssl and nettle doesn't look like it's going to be a big risk (even
for users obliged to avoid the LGPLv3 version of nettle in oe-core).

For reference, the problem with openssl 1.1 seems to be that gstreamer
embeds an openssl EVP_CIPHER_CTX struct directly within the
GstHLSDemuxStream struct, but openssl 1.1 requires that such structs
are now allocated and freed dynamically:

  https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes
  https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/hls/gsthlsdemux.h#n84

>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core