Kjetil Kjernsmo wrote:
On Thursday 15 January 2004 17:33, Rich Puhek wrote:Depending on what you're doing, pinning actually can work quite well.Yup, and I do it on my workstation (not that I understand it, it is rather magic to me).Snort is related to you overall system security, yes, but new releases of Snort have to do with your desire to run the latest and greatest releast of a package, not with security issues.Well, that's not how I read DSA-297. I have no desire to run the latest and greatest release of a package on my production server, to the contrary, with the notable exception of SpamAssassin. I would argue that it is only because of security issues I would ever consider upgrading a package on a production server (and mine isn't even in production yet! :-) ).it may use snort just because it's handy for detecting strange patters which could indicate other network problems, etc. It could even have some locally-grown programs that use some snort tools.OK, valid argument, still, wouldn't it be rather rare compared to actually using it for what it is intended for?True, but security issues aren't forcing people to use backports. If they are, they don't understand how Debian handles security.Again, that's not how I read DSA-297.
They advise using newer versions of snort because it recognizes newer attacks. Any security holes in snort will continue to be patched. In other words, if someone discovered today that woody's snort version has a buffer overflow, you can bet that snort will be updated in security within a few days.
The key difference here is in the use of the term "security issues". The security release is used to patch holes in a server. The version of snort in stable has no "security issues" in the sense that installing it does not open you up to attack.
It's kind of off the topic, but if you're concerned about tools like snort, et. al., you should be at the experience level where verifyingsignatures of untrusted packages,It has nothing to do with experience. Sometimes, you just don't have the WOT needed to verify a package. Most probably, only those who have at some point attended a Debian keysigning party have a WOT suitable for that, and perhaps people who live in an area with many Debian users. In sparsely populated areas like Norway, a good WOT is a real luxury, and one of past year's most luxurious evenings was the Debian keysigning party... :-)upgrading to testing|unstable,You don't want to do that on a production system.
On a general production server, no. Now think about why: you might have to upgrade lots of dependancies, you might get stuck with incompletely tested software, it's more difficult to maintain security updates. Those are also the arguements used for not arbitrarily upgrading packages in stable!
You may find that upgrading to unstable (or a hibrid of unstable packages) is just about ideal for something like an IDS or an antispam server. Machines like that tend to need bleeding-edge software, so almost by definition, they end up runing unstable.
doing apt-get source, or simply building from a tarball are viable options for you.Yep, but it is still besides the point: Really good reason for keeping outdated packages in the archive (ok, you provided one above)?
Is the arguement that "old" packages like snort should be removed altogether, or that "packages I really find important" should be upgraded more aggressively?
If it's the former, I'd argue that unless you can present a hugely compelling arguement for removal (like a sudden discovery of a licensing issue, with an accompanying lawsuit), it would be a bad idea to suddely have packages disappear from stable.
If it's the latter, well, we're back to the initial arguements about release cycles, package updates, etc. Also, how do we decide what's important enought to be upgraded immediately? should SpamAssassin be upgraded because I don't want to receive spam that's been catchable for a year? Should PHP be upgraded because I want to be able to serve pages that have been written in a language version supported for the last year (like $_FILES['userfile']['error'] ). Should perl be upgraded because it's a very important language? Eventually, you'd discover you come up with the package list for Debian/unstable.
Again, I'm fine with backports for many packages, and I'm fine with the general release cycle, it's just the small number of critical security-related packages that I feel needs some discussion.What's the difference if someone downloads a backport of snort or a backport of a window manager?Big difference: If the WM is a bit unstable, or it has a bit weird performance at times, I don't care. It's the cost of running unstable software. But if the NIDS fails to recognize an attack that's been known for two years, it is pretty serious.
It sounded like your main objection to backports was that someone could trojan a package on an unofficial backport site. My point wasn't stability, the question is, if you download a trojaned backport of KDE, how is that less of an issue than downloading a trojaned backport of snort? Either way, your system is trojaned. Plus, a trojaned version of a popular WM would probably have a more severe impact than a trojaned IDS, just based on the number of infected machines (I'm assuming that more prople run KDE than run snort, just a guess on my part).
If you are able to trust a backport site, then what's the problem with using it for secuity related packages?
IMHO, it's been discussed to death already. Whether you want a brand new version of snort or a new version of KDE is irrelevant to the discussion of upgrades, the same issues still apply.Well, it may be that it has been discussed to death. I'm rather new here. But I respectfully disagree that the type of package is irrelevant to the discussion.
How does the end use of the package change the debate over things like: *) how to limit the impact of dependancies *) how to avoid breaking other installed programs*) how to support critical security updates while putting newer versions in stable *) how to limit the need to unexpectedly reconfigure a package in stable (apt-get update; apt-get upgrade should just *work* on stable, if you suddenly have to stop and redo a config file because it supports a few 100 new options... that's not too cool).
I think the concept got covered fairly well the last time you brought it up (Nov, 2003).
The issue of snort, specifically, recieved quite a bit of discussion about a year ago:
http://lists.debian.org/debian-security/2002/debian-security-200212/msg00063.html
Basically, I just like to hear your thoughts, because I really haven't found any good answers.
As with any issue this complicated, there's probably no "best" answer. The consensus over past issues of updating software has been that you're on your own with having to do one of pining, outright upgrading to testing|unstable, using a backported .deb, doing apt-get source and building the package (and all deps), or getting the source and rolling your own.
I think it usually ends up being people like myself who do most of the arguing on the topic. If I was a decent programmer, I'd just shut up and try to close RC bugs :-)
Best, Kjetil