* Marc Espie <es...@nerim.net> [2014-05-03 11:50]: > On Sat, May 03, 2014 at 11:28:16AM +0200, Reyk Floeter wrote: > > On Fri, May 02, 2014 at 06:50:04PM -0600, Bob Beck wrote: > > > What's their hangup with %n? We normally don't like polluting the world > > > with #ifdef OPENSSL_NO_PERCENT_N... We normally nuke stuff like that > > Well, it is an evil thing that is rarely used and well-known for some > > format string vulnerabilities. So either adding this #define or > > removing it from our libc wouldn't be a bad idea. But it is in POSIX, > > right? > > At a first look, I only found it in a few places of our tree where it > > could be removed: > > > > gcc, texinfo, curses, libform, sqlite, less, tmux, unbound, nsd > > > > Not couting ports, but some software already seems to check if %n is > > available to do a fallback otherwise. > And you do expect the fallback to be of good quality ? > > I think that the same rationale that lead to including some crypto code > in openssl applies there: if we don't provide it, people will roll their > own posixy-printf, and we know how well that turns out in general... > > (including stuff that peeks and duplicates the internals of FILE, like > I'll be happy if I *never* get to fix this kind of code again).
both of you are kinda missing the point. there is no argument here to remove %n support from our libc, the point is wether we can add a #define to allow people compiling themselves (probably not as part of OpenBSD) to remove it without having to change the code. And since that's not intrusive and doesn't create a portability mess like the one we're dealing with in libssl right now, I don't see a problem with that. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
