[oe] samba-essential upgrade or remove?

[Frans Meulenbroeks]

2010/3/15 Holger Hans Peter Freyther <holger+oe at freyther.de>:
> On Monday 15 March 2010 08:30:09 Frans Meulenbroeks wrote:
>
>> Do we feel we have that responsibility?
>>
>> I didn't feel that sentiment when it came to removing other legacy
>> recipes (some of which definitely also will have security issues).
>> E.g. for openssl we have
>> openssl_0.9.7e.bb
>> openssl_0.9.7g.bb
>> openssl_0.9.7m.bb
>> openssl_0.9.8g.bb
>> openssl_0.9.8m.bb
>> I'm pretty certain the last one will fix some vulnerabilities present
>> in the first one.
>
> Well you are comparing two different things here. One is having the _default_
> of a recipe with known security issues, and one is keeping old non default
> recipes with security issues.

I agree they are not really identical issues. Then again it both boils
down to quality of the recipes.
see next remark
>
> If a distro maker decides to use an ancient version of OpenSSL it was his
> choice, if he just typed bitbake foo-image and he has a vulnerable daemon
> waiting to be owned in his default image... the story is a bit different.

Personally I feel it is pretty pointless to have old non-default
recipes in a development head.
If a distro wants to use an ancient version let them create their own
branch (I can perfectly understand that ancient versions are still
present in a stable branch or in a distro specific branch)
>
> I think we have at least three options on how to deal with it:
>
> 1.) Put a big fat warning on Openembedded.org saying it should not be used for
> users that have network connectivity or might put a SDcard/Storage with
> content on a device as we don't care about fixing vulnerable software.

Independent on what we say for the next two options I think we should
do that (although maybe in a different wording)
Our code is provided as is and we do not have the resources (or people
are not interested) to keep up with the latest vulnerabilities and
issues.
Actually it is not even limited to networking code. If you decide to
use an app, it can also be that we are providing an old version that
has a security hole that can be exploited e.g. to gain root access.
>
> 2.) Adopt a policy of addressing vulnerabilities in our defaults right away..
>
> 3.) Remove recipes for vulnerable software when no one is updating them in
> time... This can be combined with option 2...

These are good plans, but I'm not sure if you will get volunteers for
2 and people will definitely complain if you do 3.

Btw: personally I have no big problems with the samba vulnerabilities
(although preferably I would like to have them addressed). I'm using
OE images on some of my systems in home, but they are behind a
firewall so external exploits are less likely. The internal users are
trusted and also not capable to hack the system.

Frans