Re: Security of Debian Testing
On Sun, Jan 23, 2005 at 12:04:18PM +0000, Floris Bruynooghe wrote:
> On Sun, Jan 23, 2005 at 11:14:28AM +0000, Bob Hutchinson wrote:
> > On Sunday 23 Jan 2005 09:37, Anthony Simonelli wrote:
> > > I realize that Debian Testing "Sarge" is not supported by the
> > > Security Team and that it is the last branch of the Debian to
> > > receive updates.
> >
> > I run servers on both testing and stable and the security updates
> > are the same on both, as they both come from the same place, deb
> > http://security.debian.org/ stable/updates main contrib non-free
>
> Erm, afaik this line won't do anything on your testing machines...
> Only packages witht the stable version number will get uploaded into
> this archive. The apt system will not consider these security
> updates as it has more recent versions of the packages from you
> testing archive. That's whats meant with "there's no security
> support for testing" I thought.
Right. A testing machine won't usually see stable's security uploads,
because usually the testing version is already higher than the stable
version (because of some other update made in the last 3 years:).
You have to know the history of testing for this to all make sense.
Testing was an experiment that Andreas Barth (I think) set up, and
which eventually became "official", and quite popular. It allows
bug-free uploads to become quickly available (more quickly than
stable), while buggy ones are left to sid.
Uploads go directly to unstable (after all the archs are compiled, or
something). And after some conditions are met (including a minimal
waiting period), they are *automatically* propogated to testing. (See
packages.qa.debian.org for testing migration status).
Because its automatic, its kind of nonsensical to support testing WRT
security. Most of the time, a security-related upload will go to
unstable, and (oftentimes) the only changes made will be for security.
So, if you run testing, and you want a given security update to a
given package, you can probably just do "apt-get install
foopkg/unstable" (this assumes that you have an unstable source
available; read about apt pinning for how to make multiple versions of
the distribution available and assigning different priorities to
them).
(The security team also makes the same security uploads for stable,
which become availabe from security.d.o. Here, though, the changes
are *guaranteed* to be security only.)
A week later, when that version of that package has propogated to
testing, you're no longer running the "unstable" version of that
package, because now its "in" testing. Its just that you installed it
before it was there.
So .. your initial question:) Since Sarge is coming Real Soon Now, it
makes sense to me to start with a sarge system (which is very similar
to a testing system; only some things are "frozen", and the frozen
things aren't extremely old, like woody is). You can add a stable
security line if you like, but don't let it give you a false sense of
security, because it will probably never do anything. Also add a sid
line if you like (I have experimental, for mysql subtables support,
sarge and sid, plus a couple unofficial ones).
Note the difference between Sarge and testing. If you make it a Sarge
system, when Sarge is finally realized, you're already running it. If
you make it a testing system, you would be running "Sarge+", which
would be the same as sarge, for many packages, but in other cases,
would include random updates. So, it depends on whether you
ultimately want a "stable" system or if you want to perpetually run
"testing".
It isn't hard to secure a system which will be exposed to the public
internet, just look at netstat -l, use tcp wrappers, usual stuff.. If
you're paranoid, subscribe to security-announce, and then update to
the sid version of packages when security updates become available.
But this probably won't even be necessary unless you install a lot of
software (of the ~20 current DSAs, I think 4 are remotely exploitable,
and none of those are in the base system). You can expect that
security related uploads will be priority=high, and will thusly
propogate to testing (which is not necessary the same as sarge) in ~3
days. If its not going to have a public IP address, well, then
there's no concern at all as long as you trust your shell users.
Hope that helps.
Justin
Reply to: