On Thu, Dec 17, 1998 at 09:02:52PM -0800, Oscar Levi wrote: > On Thu, Dec 17, 1998 at 11:07:29PM -0500, Joey Hess wrote: > > Oscar Levi wrote: > > > Not necessarily true. A crash bug that affects 1 out of 10000 runs of > > > a program is not release critical. > > > > That is correct. > > > > > A security hole, in of itself, is not a release critical bug. > > > > That is incorrect. > > > > You seem to be confusing a bug that crashes the kernel and a security hole > > that may crash the kernel, or allow access to private info, or anything > > else. A security hole can be reproduced at will by an attacker, without a > > great deal of difficulty. > > Is it correct that this security hole requires login access to the > computer? If an attack can be perpetrated from anywhere on the > internet to an internet connected computer, then it is clear that the > hole in 2.0.35 has a high probability of exploitation since a large > percentage GNU/Linux systems are Internet connected. If the attack > requires access to a user account on the machine, then the exploit is > overrated. It is all in the interpretation of 'great deal of Did you forget to take your medication today? That's a ridiculous statement, obviously an exploit that requires an account is not as serious as one that doesn't but it is still a big concern. You shouldn't have to worry about whether users want to exploit your system or not, it shouldn't be possible in the first place. > difficulty.' > > > > We don't have guidelines for release that we can use to decide if this > > > is important or not. > > > > Yes we do. We have a release manager who says we will not ship if we have > > critical bugs. We have a definition[1] of critical bugs that says "critical > > makes unrelated software on the system (or the whole system) break, or > > causes serious data loss, or introduces a >>>security hole<<< on systems > > where you install the package." > > While the opinion of a release manager is the inevitable last stand > for determining when to release, it is not a substitute for parameters > that we ALL can measure. Nor for a testing framework. > > > > In your opinion, is it worth a three-week delay > > > to switch kernels? > > > > Yes. It's worth a delay to fix any security hole. Debian must not ship with > > known security holes. Quality is our priority, we have never sacrificed > > quality for marketing concerns. > > Let's let the security issue pass. It isn't important. I agree we > should upgrade. Now, at this point is it worth shipping slink? By > the time we get around to gel'ing it, the packages will be out of > date. Some already are. Umm, call me crazy but 2.0.36 isn't much different than 2.0.35, just replace it and let's be on our merry way. It's not like we are switching from libc5 to libc6 or something. And I'm pretty sure security is an imporant issue with most people. > Software release is time-critical. No matter how hard you beat the > quality drum, the distribution that can ship often will show the best. > RedHat has shipped several buggy distributions in the 5.x series. I > just tried to install 5.2 and found a nest of problems. Unpleasant as > it is, users can only choose a distribution that ships. Hamm is out > of the running and the competition is fierce. They shiped with bugs > that requires 30MB of updates. But they shipped...and people use it. Are you suggesting we ship a buggy distribution? I agree timely releases are imporant but sacrificing security for a release date is not a good idea. -- Stephen Crowley crow@debian.org, stephenc@wf.net -* Finger crow@va.debian.org for my public key. PGP#22714B25 *-
Attachment:
pgpI72dsFteko.pgp
Description: PGP signature