All of lore.kernel.org
 help / color / mirror / Atom feed
From: akuster808 <akuster808@gmail.com>
To: Adrian Bunk <bunk@stusta.de>
Cc: yocto@yoctoproject.org
Subject: Re: [meta-security][PATCH 2/2] sssd: add DISTRO_FEATURE sssd
Date: Sat, 6 Apr 2019 12:25:17 +0530	[thread overview]
Message-ID: <ab895912-7d74-e5ee-ce94-4a57f2c0e481@gmail.com> (raw)
In-Reply-To: <20190406063608.GA3290@localhost>



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




      reply	other threads:[~2019-04-06  6:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-04 22:17 [meta-security][PATCH 1/2] libldb: work around samba libldb packaging issues Armin Kuster
2019-04-04 22:17 ` [meta-security][PATCH 2/2] sssd: add DISTRO_FEATURE sssd Armin Kuster
2019-04-05  4:59   ` Adrian Bunk
2019-04-05  5:35     ` akuster808
2019-04-05  8:19       ` Adrian Bunk
2019-04-06  0:24         ` akuster808
2019-04-06  6:36           ` Adrian Bunk
2019-04-06  6:55             ` akuster808 [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ab895912-7d74-e5ee-ce94-4a57f2c0e481@gmail.com \
    --to=akuster808@gmail.com \
    --cc=bunk@stusta.de \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.