hey joey (et al), On Wed, May 03, 2006 at 01:33:58PM -0400, Joey Hess wrote: > sean finney wrote: > > this is a surprising change. guess that's what i get for not being > > subscribed to -policy :) > > Not really, it was last discussed on -policy in 2003, so being > subscribed wouldn't have helped, I'm as suprised as you are. okay, so i'm not totally out of the loop then. > The rationalle is explained in #32263, though the logs are > long. Here's the essence of it: > > > On Thu, Nov 02, 2000 at 09:16:02AM -0500, Brian White wrote: > > > ----- > > > Most people setting up a web site expect /cgi-bin/ to be available for > > > scripts on their site. Unfortunately, Debian uses this for those scripts > > > packages that get installed. These two need to be independant. > > > > > > As such, Debian's system needs to be altered a bit. I recommend using > > > instead the name "/cgi-lib/" for scripts under /usr/lib/cgi-bin/. This > > > will keep both features independant and not affect the general use of > > > the system. wow. at first i thought you dropped a digit off the bug number :) > Why this change was accepted into policy in 2006 when the last message > about it was back in 2003, I have no clue. All that seems to have > changed in between is the slight support for it that existed in 2003 > bitrotting away. truly confounding. istr there being an equally crufty bug about wanting to split up /usr/lib/cgi-bin to include a /usr/share too, but can't seem to find it now. > > i would argue that /usr/lib/cgi-foo is an outdated approach anyway, and > > that most applications ought to be scriptaliasing /package/cgi-bin > > or /cgi-bin/package to somewhere under /usr/lib/package (this would in > > fact be another use for the non-existant libexec dir...). but that's > > just my $0.02. > > Debian still has web servers other than apache2 in it, so that seems > difficult to do. i'd disagree. this is something i'd been mulling over for a while, and i have something somewhat concrete that i think is fairly reasonable. if policy wrt to cgi-bin is going to be changed, i would suggest: - that cgi-bin is defined to be a location outside of debian packages' reach entirely (/srv/www/cgi-bin or /var/www/cgi-bin, or whatever). - httpds which support scriptaliasing ship this as the default location - httpds which can not scriptalias it somewhere else (those that hard-code it at compile time, i'm guessing > 0 may do this) use that as the location. - applications which wish to provide cgi-bin based scripts are allowed to use the scriptalias function of applicable httpds to claim subdirectories of cgi-bin. - under no circumstances are packages to place files in the default cgi-bin location. - it is the admin's privilege/responsibility/authority to modify the contents of the default cgi-bin location. with this approach, the admin is free to do whatever he/she wishes with the cgi-bin directory (place files, symlink to directories provided by debian packages, etc), without interference from debian packages. there is also a clear distinction of domain between the local admin and the debian package management system, which is generally a good thing and something we seem to like doing in debian. for the vast majority of users, packages are still able to install and configure themselves with the local webserver, so the overall effect of such a change would be minimal. in fact, even finding the list of affected packages would be a fairly trivial thing to do. using apt-file or similar, you could find all packages providing files under /usr/lib/cgi-bin (packages providing their cgi-files outside of this directory are already scriptaliasing). of those packages, you could check for which ones do not explictly provide scriptalias functionality in their configuration, and open corresponding bugreports. sean --
Attachment:
signature.asc
Description: Digital signature