Subject: Re: CVS commit: syssrc
To: None <>
From: Charles M. Hannum <>
List: tech-security
Date: 12/08/1999 05:08:56
  by with SMTP; 8 Dec 1999 10:22:56 -0000
	by (8.8.8/8.8.8) id FAA09358;
	Wed, 8 Dec 1999 05:09:00 -0500 (EST)
Cc: Assar Westerlund <>,
Subject: Re: CVS commit: syssrc
References: <>
From: (Charles M. Hannum)
Date: 08 Dec 1999 05:08:56 -0500
In-Reply-To: Matthew Jacob's message of "Sun, 5 Dec 1999 04:03:52 -0800 (PST)"
Message-ID: <>
Lines: 29

[Moved to tech-security.  Note that I'm not picking on Matt here; he
just happens to be the target most visible at the moment.  B-)]

Matthew Jacob <> writes:

> Because I didn't think to check that snprintf is now available. It is for
> FreeBSD, but NetBSD && OpenBSD I didn't check. Still, having a buffer big
> enough is not unreasonable, no?

So, while trying to come up with a justification of `just using a
large enough buffer' in highly enclosed contexts recently, I have come
to the conclusion that it's not justifiable, for the following reason:

One of the first things that any `security' auditor is going to do is
check for calls to functions that are known to be `unsafe'.  It may be
all fine and dandy on a single inspection to decide that a particular
call is `safe', but when there are may such calls remaining, it makes
the job of an independent auditor much more difficult, because each
call has to be inspected again.  In this context, it makes more sense
to simply eliminate calls to such functions completely.  Furthermore,
bitrot (e.g. changing the maximum length of an input) may cause the
code to become `unsafe' later.

Of course, you also need to be sure you aren't introducing truncation
bugs (where a string is truncated by snprintf(), but the calling code
doesn't notice) while doing this.  Unfortunately, much auditing has
been done in many systems where such care was not taken.