Re: Deprecating ftpd in the FreeBSD base system?

On Thu, Sep 17, 2020 at 3:54 PM Ian Lepore <ian_at_freebsd.org> wrote:

> On Thu, 2020-09-17 at 12:49 -0700, John-Mark Gurney wrote:
> > Ian Lepore wrote this message on Thu, Sep 17, 2020 at 09:01 -0600:
> > > On Thu, 2020-09-17 at 18:43 +0400, Gleb Popov wrote:
> > > > On Thu, Sep 17, 2020 at 6:05 PM Cy Schubert <
> > > > Cy.Schubert_at_cschubert.com>
> > > > wrote:
> > > >
> > > > > I've been advocating removing FTP (and HTTP) from libfetch as
> > > > > well.
> > > > > People
> > > > > should be using HTTPS only.
> > > > >
> > > >
> > > > Isn't this a bit too much? I often find myself in need to
> > > > download
> > > > something starting with "http://" or "ftp://" and use fetch for
> > > > this.
> > >
> > > Indeed, we have products which rely on this ability in libfetch and
> > > we
> > > have to keep supporting them for many many years to come.
> > >
> > > I hate it when someone imperiously declares [For security reasons]
> > > "People should/shouldn't be using ______".  You have no idea what
> > > the
> > > context is, and thus no ability to declare what should or shouldn't
> > > be
> > > used in that context.  For example, two embedded systems talking to
> > > each other over a point to point link within a sealed device are
> > > not
> > > concerned about man in the middle attacks or other modern internet
> > > threats.
> >
> > And I really dislike when people want to make sure that their unique
> > case that less than a percent of people would every hit blocks the
> > security improvements for the majority of people...
> >
> > I've given up on a number of security improvements in FreeBSD because
> > of this attitude...
> >
>
> Good.  Because what you call "improvements" I would probably call
> "Imposing policy rather than providing tools."
>
> I've don't complain about making defaults the safest choices available.
> I complain about removing options completely because they're unsafe in
> some circumstances according to some people.
>
> -- Ian
>
>
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>

  Even making defaults the "safest choice" I have any issue with. Security
is a balance between risk, environment and usability.  The "Safest choice"
is turning your box off or cutting your internet connection. Now hardening
as an option in a global config file for whatever program I have no issue
with just need to be very careful on what is hardened by default and what
is exposed as an option for hardening to those who need it. Also as a
reminder just because something has a hardening option that is disabled by
default that doesn't mean the project ever needs to enable it by default.
Sometimes we add those options and have a migration path/timeline to them
being enabled by default sometimes we just add those options for those who
need them whether by policy, environment, or paranoia.

So a global option in a config file or ENV variable to disable unencrypted
protocols by default is fine. It just should

Also in defense of http is it allows caching. If you are downloading a
signed resource to 10, 100 or 1,000,000 boxes and don't care who knows
caching maybe a very helpful option.

--Nick "darkfiberiru" Wolff