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

[Pierre Ynard]

> Except:
> - It does not support TCP on Windows at all, which is a regression
> over C.

How does it not support TCP on Windows at all? I just tried, and it
works fine for me. And it was quite the bother for me to go test that,
apparently for nothing.

> - It does not support Unix sockets, which is also a regression over C
> and a security vulnerability by forcing the use of insecure TCP.

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.

First, with two maintained CLIs so far, people who wanted to use a Unix
socket could simply do so with the C CLI. Yes, adding support to lua
would have been better, and yes, even necessary if we had decided to
keep only the lua CLI. But that's not the bridge we chose to cross so
this is moot.

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. It's still just your
opinion, and I pointed that out and rebutted it when we last talked
about it two weeks ago, but you declined to follow it up with me. If we
do decide to deprecate TCP and recommend Unix sockets, then yes it does
make the lack of lua support a more pressing issue - except that the lua
CLI was removed so it's again moot.

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, and I gave valid use cases for it: it should be kept
working, not removed. On Windows, I think the lua CLI was never the
default, so granted, concurrent TCP clients never worked there, but
there are no Unix sockets so TCP is all the more valuable to keep
and whether the implementation supports Unix sockets is all the more
irrelevant.

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.

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

> 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? That's not how TCP or sockets inherently work. Nor is it how
the CLI was designed, 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.

Anyway, TCP is reliable. Most commands return some status change or
"returned 0 (no error)" message, 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.

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

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,
optional one, contrary to the point of view you're putting forward that
Unix sockets should be recommended and TCP deprecated.

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

> Maybe some parts of the HTTP web interface require Internet (and that
> would be a bug IMO), but that's completely irrelevant to the HTTP
> remote controls.
> What leaks? Where is bug report?
> WTF is this about even?

Yes, in the web front end, we understand each other here.

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

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