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]
