"Secure coding" audit checkers and Kerberos

[Simo Sorce]

On Wed, 2008-10-15 at 22:00 -0500, Nicolas Williams wrote:
> 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).

After almost 10 years from C99 avoiding it would be just absurd if you
ask me. If there are platforms that really can't cope with C99 after 10
years I honestly think nobody should consider using them as a KDC
anyway.
I think you might even decide not to provide substitute functions, but
just have configure tests and refuse to build if they do not pass.
*If* it turns out a large number of platforms do not work then you may
decide to implement substitute functions for the ones you use that fail.


/Simo who has written C99 snprintf() substitute functions too, like many
here, and thinks it is really time vendors update their stuff or die
off.