Re: SECURITY: bug in Berkeley DB on some systems (eg. Solaris <= 2.5) [#375]

[Jeff Garzik <jgarzik pobox com>]

Sleepycat Software wrote:
> 
> Hi, Frederic, Keith Bostic from Sleepycat Software here.  Amy Adams asked
> me to review your email.
> 
> > From: Frederic Devernay <devernay@istar.fr>
> >
> > I propose that you modify db to either:
> > a- make the fake snprintf and derivatives static wherever they're used
> 
> This is going to be a pain, I really don't want to do this, although we
> probably could.
> 
> > b- not use snprintf if it's not in the system libraries
> 
> This isn't really an option, as it would limit the number of places where
> Berkeley DB can run.
> 
> > c- provide a _clean_ implementation of snprintf (there are quite a lot
> > around here, in various implementations of libc, and in glib -- which
> > comes with gtk)
> 
> I'm certainly happy to consider this, but I've never seen a version of
> any printf-style function that I'd want to add to our distribution and
> maintain.  The "safe" versions that I've seen generally consisted of
> signal handlers and/or malloc calls wrapped around an "unsafe" version,
> neither of which is possible in our environment.  First, we're a library,
> so we can't touch the signal handlers.  Second, our most common error
> message is ENOMEM, so doing further malloc's isn't a good plan.

Try http://ext1.nea-fast.com/~jgarzik/snprintf.c

That is from the Mutt mailer, and doesn't seem to include the unsafe
qualities you describe above.

	Jeff