From owner-freebsd-doc Wed Apr 4 10:15:12 2001 Delivered-To: freebsd-doc@freebsd.org Received: from dfw-smtpout4.email.verio.net (dfw-smtpout4.email.verio.net [129.250.36.44]) by hub.freebsd.org (Postfix) with ESMTP id 8C5CE37B71A for ; Wed, 4 Apr 2001 10:15:05 -0700 (PDT) (envelope-from bokr@accessone.com) Received: from [129.250.38.62] (helo=dfw-mmp2.email.verio.net) by dfw-smtpout4.email.verio.net with esmtp id 14kqs3-0002wG-00; Wed, 04 Apr 2001 17:15:03 +0000 Received: from [63.183.7.113] (helo=gazelle.accessone.com) by dfw-mmp2.email.verio.net with esmtp id 14kqs2-0007kE-00; Wed, 04 Apr 2001 17:15:03 +0000 Message-Id: <5.0.2.1.1.20010404092059.00aeebf0@mail.accessone.com> X-Sender: VN/bokr@mail.accessone.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 04 Apr 2001 10:12:57 -0700 To: Dima Dorfman From: Bengt Richter Subject: Re: docs/26286: format string warnings in man pages. Cc: freebsd-doc@freebsd.org In-Reply-To: <200104040120.f341K4R75749@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 18:20 2001-04-03, you wrote: >The following reply was made to PR docs/26286; it has been noted by GNATS. > >From: Dima Dorfman >To: Bengt Richter >Cc: freebsd-gnats-submit@freebsd.org >Subject: Re: docs/26286: format string warnings in man pages. >Date: Tue, 03 Apr 2001 18:15:57 -0700 > > Bengt Richter writes: > > (I am implicitly suggesting that security risk documentation > > be accumulated in a single place for reference and browsing. ^^^^^^^^^ > > This would serve several goals at once, not least of which is > > a single instance of explanatory text to update when appropriate. > > We already have this: http://www.FreeBSD.org/security/#spg > Which is good, but to refer to specific paragraphs/concepts via a link from a footnote, #spg would need paragraph numbers or other identifiers. The more #spg grows, the more the need for paragraph/section identifiers for reference. > In a perfect world, most security bugs being found right now wouldn't > exist because all programmers would read that, and all the sites that > page links to, and know that passing the wrong data to the wrong > format specifier is a recipe for [security] disaster; unfortunately, > we don't live in a perfect world. Some programmers don't even bother > reading the man pages to look for security warnings, and many more > didn't read that page. > > The best thing we can do is stick this information in their face. Would you (e.g.) want to put #warning lines in ? Or configure make to call a new tool that scans for risky stuff listed in a .conf file, and issues warnings that you have to know what you're doing to turn off? Or modify etc. with conditionals so you have to define USE_RISKY_PRINTF or USE_RISKY_XXX to use a call to a risky XXX (or else get a warning lecture via #warning lines) ? How in-your-face do you want to get ;-) Hm. Actually, maybe that wouldn't be so bad if you could disable it wholesale with -DNO_USE_RISKY or something. Of course, this wouldn't flag risky stuff you coded yourself. > Sticking outdated, wrong, or incomplete information in their face > doesn't make the problem better, however. That was my original > concern; if the information mentioned in each man page is incomplete Using references to centralized info makes it easier to maintain "complete" info, I would think. Also implies less updates to the referring docs, and little or no consistency/duplications problems between referring docs. > (and the patch submitted was), it may lead some to think that by > reading that they know enough, and not bother to investigate further. Would they bother to click a live hyperlink in an HTML version? > > That said, I'd like to make it clear that I'm not opposed to the patch > in general. I'm just concerned that keeping it up to date will be a > pretty big problem, and thus it may end up doing more harm than good. A reason for a centralized single-instance info representation, which can be referred to instead of sliced and duplicated, IMHO. Regards, Bengt Richter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message