Re: join us!

[Ben Collins <bcollins@debian.org>]

On Thu, Aug 31, 2000 at 07:18:18AM -0600, Kurt Seifried wrote:
> > Yes I read the update. I'd be happy to review your articles for you, but I
> > don't think you should stop at one reviewer. Debian is a very big project
> and I'm
> > still finding my way around parts of it. You may have been in contact with
> Ben
> > Collins. If so I suggest you ask him too.
> 
> Yeah, he did email me, not terribly friendly. I think it's rather obvious I
> researched the article if I was taking apart files like lilo.conf/etc.

My appologies, but you did touch a nerve. Anyone in a place of high
visibility and large influence is expected to hold to higher standards
than everyone else. Sucks I know, but you have to carry that
responsibility, or you get problems like this one.

> Ben Collins wrote:
> 
> "If you would have bothered to check the changelogs for the packages you
> noted as having "root hacks in them", you would have noticed that every
> daemon you pointed out is not vulnerbale to the holes you point out. Here is
> a list:"
> 
> One question: where is it explicitly stated that Debian backports fixes and
> that one needs to read /usr/doc/*/changelog?
<snipped large portion of technical backing>

This is ludicrous. Backporting fixes is done everywhere in the industry at
every level. Just because someone is running Solaris 5.5.1, is it a
vulnerable system? No, you have to run the patch checks to see if it is
secured.

On Windows95/98/2k/NT, the version level means nothing, even the SP# means
nothing, because patches are seperate pieces even then.

Now this is at a higher level, but we still see it in lower levels. Let's
take the Linux kernel. You'll notice that security fixes for that come
about well before there is a version increase, and most distributions
release a patched version well before they wait for a version increase to
be made available. GLibc is the same way, and even RedHat will patch up
the current version and release (I know this from experience).

Now, let's look at the reasoning Debian has for this. We'll inspect the
release cycle as it goes.

Debian unstable, oh the glory of mass uploads and new packages abound the
project. Bleeding edge releases of major and unknown software enter the
project. Many of these programs have major bugs in them. When new version
of the program come out, hey, they just get packaged up and tossed in,
hopefully not introducing any new bugs. Even if they do, it's ok, we're
"unstable".

Now, along comes the initial freeze. No new packages are allowed in, and
new uploads are done in semi-caution. We're nearing release, and adding
too many new features always invites more new bugs. If major security
concerns arise, fix as needed, however it's needed.

Down the road, we enter a "deep freeze". Oh shit! We're getting ready to
release. Boot-floppies and CD images start being tested very heavily.
Surely we don't take any new packages. New features are moot at this
point. The only uploads allowed are ones fixing fairly important bugs
(What we call Release Critical, see our website for details, in the Bug
Tracking System). If a security problem comes along, it has to be fixed,
however, we'll take the case of Apache like this:

Apache 1.3.9 is in the current frozen. We have to fix the bugs, but since
then Apache 1.3.12 has been released. We don't want this new version. The
current version has proven to contain no bugs in our BTS, the only problem
being this security flaw. This new verion may contain new unforseen bugs
that will require fixing again in the near future and maybe even some
incompatibilites that will require some hacking in order to make upgrades
easy. Do we take this extremely new version or do we side with caution and
backport the fixes? Obviously, for the sake of a more stable, bug-free
distribution, we fix the known bugs, and avoid introducing new ones. The
changes get noted in the packages' changelog (every Debian package has a
Debian changelog in the doc dir, it's documented that way).

This same thing happens after freeze. The current release gets patched to
fix *known* bugs, and we avoid at all costs introducing new ones. IMO,
this is a lot smarter than just taking the newest version. And anyone who
says anything different is just a version number junky, and not really
concerned or knowledgable about what it takes to produce a bug free
distribution.

-- 
 -----------=======-=-======-=========-----------=====------------=-=------
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'