"Secure coding" audit checkers and Kerberos

Tom Yu tlyu at MIT.EDU
Wed Oct 15 23:33:33 EDT 2008

Nicolas Williams <Nicolas.Williams at sun.com> writes:

> On Wed, Oct 15, 2008 at 10:55:40PM -0400, Tom Yu wrote:
>> Nicolas Williams <Nicolas.Williams at sun.com> writes:
>> > On Wed, Oct 15, 2008 at 04:05:10PM -0500, John Hascall wrote:
>> >>   1) snprintf is also non-standard
>> >>   2) there are some horrible snprintf's out there,
>> >>      including ones which do little more than call sprintf!
>> >
>> > The MIT-krb5-uses-snprintf() train departed long ago.
>> >
>> > The Consortium might well decide to [continue to] provide portable
>> > versions of these, or that MIT krb5 will not support platforms which do
>> > not provide at least working snprintf().  I would support either
>> > position.
>> >
>> > I do object to avoiding *s*printf().  If ultimately that means that MIT
>> Do you mean to say that you object to *not* avoiding sprintf, i.e.,
>> that you object to retaining any uses of sprintf?
> No, I meant what I wrote.  I object to *s*printf() avoidance.  I do
> realize that that means checking for the correctness of a platform's
> implementation, and it might mean avoiding precision specifiers for %s
> (but I've not settled that yet; see my other reply).

Oh.  Do you mean the sprintf family of functions, rather than the
sprintf function in particular?  I may have misread your asterisks as
emphasis around the letter "s" rather than as globs.  I understand why
you might prefer using one of the sprintf functions to using some
unwieldy sequence of invocations of strcpy and strcat (or strlcpy and

More information about the krbdev mailing list