On Sat, May 03, 2014 at 01:00:28PM +0200, Henning Brauer wrote: > * 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. No, I was just responding to Reyk, who apparently wanted to take it further. As long as the #ifdef doesn't turn into yet another quagmire, it's obviously okay to have it (coming after the commit, of course).
