Re: [OE-core] [yocto-security] [PATCH] openssl: drop support for deprecated algorithms

["Mark Hatle" <mark.hatle@kernel.crashing.org>]

On 12/19/20 12:04 PM, Konrad Weihmann wrote:
> 
> 
> On 19.12.20 18:58, Richard Purdie wrote:
>> On Sat, 2020-12-19 at 18:53 +0100, Konrad Weihmann wrote:
>>> On 19.12.20 18:36, Richard Purdie wrote:
>>>>    PACKAGECONFIG[cryptodev-linux] = "enable-devcryptoeng,disable-devcryptoeng,cryptodev-linux,,cryptodev-module"
>>>> +PACKAGECONFIG[no-tls1] = "no-tls1"
>>>> +PACKAGECONFIG[no-tls1_1] = "no-tls1_1"
>>>>    
>>>>    B = "${WORKDIR}/build"
>>>>    do_configure[cleandirs] = "${B}"
>>>> @@ -52,6 +54,10 @@ EXTRA_OECONF_class-nativesdk = "--with-rand-seed=os,devrandom"
>>>>    CFLAGS_append_class-native = " -DOPENSSLDIR=/not/builtin -DENGINESDIR=/not/builtin"
>>>>    CFLAGS_append_class-nativesdk = " -DOPENSSLDIR=/not/builtin -DENGINESDIR=/not/builtin"
>>>>    
>>>> +# Disable deprecated crypto algorithms
>>>> +# Retained for compatibilty - des (curl), dh (python-ssl), dsa (rpm)
>>>> +DEPRECATED_CRYPTO_FLAGS = " no-ssl no-idea no-psk no-rc2 no-rc4 no-rc5 no-md2 no-md4 no-srp no-camellia no-bf no-mdc2 no-scrypt no-seed no-siphash no-sm2 no-sm3 no-sm4 no-whirlpool"
>>>> +
>>>   From my perspective this breaks backward compatibility, so I would
>>> rather have them all that as optional PACKAGECONFIG fields (which also
>>> does make it easier for ppl, still relying on one of those algorithms,
>>> for whatever reason, to re-enable them) - with the current approach all
>>> one could do is to override it with a bbappend - and tbh letting ppl
>>> have bbappends for this recipe, doesn't sound like the best idea in the
>>> long run to "enforce" any kind of "security" or "hardening"
>>
>> Having it as a variable does mean you could customise the variable and
>> doesn't mean it has to be done with a bbappend, it can be set from a
>> distro config too.
>>
>> I'm not sure turning each one into a packageconfig is going to be more
>> helpful compared to this in practise...
> 
> I'm not sure I follow, as this is a "hard" assign - if it would (in 
> theory) a ??= assignment, yes then it would be fine. Still that leaves 
> us with a not commonly known variable, while PACKAGECONFIG is more 
> widely accepted in 3rd party layers/distros from my experience.

In the past I had done something similar w/ PACKAGECONFIG, and then had a
comment in the recipe that indicated that certain items were not recommended
with a link to the OpenSSL documentation where it explained that.

It might also be a reasonable idea (security wise, maybe not OE wise) to display
a bb.warn if one of the 'unsafe' crypto algorithms is enabled.

As for someone mentioning that it's unclear if we should be maintaining a list,
in the past there was a list in the OpenSSL documentation.  I would certainly
rely on that list as what should and should not be enabled by default (with
exceptions as appropriate.)

--Mark

>>
>> Cheers,
>>
>> Richard
>>
>>
>>
>> 
>>