Re: Retiring lpr and lpd

On Thu, 26 Feb 2026 20:21:52 +0000
Shawn Webb <[email protected]> wrote:

> On Fri, Feb 20, 2026 at 07:40:54PM +0100, Dag-Erling Smørgrav wrote:
> > Hi,
> > 
> > The lp* family of printing utilities have received practically no
> > maintenance in two decades and are showing their age.  What's worse,
> > most of them are setugid, and lpd(8) is a network-facing daemon with
> > IP-based authentication and little to no input validation.  Furthermore,
> > better-maintained alternatives are available from ports: print/lprng is
> > a drop-in replacement derived from the same code base, while print/cups
> > provides far more functionality and a compatible command-line interface.
> > 
> > Unless someone steps up and does a credible job of modernizing these
> > utilities, we have no other choice than to retire lp(1), lpc(8), lpd(8),
> > lpq(1), lpr(1), lprm(1), lptest(1), and pac(8) from base.
> > 
> > In the next few days, I will commit patches to add deprecation notices
> > to all relevant manual pages (D55381) and switch the LPR build option
> > from default-on to default-off (D55380).  The code will remain in the
> > tree, and remain buildable, but unless the situation changes, it will be
> > removed from the tree no later than shortly before stable/16 is branched
> > in the fall of 2027.
> 
> I should prefix this with a note: I really don't care what happens
> here. I lean towards removal of bit rot in a more general sense, but I
> have no strong opinions.
> 
> With that said, a random idea poppped in my head. I'm not advocating
> for the idea, I'm simply hoping to convey the idea.
> 
> What if the lpr/lpd (and related?) components (I'm just gonna say lpr
> from now on to be brief, but please understand I mean any/all
> components involved) are separated out to a wholly separate git repo
> (specific to lpr).
> 
> This repo would be self-contained and buildable as an out-of-tree
> component. So you'd have your BSD-flavor Makefiles that use the normal
> bsd.lib.mk, bsd.prog.mk, (and bsd.*.mk, ...).
> 
> Then, a separate discussion can be held whether to generate a new
> ports entry. This at least gets the components out of base, but usable
> for those users who need ;it. Users could clone the repo, cd to it,
> and `make install` it).
> 
> This would provide a middle-ground, where a piece of software that is
> known to be problematic is still useable, but not via normal channels.
> Operators would be explicitly opting into lpr.
> 
> Thanks,
> 
> -- 
> Shawn Webb
> Cofounder / Security Engineer
> HardenedBSD
> 
> Signal Username:  shawn_webb.74
> Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50
> https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc

In this specific requirement, isn't ports sufficient?

If any specific version range(s) of port is marked as vulnerable
in vuxml, ports framework disallows building it by default and
to bypass the check, DISABLE_VULNERABILITIES make argument needs
to be set to "YES", thus, (IIUC) official pkg builder wouldn't
build it, so any local admins need to "intentionally" build it
locally.

If the same kind of restrictions can be introduced into base,
local admins who want to install anything marked as vulnerable,
knowing and taking risks by themselves, can build it from src
locally.

This would be an "intermediate" solution between keeping and
removing. Not sure how difficult to implement it.

Shawn, this kind of features best fit to HardenedBSD, isn't it?
This woukdn't be only for lpr family.

Regards.

-- 
Tomoaki AOKI    <[email protected]>