What to do about rcmdsh(3) ?

[John Baldwin]

On 7/3/18 9:43 AM, Eitan Adler wrote:
> On Tuesday, 3 July 2018, John Baldwin <jhb at freebsd.org <mailto:jhb at freebsd.org>> wrote:
> 
>     On 7/2/18 8:30 PM, Cy Schubert wrote:
>     > In message <CAF6rxgmJZyivZtQDKnUa12DJ5PqWVp40wOQg5Wt8zJWeuUUJYg at mail.gma
>     > il.com <http://il.com>>
>     > , Eitan Adler writes:
>     >> On 26 June 2018 at 23:45, O'Connor, Daniel <darius at dons.net.au <mailto:darius at dons.net.au>> wrote:
>     >>>
>     >>>
>     >>>> On 27 Jun 2018, at 13:01, Eitan Adler <lists at eitanadler.com <mailto:lists at eitanadler.com>> wrote:
>     >>>>
>     >>>> On 24 June 2018 at 05:14, Konstantin Belousov <kostikbel at gmail.com <mailto:kostikbel at gmail.com>> wrote:
>     >>>>> On Sun, Jun 24, 2018 at 03:32:13AM -0700, Eitan Adler wrote:
>     >>>>>> Now that the rcmds are removed from base, it opens a question about
>     >>>>>> what to do with rcmdsh(3).
>     >>>>>> This is documented as
>     >>>>>>     rcmdsh ??? return a stream to a remote command without superuser
>     >>>>>> And is implemented as a rather simple wrapper of getaddrinfo and exec.
>     >>>>>>
>     >>>>>> This isn't something I'd imagine we'd add to libc now-a-days and is
>     >>>>>> currently broken by default (due to defaulting to _PATH_RSH)
>     >>>>>>
>     >>>>>> I'm not sure there is much value in keeping this function around. I
>     >>>>>> did a rather naive search for uses of this function in ports and
>     >>>>>> couldn't find any. I'm preparing a more comprehensive patch for an
>     >>>>>> exp-run.
>     >>>>> There is a huge value in keeping ABI compatibility.  The symbol must be k
>     >> ept.
>     >>>>> You may remove default version for the symbol if you are so inclined.
>     >>>>
>     >>>> I'm new at this. How does one do that?
> 
>     >
>     > If you wanted to retire the symbol as suggested
>     by kib@ that would also be fine and would prevent new applications from
>     using it going forward (but you don't get to remove the source from libc).
> 
> 
>  Sounds like a plan. I'm new at this. How does one do that?

See https://reviews.freebsd.org/D12298 and the change to gets.c in
particular.  You rename the function and add a __sym_compat().  You will
also want to update the manpage to note it has been removed and you need
to MFC the deprecation warning to older branches.  Possibly the actual
removal needs to be deferred to 13.0 since we are fairly close to 12.0.
Also, we haven't had any real warnings.  So, what I would do is the
following:

1) As a trial balloon, hack up a patch that just removes rcmd() and rcmdsh()
   and any other related functions from the headers and request an exp-run
   just to ensure ports don't blow up before investing a lot of work in the
   "full" solution.

2) For 12.0 I would add __warn_references() warnings for rcmd() and rcmdsh()
   (see gets.c for examples) as well as deprecation notices to the manual
   pages.  These changes can also be merged to stable branches.

3) After 12.0 branches, I would use the __sym_compat approach to preserve
   the existing versioned symbols but remove the default version (this
   also means removing the prototypes from headers).  This patch will
   probably also need an exp-run.

-- 
John Baldwin