Anthony Towns <aj@azure.humbug.org.au> writes: > This is daft. Packages should be functional as soon as they're > installed, not be fundamentally broken and require administrator > action. Permissions aren't maintained over upgrades, so this will > result in further breakage. And CGI applications with security > issues shouldn't be packaged.
Sometimes you don't know about the security issues in advance. Presumably the intent of the proposal is that, when this happens, only sysadmins who have taken some intentional action to install or activate the CGI programs have any risk. That seems like a good goal to have, even if the mechanism leaves something to be desired. An alternative approach would be to require that CGI programs are only included in packages which would be completely nonfunctional without the CGI program being active. In the case where the purpose of the package is already to provide the CGI programs this would require no change. In the case where a package includes optionally usable CGI programs (say, a web interface to a facility that can also be controlled via the command line or an X application) this would require splitting the CGI programs out into a new package. It looks like this already happens to an extent e.g. squid/squid-cgi. -- http://www.greenend.org.uk/rjk/
