PSA: lpd/lpr will be removed from FreeBSD

atax1a said:
what a weirdly condescending reply, considering you dont even know how old we are, or the kind of old software we keep running outside of this forum. but ok. sounds like you'd rather complain than contribute, you do you.
Click to expand...
perception is usually everything. Given the difference in avatars, I think it's entirely reasonable to assume a generational gap. LOL For instance, when you see a stone head that looks like a grouchy Karl Marx so you think of someone born post-y2k? or do you add 50 years onto that?
 
kent_dorfman766 said:
perception is usually everything. Given the difference in avatars, I think it's entirely reasonable to assume a generational gap. LOL For instance, when you see a stone head that looks like a grouchy Karl Marx so you think of someone born post-y2k? or do you add 50 years onto that?
Click to expand...
unfortunately for those concerned, we don't exactly experience linear causality, and so cannot answer the question as asked.
 
hedwards said:
If you hang around the open source world, or really computers in general long enough, you'll have favorite pieces of software that get discontinued for one reason or another. If you're lucky, it can be run in an emulator or container, for most of the time that I've been using computers that wasn't a viable option.
Click to expand...

Weeell, hold on a second.

Some of us use open source software specifically because this cannot happen against the will of a sufficient fanbase of such software. You can never really take it away.

The issue at hand here is that software with security issues is not "finished" and needs such a sufficient fanbase to code on it. That is an entirely different matter from kicking out software that is finished for some time and does not pose a risk.
 
cracauer@ said:
Weeell, hold on a second.

Some of us use open source software specifically because this cannot happen against the will of a sufficient fanbase of such software. You can never really take it away.

The issue at hand here is that software with security issues is not "finished" and needs such a sufficient fanbase to code on it. That is an entirely different matter from kicking out software that is finished for some time and does not pose a risk.
Click to expand...
Sort of, any software that doesn't have DRM tied into a server can potentially be used forever. The open source stuff offers more options in terms of keeping it going longer, but nothing is permanent. But looking at what's been happening with Linux being increasingly held hostage by key packages that are deliberately not compatible, I wouldn't just assume that open source doesn't mean that there can't be serious issues that result anyways.

I don't think that you can really separate not finished from the security issues that can come later on that so cleanly. Especially in a time when so many software packages use various libraries that have various degrees of security and doneness involved.

That being said, I do think that there should be a considerable amount of caution in terms of removing things if there isn't an obvious security or other issue to trigger it. But, that being said, ensuring that it's at least somewhat secure isn't free. It's just cheap these days.
 
atax1a said:
was there this much handwringing when they removed telnetd
Click to expand...
This one was a little crap in my opinion.

Sure, SSH is kind of the secure alternative but if you have ever tried to log into a truly ancient machine, it simply fails because the different encryption methods no longer align.
A more resilient choice is to keep telnetd, or have a standardized "null encryption" for SSH. Did telnetd need to be maintained? Not really, its a simple daemon it could simply idle there and not be removed.

That said, lpd, lpr, and telnetd are not part of POSIX / SUS so it isn't *too* terrible. (Though they are part of BSD heritage, lp is part of POSIX/SUS).
 
malco_2001 said:
Why do they need removed? Just don't install them for pkg base so those who still want them can install. I get annoyed with this and this needs to be removed because of security. Sure let's be like Linux and just rewrite everything and stop the concept of finished software.
Click to expand...
They at least keep it small this way. A FreeBSD amd64 world install is about 450MB
Assuming it's not the HP agenda of owning 100% corporate control of printers. Cups obsoleting support for old printers was already suspicious. Same problem, basically: there is no technical advantage. It's only dropping support for reasons. Best excuse I heard is lack of developer capacity, but we don't have to delete working things for that.
 
telnetd had a big security hole discovered just recently. At least the one on Linux, dunno how many variants are out there.

If you had a telnetd running as a backup to sshd you would have screwed yourself.
 
cracauer@ said:
telnetd had a big security hole discovered just recently. At least the one on Linux, dunno how many variants are out there.

If you had a telnetd running as a backup to sshd you would have screwed yourself.
Click to expand...
telnetd was always something that should never be exposed outside of a private and secure network. A bit like NFSv3 or.... lpd ;)

And lets be honest, Linux probably badly integrated systemd into it and fscked it up.

My bigger concern is when mount_smbfs(8) being dropped (like it was in NetBSD). The rationale was that v1 was no longer supported by Windows... Who gives a damn what Windows supports? We are running a completely different OS with our own SMB server. Worse was that NetBSD had no alternative and had to fall back on a very unmaintained and slow FUSE driver.

In most cases, the argument of "well maintain it yourself" is a little redundant when all it would be is reverting the removal commit :beer:
 
malco_2001 said:
Old software doesn't have to stop running, it doesn't have to be removed.
Click to expand...

If someone "wants" to run LPR/LPD on FreeBSD, now or a 1,000 years from now, there is nothing stopping them from doing so?

I have OLD UNIX software that I download from somewhere, compile myself and install on to my FreeBSD hosts. I don't specifically need some "specific software" to be specifically supported by some FreeBSD software repository/maintainer in order to use it.

For many years software would arrive over USENET (think "comp.sources.unix") and we compiled it and ran the finished binaries on our machines.

I mean "it's nice" that in 2026 there is a "pizza delivery" system set up to easily install software on to FreeBSD machines, but honestly this is not how it was done historically.

Sorry this is "inconvenient" - but really you should maintain and keep backups of the software you seriously care about on your FreeBSD host(s).
 
Alain De Vos said:
https://www.freshports.org/sysutils/LPRng/

Note, not maintained ...
Click to expand...

LPRng - Browse /lprng at SourceForge.net

