I understand. It's hard, if you program in C, which is an unsafe language, to avoid bugs and, hence, to avoid security holes. Why not just have a history (like what you say below) of the bug/security situation near the top in the README file?
The three exclamation points from ./configure seem to demand action from the user, and there isn't enough information at that point for the user to decide what to do. The README file could mention that it was the SMB printing code (not "printer", since a "printer" is a physical machine) that had the most bugs before, and so people might consider disabling it if they're worried. If you feel tempted to say something like "The SMB printing code may still have an exploitable buffer overflow problem", then a more thorough audit is required, and you might want to provide an apology for not doing it yet, ask for volunteers, etc. ----------------------------------------------------------------------------- Date: Wed, 18 Sep 2002 11:12:25 -0700 From: Guy Harris <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Content-Disposition: inline On Tue, Sep 17, 2002 at 02:04:33PM -0500, Daniel R. Grayson wrote: > checking whether to enable the possibly-buggy SMB printer... yes > configure: warning: The SMB printer may have exploitable buffer overflows!!! > > I don't know what to make of it. Does this warning mean that you are > distributing code known to have security holes? It says "may have", not "does have". At one point, there were definitely places where it could run past the end of the packet and keep going. We audited the code somewhat, and fixed what we found; I can't speak for Bill Fenner, who did most of the work, but I think we found most of the places where that happens, if not all. Bill, should we remove that warning at this point? - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
