On Fri, Oct 01, 1999 at 10:20:41AM -0400, Clint Adams wrote: > > it isn't useful to run the vtund server until it is configured. there > > is no "standard" configuration which is suitable for shipping as a > > default - it MUST be customised for each site, each tunnel must be setup > > individually. > > When did "useful" enter this discussion?
usefulness or utility has always been in this discussion. you should pay more attention. > pipsecd starts the daemon automatically even though no tunnel has > been set up, and even if userlink-modules hasn't been installed. > > And even though it is of absolutely no use to you, the daemon > starts running when you install the package. And if there's some > sort of exploitable back door in the code, you're vulnerable. > But fine, you think security is a non-issue. if pipsecd turns out to have a security hole then that MUST be fixed regardless of whether it is started at install-time or not. fixing the bug is the solution to the problem. merely not starting it is no solution at all, that's just hiding your head in the sand. > You seem to recognize at least one situation where it is > counterproductive for Debian to make an assumption about the > user's configuration. Why can you not recognize others? i have little interest left in this tedious thread, so i'll say this once and once only. i really hope you can manage to understand it: vtund was my package to create as i saw fit. I personally saw no need to have the vtund running when it wasn't yet configured, so I personally chose not to have it start until the user configured it. The maintainer of pipsecd, according to your report, made a different choice. that is their right. this is not a matter for policy, this is not a matter where a tiny minority of whiners can have artificial hysterics about fantasy security issues and other FUD. my package, my decision. if you feel that the way i manage my package is a problem, then file a bug report - i'll evaluate that bug report and take whatever action (if any) i feel is appropriate. ditto for the pipsecd package, Samuel can make up his own mind about how to look after his package. by the same token, packages containing other daemons belong to their respective maintainers. if there is any conflict between differing packages, then it is up to the relevant maintainers to sort out a solution - e.g. the emacs and xemacs conflict...until the people responsible for those packages put their heads together and figured it out, it was not possible to have both installed at the same time. now, it is no problem at all. what this means is that if there is a great desire to have several pop packages installed at once, then it is up to the maintainers of the pop packages (and other interested parties) to come up with a way that can be achieved without hassle, and without imposing stupid and onerous burdens on the maintainers of unrelated packages. craig -- craig sanders