Re: rc2 testing: groff uses bogus putenv test

"G. Branden Robinson" <[email protected]> Fri, 6 Feb 2026 08:13:37 -0600
Newsgroups	gmane.comp.printing.groff.general
Message-ID	<20260206141337.vu2pj4ewvwa5icxr@illithid>
Hi Ingo,

At 2026-02-06T14:46:55+0100, Ingo Schwarze wrote:
> G. Branden Robinson wrote on Thu, Feb 05, 2026 at 12:34:16AM -0600:
> > Can you name a security problem arising from groff's use of a
> > standard C library facility that OpenBSD's libc implementation would
> > prevent or mitigate, but which gnulib replaces and thereby
> > re-exposes?
> 
> I already named an example, maybe it was overlooked among the
> significant number of mails:
> 
>  * Support for printf(3) %n was removed from OpenBSD libc
>    for security reasons.
>  * GNUlib printf(3) supports %n.
>  * One of the reasons why the groff build system replaces native
>    OpenBSD printf(3) - and many other functions - by GNUlib printf(3)
>    is that GNUlib printf(3) supports %n.

I do have a vague memory of you mentioning this, but not recently.

> As far as i know, groff does not (intentionally) use %n.

Indeed not.  From the groff 1.23.0 ChangeLog:

2021-08-15  G. Branden Robinson <[email protected]>

        Resolve compiler warnings relating to format string security and
        ISO C++98 conformance.

        * src/preproc/eqn/delim.cpp (define_extensible_string):
        * src/preproc/pic/pic.ypp (do_sprintf): Use #pragma to silence
        GCC "format-nonliteral" warning and explain why our usage is
        safe in a comment.

        * src/preproc/preconv/preconv.cpp (detect_file_encoding): Use
        `l` modifier to `%u` `fprintf()` conversion instead of `z`, and
        cast return values of `size_t` to unsigned long; "ISO C++98
        does not support the ‘z’ gnu_printf length modifier" (it doesn't
        support `ll` either).  N.B. this is debugging output only.

        * src/roff/groff/groff.cpp (synopsis):
        * src/roff/troff/input.cpp (usage): Repeat variadic argument for
        `%s` conversion in `fprintf()` call because "ISO C++98 does not
        support %n$ operand number formats".
...

I see no other _relevant_ matches in the groff source tree for `%n`,
though as I'm sure you'd (rightly) point out, that's no defense if we
commit the grave mistake of permitting the input to construct format
strings _for_ us, and you're correct that OpenBSD's nonstandard
printf(3) mitigates such a weakness if it exists.

https://cwe.mitre.org/data/definitions/134.html

> That makes the choice to insist on having it quite strange.

I _don't_ insist.  printf(3)'s `n` conversion specifier comes with
gnulib and conforms to the POSIX standard.

https://pubs.opengroup.org/onlinepubs/9799919799/functions/printf.html

If OpenBSD wants to make its printf(3) the standard, it knows who to
talk to.

> On the other hand, "we don't use it, so having it available in the
> implementation poses no risk" is a weak argument.

Not necessarily.  That depends on how easy it is to attack groff's
executable programs so as to gain control of a format strings it uses
_and_ its parameter list.  Compare that to how easy it is to inject
object code that does what `printf("%n", &foo)` would have achieved, or
(more likely, I suspect) some more direct means of overwriting memory
with a small integer.

> Defense in depth means that you get the best level of security when
> you do *both*: *neither* use the dangerous feature *nor* provide it in
> the implementation - because that means not even a bug can trigger its
> accidental use.

It's a good principle.  But few principles should be adhered to
slavishly, and I suggest that the vituperation with which express of
groff's propensity to crash during compilation--but only on OpenBSD and
when crudely attempting to defeat linkage with gnulib, factors you never
disclose to your readers without prompting--indicates how tightly you're
fastening an iron collar around your own neck.

Again, if someone can tell me how to (easily) set up the moral
equivalent of a `--without-gnulib` option to groff's "configure" script,
I'm inclined to embrace it.  I would have "configure.ac" disclose this
fact in the configuration summary, and its exercise could influence the
level of support I'm willing to extend to such configurations.  That
said, I have no reason to suspect any particular problems apart from
people discovering dismaying deficiencies in their systems' C libraries,
blaming groff for those deficiencies, getting pissed off, and writing
screeds on the Web about how they're moving their bookmarks to Markdown/
Heirloom/Typst/TeX/whatever.

See, e.g., "etresoft" at <https://discussions.apple.com/thread/\
256113690?sortBy=rank>.

So be careful out there, folks--like a slave collar, a black turtleneck
can constrict blood flow to the brain.

Regards,
Branden
signature.asc (application/pgp-signature, 833 B)