Re: Security of Debian Testing
--- Justin Pryzby <justinpryzby@users.sourceforge.net>
wrote:
> 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
>
>
> --
> To UNSUBSCRIBE, email to
> debian-testing-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
>
>
I used Jigdo to create the ISO files (all 14 of them).
The iso name is "sarge-i386-1.iso". What is the
difference between the OS I install from this disk,
and "testing"?
I asume I would be running "testing" since Sarge is
not "frozen", but if and when Sarge is "frozen" will I
then be running Sarge? If not, how do I convert my
"testing" box to stable Sarge when it is released?
I hope this is making sense and I am not completely
miss-understanding. I'm sure you all have a lot to do
and to be bugged with these questions can be annoying.
Reply to: