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

[Adrian Bunk]

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.

> > 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.

> > 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.

> - armin

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed