On Tue, Aug 8, 2017 at 11:55 AM, Mark Hatle <mark.ha...@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
> PACKAGECONFIG[hls] = "--enable-hls
> 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
> 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:
> Openembedded-core mailing list
Openembedded-core mailing list