The LPRng software is an enhanced, extended, and portable implementation of the Berkeley LPR print spooler functionality. While providing the same…
sourceforge.net sourceforge.net
LPRng has release 3.9.0 on 2023, but we use previous 3.9.C from 2012 in ports.
and looking into https://sourceforge.net/p/lprng/lprng/ci/master/tree/ tells us that upstream is still maintained.
Maybe, updating the port is needed.
 
So, what can a user do now?

* Current state: base lpr/lpd has vulnerabilities and no one dares to fix it.
* Possible future:
1. lpr/lpd just removed
2. lpr/lpd replaced by some other implementation
* Possible replacement of lpr/lpd in ports/packages
1. sysutils/LPRng
2. print/cups
 
Let me summarize a little.
It seems to have started with this bug report.

⚙ D55399 lpd: Improve robustness

reviews.freebsd.org reviews.freebsd.org
des@ tried to fix it, but it seemed to have a fundamental problem, so he proposed to abolish it.
cy@ tried to move it from base to port, but several people opposed creating a vulnerable port.
des@ wrote that he has done more in the last five days than in the last 25 years.
There was some opposition to the 25-year period.
 
  • Thanks
Reactions: PMc
atax1a said:
can't see anything wrong with cups tbqh
Click to expand...
Whilst I don't disagree in principal (after all, cups is generally needed for most printers anyway), the dependencies pulled in are fairly extreme for functionality simply to replace lpd.

avahi-app-0.8_6, brotli-1.2.0,1, dbus-1.16.2_4,1, dbus-glib-0.114, expat-2.7.4, gdbm-1.26, gettext-runtime-0.26, glib-bootstrap-2.84.4,2, gmake-4.4.1, gmp-6.3.0, gnome_subr-1.0, gnutls-3.8.12, indexinfo-0.3.1_1, libICE-1.1.2,1, libSM-1.2.6,1, libX11-1.8.12,1, libXau-1.0.12, libXdmcp-1.1.5, libdaemon-0.14_1, libevent-2.1.12, libffi-3.5.1, libiconv-1.18_1, libidn2-2.3.8, libinotify-20240724_3, libpaper-1.1.28_1, libtasn1-4.21.0, libunistring-1.4.2, libxcb-1.17.0, libxml2-2.15.2, mpdecimal-4.0.1, nettle-3.10.2, p11-kit-0.26.2, pcre2-10.47_1, pkgconf-2.4.3,1, py310-packaging-26.0, python310-3.10.20, python311-3.11.15, readline-8.3.3, xorgproto-2024.1, zstd-1.5.7_1
Click to expand...

Highlight includes, not one but two python interpreters (naturally)
 
atax1a said:
can't see anything wrong with cups tbqh
Click to expand...
For most people CUPS is the better answer. It is a larger footprint and has regular security issues of its own however. I think it's a matter of taste. Some people prefer pulseaudio over OSS. I prefer OSS. I even took the time to make an OSS sound backend for Gershwin Desktop Environment. I would have done the same for printing for LPD/LPR for when cups was not installed.

At least I thought ahead that FreeBSD might follow a the Linux trend of removing software so I wrote a DirectoyServices implementation to replace NIS that uses a custom NSS module. I would have liked to have added support for mdo as well instead of sudo.

My mindset is the smaller the footprint the better. I wanted to run on the lowest end devices and support a minimal FreeBSD as well as possible better than any desktop environment ever has. Now with age verification laws and security compliance's I am afraid my journey is probably going to come to an end before it can even really begin to show people what a purist experience can look like. Simply because the future is now uncertain as to whether or not I can develop software as a passion without legal risk, and not knowing tomorrow what components will be removed next. This thread was just another defeat, and de-motivator I am afraid.

With all that said if I had not the experience I have had I probably would defend the decision to remove LPD/LPR the same way. In fact I probably would have defended the same kind of decisions to "modernize" and remove unmaintained work I am sure of it. I just have a different philosophy now because how I see things has changed after watching the evolution of Linux especially in recent years. I see FreeBSD becoming a Linux Jr and find it somewhat uncomfortable, and saddening. It's just diminishing any hope I had left.
 
Charlie_ said:
Let me summarize a little.
It seems to have started with this bug report.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293278
https://reviews.freebsd.org/D55399
des@ tried to fix it, but it seemed to have a fundamental problem, so he proposed to abolish it.
https://lists.freebsd.org/archives/freebsd-arch/2026-February/001174.html
cy@ tried to move it from base to port, but several people opposed creating a vulnerable port.
https://lists.freebsd.org/archives/freebsd-arch/2026-February/001207.html
des@ wrote that he has done more in the last five days than in the last 25 years.
https://lists.freebsd.org/archives/freebsd-arch/2026-February/001231.html
There was some opposition to the 25-year period.
https://lists.freebsd.org/archives/freebsd-stable/2026-March/003894.html
Click to expand...
I missed this.

I don't know if OpenBSD's implementation of lpd is vulnerable. Perhaps a quicker fix would be to import that.
Looking at the code (and noting last commit message), I don't immediately spot anything that is very unportable. des@ mentions "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" so I would propose breaking compatibility is much better than removal. OpenBSD's implementation should be no problem.

Of course as des@ mentioned, priorities based on finance:
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.
Click to expand...
So its probably much easier (and free) to leave alone the version in base and simply not execute it on important machines.
He mentioned that most people have "moved on to IPP" so there is very little risk.

But as mentioned, I don't really use it myself so am not avidly against its removal, But if they simply stated "eww, its old and I don't like old", that seems like a stronger reason to remove it than the ones given.
 
You must log in or register to reply here.
Back
Top