On 02/23/2026 8:43 PM CST Greg 'groggy' Lehey <grog@freebsd.org> wrote:
I've asked numerous times, but nobody has told me whether they
have spoken with the OpenBSD project about it. And what about
NetBSD or DragonflyBSD?
On 02/23/2026 8:43 PM CST Greg 'groggy' Lehey <grog@freebsd.org> wrote:
I've asked numerous times, but nobody has told me whether they
have spoken with the OpenBSD project about it. And what about
NetBSD or DragonflyBSD?
Have _you_ spoken to them?
So, where are all these magical entities who are supposed to do the
boring daily grindy work like this?
Have they ascended to another plane, or are they just tired, old,
people like me?
On 02/23/2026 8:43 PM CST Greg 'groggy' Lehey <grog@freebsd.org> wrote:
I've asked numerous times, but nobody has told me whether they
have spoken with the OpenBSD project about it. And what about
NetBSD or DragonflyBSD?
Have _you_ spoken to them?
So, where are all these magical entities who are supposed to do
the boring daily grindy work like this? Have they ascended to
another plane, or are they just tired, old, people like me?
mcl
I'm really quite concerned about the plans to remove lpd. IFeel free to review https://reviews.freebsd.org/D55399 yourself, keeping
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.
- I have done more to improve lpd and keep it alive in the last 5 daysYou have. I appreciate that. Thank you.
than everyone else combined in the last 25 years.
But I can'tBest,
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.
Greg 'groggy' Lehey <grog@freebsd.org> 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.
I estimate the effort needed to overhaul the entire code base and
add tests to about 200 hours or two months full-time.
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.
- 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.
- 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.
- 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.
On Tuesday, 24 February 2026 at 12:30:39 +0100, Dag-Erling Sm=C3=B8rgrav =wrote:
gGreg 'groggy' Lehey <grog@freebsd.org> 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, keepin=
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
You've caught me here. I had never heard of IPP. My understanding isCUPS!
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 wantNote that CUPS is maintained unlike BSD's lpd & it also used on MacOS.
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.
The real point of the message was further down, which you don't quote,Why not? We do that all the time. I don't think a single year has gone
and which core@ has not addressed at all: we shouldn't remove basic functionality from the base system.
IPP is the protocol that CUPS speaks. There may be otherIPP is the protocol that all modern network printer speaks. It predates
implementations, but Linux having adopted CUPS /en masse/ makes it
somewhat unlikely.
If the standard for being in ports was "no known vulnerabilities" IThat is in fact the standard. Ports with known vulnerabilities get
think we wouldn't have much of a ports collection.
In the case of lpd(1) and the traditional printing toolchain, no one has such illusions. For a quarter of a century now, all new deployments have been based on the CUPS printing system, which is permissively licensed
and readily available in the ports.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 59 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 05:36:14 |
| Calls: | 810 |
| Files: | 1,287 |
| D/L today: |
6 files (10,211K bytes) |
| Messages: | 204,948 |