On Sun, Mar 08, 2020 at 11:04:40PM +0100, Bruno Haible wrote: > Hi Adrian,
Hi Bruno, >... > it would > make sense for gnulib to have "nearly POSIX" compliant variants of these > functions; this would remove the need for the gnulib *printf* code in > many cases. this sounds like a good idea. Looking at git history the usage in bison this is due to https://lists.gnu.org/archive/html/bug-gnulib/2009-10/msg00143.html gzip is due to http://git.savannah.gnu.org/cgit/gzip.git/commit/?id=bc4b1e68a8da345c6027dd034592f66808a6f254 So -DGNULIB_POSIXCHECK recommending a "nearly POSIX" compliant variant could avoid replacing the glibc code with the gnulib code. >... > Or because of security considerations (%n being used to construct "gadgets" > in malware)? This, and distributions using several copies of the gnulib code instead of the fortified and security supported code in glibc. >... > --- a/doc/posix-functions/fprintf.texi > +++ b/doc/posix-functions/fprintf.texi > @@ -30,6 +30,7 @@ NetBSD 3.0, AIX 5.1, HP-UX 11.23, IRIX 6.5, Solaris 9, > Cygwin 1.5.x, mingw, MSVC 14. > @item > This function does not support the @samp{n} directive on some platforms: > +glibc when used with @code{_FORTIFY_SOURCE >= 2} _FORTIFY_SOURCE > 0, the glibc code is under if ((mode_flags & PRINTF_FORTIFY) != 0) > (set by default on Ubuntu), >... Ubuntu has enabled it by the default in gcc, which means you get it by default not only for package building. Debian/Gentoo/Fedora/openSUSE (including RHEL/SLES) all add _FORTIFY_SOURCE by default at least for building packages, it might be hard to find a distribution that is not doing compile time hardening in the year 2020. cu Adrian
