PSA: lpd/lpr will be removed from FreeBSD

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:

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.
What I had proposed earlier was moving it to a base pkg. I’ll go deeper in the example call it FreeBSD-printing if it doesn’t have its own already. Then just don’t install it. Make a set for optional.txz for future things like this and so on if needed. Allow users to select it and install it if they want to and install time but just don’t install it by default security problem solved for those it would be a risk for. That is something I would propose a contribution for. If that is a proposal that would get accepted.
 
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.
Well from a user point of view CUPS is the easiest way to get your printer running. Period. It's today the de facto standard in terms of printing software on *NIX based systems. Since it is so wide spread it is also the best bet to get your printer running if it has obscure functions.

CUPS is being used in MacOS and comes shipped with it by default.

From a FreeBSD perspective the license is a Apache 2.0. So this is also on the better side of affairs.

What might push some people away from CUPS is that Apple Inc. owns it nowadays, but there's also an active fork by OpenPrinting.

In short: most people will install CUPS anyway when trying to print stuff. CUPS is what put development to most other alternative to a halt.
 
Well from a user point of view CUPS is the easiest way to get your printer running. Period. It's today the de facto standard in terms of printing software on *NIX based systems. Since it is so wide spread it is also the best bet to get your printer running if it has obscure functions.

CUPS is being used in MacOS and comes shipped with it by default.

From a FreeBSD perspective the license is a Apache 2.0. So this is also on the better side of affairs.

What might push some people away from CUPS is that Apple Inc. owns it nowadays, but there's also an active fork by OpenPrinting.

In short: most people will install CUPS anyway when trying to print stuff. CUPS is what put development to most other alternative to a halt.
I did acknowledge this earlier when I presented my case.
 
Well from a user point of view CUPS is the easiest way to get your printer running. Period.
No, it is not. Period.

It is perhaps easiest only for people that do want to take a little of time and learn before configuring.
That user should be using MS Windows, not FreeBSD.

In short: most people will install CUPS anyway when trying to print stuff.

I will not bloat my system for doing something like: cat file.ps > /dev/lineprinter
 
when you need to install a web interface for something as simple as sending a document to a printer, something is wrong. It feels like systemd...
Indeed.

This happens when computers are seen as completely black box.

People does not know for what lpd or cups is there, only know that they must do something with them for printing,
and if lpd is not there, then cups must be there.

Cups may have an advantage over lpd: it is bidirectional and may be better for some strange printers.
But it is worth the big bloat? I prefer to change the printer.
 
Also cups needs ppd drivers for your specific printer. If no ppd driver exists , problem.
For intelligent printers you can use netcat , nc.
How i currently print :
Code:
gs -q -dNOPAUSE -dBATCH -sDEVICE=pxlmono \
   -dDuplex=true -dTumble=false \
   -sOutputFile=output.prn \
   -c "<</Duplex true /Tumble false>> setpagedevice" \
   -f $1
nc <IP-ADRES-PRINTER> 9100 < output.prn
 
Well from a user point of view CUPS is the easiest way to get your printer running.
Installing Windows and popping in the printer driver CD is certainly easier. Especially for bargain bin printers like most consumers have.

However as per this forums, we tend to like FreeBSD and software that aligns to the same UNIXy / light design.

most people will install CUPS anyway when trying to print stuff. CUPS is what put development to most other alternative to a halt.

You aren't wrong. But CUPS is is a (heavyweight) compromise and workaround, rather than the goal. I would even consider VirtualBox + USB passthrough and use that as my "cups" server if I absolutely *needed* some random printer to work. Neither solution is great though.
 
I have an HP multifunction printer; I need to be able to use its fax, scanner, and printer functions. I tried in the past to avoid CUPS (disaster! It was impossible, at my level of expertise, to get this printer working without it). I installed HPLIP, and everything works. Some HP printers expose a small internal HTTP API via their embedded web server. So, no more CUPS. Is it possible to access all these functions other than HPLIP or CUPS?
 
I have an HP multifunction printer; I need to be able to use its fax, scanner, and printer functions. I tried in the past to avoid CUPS (disaster! It was impossible, at my level of expertise, to get this printer working without it). I installed HPLIP, and everything works. Some HP printers expose a small internal HTTP API via their embedded web server. So, no more CUPS. Is it possible to access all these functions other than HPLIP or CUPS?
I used to initiate scans from printer webUI. Never faxed, but my printer had a touchscreen to presumably do it from there.

