routed && route6d removal proposal

[Chris]

On Wed, 24 Jun 2020 10:07:34 +0100 Alexander V. Chernikov melifaro at freebsd.org said

> 22.06.2020, 14:54, "Hiroki Sato" <hrs at freebsd.org>:
> > "Alexander V. Chernikov" <melifaro at freebsd.org> wrote
> >   in <273191592779927 at mail.yandex.ru>:
> >
> > me> Hey,
> > me>
> > me> I would like to propose removal of sbin/routed and usr.sbin/route6d.
Please don't.

> >
> >  I am still using both of them in production environments because they
> >  work well at least for my configurations and most of promising
> >  alternatives are under GPL, not BSDL.
+1 on this.

I began using this around FreeBSD 6, and continued using it through 9. I
also chose this as a solution for several of my clients. I use it because
it's "cheap" -- simple, lightweight, and dependable. With near zero
maintenance -- and it's already available in $BASE. While fairly utilitarian
by today's standards. Sometimes you just need to get the job done, and this
does just that. Which IMHO makes this a shinning star.
Please don't remove this. It's going to make the lives of others a little
more difficult.

Thanks for taking time time to read.

> That's actually a very good datapoint I certainly missed.
> >
> >  Why do we need to rush to remove them? Discussion about whether we
> There is no rush. In my opinion, popularity&usage of rip is going in one
> direction, for the reasons stated in the original e-mail.
> At some point in time it's worth checking the reality and verify whether we
> still need it in base or not.
> I stated 2 week timeframe (though I admit I wrongly written Jun instead of
> July) for collecting feedback to base a decision upon.
> It looks like there is enough feedback already.
> >  should keep or remove such old bits tends to be controversial when
> >  there is a user like me. I would agree with the removal if they were
> >  harmful or impossible to maintain, but would not for the reason that
> >  they are simply old and probably no one uses it today. Reason 1 and
> >  2 look like the latter at least to me. "too old to be worth keeping"
> >  is a matter of degree. Uucp, rlogind, and timed should be removed
> >  (and were removed) because there are few non-FreeBSD platforms which
> >  support these protocols. RIP is still widely supported---just like
> >  FTP, which nowadays no one prefers to use and major www browsers are
> >  about to drop the support of---and not be considered an inherently
> >  vulnerable protocol like telnet. And keeping these daemons is not
> >  harmful even for users who want to use third-party routing daemons
> >  you listed.
> My concern is hidden housekeeping costs. You have to update the
> documentation, where
> it exists. There are some bugs and you have to do something there. There are
> security vulns or Coverity reports.
> when you do a change, you have to verify it somehow and you have to tests,
> so you have to spend more time.
> Each of it is a small thing by itself, but they add up and drain developer
> time.
> 
> >
> > me> 1.1. Nowadays the daemon name is simply misleading. Given situation
> > me> described above, one does expect far wider functionality from the
> > me> program named "route[6]d" than just RIP implementation.
> >
> >  I do not think this is a good reason to remove something nor people
> >  have got confused actually. If this is true, quagga or bird are much
> >  worse.
> >
> > me> 2. Multiple routing stacks supporting all major routing protocol
> > me> including RIP exists these days: bird, frr, quagga. Many BGP-only
> > me> designs in are gaining popularity, so do bgp speakers such as exabgp
> > me> or gobgp. Nowadays, if one needs dynamic routing on the host, OSPF or
> > me> BGP speaker is the choice. FreeBSD packages contains well-maintained
> > me> ports for these. Having RIP[ng] speakers in base offers no advantage.
> > me>
> > me> 3. Both routed/route6d are largely unmaintained [4] and presents an
> > me> additional attack vector. Here is the list of last non-trivial commits
> > me> to routed/route6d:
> >
> >  I think this is a separate issue. What attack vectors which are
> >  known to be vulnerable do they have?
> I'm referring to the cases like SA 14:21 or SA 20:12.
> >
> >  The small commit counts are not equal to its unreliability. Older
> >  daemons such as ppp(8), dhclient(8), ftpd(8), or bootpd(8) have
> >  received few substantial changes in recent years because they are
> >  mature.
> Well, I see another alternative reason, but that's another discussion :-)
> Also, dhclient got 50 commits in the last 4 years, so I wouldn't put it in
> this list.
> >
> >  I am not a strong protester and will be happy to keep them as ports
> >  if everyone wants to remove them and it will happen, but I would like
> >  consistent criteria on removing software in the base system (they do
> >  not need to be perfect nor strict, though). I believe harmfulness is
> My criteria (briefly) is the "moral" staleness, existence of the viable
> alternatives and no users.
> I should have stated the latter more explicitly.
> >  more important than the fact that it is old or we have more choices
> >  in the ports tree. If we have negative factors on maintaining them,
> >  removing them would be one of the choices as a result. If the
> >  existing routed/route6d makes difficulty on people who want to use
> >  third-party routing daemons, it should be fixed. These kind of
> >  harmfulness look below the threshold to me at this moment though I
> >  may be biased because I am still using them today...
> >
> > -- Hiroki

--Chris