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

[Rémi Denis-Courmont]

Le lundi 23 novembre 2020, 11:36:03 EET Pierre Ynard via vlc-devel a écrit :
> > > 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.

It is not. But adding documentation that we know all too well will be ignored 
by most users in the wiki, the NEWS file, a sticky forum note or whatever, is 
*not* educating users and nudging them.

It's really just pretend, so that we can tell people they were warned and 
deflect moral responsibility.

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

While this is possible, we just end up with duplicate CLI and Telnet interface 
functionality. I can't say that I see the point.

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

In theory, it's possible, if you have single user systems on a walled-garden 
network. The thing is, as we have seen with the furore over the HTTP interface 
password (or even before that, the untrusted item options), people way 
understimate the implications of running HTTP, RC or Telnet, and thus simply 
won't secure them more than they are forced to.

-- 
Rémi Denis-Courmont