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

[akuster808]

On 4/6/19 12:06 PM, Adrian Bunk wrote:
> On Sat, Apr 06, 2019 at 05:54:35AM +0530, akuster808 wrote:
>>
>> 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?
> X11 and PAM are low-level libraries.
>
> A user might choose to build a distribution without X11 support or 
> without PAM support, and there is no better solution for this.
>
> It is not intended for temporary quick hacks.
>
>>> 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.
> What are you referring to here?
>
>> I do have another option and that is to supply the previous libldb. This
>> I know is standard practice for other layers.
> I actually wonder why sssd currently requires libldb,
> it does not DEPEND on it so is not built against it.
Its hard coded in the configure. it is in the DEPENDs list in the recipe.

>
>>> 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.
> 0001-ldb-Refuse-to-build-Samba-against-a-newer-minor-vers.patch in samba
> seems to have been added to prevent exactly this in the future.
>
>> 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.
> samba uses the internal version and for sssd it is a non-default
> PACKAGECONFIG.
Correct.

>
>>> 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.
> using != maintaining
>
> Users tend to use whatever is provided by a stable series,
> and trust that this is properly security supported.
>
> They cannot even notice that samba has not been updated for warrior
> before warrior becomes a stable series and they start using it.
>
> Creating an automated regular report based on cve_check for master and 
> all supported stable series for several layers might be easy enough.
>
> Currently the output would be depressing for master and worse
> for stable branches.
>
> Actually providing security support by providing properly tested fixes
> for master and 2 supported stable series would be full-time work for
> several people.
yep.  Late we have had 3 stable for a short period while the oldest on
gets it last dot release.

Thanks for you input and feedback

kind regards,
- Armin
>
>> - armin
> cu
> Adrian
>