Contributed by tbert on from the good-diffs-make-good-neighbors dept.
i maintain Android's C library which, as you may know, contains a lot of OpenBSD code. i've been working to clean up our mess and get us back in sync with upstream, and currently have 173 files that are exactly the same as current upstream OpenBSD. (more than we have from the other two BSDs put together.)
There's more after the fold:
the one thing i've had pushback on is that by switching to the current upstream source i've effectively added support for printf(3)'s %n to Android, which our security guys are not happy about. Android has never supported %n before.
ideally i'd like to have no differences between Android and OpenBSD in the shared source files, because i've seen what a mess things were when we diverged (and how many bugs went unfixed in Android despite having been fixed for years upstream). so rather than start back on the slippery slope of adding Android-specific hacks, i wondered if you'd consider adding #ifndef REMOVE_PERCENT_N_SUPPORT (or whatever) around the implementation of %n in lib/libc/stdio/vfprintf.c and lib/libc/stdio/vfwprintf.c.
you already have stuff like FLOATING_POINT and PRINTF_WIDE_CHAR so there's some precedent here.
thoughts? (assuming this is the right list. if not, please point me in the right direction.)
The thread goes on with suggestions from Bob Beck (beck@) and others that OpenBSD tends to prefer removing knobs rather than put more in, and so there may be other ways to fix the perceived problem and help our downstream Android developers.
The change was subsequently committed:
CVSROOT: /cvs Module name: src Changes by: email@example.com 2014/05/03 06:36:45 Modified files: lib/libc/stdio : vfprintf.c vfwprintf.c Log message: Add #ifndef NO_PRINTF_PERCENT_N. Since we are fully standardized, we don't use disable %n ourselves. But Google's Android libc is based on our libc.... Giving them an easy knob to disable this dangerous feature easily make their job easier without making our job any harder. Request from Elliott @ google
It's nice to see good code (and security-consciousness!) being exported to other projects.
(Comments are closed)