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

[Rémi Denis-Courmont]

Le lauantaina 21. marraskuuta 2020, 12.43.34 EET Pierre Ynard via vlc-devel a 
écrit :
> > There are several issues with TCP mode:
> > - It can only handle one client at a time, and will ignore any new
> > 
> >   connection until the current one properly ends, making it as
> >   unreliable as it comes.
> > 
> > - Most commands are not acknowledged.
> > - It has no security whatsoever.
> > 
> > There is not much point trying to "fix" those issues, as it would
> > not provide backward compatibility, which was the only reason to keep
> > this.
> 
> This is problematic.
> 
> The lua CLI handled multiple TCP clients fine.

Except:
- It does not support TCP on Windows at all, which is a regression over C.
- It does not support Unix sockets, which is also a regression over C and a 
security vulnerability by forcing the use of insecure TCP.

> I'd like if you could please clarify how most commands are unacknowledged,
> because I'm seeing messages for them;

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

> but at least the lua CLI always returned a new "> " prompt as
> acknowledgement.

And that's a regression that broke existing programmatic usage of the 
interface. 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.

> So you broke this by removing the lua CLI, then you refused fixing
> broken features,

I can't fix broken features.

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

> and now you're using the fact that they're broken as rationale to remove
> them.

Of course.

> This process is problematic.

No. It's perfectly normal. You fix or replace what's broken, not what's working 
fine.

> I'm going to state again what was decided at the last technical meeting
> 
> about this:
> > Regressions will be fixed by Rémi (or other) if there are track
> > issues

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 disagree with this patchset. TCP mode is a good and practical feature,
> with valid and secure use cases, for example a custom streaming
> application involving controller and streaming components split
> across several application servers on a trusted server LAN.

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.

> > For remote control, the HTTP interface is much better. It is insecure,
> > but at least it handles multiple clients, acknowledges requests and
> > requires a password.
> 
> The exact same thing can be said about the lua CLI.

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.

> In fact the lua CLI is even better because contrary to the HTTP interface,
> it works without internet access,

That claim is completely wrong.

The HTTP controls work without internet access and you know that full well. 
They just require an IP network, exactly like TCP mode.

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.

> doesn't leak

What leaks? Where is bug report?

> or advertise the location of the VLC instance interface,

WTF is this about even?

> and doesn't open cross-site attack vectors.

Fair enough. It just opens a big obvious RCE isntead, which is way worse.

> > For reliability and security, a much better approach is to pass the
> > CLI commands over SSH (or similar) - which is what people actually do.
> 
> Do you have data to back up that assertion about what people do?

There is plenty of evidence out there that SSH (or stunnel, or whatever else) 
is more secure than raw TCP actually, yes.

> I can see how it sounds like a better approach with interactive sessions,
> but for non-interactive application interfacing, an SSH channel as
> dependency sounds very heavy,

This is 2020, not 1990. People do unattended rsync over SSH, not RCP anymore.

> and slow

How many megabauds do you need to remote control VLC, that this would be 
measurable exactly?

> especially if you don't keep
> it open, also for example can you forward a connection to VLC's Unix
> control socket over an SSH tunnel the way you can with a TCP socket?

Yes, as a matter of fact, you can forward Unix sockets over SSH.
That's how X11 forwarding has been working for decades.

-- 
雷米‧德尼-库尔蒙
http://www.remlab.net/