samba-essential upgrade or remove?

samba-essential upgrade or remove?

[Holger Hans Peter Freyther]

Hi all,

samba-essential is currently based on the 3.0.x series of samba that has 
reached end of life. Our current version is 3.0.20, the latest upstream is 
3.0.37, the stable 3.5.x series was just opened...

So what should we do? There is currently no in tree usage of samba-essential, 
should we drop it?

z.

Re: samba-essential upgrade or remove?

[Dr. Michael Lauer]

While I'm not using it atm., I recall that samba-essential was the only recipe that worked relatively
painless when Matthias Hentges create it back then.

:M:

Re: samba-essential upgrade or remove?

[Holger Hans Peter Freyther]

On Monday 08 March 2010 13:42:07 Dr. Michael Lauer wrote:
> While I'm not using it atm., I recall that samba-essential was the only
> recipe that worked relatively painless when Matthias Hentges create it
> back then.

Then please fix it. You will do a great service to our users. The following 
CVEs are not addressed:
	CVE-2009-2813, CVE-2009-2948, CVE-2009-2906, CVE-2009-1888, 
CVE-2008-4314, CVE-2008-1105, CVE-2007-6015, CVS-2007-4572,  CVE-2007-5398, 
CVE-2007-2444, CVE-2007-2446, CVE-2007-2447, CVE-2007-0452, CVE-2007-0453, 
CVE-2007-0454, CAN-2006-1059..

most of these are overflows and DoS

z.

Re: samba-essential upgrade or remove?

[Holger Hans Peter Freyther]

On Monday 08 March 2010 13:51:35 Holger Hans Peter Freyther wrote:
> On Monday 08 March 2010 13:42:07 Dr. Michael Lauer wrote:
> > While I'm not using it atm., I recall that samba-essential was the only
> > recipe that worked relatively painless when Matthias Hentges create it
> > back then.
> 
> Then please fix it. You will do a great service to our users. The following
> CVEs are not addressed:
> 	CVE-2009-2813, CVE-2009-2948, CVE-2009-2906, CVE-2009-1888,
> CVE-2008-4314, CVE-2008-1105, CVE-2007-6015, CVS-2007-4572,  CVE-2007-5398,
> CVE-2007-2444, CVE-2007-2446, CVE-2007-2447, CVE-2007-0452, CVE-2007-0453,
> CVE-2007-0454, CAN-2006-1059..


any update? Is anyone volunteering to update samba-essential or shall we 
remove it from the tree? I think we have a responsibility to our users that if 
we install a network daemon that we at least fix the known security issues with 
this one or remove it from our recipe collection... Opinions?

z.

Re: samba-essential upgrade or remove?

[Frans Meulenbroeks]

2010/3/15 Holger Hans Peter Freyther <holger+oe@freyther.de>:
> On Monday 08 March 2010 13:51:35 Holger Hans Peter Freyther wrote:
>> On Monday 08 March 2010 13:42:07 Dr. Michael Lauer wrote:
>> > While I'm not using it atm., I recall that samba-essential was the only
>> > recipe that worked relatively painless when Matthias Hentges create it
>> > back then.
>>
>> Then please fix it. You will do a great service to our users. The following
>> CVEs are not addressed:
>>       CVE-2009-2813, CVE-2009-2948, CVE-2009-2906, CVE-2009-1888,
>> CVE-2008-4314, CVE-2008-1105, CVE-2007-6015, CVS-2007-4572,  CVE-2007-5398,
>> CVE-2007-2444, CVE-2007-2446, CVE-2007-2447, CVE-2007-0452, CVE-2007-0453,
>> CVE-2007-0454, CAN-2006-1059..
>
>
> any update? Is anyone volunteering to update samba-essential or shall we
> remove it from the tree? I think we have a responsibility to our users that if
> we install a network daemon that we at least fix the known security issues with
> this one or remove it from our recipe collection... Opinions?

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.

The same probably holds for all network related stuff (nfs, apache,
php, cups, ...)

Btw this is not a volunteering proposal from my side. I haven't
recovered from being burned last time.

Frans

PS: I'm in favour of keeping samba-essential. In an embedded system
lightweight solutions are often desirable.

Re: samba-essential upgrade or remove?

[Holger Hans Peter Freyther]

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.

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.

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.

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


z.

Re: samba-essential upgrade or remove?

[Frans Meulenbroeks]

2010/3/15 Holger Hans Peter Freyther <holger+oe@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

Re: samba-essential upgrade or remove?

[Martin Jansa]

