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
>>
>>
>>
>>
>>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#146031):
https://lists.openembedded.org/g/openembedded-core/message/146031
Mute This Topic: https://lists.openembedded.org/mt/79087117/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
