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 <akuster...@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 > -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