On Mon, Mar 15, 2010 at 09:08:24AM +0100, Frans Meulenbroeks wrote:
> > 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.

For security issues would be nice to adopt some form of Angstrom
blacklist class and put blacklist entry for all vulnerable recipes in
some security-blacklist.conf included from bitbake.conf.

This way it would be easy to show why the recipe is not available (CVE
noted in message shown by blacklist when some image tries to pull that
recipe).

Also it would allow easy blacklist removal for people who don't care
about security and easy to return recipe if someone cares and puts
enough time to fix that issue.

But current code would probably need to extend for blacklist based on
PN-PV not only PN (which someone already proposed for blacklisting old
recipes).

Regards,

-- 
uin:136542059                jid:Martin.Jansa@gmail.com
Jansa Martin                 sip:jamasip@voip.wengo.fr 
JaMa                         

Re: samba-essential upgrade or remove?

[Dr. Michael Lauer]

Am 15.03.2010 um 08:46 schrieb Holger Hans Peter Freyther:

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

Gets my vote; however with less dramatic wording.

:M:

Re: samba-essential upgrade or remove?

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 15-03-10 08:46, Holger Hans Peter Freyther wrote:
> 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.
> 
> 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.
> 
> 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.
> 
> 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...

I don't think 1) is a realistic option, if we go with that, we should
just redirect oe.org to buildroot.org and go home.

I my vote goes to 2) and I like 3) as well.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLnf44MkyGM64RGpERAmzaAKCp0hTPChpWBSA+ZNOu4EONro5SdACggdvk
i1RVEm4+eqwaPItxFiYzE9Q=
=2RGA
-----END PGP SIGNATURE-----

Re: samba-essential upgrade or remove?

[Frans Meulenbroeks]

2010/3/15 Koen Kooi <k.kooi@student.utwente.nl>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 15-03-10 08:46, Holger Hans Peter Freyther wrote:
>>
>> 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.
>>
>> 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...
>
> I don't think 1) is a realistic option, if we go with that, we should
> just redirect oe.org to buildroot.org and go home.

Why is it not realistic.
Lots of driver code I get from commercial vendors, contain statements like
"this is sample code only, not intended for use in products, proceed
at own risk, bla bla bla".

And frankly speaking I doubt that we have the resources to actually
make sure that we fix all known security vulnerabilities shortly after
a fix becomes available.

So a +1 for having a warning on the OE website. Actually I would
suggest repeating the message on the getting started page
(http://wiki.openembedded.net/index.php/Getting_Started)

(and of course each distro can decide on their own whether they want
to have such a warning on their website or not).

Frans

>
> I my vote goes to 2) and I like 3) as well.
>

> regards,
>
> Koen

Re: samba-essential upgrade or remove?

[Holger Hans Peter Freyther]

On Monday 15 March 2010 10:51:33 Frans Meulenbroeks wrote:

> > I don't think 1) is a realistic option, if we go with that, we should
> > just redirect oe.org to buildroot.org and go home.
> 
> Why is it not realistic.
> Lots of driver code I get from commercial vendors, contain statements like
> "this is sample code only, not intended for use in products, proceed
> at own risk, bla bla bla".

You are mixing two things again. One is warranty and of course our MIT license 
says that the stuff comes "as is" without warranty and such. The other is what 
do we want to try. I think we should folllow CVEs and have no known security 
issues in our default set (bitbake -s).

Re: samba-essential upgrade or remove?

[Frans Meulenbroeks]

2010/3/15 Holger Hans Peter Freyther <holger+oe@freyther.de>:
> On Monday 15 March 2010 10:51:33 Frans Meulenbroeks wrote:
>
>> > I don't think 1) is a realistic option, if we go with that, we should
>> > just redirect oe.org to buildroot.org and go home.
>>
>> Why is it not realistic.
>> Lots of driver code I get from commercial vendors, contain statements like
>> "this is sample code only, not intended for use in products, proceed
>> at own risk, bla bla bla".
>
> You are mixing two things again. One is warranty and of course our MIT license
> says that the stuff comes "as is" without warranty and such. The other is what
> do we want to try. I think we should folllow CVEs and have no known security
> issues in our default set (bitbake -s).

