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.
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. If we follow this direction, we can pare
down FreeBSD to a bare minimum (the kernel and what else?).
So what should be done? I'm explicitly copying core@ on this, though
I assume that you have all been following things. But this is a basic
issue for the project, so core@ (and not srcmgr@) should have a
position on this.
I understand that des no longer feels interested in maintaining lpd or
fixing its apparently numerous bugs. But there are alternatives:
1. Find somebody who *is* interested. I haven't seen anything on the
mailing lists asking for this. Why not?
2. Take the corresponding code from another BSD, like we have done in
the past. des tells us, without details, that the OpenBSD code
has the same bugs. 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?
3. Make it a shared project amongst BSDs, like make(1).
On 23 Feb 2026, at 21:43, Greg 'groggy' Lehey wrote:the past 2-3 weeks. We (RPI) had a major screwup with our VM cluster a =
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. If we follow this direction, we can pare
down FreeBSD to a bare minimum (the kernel and what else?).
So what should be done? I'm explicitly copying core@ on this, though
I assume that you have all been following things. But this is a basic=
issue for the project, so core@ (and not srcmgr@) should have a
position on this.
I understand that des no longer feels interested in maintaining lpd or=
fixing its apparently numerous bugs. But there are alternatives:
1. Find somebody who *is* interested. I haven't seen anything on the=
mailing lists asking for this. Why not?
2. Take the corresponding code from another BSD, like we have done in=
the past. des tells us, without details, that the OpenBSD code
has the same bugs. 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?
3. Make it a shared project amongst BSDs, like make(1).
Hmm. I seem to be out of some loop here.
First let me apologize for not following much of anything in FreeBSD in=
all our virtual machines to alleviate some [urgent] dangers, and is now=requiring
a second reboot of all our virtual machines because the first fix was i=ncomplete
so we now need to fix the fix.
Also, I went to do a minor macOS upgrade on my main PGP-capable mac las=t week, and instead that mac was upgraded two major versions of macOS. W=
Back in January Warner sent me an email saying *"It's been several years since you've committed to lpr/lpd. Is that still something
you're interested flagging for review in MAINTAINERS?".* I appreciate him reaching out like that, even if he was only trying to see if I was still alive. :) I replied *"Yes, at least for now. Thanks."* I expected to get
some lpd-related emails after that, but have not seen any. I realize that
it could be that some were sent and I missed them.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 65 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 11:11:11 |
| Calls: | 862 |
| Files: | 1,311 |
| D/L today: |
3 files (7,546K bytes) |
| Messages: | 265,264 |