thoughts on modules-extra subpackage...

[Andy Gospodarek]

On Tue, Dec 06, 2011 at 05:01:39PM -0500, Josh Boyer wrote:
> On Tue, Dec 06, 2011 at 04:55:04PM -0500, John W. Linville wrote:
> > On Tue, Dec 06, 2011 at 04:19:35PM -0500, Chuck Ebbert wrote:
> > > On Fri, 2 Dec 2011 13:38:51 -0500
> > > "John W. Linville" <linville at redhat.com> wrote:
> > > 
> > > > As for the stated benefits...  I'm skeptical of the security argument.
> > > > I mean, I can believe that a module could get accidentally or
> > > > inadvertantly loaded and then exploited.  I just think that closing
> > > > those holes is a better plan.
> > > 
> > > Unfortunately, network modules will be autoloaded if a program opens
> > > a socket with that protocol. They've talked about securing that, but
> > > it never happened.
> > 
> > That seems more realistic for a protocol module (e.g. sctp) than
> > for a queueing discipline (e.g. sch_sfb) or a TCP congestion control
> > algorithm (e.g. tcp_westwood).
> > 
> > > And there is a long history of security bugs being found in the new
> > > and/or infrequently-used modules.
> > 
> > That's probably true.  I still wonder if that is common enough to be
> > worth the change.
> 
> I'm still of the opinion we should just turn them off.
> 
> At the same time, we should probably be a bit more judicious about
> enabling new drivers.  They're normally not all that great in their
> first full release, so they should default to off until requested or
> proven otherwise.
> 

How are we going to know how bad they are if we do not enable them?

I'm not saying we cannot do what you propose, I would just like to
understand how well you expect a driver to perform before you are
willing to enable it.