2008/8/27 Chris Bannister <[EMAIL PROTECTED]>: > On Tue, Aug 26, 2008 at 03:30:37AM +0100, Sam Kuper wrote: >> (4) Request the Debian Etch rkhunter maintainers to upgrade rkhunter >> in Etch to version 1.3.2. If successful, this would undoubtedly be the >> best solution. Dear Micah and Julien, how about it? Sysadmins will >> love you even more than they do already! :) > > Not a chance. Why do you think its called "stable"?
Perhaps naively, I thought it was called "stable" because it was for systems that had to be stable, stable in this case meaning reliable. To me, this suggests that stable releases should not have the latest toys packaged (most people don't need a Mozilla Ubiquity beta on their production servers), nor even necessarily the latest utilities, in order to minimise potential conflicts between packages. What it should have, however, are up-to-date security packages. A rooted server is not a stable one: it could be brought down, outside of its sysadmin's control, at any minute. Maybe I was wrong to think that the priority is that the computer on which the OS is installed is stable (reliable), and not that the OS itself is stable (unchanging). Furthermore, even on the latter interpretation of the significance of calling the release "stable", isn't it the case that Etch still includes security fixes? Well, if in order to run rkhunter - a program which can be important to maintaining a system's security - a download is needed that is no longer available and isn't included in the "stable" package, shouldn't that be fixed? I think it should, which is why I wrote the email that generated this thread. That said, if this isn't the Debian way, and/or I'm misunderstanding the significance, in the Debian context, of the term "stable" (this is quite possible - in which case, I'd welcome correction), it's not the end of the world. It'll just mean that pure Etch systems aren't quite as secure as they could be. Sam PS. Hmm, I delayed sending the reply above in order to have some more time to think about the different kinds of "stability" that are important for production servers, etc. While I've explained above that I place great store by the reliability of a computer system, and have emphasised that this can be aided by updates that add missing security functionality, I've not examined the merits of the other kind of stability: the kind of stability that refers to the intentional unchanging or barely-changing nature of the software on the system. I'll do that a bit more here, to see if I'm understanding its importance, and the reason there's "not a chance" (see Chris Bannister above) rkhunter in Etch will be upgraded to 1.3.2. The reason is: *rkhunter 1.3.2 works differently to 1.2.9. If you have a script that calls 1.2.9 a particular way, that script may just possibly get broken by upgrading to rkhunter 1.3.2. This sort of thing could pose a security risk. Therefore, it's better to keep Etch's rkhunter at 1.2.9 and only patch it if an exploit in it is discovered.* Now, I'm not sure I agree with that reason entirely. I think it has merit, but then so does the alternative approach I raised earlier in this email. Which has the greater merit? I guess the community's judgement has been that the "Stable software should change as little as possible" argument beats the "Stable software should change as much as it needs to to ensure packages useful for security are up-to-date and usable without requiring external downloads" one. And you know what? After this extra reflection, I'm almost convinced that the community's judgement was correct. With more time, I might become wholly convinced; we'll see... :) Chris, thank you for the thought-provoking question. Sam
