Re: routed && route6d removal proposal

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.
>
>  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.
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