On Sat, Dec 19, 2020 at 4:08 PM Richard Purdie
<richard.pur...@linuxfoundation.org> wrote:
>
> On Sat, 2020-12-19 at 19:04 +0100, 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.
>
> You could do various things to this from a distro config, e.g.:
>
> DEPRECATED_CRYPTO_FLAGS_pn-openssl = "xxx"
>
> or
>
> DEPRECATED_CRYPTO_FLAGS_pn-openssl_<distrooverride> = "xxx"
>
> DEPRECATED_CRYPTO_FLAGS_pn-openssl_append = " extra-disable"
>
> DEPRECATED_CRYPTO_FLAGS_pn-openssl_remove = "add-me-back"
>
> so I'd say that its not a particularly "hard" assignment?
>
> We could make it a ??= but I'm not sure it would change much practcial
> use as it would almost always be with an override of some sort?
>
> Whilst PACKAGECONFIG is more well known,the variable name here may
> actually improve readability...
Does it? It just looks like an extension of a definition of
PACKAGECONFIG but with the logic all reversed (e.g. instead of adding
FOO to PACKAGECONFIG to enable support for something we now have to
add no-FOO to the new custom variable to disable something). Inverting
the logic of all the options makes it closer to the semantics expected
by the openssl configure scripts, but makes it further from the
semantics expected by someone using OE to configure a package (who is
presumably used to the "add FOO to PACKAGECONFIG to enable something"
convention).
Converting all these options to individual PACKAGECONFIG options but
not adding them to the default value PACKAGECONFIG seems like the
better approach. Users who need to enable a particular algorithm can
then add it to PACKAGECONFIG in the usual way.
In general, disabling old or unused algorithms by default is a good
change though.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#146032):
https://lists.openembedded.org/g/openembedded-core/message/146032
Mute This Topic: https://lists.openembedded.org/mt/79087117/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
