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

[Rémi Denis-Courmont]

Le sunnuntaina 22. marraskuuta 2020, 14.41.22 EET Pierre Ynard via vlc-devel a 
écrit :
> How does it not support TCP on Windows at all?

The poll() code path exclude Windows.

And in any case, the poll() code assumes half-duplex, so really it does not 
work on any platform.

> Indeed. But the way you discuss this is still problematic. I'm going to
> take the time to state it, but I'm not sure why.

I guess I should just push instead of sending for review then.

> As for how it might have discouraged the preferred, secure use of
> Unix socket, I'm not aware that this opinion about deprecating TCP in
> favor of Unix sockets was a thing until recently.

What is that even supposed to mean? The Unix mode is not newer than the TCP 
mode. They were added at the same time, with TCP mode being essentially a 
quick-and-dirty workaround on Windows (obviously much easier than doing Win32 
messaging).

> It's still just your opinion,

No, the fact that TCP mode is insecure, and that socket support is broken in 
Lua is just a fact. You are just misrepresenting it as an opinion because you 
don't like it.

> and I pointed that out and rebutted it

No.

> If we do decide to deprecate TCP and recommend Unix sockets,

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.

> More importantly, this is not about comparing the merits of competing
> CLI implementations, this is about the merits of a feature. On Linux,
> TCP worked fine,

No, and I already pointed out multiple ways that it was broken.
In the patch and in the thread.

> Even more importantly, in particular, this is not a game of blame or
> tallying the regressions of whom or which to make one more deserving to
> assert their point of view.

That's rich of you to say when you were the first one  to complain about 
regressions. Yes some of the regressions were real, e.g. missing commands. But 
some were essentially about reproducing Lua implementation bugs in the C 
implementation (and in some cases, break backward compatibility of the C 
implementation with itself).

> > And that's a regression that broke existing programmatic usage of the
> > interface.
> > 
> > And that's a pretty rich claim to make considering that you did not
> > exactly rush to fix the decade-old regression brought by Lua CLI over
> > C RC...
> 
> Same, as I told you many times before, this is not a game of tallying
> blame or invoking past mistakes to justify current ones.

And the justification for having an ridiculous insecure TCP mode with broken 
(C) or no (Lua) support for event notifications is what exactly?

All it does it make it easy for people to shoot themselves in the feet not 
realizing the severity of the security issue, or simply not caring.

> > Most commands do not return an answer. That's just how the RC protocol
> > syntax has been "designed". For Unix, it's not much of a problem
> > because it's a perfectly reliable "transport", but for IP...
> > 
> > And while showing a prompt on TTY makes sense, but on a socket or a
> > pipe, that's a bug no matter of you slice it.
> 
> Are you looking at this from some request/response message frame point
> of view?

Your attitude of asking questions that are answered in the previous email just 
for the sake of arguing is really annoying.

Adding prompt over non-TTY breaks backward compatibility of C RC with itself, 
does not work with event notifications, and fails to follow the convention that 
every other command line interpreter does.

That's not one, but three independent reasons not to do it.

> That's not how TCP or sockets inherently work.

This has nothing to do with TCP or sockets semantics. Adding a prompt where 
they was none and where it is typically not expected breaks things.

> Nor is it how the CLI was designed,

Oh but it was. The VLC RC interface was designed without a prompt. Somebody 
just did not care about backward compatibility, and failed to account for 
notification, and added it in Lua. There never was a prompt in C AFAIK.

> most of its output is aimed and formatted for text display, not at being a
> response message frame. I'm not sure why you would try to look at it that
> way.

The RC interface was originally designed for Remote Control, especially socket 
mode. It was expressly meant to be used for other programs to control VLC.
 
> Anyway, TCP is reliable.

It's not a problem of TCP. It's a problem of the protocol over it. There's no 
way to know if the command was processed or not, and if it succeeded or not.

> Most commands return some status change or
> "returned 0 (no error)" message,

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.

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.

> on 3.0 at least: if that was removed on
> master then that's another problem that was created from nothing, so we
> can just undo it.

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.

> > I never promised to fix all the regressions. I said regressions should
> > be filed, and I would fix missing commands (and I think I did).
> > 
> > Complain to the note taker.
> 
> I did already have a word with him about it, he confirmed what's written
> in the notes.

That's not my problem.

> I hear your version; that doesn't change what was decided
> that regressions need to be fixed, not wontfix'd, nor solved by the
> removal of features.

Regressions were fixed, except for --cli-host which you just rejected, so 
that's on you.

I never agreed to reproduce bugs from Lua into the C implementation, 
especially not anything that breaks backward compatibility of C RC with 
itself.

> And you're avoiding once again to discuss my point about how cli.lua and
> telnet are still there outside the C CLI and not actually dropped.
> 
> > The TCP mode is a security vulnerability that was only left because of
> > laziness and (lack of Unix sockets on) Windows.
> > 
> > I guess on Lua it was also added as a poor excuse of a substitute for
> > the Unix mode, but that's not a consideration for C.
> 
> Interface features open attack vectors. That's not a real argument, the
> real arguments are the intent and trade-off. And on the contrary, I'm
> guessing more probably that lua got TCP but not Unix socket support
> because TCP is seen as the main feature and Unix sockets a secondary,

Lua got TCP because Lua needed TCP anyhow, whereas Unix would have required a 
whole new set of Lua wrappers. Really, that was the main argument against the 
Lua interface, that it just adds an extra layer of boilerplate to work at for 
every feature to add.

Also the original author of the Lua RC interface is not exactly remembered for 
caring about robustness and security in VLC, so that's hardly a surprise.

> optional one, contrary to the point of view you're putting forward that
> Unix sockets should be recommended and TCP deprecated.

That's a self-defeating argument, considering that TCP and Unix modes were 
added at the exact same time, with the earlier ostensibly a (crappy) fallback.

> > Yes indeed, TCP mode should be removed either way, and should have
> > never been added to the Lua variant. Unix and console modes are
> > actually secure for local control, and HTTP works better for remote
> > control.
> 
> Okay, now I agree that stated this way, this is a valid opinion. I still
> disagree.

And so you suggest fixing the security hole how exactly? Are do you suggest to 
keep it open?

> > This is 2020, not 1990. People do unattended rsync over SSH, not RCP
> > anymore.
> > 
> > How many megabauds do you need to remote control VLC, that this would
> > be measurable exactly?
> 
> I mean latency caused by session initiation, especially if the session
> isn't kept open. Cryptographic exchanges can be slow (by design), and
> so can protocol exchanges on high-latency links. Latency concerns,
> for example how long a media takes to start playing after sending the
> command, are a real performance concern for a media application.

That's complete technical nonsense right there. If latency is so high, then 
the 3-way handshake of TCP would be an issue too. And VLC would be barely 
controllable anyway.

You'd have to maintain the connection open. Thus it does not matter if you use 
SSH or TLS or whatever, or just insecure plain text, because you will want to 
avoid the handshakes as much as possible.

-- 
レミ・デニ-クールモン
http://www.remlab.net/