[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: critique of gnulib
Re: critique of gnulib
Sun, 1 Sep 2019 15:46:16 -0700
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
Thanks for your thoughtful reply. A few points:
Jonas 'Sortie' Termansen wrote:
I object to the notion that truncation is a worse outcome than a buffer
overflow. A buffer overflow is at worst a remote code execution
vulnerability, while a truncation is at worst a program bug (although
that may be exploitable in turn, it is not inherently exploitable).
We look at things a different way. Buffer overflows are easily caught by
widely-available tools, and if remote code execution is a problem then one ought
to be using such tools. In contrast, silent truncation bugs cannot be caught
easily and automatically, so these bugs are much harder to find and fix. If one
looks at the overall bug burden, silent truncations are probably a worse problem
for Gnulib-like code than buffer overflows are. (Integer overflows are probably
worse than either.)
Of course this is a judgment call and your judgment might differ. Still, there's
a lot to say for the GNU tradition of refusing to impose arbitrary limits (as
snprintf-using code usually does), and it's reasonable to follow that tradition.
Generally asprintf should be used instead of
sprintf/snprintf because it does the buffer allocation for you and
significantly reduces the risk.
asprintf is often a good way to go, and Gnulib uses it. However, like sprintf
and snprintf, asprintf mishandles large buffers and so careful code cannot use
it to both allocate and format large results - which means that careful code
must do the "risky" stuff anyway since asprintf is not up to the task.
To recap, my primary requests are:
1) Categorizing gnulib into three parts (replacement functions for when
they don't exist, workarounds for bugs, and utility functions).
2) Making it possible to disable the gnulib bug replacements with a
configure command line option.
3) Defaulting to assume the best when cross-compiling to unknown systems.
(3) shouldn't be that hard to do, though it would be tedious. (2) sounds
trickier, since not everybody agrees about what's a "bug" (are we talking about
a bug relative to C11? to C99? to POSIX-2017? to current GNU? that sort of
thing). I don't see the categories in (1) as being that sharp or useful, but
perhaps I'm missing something.
To my mind, the most important feature needed is to make it easy to do reliable
cross-compiling, by letting the builder supply a method for 'configure' to run a
program on the target platform. This would be an Autoconf feature, not a Gnulib
feature. It would have addressed many of your problems. It's been on the
Autoconf to-do list nearly forever, alas.
Re: critique of gnulib - stdioext, Bruno Haible, 2019/09/08
Re: critique of gnulib - malloc wrapper, Bruno Haible, 2019/09/08
Re: critique of gnulib - disabling workarounds, Bruno Haible, 2019/09/08