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

[Alexandre Janniaux]

Note that I don't care about supporting telnet protocol and its
user management, control command and what else that I don't even
know with this patch. That's not what it does. Telnet is
exhibiting the issue and like Romain my main wonders are why we
should care about parsing \r\n or \r characters at all,
especially since it will likely break logs and rc output in
scenario that were functionnal before.

I also don't understand the position around telnet, its previous
use case but that's probably something we should discuss with a
smoother communication channel.

Regards,
--
Alexandre Janniaux



On Fri, Nov 06, 2020 at 01:20:23AM +0100, Pierre Ynard via vlc-devel wrote:
> > 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."
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel