Re: Retiring lpr and lpd

On Sun, Mar 1, 2026 at 1:05=E2=80=AFAM Lexi Winter <[email protected]> wrote:
>
> Rick Macklem wrote in <CAM5tNy67+gp=3DOBMRJaBTWXv_K3axtHZ-cb3c8Xsq5N9JxXk=
[email protected]>:
> > Security, like safety, is not an absolute. It requires a user/sysadmin
> > to evaluate the risks and make an informed decision on what to run
> > and how to do it.
> > --> Firewalls were invented for a reason.
> >
> > For example, if you want to secure it, NFS must be used with
> > either Kerberos or TLS. but almost no one does this, due to
> > administrative hassles and performance issues (encrypting/decrypting
> > all those messages results in a lot of overhead).
>
> i think there's a difference between NFS and lpd here.
>
> with NFS, anyone with expertise in NFS is familiar with the various
> issues it has (e.g., no encryption/authentication by default) and
> therefore knows that to deploy NFS securely, they must use Kerberos
> or TLS.  the only FreeBSD-specific knowledge they need is how those
> features are configured on FreeBSD.
>
> an administrator who is not competent in NFS may deploy NFS in an
> insecure way by accident, but this is not a security vulnerability
> in FreeBSD, any more than the fact that someone may deploy a website
> without TLS by accident, which does not represent a vulnerability
> in Apache HTTPd (or nginx, etc.).
All good points, which I would tend to agree with. However, it seemed like
others felt that insecure --> purge it from both /usr/src and ports, to
protect users from inadvertent misuse. (Similar to the "force everyone
to use https and not http edict".)

My original post was just "I do not think insecure is a
sufficient condition for removing software from the default system
configuration,
let alone purging it from /usr/src and ports".

>
> with lpr, the situation is different, because the software itself
> has known security issues that are not inherent in the lpr protocol
> (to the extent that it even has a protocol) or the concept of print
> spoolers in general.  that means even someone competent with print
> spoolers could inadventently open security issues that are specific
> to the FreeBSD implementation of lpr.
>
> i don't have any particular opinion on whether lpr should be removed,
> but i don't think this is a good argument against it.
>
> > (For example, I use ftpd. I know there are security vulnerabilities, bu=
t
> >  they are not a concern in the environment I use it in.)
>
> ftpd, as far as i know, has no known security vulnerabilities.
> there are certainly security issues with deploying ftpd with
> plaintext password authentication over a clear channel, but
> again, anyone competent in administration of an FTP server is
> well aware of that, and ftpd could still be used to provide,
> e.g., anonymous FTP access.
>
> i did remove ftpd in 15.0, but this was not because it was insecure or
> had any known vulnerabilities (as far as i'm aware); rather because the
> consensus of the project was that FTP is not a very widely used protocol
> nowadays and replacements for ftpd can easily be found in ports.  NFS is
> again a bit different here because you couldn't just put the NFS server
> in ports.  (well, i suppose you could, but ports kmods are terrible and
> everyone hates them.)
That is not my recollection. I may be wrong, but my understanding was
that removal of ftpd was because it was insecure and people "should"
use scp, because it is more secure.
(For me, I use ftpd, since I find it convenient for moving files between
Windows and FreeBSD. However, I didn't have a problem with it being
moved to ports.)

How to decide when to move something from /usr/src to ports is a
separate topic. It might be possible to create some guidelines...

I vaguely recall that, for drivers for old hardware, it took 5 users
emailing that they still wanted it to keep it in /usr/src. (This was
when Brooks Davis was getting rid of old NIC drivers, I think?)

Insecure could be a factor in the decision making process, but
I do not think it should be considered a sufficient condition for removal.

rick