From owner-freebsd-security Wed Feb 5 23:21:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA21749 for security-outgoing; Wed, 5 Feb 1997 23:21:34 -0800 (PST) Received: (from mpp@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA21738; Wed, 5 Feb 1997 23:21:24 -0800 (PST) From: Mike Pritchard Message-Id: <199702060721.XAA21738@freefall.freebsd.org> Subject: Re: 2.1.6+++: crt0.c CRITICAL CHANGE To: karl@Mcs.Net (Karl Denninger) Date: Wed, 5 Feb 1997 23:21:24 -0800 (PST) Cc: security@freebsd.org In-Reply-To: <199702052036.OAA12786@Jupiter.Mcs.Net> from "Karl Denninger" at Feb 5, 97 02:36:11 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > From: Karl Denninger > Look. I've submitted prs before which have been flamed because they weren't > "stylized" the way people wanted them, or were just ignored until some time > later -- even when SEVERE and SECURITY have shown up in them. > > Frankly, I'm tired of tilting at windmills. What PRs were those? I checked, and can only find about 5 or so PRs that I can determine were written by you. All but one were fixed within one week of submission. Most were responded to within 48 hours. The one that was not acted on immediately was a non-security problem. Please correct me if I am wrong. With that said, yes, there are security related PRs that have remained open for too long. However, all of this work is being done by VOLUNTEERS! Some of these problems require rebuilding the entire system for testing. That takes time. Especially if you are trying to do a complete job and make sure that the changes are correct for multiple releases. I would rather wait and have the correct fix the first time, and not a series of fixes that fix the previous fix because it was rushed out the door without enough thought or testing. >> From: "Justin T. Gibbs" >> Not true. Simply because you are not privy to the discussions about this >> issue does not mean that we are ignoring anything. Our announcement will >> have information on *all* versions of FreeBSD that have this problem. > Keeping the discussion private (ie: "not privvy") means you believe there's > something to hide. I disagree. Either discourse in public or it doesn't > count in my book. Just because you aren't in the loop, someone is hiding something? I fail to see the logic in this. I'm a FreeBSD developer and I wasn't included in any of the private core team discussions and I don't feel that anything was being hidden from me. As someone from the core team pointed out, a lot of what was initially discussed was either wrong or did not apply. This type of misinformation would only tend to cause even more confusion than has already taken place. E.g. if someone mentioned that the xyzzy() routine seemed to have a similar problem and it really did not, I'm sure that someone would misread it and then start demanding why xyzzy() hasn't been fixed, when in reality there was never a problem at all. I'm happy to have access to an actively developed operating system with a large number of enthusiastic developers. I've had to work on large vendor operating systems in the past where you were lucky if your very critical crash or security problem was addressed in the next binary only release a year later. -Mike -- Mike Pritchard mpp@FreeBSD.org "Go that way. Really fast. If something gets in your way, turn"