Re: Update of security-critical outdated packages
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-----
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
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
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
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.