Re: rc2 testing: groff uses bogus putenv test

"G. Branden Robinson" <[email protected]> Thu, 5 Feb 2026 00:34:16 -0600
Newsgroups	gmane.comp.printing.groff.general
Message-ID	<20260205063416.yezezsla6en3m3eg@illithid>
At 2026-02-05T07:01:16+0100, Ingo Schwarze wrote:
> G. Branden Robinson wrote on Wed, Feb 04, 2026 at 10:06:36PM -0600:
> 
> > I wonder why Bruno Haible has so much less difficulty building on
> > OpenBSD than you do.
> 
> If i understand correctly what Bruno is doing, i regard the
> wording "building on OpenBSD" as misleading.  If i understand
> correctly, he accepts replacing significant parts of the OpenBSD C
> library by gnulib replacements,

That's my understanding too.

> including parts of the OpenBSD C library that have been carefully
> crafted to make programs running on OpenBSD less susceptible to
> widespread security vulnerabilities.

This claim presumes that little care for security has gone into gnulib,
but I suppose this attitude is on-brand for OpenBSD users.

> Groff does *not* actually need the insecure features that OpenBSD
> removed and that gnulib still provides, so doing it the way Bruno does
> it, if i understand correctly what he is doing, essentially defeats
> the purpose why people are running OpenBSD in the first place.

I won't venture to speculate on why people choose to run OpenBSD.
(I concede that being utterly fed up with Charles Hannum and other
NetBSD principals was a pretty good one, 25 years ago.[1])

> As far as possible, we want software running on OpenBSD to come as
> close as possible to OpenBSD quality standards.  Admittedly, in ports
> land, that is not always possible, so the OpenBSD ports tree contains
> plenty of dubious and sloppy software, but for a piece of software as
> important as groff, i consider not giving up completely on quality
> worthwhile, and that implies making sure that OpenBSD security
> features are not circumvented.

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 think it is more to sound to reason from such a basis than "we're
OpenBSD, therefore our code is more secure, therefore defeating gnulib's
replacements is necessary to achieve security".

Such a logical process is known as "drinking one's own Kool-Aid".

> > Do you not build stock groff, but only attempt a build after
> > applying your raft of patches to make the formatter work more like
> > mandoc(1)?
> 
> Yes, i do apply a few patches to make the formatter work more
> like mandoc(1), but for 1.24.0rc2, none of the patches so far touch
> any file outside tmac/, and none of these patches changes whether the
> build succeeds or in which way it fails:
> 
>    $ ls patches/
>   patch-tmac_an_tmac              patch-tmac_mdoc_doc-ditroff
>   patch-tmac_doc_tmac             patch-tmac_mdoc_doc-nroff
>   patch-tmac_man_local            patch-tmac_mdoc_doc-syms
>   patch-tmac_mdoc_doc-common      patch-tmac_mdoc_local

Okay.  I suspect I have a notion from the CVS logs of mandoc(1) what
these are.

I ask that when you editorialize on what you purport to be groff's
massive number of crashes during compilation in public emails and on the
Web, you start informing people that this happens largely because you
refuse to build groff in a supported configuration.

If the GNU Autools people offered a configuration-time option to "opt
out" of gnulib usage, as we've recently discussed, I wouldn't at all
mind supporting that in groff.  I'm not bothered in the least by the
prospect of groff being employed as a libc quality assurance tool.
(Many years ago I might have claimed that there's no way groff makes
ambitious use of libc, but it kind of does; its pipeline construction
and management stuff seems pretty good at finding problems with systems
that struggle with POSIX conformance.)

My job is to maintain groff.  When you complain about problems that
aren't in groff's source code and therefore not within my remit or power
to address, you risk wasting our time.

Regards,
Branden

[1] https://www.theos.com/deraadt/coremail.html
signature.asc (application/pgp-signature, 833 B)