I only ever used CUPS since like 2016 and took it for granted allowing easy printing to printers on wifi with IPP. On FreeBSD I onestart/stopped CUPS when I needed to print (liked on-demand vs always-on default on Linux). I preferred CUPS as a generic print solution that happened to work with my printer vs HPLIP (iirc it was a Python or 3rd-party dedicated app; I might randomly want to print to something non-HP :p)
 
I used to initiate scans from printer webUI. Never faxed, but my printer had a touchscreen to presumably do it from there.

I only ever used CUPS since like 2016 and took it for granted allowing easy printing to printers on wifi with IPP. On FreeBSD I onestart/stopped CUPS when I needed to print (liked on-demand vs always-on default on Linux). I preferred CUPS as a generic print solution that happened to work with my printer vs HPLIP (iirc it was a Python or 3rd-party dedicated app; I might randomly want to print to something non-HP :p)
It is still possible to use hplip for full hardware recognition and support of the multifunction printer and use cups in parallel.
 
I have an IP printer , brother, don't know how to print. Normally it should understand IPP protocol & postscript.
Maybe print pdf pipe it through goscript and send it raw to the printer port ?

I have a Brother printer as well -- I use "Raw" for the printing when I setup CUPS and .. everything I have is printing? This includes CUPS on FreeBSD, Linux, etc.

The complaint about CUPS is... you don't want to use HTTP to configure it... okay :)...

But you are "completely okay" using HTTP/HTTPS to type "your complaint" about using CUPS on to the FreeBSD Forums?

Makes sense..
 
The complaint about CUPS is... you don't want to use HTTP to configure it... okay :)...

But you are "completely okay" using HTTP/HTTPS to type "your complaint" about using CUPS on to the FreeBSD Forums?
I don't think HTTP is the issue people have with CUPS. The extra dependencies it drags in isn't really HTTP related either.

But going with your analogy, people are completely OK using a lavatory if they have an upset stomach but don't want to involve a lavatory when preparing food or printing documents. Does that make sense?
 
But then you still use lpd , which is insecure and obsolete and will be gone. No long term project ...
That was the point here.

i'm still trying to find out what that "insecure" actually is.
From what I read so far, the big issue seems that your system gets into some troble when you try to print files that are bigger than your disk.
Well, what a surprize!

Corrollary:
when I happened to travel Africa and SE-Asia, the thing I enjoyed most was that there is no security. People know that they will die at some point, and they accept that risk.
Here, in our "civilized" madhouse, we need over- and over- and over-insurance in order to avoid that anybody ever dies. But nevertheless, still everybody will die at some point. It is just about harrassing the people - and also, as Herger the Joyous did say: The All-Father wove the skein of your life a long time ago. Go and hide in a hole if you wish, but you won't live one instant longer. Your fate is fixed. Fear profits a man nothing. (The 13th Warrior)
 
But going with your analogy, people are completely OK using a lavatory if they have an upset stomach but don't want to involve a lavatory when preparing food or printing documents.

I am sure there is still a (link - Wikipedia) Walnut Creek FreeBSD CD ROM you can install if you really want to FREEZE your entire operating systems for good to the "good ole days" in the 1990s.

For the rest of us -- "we live in the real world" where software is going to go out of date and will be removed from the current FreeBSD software release.

BUT! Good news, software NEVER DIES -- You can always (til the end of time? Or the length of AI's short term memory?) download, compile and install the LPRNG software on to your own FreeBSD host for as long as you like from Source Forge - Here's a (link - Source Forge) LPRng - An Enhanced Printer Spooler
 
des@ is in a difficult position here. On one hand his action would require providing evidence of insecurity. On the other hand that would tip off people who want to hack all the systems that still have lpd/lpr (otherwise known as all of them).
 
Insecurity, were are not running an inetd server. 99.99% are behind our provider.
The thing is we need someone, who looks after the code. And also watches future directions.
 
I am sure there is still a (link - Wikipedia) Walnut Creek FreeBSD CD ROM you can install if you really want to FREEZE your entire operating systems for good to the "good ole days" in the 1990s.
I feel a compromise can be had. Doing nothing at all, could well be that ;)

No need to FREEZE. Of course I am happy for them to fix lpd if they had time. Or as cracauer@ mentioned, prove how a disabled by default program can be a security hazard.

For the rest of us -- "we live in the real world" where software is going to go out of date and will be removed from the current FreeBSD software release.
The real world might just end up being stuck with nothing but restricted consumer tablets with an entirely web based environment. So I wouldn't be too keen on joining that race to the bottom. Regressed functionality means we might just end up yearning for the days we had access to a general purpose OS from the 1990s. No age verification for one...
 
Back
Top