Re: lpd: the thin edge of the wedge?

IPP is the protocol that CUPS speaks. There may be other implementations,
but Linux having adopted CUPS /en masse/ makes it somewhat unlikely.

On Tue, Feb 24, 2026 at 10:23 PM Greg 'groggy' Lehey <[email protected]>
wrote:

> On Tuesday, 24 February 2026 at 12:30:39 +0100, Dag-Erling Smørgrav wrote:
> > Greg 'groggy' Lehey <[email protected]> writes:
> >> I'm really quite concerned about the plans to remove lpd.  I
> >> understand that there are security issues with lpd, even if I haven't
> >> heard any reports of exploits in over a third of a century, but the
> >> approach seems wrong to me.
> >
> > Feel free to review https://reviews.freebsd.org/D55399 yourself, keeping
> > in mind that it addresses only _some_ of the issues I found in just
> > _one_ of the 28 source files that make up lpr / lpd.
>
> No, I believe you.  You've only quoted the start of my message, and
> even there I say that I accept that there are security issues.  That's
> why I didn't copy you explicitly on my message.
>
> The real point of the message was further down, which you don't quote,
> and which core@ has not addressed at all: we shouldn't remove basic
> functionality from the base system.
>
> Still, to your points:
>
> > I estimate the effort needed to overhaul the entire code base and
> > add tests to about 200 hours or two months full-time.
>
> Noted.  I didn't expect the current code to be salvageable.
>
> > I would also like to point out that:
> >
> > - I have not removed lpr / lpd.  I have merely marked them deprecated
> >   and proposed a plan to remove them in or around September 2027, which
> >   is more than a year and half from now, unless they have significantly
> >   improved in the interim.
>
> Right, but the current course doesn't seem to make that likely.
>
> > - I have done more to improve lpd and keep it alive in the last 5 days
> >   than everyone else combined in the last 25 years.  But I can't
> >   continue to neglect my paying customers to fix something that almost
> >   nobody uses.  Someone will have to step up to either do the work or
> >   hire me to do it.
>
> Yes, I understood this too, just not the details.
>
> > - Simply moving the code to ports will do nothing to address the
> >   underlying issue, and I will strenuously object to adding software
> >   with known vulnerabilities to the ports tree.
>
> Agreed.  Moving to ports is exactly what I don't want to do.
>
> > - Some of the issues with lpd cannot be fixed because they are
> >   inherent to its design, which cannot be changed without breaking
> >   compatibility, which is _the only reason_ to keep lpd.  The rest
> >   of the world has moved on to IPP.
>
> You've caught me here.  I had never heard of IPP.  My understanding is
> that it, too, is not supported by the base system.  What would it take
> to change that?  It looks as if it could be a good alternative.
> Declaring lpd obsolete would be fine then, and people who really want
> it could then use a port.
>
> But CUPS is not the answer either, for most of the same reasons.  In
> addition, a comment from Theo (who confirmed that nobody had spoken to
> the OpenBSD community):
>
>   well, let them enjoy cups.  I have studied that monster a few times.
>   it is a huge piece of software lacking any attempt at a security
>   architecture, and a culture around it that will never make changes.
>   in such circumstances, i always stick to small pieces of software
>   where we can hopefully delineate the boundaries.
>
> Would you see things differently?
>
> Greg
> --
> Sent from my desktop computer.
> See complete headers for address and phone numbers.
> This message is digitally signed.  If your Microsoft mail program
> reports problems, please read http://lemis.com/broken-MUA.php
>


-- 
brandon s allbery kf8nh
[email protected]