Re: Releasing groff 1.22.5?

[Ingo Schwarze]

Hi,

Ingo Schwarze wrote on Thu, Oct 15, 2020 at 05:32:32PM +0200:

> Meanwhile, i heard rumours that the upcoming change in libc that will
> cause %n in writeable memory to abort the program will cause some
> gnulib ./configure tests to (wrongly) fail, again resulting in
> compilation of vasnprintf.c

So far, the rumour turned out to be true.

On OpenBSD-current, after building a kernel and libc that rejects
%n in writeable memory and after rebuilding GNU m4 and GNU bison
on top of that, when i run "../configure" in groff/build, i now see
this in config.status:

configure:9431: checking whether printf supports the 'n' directive
configure:9512: result: no
gl_cv_func_fprintf_posix=no
gl_cv_func_printf_directive_n=no
gl_cv_func_printf_enomem=no
REPLACE_FPRINTF='1'
#define REPLACE_FPRINTF_POSIX 1

The groff build consequently proceeds to build vasnprintf.c.

(I certainly don't like it when application software goes out of
 its way trying to defeat security features of the operating system.
 By the way, Dave Kemper reported the same effect from his Gentoo
 Linux system: groff is trying to circumvent system security features
 there, too.  But that's a long-standing effect rather than a
 regression, so it probably shouldn't hold up the release.)

> with %n

But this part is not true.  At least on OpenBSD (and probably on
Gentoo, not sure about other platforms, this is certainly all rather
fragile) config.status says:

configure:10741: checking whether snprintf returns a byte count as in C99
configure:10843: result: yes
configure:10849: checking whether snprintf truncates the result as in C99
configure:10942: result: yes
#define HAVE_SNPRINTF_RETVAL_C99 1
#define HAVE_SNPRINTF_TRUNCATION_C99 1

That results in %n not being used by the new version of lib/vasnprintf.c.

> and ultimately killing groff at run-time.

That part of the rumour isn't true either.

A package of groff-current built as described above works for me
on OpenBSD-current, not counting two or three minor regressions
that i'll inestigate sepaarately because they are clearly unrelated
to vasnprintf.c.

So i think further deliberation of the vasnprintf.c issue can be
postponed until after release.

Yours,
  Ingo