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
Description: PGP signature
