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 \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=========------=======-------------=-=-----=-===-======-------=--=---'
