Date: Tue, 21 Jul 1998 21:13:51 -0500 From: Jon Hamilton <hamilton@pobox.com> To: Brett Glass <brett@lariat.org> Cc: security@FreeBSD.ORG Subject: Re: Making it work (Was: Why is there no info on the QPOPPER hack?) Message-ID: <199807220211.TAA10787@hub.freebsd.org> In-Reply-To: Your message of "Tue, 21 Jul 1998 19:23:01 MDT." <199807220123.TAA21937@lariat.lariat.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199807220123.TAA21937@lariat.lariat.org>, Brett Glass wrote: } At 07:06 PM 7/21/98 -0500, Jon Hamilton wrote: } } >You're being casually dismissive of a real issue again. Surely you } >aren't going to try to keep a straight face while suggesting that } >it's rare to see a quick bug fix for an exploit that either causes } >more problems than it solves, or doesn't address the problem it's meant } >to fix? } } This is usually because the patch is created in a hurry by one individual } without adequate review. That's where the notion of a team comes in. And this team is going to flash the bat signal and gather round the table every time any member finds any problem in any software? How do you balance the delay of having many people examine the problem (and the fix) vs. having fewer people do the work and getting the result out more quickly? How large is this team? What happens when there's disagreement among the team as to what is or isn't a good fix? What about the fact that you're still applying band-aids to poorly written code in the first place, in effect treating the symptom rather than the cause? } >Where do you propose to find these people, and what makes you } >think they're going to perform this task for you for low or no cost? } } Self-interest. These will likely be the same people who are motivated } to close holes in their own systems fast, and will appreciate the } chance to work with a team rather than fending entirely for themselves. You've found the right motivation, but I don't think you'll find enough people who are both interested in such an endeavor and willing/able to be part of a group such as you're describing. Once you get a group larger than a certain critical mass, it becomes a time sucking pig trying to generate some semblance of consensus, and people spend lots of time bickering rather than doing something more productive. Not entirely unlike this thread. } >All the world doesn't look like your installation, and solutions that } >work just fine and make good sense for your installation may simply } >not fit elsewhere. } } I think if one limits the scope of solutions to patched versions of } existing programs, it becomes feasible to allow an automatic update. For you, and for installations like yours which are managed by people who think the same way you do. If there are enough such combinations, maybe your idea will fly. } Nothing's foolproof, of course. For example, if a DoS attack came before } the patch arrived, it might not get installed. But the odds are good that } it would help. Well, if a DoS attack came before the patch arrived and the patch wasn't able to make it, the odds are very poor that it'd help :) I suspect that you meant that in a big picture sort of way, your idea would solve more problems than it creates. I still think there's more hidden overhead in there than you're acknowledging, and there are other problems waiting to bite you which you seem eager to dismiss out of hand, but it is of course your prerogative to charge ahead down your chosen path. I don't imagine the odds are very good at this point that either of us is going to convince the other that he's wrong, and since the arguments are starting to come full circle, I think it's getting to be time to move on. I'll keep an eye out for announcements of your project's success. -- Jon Hamilton hamilton@pobox.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807220211.TAA10787>