[yocto] [meta-security][PATCH 2/2] sssd: add DISTRO_FEATURE sssd

[akuster808]

On 4/5/19 1:49 PM, Adrian Bunk wrote:
> On Fri, Apr 05, 2019 at 11:05:17AM +0530, akuster808 wrote:
>>
>> On 4/5/19 10:29 AM, Adrian Bunk wrote:
>>> On Fri, Apr 05, 2019 at 03:47:46AM +0530, Armin Kuster wrote:
>>>> Signed-off-by: Armin Kuster <akuster808 at gmail.com>
>>>> ---
>>>>  recipes-security/sssd/sssd_1.16.4.bb | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/recipes-security/sssd/sssd_1.16.4.bb b/recipes-security/sssd/sssd_1.16.4.bb
>>>> index 34bc8c8..d6a308c 100644
>>>> --- a/recipes-security/sssd/sssd_1.16.4.bb
>>>> +++ b/recipes-security/sssd/sssd_1.16.4.bb
>>>> @@ -16,7 +16,7 @@ SRC_URI[sha256sum] = "6bb212cd6b75b918e945c24e7c3f95a486fb54d7f7d489a9334cfa1a1f
>>>>  
>>>>  inherit autotools pkgconfig gettext python-dir distro_features_check
>>>>  
>>>> -REQUIRED_DISTRO_FEATURES = "pam"
>>>> +REQUIRED_DISTRO_FEATURES = "pam sssd"
>>>> ...
>>> Adding a distro feature for a leaf package is wrong.
>> Is it a naming issue or something else? I would like to understand so I
>> may avoid making the same mistake.
> This has nothing to do with naming.
> It is about getting rid of workarounds by fixing the root cause,
> instead of adding more and more layers of workarounds.
>
> A DISTRO_FEATURE is for cases where PACKAGECONFIG in many recipes should 
> be toggled with one setting, or the setting has to be the same in several
> recipes.
The definition is old and needs to be updated to modern time. There a
plenty of recipes that require libraries the we ended up using this
mechanism. Look at the X11 situations. The sssd requires PAM but there
is no PAM config option supported in the recipe so I should remove PAM
to then?
>
> DISTRO_FEATURES is not appropriate to guard a quick hack workaround for
> breakage caused by another workaround.
Its being used in the case of mali support.  So I do see value in able
to use this mechanism in those cases.

I do have another option and that is to supply the previous libldb. This
I know is standard practice for other layers.
>
> The problem at hand is that libldb in meta-openembedded was upgraded to 
> a version not compatible with the version of samba in meta-openembedded.

And that should not have been allowed IMHO.  What is even worse, one can
not install libldb onto a system without seen the same issues so it
appears no one is using it.

>
> As workaroud the libldb shipped in samba was used and installed by 
> the samba recipe.
>
> The proper fix would be to upgrade samba to 4.9 or 4.10,
> and use the external libldb again.
> This would make all problems caused by having two different versions
> of libldb disappear.
>
> If this is not possible, it is likely samba that should stop just 
> shipping the (older versions of) the conflicting binaries for now.
>
> In a semi-related note, the current samba is a pretty outdated even for
> the 4.8 branch and misses several CVE fixes.
Make you wonder if folks are using samba.
- armin
>
> cu
> Adrian
>