Re: removing Secure RPC DES authentication

On Sun, Aug 17, 2025 at 01:32:03AM +0100, Lexi Winter wrote:
> this is somewhat connected to the thread "ABI guarantees" but because
> it's about a specific feature, i thought it would reduce noise to create
> a new thread for it.
> 
> currently we include functions in libc to provide "Secure RPC", an
> authenticated form of RPC that uses DES to secure inter-host traffic
> and authenticate users across the network.  Secure RPC is a core part
> of NIS+, an updated version of NIS/YP.
> 
> libc support for Secure RPC is not self-contained, but relies on an
> external daemon called keyserv(8) to manage the key material.  this
> daemon was removed from the base system in January (9dcb984251b3[0]),
> at which point Secure RPC became non-functional: any attempt to use
> it will return an error.
> 
> [0] https://cgit.freebsd.org/src/commit/?id=9dcb984251b3
> 
> the justification for this removal was that Secure RPC relies on DES,
> which means it's not actually secure at all, and no one should use
> it[1].  i find this perfectly reasonable, and no one has objected to
> its removal.
> 
> [1] while it might have applications for retrocomputing, as far as i'm
>     aware, every system that supports NIS+ also supports NIS/YP, and
>     both provide equivalent security, so there is very little reason
>     to deploy NIS+ nowadays.
> 
> later, since the related libc functions no longer worked, i removed
> these and replaced them with stubs[2], meaning old applications would
> continue to run, but new applications could not be linked with these
> symbols.  kib@ objected to this change[3], so this was reverted[4].
> 
> [2] https://cgit.freebsd.org/src/commit/?id=7ac276298b72
> [3] https://lists.freebsd.org/archives/dev-commits-src-main/2025-August/034755.html
> [4] https://cgit.freebsd.org/src/commit/?id=837b13af68bd
> 
> i would like to discuss this with the aim of re-applying this change,
> so we once again remove these functions and replace them with stubs.
> my argument for this is:
> 
> * the functions don't work and will always fail; instead of shipping
>   dead code that tries to make (local) network connections, we can
>   achieve the same result by removing the code and returning the
>   error early.
> 
> * the user cannot take keyserv(8) from an older release and build it
>   on 15.0, because it relies on undocumented, private libc symbols
>   that are not protected by the ABI guarantee and could be removed
>   or broken at any time.  since we aren't providing compatibility
>   here anyway, it's cleaner to remove the entire thing at once (in
>   15.0) rather than encouraging users to rely on private APIs.
> 
> while i understand the desire to support backward compatibility for
> applications, i see this as similar to removing Xerox XNS: that also
> broke applications, because any application that relied on XNS stopped
> working, but this was justified because XNS is an obsolete network
> protocol.
> 
> similarly, DES authentication for RPC is an obsolete network protocol
> that has also been overcome by events.

There is confusion between the feature stability vs. ABI stability.
Feature stability means that we never remove feature, like RPC DES auth,
or NIS nss, or rpcbind. ABI stability guarantees that binary is provided
with interfaces from base system' binary objects. We must provide the
same code for the binary with libc.so.7 as it was when the object was
linked. Of course this is true modulo the added features and bug fixes,
but even bug fixes are more nuanced and we do have to provide bug-to-bug
compatible compat implementation often.

If the libc functions cannot work on stock base because e.g. keyserv was
removed, it is user' problem to recreate the outer environment.  For
instance, bind was removed, and recursive resolver replaced by unbound.
To get full previous functionality, users need to install bind.

Now lets switch to the discussion of the feature, not ABI.

I am not sure what was the reasoning for the removal of the keyserv?
Is it because you decide that it is 'unpopular'?  The proverbial lack of
complaints from the current- users is not an argument, the userbase for
current is miniscule.  The flood of reports comes after x.1, if not x.2,
release.

Was keyserv at least moved to ports?  I doubt, due to your mention of the
private libc interfaces.

What is the cost we have to pay to keep secure RPC in libc and possibly
the daemons in ports?  Is there some fantastic feature that is blocked
by the cost of handling of the secure rpc?

Not an argument for anything, but glibc does have the secure rpc, which
is because, I suspect, that they also have nis+.