[vlc-devel] [PATCH] cli: fix line trimming with socket cli

[Pierre Ynard]

> This looks plain wrong. CR is not a special character, or specifically
> a line ending in a Unix CLI (main use of RC interface) or in
> netcat-type tools (secondary use with in Unix or TCP socket modes).

What if you pipe commands from a file saved with CRLFs?

Also, if I see correctly, the CLI outputs CRLFs (both C and lua). So umm
wouldn't it be rather strange if it didn't accept them in the input?

> RC/CLI is *not* implementing the Telnet protocol. telnet is not for
> raw I/O. There's netcat et al for that.

> The point is that you cannot use a Telnet client. VLC RC sends and
> receives raw UTF-8; that is simply not compatible with Telnet in
> either direction.

> I'm not sure about the Telnet protocol specifically, but VLC RC and
> VLC Telnet interfaces are different modules.

What do you mean with that about different modules? Telnet is a
transport whose main use case is indeed to provide access to a remote
CLI. There hasn't been any separate "telnet interface" since it was
merged into the lua CLI.

Now if we consider your point about text encoding, as far as I can tell
there was never any consideration in the code about telnet being limited
to ASCII, so we could even argue that there has never been any VLC
interface actually implementing a telnet transport.

It makes no sense to segregate this concern as if telnet was something
else's problem, not RC's. And we decided to fix regressions in the
CLI such as missing transports - not add regressions like CRLF going
unsupported. So logically, we should either port and fix telnet to
the C CLI, or consider that it's too broken and unwanted, and drop
it altogether from VLC - which would allow finally actually deleting
the redundant lua CLI. However, considering that the current telnet
interface is fine for lua but no good for the C CLI is a no go.

> And Telnet clients don't support Unix sockets, which are the
> recommended access mean - for pretty damn obvious security reasons.

Recommended by which authority, and in what way? I'm not aware of
anywhere stating that, and I'm not sure users are getting that message
either. If some given transports are recommended or discouraged, maybe
it could at least be stated in the their settings' help text.

But let's talk about that. Unix sockets indeed allow easily setting
up some access control. But TCP sockets also allow setting up access
control with iptables or firewall rules. As for telnet, the prominent
difference in whatever telnet interface VLC offers is that it takes a
password. A simple password without channel encryption is considered
secure enough for the web interface, and unlike it telnet isn't
even open to cross-site attacks. Moreover, unlike the socket's file
permissions or TCP firewalling, telnet doesn't require external set
up or tools. So you could say it's actually the better choice on that
front!

So what do we do with our offer of CLI transports?

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