Food for thought - SECURITY (design flaw?)
Something seems "not quite right" with choosing woody/testing, as "safer"
With potato, as you know, the security-minded admin adds
deb http://security.debian.org potato/updates main contrib non-free
to /etc/apt/sources.list. This is a great design aspect for Debian,
making security simple for the newbie as well as the seasoned admin.
With sid, as you know, security fixes end up in the main archive as
soon as they become available, (+24h?,) hence there is no need for an
equivalent line for unstable.
But what of woody? Many admins choose testing as "safer" than unstable,
due to the two-week lag in changes. Yet, on a woody box, just tonight
I see the following changelog while upgrading woody:
micq (0.4.6-4) unstable; urgency=low
* Adopted micq package
+ Patched micq to reconnect when server sends 'Go Away!' command.
-- Sander Smeenk <email@example.com> Tue, 23 Jan 2001 22:47:10 +0200
micq (0.4.6-3) unstable; urgency=HIGH
* Applied patch from Guillaume Morin <firstname.lastname@example.org> to fix a
possible remote exploit reported in BugTraq. Thanks!
-- Jordi Mallach <email@example.com> Sun, 21 Jan 2001 20:08:51 +0100
An "urgency=HIGH" patch, taking weeks to hit woody machines ... Hmmm.
Suddenly it appears that running testing is more dangerous than
running unstable, at least as far as security matters are concerned.
(The choice of testing still shields from most maintainer script errors
The apparent fix appears to be an addition of
deb http://security.debian.org woody/updates main contrib non-free
(deb http://security.debian.org testing/updates main contrib non-free)
capabilities to security.debian.org, which of course does not presently
exist, followed perhaps by parallel commented-out additions to the
default /etc/apt/sources.list that ships in testing.
Is this a design flaw in the implementation of woody/testing?
Would the above be the appropriate solution?
This appears to warrant discussion. I don't have a working email address
currently, so will attempt to intermittently follow the list traffic in
Please (OpenPGP) encrypt all mail whenever possible. Request the following
Public Keys for Lazarus Long <firstname.lastname@example.org>
Type Bits/KeyID Fingerprint DSA KeyID: vvvv vvvv
ElGamal: 2048g/21ED0589 F635 6388 2D82 B8FA CE77 2789 D5F4 F28D 8DD0 5745