[vlc-devel] [PATCH 1/2] cli: remove TCP mode (--rc-host)

[Rémi Denis-Courmont]

Le lundi 23 novembre 2020, 11:33:46 EET Pierre Ynard via vlc-devel a écrit :
> > We are not deciding that now. It was that way all along for the last
> > 16 years or so. The only difference is that security is a much more
> > pressing and visible issue nowadays.
> 
> Okay, let's assume that intent. The problem is still that, as I can't
> see any material substantiation for it,

Substantation of what? Do I really have to explain how to get RCE out of 
untrusted options yet again and thus make it extra easy for script kiddies? 

> users probably can't either.

But that's the whole point. Users don't realize that enabling the "remote 
control" interface of a "media player" leads to full RCE, and I can't fault 
them for that. That's *our* fault for failing to provide adequate security.

> > And the justification for having an ridiculous insecure TCP mode
> > with broken (C) or no (Lua) support for event notifications is what
> > exactly?
> 
> I don't motivate TCP mode from backwards compatibility, but as a good
> and valuable feature with valid use cases that we want to provide,

Backward compatibility is the *only* possible motivation. If you don't care 
about strict compatibility, you can use the so-called telnet interface which 
provides the exact same functionality as RC's TCP mode.

And that's solely for the users who want to remote control VLC through a 
command line interface, which can be counted with fingers. For prorgammatic 
use, the HTTP control requests are much saner, and indeed, that's what all VLC 
remote control apps use already.

So hmm... why exactly do you want to keep TCP mode then?!

> and thus keep. I see no real justification for not having event
> notifications in the lua CLI apart possibly from technical limitations
> in lua bindings, so indeed this would have been another missing feature
> never added there, you're right.

> > As a matter of fact, most commands don't return anything at this
> > time. I just added error codes, but that's brand new, and it's not
> > propagated. And I can't propagate it in socket mode as that would
> > obviously break backward compatibility.
> > 
> > No! There is no such thing in 3.0 RC either, or any previous version.
> > It was not even architecturally possible, as commands were (ab)using
> > the variable callback system.
> 
> When I type commands, it outputs "returned 0 (no error)" and other
> notification messages as a response, even over TCP, so I'm not sure
> what you mean.

It does not. Not in the C RC interface. And it couldn't be added without 
breaking compatibility with older versions of its self. And that seems rather 
obnoxious also. My shell does not tell me about "no errors" for every command.

> > And really, that's the whole point: the only motivation for TCP
> > mode would be backward compatibility. But if we can't keep backward
> > compatibility because we want to add a password test, a prompt and/or
> > a result code, then that's moot.
> 
> I disagree that backward compatibility is the whole point.

And the point is what then? Save 0.0001% of the user base from adjusting their 
command line to start the Telnet interface instead of RC?

> Also, requiring to set a new setting for the password is a whole lot less
> problematic than requiring to arrange a new channel or switch to a new
> remote interface.

Of course. But if you are okay with requiring a password, why do you even 
object to removing CLI TCP mode while keeping Telnet? (That's what this 
patchset does, just saying.)

> And the switch away from the lua CLI involves many small differences in
> features and output; adding a prompt (which I'm not saying I advocate)
> would actually maintain compatibility from 3.0,

Adding a prompt and adding result codes breaks compatibility with C RC. It was 
a bug in Lua to break compatibility in the first place (and one of the reasons 
for keeping C RC all along). So I am not implementing bug-compatibility with 
Lua RC as the expense of self-compatibility.

> except on Windows where
> the lua CLI wasn't the default. I don't think you'd consider those minor
> things as problematic for the transition.
> 
> > > I did already have a word with him about it, he confirmed what's
> > > written in the notes.
> > 
> > That's not my problem.
> 
> What if I said that back to you, that what you bring up is not my
> problem? This is a team project.

A team project where you don't follow the bug reporting practices.

Out of the alleged "regression" bugs that you reported:
- One bug did not exist. You must not have tested (4.0) at all.
- One report looks like a feature request against core, not a C RC bug.
- One report relates to Telnet rather than RC.
- Make that two if counting the VLM report.

Also:
- One bug (seek) was promptly fixed.
- One bug (volume) was pending and is now fixed.
- One bug is pending (item meta).
- And one last report is addressed by patch 2 right here.

-- 
Rémi Denis-Courmont