[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: critique of gnulib

From: Paul Eggert
Subject: Re: critique of gnulib
Date: Sun, 1 Sep 2019 15:46:16 -0700
User-agent: 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]