On Thu, Apr 7, 2011 at 5:24 PM, Arno Töll <deb...@toell.net> wrote: >> No. >> It does increase the amount of code that's executed, but (IMO) not in >> a significant way. FastCGI is not some obscure module. >> If loading the module does affect safety in a significant way one >> should probably avoid the entire webserver. > > Safety is the minimization of unwanted risks. This is, how an engineer > defines safety. For security this reads: avoid unneeded threats whenever > you can. The code you don't execute can't lead to a vulnerability. > Especially if you execute it unnecessarily. > > It's as simple as that.
It's also, almost always, a tradeoff with usability / simplicity. >> Ideally the module would unload itself when not configured. > > I'm unsure if a module should apply this kind of heuristics since I tend > to state "software should not start to think on behalf of the > administrator being too lazy to configure things". If things can be automated without disadvantages then they should be automated. >> I agree about those goals, so the question is: what is core functionality? > > Bear in mind we discuss about a web server, that is essential core > functionality is well defined by HTTP 1.1 > [http://tools.ietf.org/html/rfc2616]. That means: Everything needed to > run a fully compliant HTTP 1.1 web server is enough for the > functionality /everyone/ expects when installing lighttpd. That'd be the minimal functionality required. Debian aims for usable, not necessarily minimal. > For lighttpd this requires the core components only, that can't be > loaded (or unloaded). > > Now let's take a look in the trunk's lighttpd.conf: > >>>server.modules = ( >>> "mod_access", >>> "mod_alias", >>> "mod_compress", >>> "mod_redirect", >>># "mod_rewrite", >>>) > > As we are packaging for Debian we need to be conform to Debian's Policy > Manual § 11.5 > [http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-web-appl]. > Following that we require an alias for /cgi-bin, /doc and /images, hence > mod_alias is required (what happened to the DPM compatible configuration > by the way, the current configuration looks like as if it would violate > the DPM?) It was moved to conf-available, as it interacted very badly with other alias stuff. > mod_access provides url.access-deny which is a good idea too, although > this probably should include .htaccess as well, since a lot of people > leave those files in their doc roots as well, even if they are useless > for Lighttpd. > > mod_compress might be technically a good idea, but it is not required > for core functionality. I would suggest not to remove it completely, but > to comment it out and leave it as hint to the user. Again, minimal vs best suited to majority. > mod_redirect is not used at all in its default configuration currently. > > Note I also dislike to split up configuration into dozens of files, so I > would suggest not to remove some basic configuration quirks, but to > leave the administrator the choice whether he wants to activate a > certain option (set) or ship alternative configuration files. > > (Note I also asked to join the pkg-lighttpd team earlier today through > Alioth, since we are getting off topic here) Eloy will have to handle that. Olaf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
