[vlc-devel] [PATCH 2/2] cli: also mark --cli-host as deprecated

[Pierre Ynard]

> > That's a false dichotomy. There are plenty of other options, some
> > of which I've already brought up: just deprecating it in the
> > configuration and documentation while recommending an alternative,
> > printing big fat warnings about unsecured use,
>
> Neither of these options fix the issue. They're just disgraceful lame
> cop-outs.

Educating users and nudging them into the right direction is not
disgraceful on its own merit, even if we want better than just that.

> > actually securing it with access control,
>
> How? This is the HTTP interface all over again. We arrived at the
> point where it requires a password. But if we change the RC to require
> a password, then we break compatibility and I call that replacing it.

Okay, let's put a password on the CLI then. Even if there won't be
Telnet controls to disable the echo when typing the password, I don't
think that's a big issue. And it doesn't have to be a prompt upon
connecting, it can also be a CLI command that enables the client to use
the other ones.

> > leaving it to the administrators to use it only on trusted networks
> > or secure it using external tools such as firewalling,
>
> In other words, go back to the ACL model that was tried and failed,
> not heeding to our own 15 years of experience with the HTTP interface.

No I'm not talking about an internal implementation such as the ACL
system with its administration and one-size-fits-all problems, I'm
talking about leaving it to proper external tools and techniques of
choice.

> > or even mitigation such as restricting it to localhost.
>
> Not only that leaves a local escalation bug open, but it removes the
> only "advantage" of TCP over Unix -- that it works remotely.
>
> There are no merits to that option, are there?

That's not my favorite option either.

-- 
Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."