Be my guest :-)
Given the hostile attitude of some people here, I'm becoming less and
less interested to contribute.
Guess some will be happy about that :-(

Frans

Re: samba-essential upgrade or remove?

[Holger Hans Peter Freyther]

On Monday 15 March 2010 19:20:33 Frans Meulenbroeks wrote:
> 2010/3/15 Holger Hans Peter Freyther <holger+oe@freyther.de>:

> > You are mixing two things again. One is warranty and of course our MIT
> > license says that the stuff comes "as is" without warranty and such. The
> > other is what do we want to try. I think we should folllow CVEs and have
> > no known security issues in our default set (bitbake -s).
> 
> Be my guest :-)
> Given the hostile attitude of some people here, I'm becoming less and
> less interested to contribute.
> Guess some will be happy about that :-(

Well,
innovation comes by changing the status-quo, which implies a degree of 
breakage and no one likes to wake up and do a build and find his/her stuff is 
broken. Of course we do want to have progress and you do have supporters as 
well. E.g. after the autoconf change Graeme, me and probably others kicked on 
a fresh build to see where stuff is breaking and fix it (in the meta-toolchain-
qte case I didn't need anything).

Re: samba-essential upgrade or remove?

[Holger Hans Peter Freyther]

On Monday 15 March 2010 10:30:32 Koen Kooi wrote:

> I don't think 1) is a realistic option, if we go with that, we should
> just redirect oe.org to buildroot.org and go home.

Exactly.

Re: samba-essential upgrade or remove?

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 15-03-10 04:46, Holger Hans Peter Freyther wrote:
> On Monday 08 March 2010 13:51:35 Holger Hans Peter Freyther wrote:
>> On Monday 08 March 2010 13:42:07 Dr. Michael Lauer wrote:
>>> While I'm not using it atm., I recall that samba-essential was the only
>>> recipe that worked relatively painless when Matthias Hentges create it
>>> back then.
>>
>> Then please fix it. You will do a great service to our users. The following
>> CVEs are not addressed:
>> 	CVE-2009-2813, CVE-2009-2948, CVE-2009-2906, CVE-2009-1888,
>> CVE-2008-4314, CVE-2008-1105, CVE-2007-6015, CVS-2007-4572,  CVE-2007-5398,
>> CVE-2007-2444, CVE-2007-2446, CVE-2007-2447, CVE-2007-0452, CVE-2007-0453,
>> CVE-2007-0454, CAN-2006-1059..
> 
> 
> any update? Is anyone volunteering to update samba-essential or shall we 
> remove it from the tree? 

I think samba-essential reason of being can be done in regular samba
recipes by putting some better thought in PACKAGES and FILES. So: delete
this.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLnfWHMkyGM64RGpERAtouAJsHvBK9hBNaAwzz7k1hCa43rfajZACeJ8hc
OyoJWdOnb8+pAvkwoRwLCU4=
=bz/f
-----END PGP SIGNATURE-----

Re: samba-essential upgrade or remove?

[Mike Westerhof]

Koen Kooi wrote:
> I think samba-essential reason of being can be done in regular samba
> recipes by putting some better thought in PACKAGES and FILES. So: delete
> this.

No, the necessary incantations must be done in the configure stage, so
that the generated binaries do not have so many dependencies.  The size
problem is not limited to the samba packages themselves; a very
significant part of the issue are the external dependencies.

-Mike (mwester)

Re: samba-essential upgrade or remove?

[Mike Westerhof]

Holger Hans Peter Freyther wrote:
> On Monday 08 March 2010 13:51:35 Holger Hans Peter Freyther wrote:
>> On Monday 08 March 2010 13:42:07 Dr. Michael Lauer wrote:
>>> While I'm not using it atm., I recall that samba-essential was the only
>>> recipe that worked relatively painless when Matthias Hentges create it
>>> back then.
>> Then please fix it. You will do a great service to our users. The following
>> CVEs are not addressed:
>> 	CVE-2009-2813, CVE-2009-2948, CVE-2009-2906, CVE-2009-1888,
>> CVE-2008-4314, CVE-2008-1105, CVE-2007-6015, CVS-2007-4572,  CVE-2007-5398,
>> CVE-2007-2444, CVE-2007-2446, CVE-2007-2447, CVE-2007-0452, CVE-2007-0453,
>> CVE-2007-0454, CAN-2006-1059..
> 
> 
> any update? Is anyone volunteering to update samba-essential or shall we 
> remove it from the tree? I think we have a responsibility to our users that if 
> we install a network daemon that we at least fix the known security issues with 
> this one or remove it from our recipe collection... Opinions?
> 
> z.

Sigh.

I really don't think this recipe is worthy of this much controversy.
It's essential (hence the name) for certain very small NAS devices.

I fail to see how its presence is impacting others -- if you don't like
it, don't use it.  Simple.

Nevertheless, the same issues I face that prevent me from having the
time to figure out how to fix this recipe right now also preclude me
from spending time discussing and arguing my case on this.

If the presence of this recipe is so loathsome and offensive to the core
OE members that they would prefer to toss a distro out of OE, then go
ahead and do so.

As an alternative, I'll be happy to commit a change to that recipe that
renders it unbuildable for all but SlugOS -- that would ensure that no
one can build and install this "vulnerable" software in error, and
should suffice to address the issue.

-Mike (mwester)

Re: samba-essential upgrade or remove?

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 15-03-10 14:53, Mike Westerhof wrote:

> I fail to see how its presence is impacting others -- if you don't like
> it, don't use it.  Simple.

That's the point I've been trying to make to the deletionist crowd here,
but haven't been successfull with.

But in this case it's riddled with CVEs, so removing it provided noone
cares about it would be ok. But you care about it, so let's not remove it :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLnkJLMkyGM64RGpERAhERAKCSpw71gKWDrwwgpSMSPLZO/hIHGwCdG0Ox
4JYm+IEoj30irnnKKE7jmO8=
=9fgy
-----END PGP SIGNATURE-----

Re: samba-essential upgrade or remove?

[Holger Hans Peter Freyther]

On Monday 15 March 2010 14:53:44 Mike Westerhof wrote:

Dear Mike,

> Sigh.
> 
> I really don't think this recipe is worthy of this much controversy.
> It's essential (hence the name) for certain very small NAS devices.
> 
> I fail to see how its presence is impacting others -- if you don't like
> it, don't use it.  Simple.

See. This is not the point of liking or not liking a given recipe. I don't 
like the fact that this recipe is not maintained for years and has the 
possibility of damaging the reputation of distros built with OE. I assume
even users of SlugOS do not like if their device gets owned via known and 
circulating exploits?

It would be nice if we could establish a shared responsibility for maintaining 
software that listens on network ports and is handling multimedia content (the 
two kind of things most likely to be suffering flaws). I don't think it is that 
difficult. If there is a remote hole and exploits are floating around, upgrade 
the recipe?

anyway, you don't have the time..




 

Re: samba-essential upgrade or remove?

[Frans Meulenbroeks]

2010/3/15 Holger Hans Peter Freyther <holger+oe@freyther.de>:
> On Monday 15 March 2010 14:53:44 Mike Westerhof wrote:
>
> Dear Mike,
>
>> Sigh.
>>
>> I really don't think this recipe is worthy of this much controversy.
>> It's essential (hence the name) for certain very small NAS devices.
>>
>> I fail to see how its presence is impacting others -- if you don't like
>> it, don't use it.  Simple.
>
> See. This is not the point of liking or not liking a given recipe. I don't
> like the fact that this recipe is not maintained for years and has the
> possibility of damaging the reputation of distros built with OE. I assume
> even users of SlugOS do not like if their device gets owned via known and
> circulating exploits?

I think the chances are small that anyone would put a slug on the open internet.
>
> It would be nice if we could establish a shared responsibility for maintaining
> software that listens on network ports and is handling multimedia content (the
> two kind of things most likely to be suffering flaws). I don't think it is that
> difficult. If there is a remote hole and exploits are floating around, upgrade
> the recipe?

Note that this might go a lot further than you think.
It also means keeping things like php, python and perl up to date as
people could exploit bugs in php code or cgi scripts.

Frans

Re: samba-essential upgrade or remove?

[Holger Hans Peter Freyther]

On Monday 15 March 2010 15:58:17 Frans Meulenbroeks wrote:

> > See. This is not the point of liking or not liking a given recipe. I
> > don't like the fact that this recipe is not maintained for years and has
> > the possibility of damaging the reputation of distros built with OE. I
> > assume even users of SlugOS do not like if their device gets owned via
> > known and circulating exploits?
> 
> I think the chances are small that anyone would put a slug on the open
> internet.

Well, at least here in Taiwan people get a pool of public IP addresses and 
everything behind the main switch of a flat has a public address.


> Note that this might go a lot further than you think.
> It also means keeping things like php, python and perl up to date as
> people could exploit bugs in php code or cgi scripts.

Yes, I upgraded php5, python didn't need an upgrade, perl is going to be 
upgraded...  It is not like that I'm asking to create a security team and do 
code audits... All I ask for is to go to here[1] and update software in time. 
It is not like we need to update stuff every day... if we as a community can't 
do something as simple as that people should use stuff from people that can do 
that.

[1] http://www.vuxml.org/freebsd/index.html