Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 04 Apr 2001 10:12:57 -0700
From:      Bengt Richter <bokr@accessone.com>
To:        Dima Dorfman <dima@unixfreak.org>
Cc:        freebsd-doc@freebsd.org
Subject:   Re: docs/26286: format string warnings in man pages. 
Message-ID:  <5.0.2.1.1.20010404092059.00aeebf0@mail.accessone.com>
In-Reply-To: <200104040120.f341K4R75749@freefall.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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 <dima@unixfreak.org>
>To: Bengt Richter <bokr@accessone.com>
>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 <bokr@accessone.com> 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 <stdio.h> ?
         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 <stdio.h> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5.0.2.1.1.20010404092059.00aeebf0>