Re: gl_{,SN}PRINTF_DIRECTIVE_N wrongly fail on Ubuntu 18.04

[Adrian Bunk]

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