Re: Security of Debian Testing
On Sun, Jan 23, 2005 at 09:40:56AM -0600, Anthony Simonelli wrote:
> Justin Pryzby 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
> >
> >
> >
> >
> I used Jigdo to create an the Sarge ISO file (all 14 actually). The
> name of the ISO file is "sarge-i386-1.iso". Is this different from
> using "testing" as you spoke about in your reply:
>
> /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"./
>
>
> or is it still testing because Sarge has not been frozen yet? I'm kind
> of new ot the whole thing so sorry if I sound stupid.
I'm not sure either so its not a Stupid Question:) I think the "base
system" is frozen, but the rest is not. Of course, your Sarge ISO
isn't an official one, because Sarge does not yet exist. Its just
some guy (probably the same guy who will make the official one)
running some program making sure that he *can* make a sarge ISO, and
that everything works as expected. So, it is *not* the same as an ISO
of testing. Its an image of Sarge as it would exist if Sarge were
released before that ISO was made.
The official Sarge ISO will differ only in non-base packages (plus
base packages whose changes are pushed through by the release team).
I'm not sure about the definition of "base", though. It probably has
to do with the priority (required, important, standard, optional,
extra) and the section (Section: base, duh) and maybe also with the
Essentialness (those packages which are required to Mostly Work after
they are unpacked, but before they are configured). I'm not sure
about the intersection of the above sets (does essential imply base?
base imply essential? Are those mandatory intersections, or just
transient concidence?).
In any case, if you add the appropriate lines to sources.list, your
Sarge ISO image won't really matter. Updates to Sarge will be
available online, and whatever version is on your CD will get updated.
Justin
Reply to: