[Top][All Lists]

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

swarm of bugs in gnulib wrt restrict

From: Ingo Schwarze
Subject: swarm of bugs in gnulib wrt restrict
Date: Sat, 24 Oct 2020 16:24:40 +0200
User-agent: Mutt/1.12.2 (2019-09-21)


i'd like to give you a heads-up regarding a swarm of bugs in gnulib
related to the C99 "restrict" keyword.  I first sent this report
directly to Bruno Haible because, as far as i can see, he was the
last one to add a new bug to that swarm, in this commit:

commit 182afcba2635cbff91240656c7fb3742dd23ab6f
Author: Bruno Haible <bruno@clisp.org>
Date:   Sat Feb 22 20:57:30 2020 +0100

But Bruno requested that i send this to bug-gnulib@ instead because
he considered it potentially interesting for more people and because
he hoped for participation of more people who posess exxpertise with
respect to the "restrict" keyword.

Before the commit, testing for "restrict" functionality was already
broken, and using "#define restrict ..." for C++ code was already
wrong, too.

The above commit added the additional bug to the swarm
that gnulib/lib/stdio.in.h can no longer be used from C++ code
either, because it now stomps on the application namespace, too.

For details, see comment #5 in this ticket:


I'm not planning to draft patches to gnulib myself because the
complexity of gnulib is seriously excessive for my taste.  All the
same, i consider it fair to send a notification in case you want
to investigate the problem on your own, using the information
in the above GNU troff ticket.


We found this because a recent update of gnulib in the GNU troff project

  -Subproject commit dce8759f0f0236a860a3e68b63c5e99cc6f168f9
  +Subproject commit d60a35e94c4f5b8f09f15828242418f5073d46e7

broke compilation with GCC 4.2.1, i.e. the latest GPLv2 version of
GCC.  After detecting that, another user reported that the build
crashed even with "gcc (Gentoo 9.3.0-r1 p3) 9.3.0", while the
build still succeeded with clang.

Fortunately, the workaround on the groff side was easy - just adding
#include "config.h" to all files that #include <stdio.h>, even to
those that don't need it for their own purposes, but we were worried
that more might be broken in groff, so i had a closer look and found
that nothing more appears to be broken in groff, but that gnulib suffers
from the issues listed in the ticket cited above.

Unrelated to the swarm of bugs discussed above, but i might mention
this as well while here, even though it is not a proper bug report
but merely a concern.  For some years, several operating systems
have now been discouraging or even outlawing %n in printf(3) for
security reasons.  Some do so by default with an option for the
application developer to re-enable it (e.g. MS Windows), some do
so unconditionally for %n in writeable memory (e.g. MacOS X), and
GNU/Linux appears to provide some hardening option to the effect.

If the operating system provides a secure printf(3) that forbids
%n in writeable memory, then gnulib mis-classifies that deliberate
decision as a defect and compiles vasnprintf.c, which unconditionally
re-enables %n in writeable memory behind the users back.  I consider
silently and agressively disabling security features of the
operating system very nasty misbehaviour and totally outside the
scope of a portability library.

The net effect is that the more modern a version of glibc is in
use, the more likely that gnulib will wrongly consider the native
printf(3) broken and replace it with its own, less secure version.
I got a report from a user who had that happen to him even on an
up-to-date Gentoo Linux system.

Ingo Schwarze             <schwarze@usta.de>
http://www.openbsd.org/   <schwarze@openbsd.org>
http://mandoc.bsd.lv/     <schwarze@mandoc.bsd.lv>

reply via email to

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