On Thu, Apr 7, 2011 at 4:33 PM, Arno Töll <deb...@toell.net> wrote: > On 07.04.2011 15:47, Olaf van der Spek wrote: >> How does my approach require someone to read the manual? > > It doesn't. The fact, the problem exists is because people don't read > manuals :)
I'm not sure the manual says anything about this one. >> How is a loaded but unconfigured module a security threat? > > Well you don't know. Isn't that the reason why vulnerabilities do exist? 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. > Note, I don't say it /is/ a threat, I say it /could/ be a threat. Think > of unwanted code execution by passing some obscure requests just because > the module hooks into the usual processing when enabled. > > This may, or may not be feasible within the particular Lighttpd > implementation, that's not my point, see below. Ideally the module would unload itself when not configured. >> I'm not assuming it's used by everyone, but I am assuming it's used by >> a majority. > > I say we should not enable a module that it not required to provide core > functionality. It is fine to load them if they are fundamentally > required. It is the responsibility of you, being a package maintainer to > make sure the out of box configuration is inherently safe (and sane), > i.e. it does not put up with unwanted (and unneeded) risks. I agree about those goals, so the question is: what is core functionality? Olaf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
