Kjetil Kjernsmo wrote:
Depending on what you're doing, pinning actually can work quite well. But you're correct in that upgrading too many pakages quickly leads to an explosion of dependancies.-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all,It is an issue that's been bugging me for some time, and while I have tried to find good reasons, I have not, so I might as well write them down. I have a lot of respect for the security team, and I don't think I have anything to contribute other than my thoughts, but I'll try to share them. Many packages in stable are really outdated. After first installing Woody, I first thought that looking at the prospect of waiting one-and-a-half year for the next release would scare me away from Debian. Now that I've grown up a bit more, it doesn't. I'm perfectly fine with using backports for things like KDE. Also, if I was a sysadmin for a lot of boxes, supporting many not-too-savvy users, the release cycle is perfectly reasonable. For a stable system, pinning is not option, because you'll quite soon have to update things like libc6 if you do. It's not about that. Backports are fine for most purposes, and I'm fine with the release cycle.
It's about a small handful of security-critical packages, like for example Snort. In the case of Snort, the security team has explicitly discouraged people from using the packages available in Woody, see DSA-297. I find it very hard to understand that in the cases where the security team strongly advises an upgrade, that the backported packages are not included in e.g. a point release.
This has nothing to do with the security team and "security" issues as far as software vulnerabilities. If there's a security issue with a package, the security team will fix the problem in the stable release. Problem solved (as in DSA-297).
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.
So, this is just about the very few packages the security team feels are so outdated, one advice people not to use them. For those packages, the question is: What is the advantage of keeping so outdated packages in the archive?
If the package is "outdated", you have other options, including apt-get source and other options mentioned in your email. It just doesn't have to do with the security team.
In the case of snort, an old version could still be useful in the archive. Picture a machine that must run stable (for various reasons), sitting behind a decent firewall. It may use snort as a last line of defense, 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.
This is somewhat relevant to the point Ryan just raised in his recent post about "better apt security with 3rd-party sites", since having outdated packages in the archive makes people use backports from 3rd-party sites, and you don't know the validity of these packages.
True, but security issues aren't forcing people to use backports. If they are, they don't understand how Debian handles security.
It seems to me to be a perfect way to trojan a newbie's machines: The newbie hears on debian-user that he must update some of these packages: So, there is a malicious cracker who put a site up with "official updates", and the newbie adds it to his sources.list. Instantly, he gets a version of Snort that ignores attacks and chkrootkit with a rootkit... Even if you could use debsigs, a newbie probably couldn't verify the package anyway, due to the lack of personal WOT. I think it is a rather bad situation.
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 verifying signatures of untrusted packages, upgrading to testing|unstable, doing apt-get source, or simply building from a tarball are viable options for you.
If a newbie believes a posting that he "must update xxxx from site: http://whatever.not.a.debian.site:1234/my/evil/files";, there's not much to be done about it, aside from better education of end users.
As you stated, this does get more into the points raised in the other topic.
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? Either way, if the backport is evil, you're screwed. It's probably worse to have a malicious backport of more mundane software, since the effects may be less noticeable, and the software may be more widespread.
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. Granted, I'd agree that it may be more desirable to have the latest version of snort released than some obscure game packaged just as practice for a new maintainer, but the same issues about modifying stable still apply.
--Rich