Re: Retiring lpr and lpd

--o2abac2bknx74lyl
Content-Type: text/plain; protected-headers=v1; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Subject: Re: Retiring lpr and lpd
MIME-Version: 1.0

On Fri, Feb 20, 2026 at 07:40:54PM +0100, Dag-Erling Sm=F8rgrav wrote:
> Hi,
>=20
> 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.
>=20
> 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.
>=20
> 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
=66rom 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,

--=20
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/03A=
4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc

--o2abac2bknx74lyl
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmmgq1gACgkQ/y5nonf4
4frkaQ/+KffP14f1/gz0BygzIokZxviL4T7WGZoR1obD0eIJmjstMe2FV69Eq92r
eYFOhtD8RnuDOnFVmNs+7gJiQQmgy63Z7D+s11SAWDKT8wqfNmwTZ0VJAq1ofmNZ
za8VPn39nXIj6dP01bX9wmjgtdNgOYptLE9E1kPgHLPVzlFvXw8q3x0cWwUM5Yr5
kInNyrwtzVb6Is4m4TUNWetNtufZ13YpLA95QRSV99CunZCod6ArgaswmzURZU87
1eUyngvBxivGx9ijsoUQ5g/RHWjZUfQsBe8REhLuNjQSL/YhZx8jsxXB1O6cvZn2
lvxOa/3pgpv/uRHm+eZPFkPgWJuFzbeQlHQjW2JZENtTJQRzeS1AFUvDgfsQhkR4
2BR/NiWU6mwC4eiCNTLZR23oxv8ryiO8r+Qyc5d5mAuqChe24FlKkkz6HuJwJ4C1
9NR8Yepb98WRuWqzKewf11kR8Zgcwb+PqDztAReDtAlRvGKXrtXGwdtg5HXLNOvn
U2vDV+uBaTdfjJKhzv/hbUPjKeWJCej68PnXPg2Zd85XYlHor2cE3ahxPiG89G0N
V7M82GGT6NA6kCQ06Uf383bniQMArvljqEwW0nNI97icyyL1Icy0UFSevHr0//eN
vcS2DZB68ZWJb3ElsLZ/7PyZfT5v28bZ3EYLSs5ReS9B/nLpal8=
=PJ3i
-----END PGP SIGNATURE-----

--o2abac2bknx74lyl--