<html><head></head><body>Hi,<br><br>On output side, there is a problrm my that garbage CR are inserted. This will indeed corrupt logs, especially if multipexing the standard error and standard output together, so we should remove the CR on non-Windows platforms.<br><br><div class="gmail_quote">Le 6 novembre 2020 10:48:40 GMT+02:00, Alexandre Janniaux <ajanni@videolabs.io> a écrit :<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">Note that I don't care about supporting telnet protocol and its<br>user management, control command and what else that I don't even<br>know with this patch. That's not what it does. Telnet is<br>exhibiting the issue and like Romain my main wonders are why we<br>should care about parsing \r\n or \r characters at all,<br>especially since it will likely break logs and rc output in<br>scenario that were functionnal before.<br><br>I also don't understand the position around telnet, its previous<br>use case but that's probably something we should discuss with a<br>smoother communication channel.<br><br>Regards,<br>--<br>Alexandre Janniaux<br><br><br><br>On Fri, Nov 06, 2020 at 01:20:23AM +0100, Pierre Ynard via vlc-devel wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">This looks plain wrong. CR is not a special character, or specifically<br>a line ending in a Unix CLI (main use of RC interface) or in<br>netcat-type tools (secondary use with in Unix or TCP socket modes).<br></blockquote> What if you pipe commands from a file saved with CRLFs?<br><br> Also, if I see correctly, the CLI outputs CRLFs (both C and lua). So umm<br> wouldn't it be rather strange if it didn't accept them in the input?<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">RC/CLI is *not* implementing the Telnet protocol. telnet is not for<br>raw I/O. There's netcat et al for that.<br>The point is that you cannot use a Telnet client. VLC RC sends and<br>receives raw UTF-8; that is simply not compatible with Telnet in<br>either direction.<br>I'm not sure about the Telnet protocol specifically, but VLC RC and<br>VLC Telnet interfaces are different modules.<br></blockquote> What do you mean with that about different modules? Telnet is a<br> transport whose main use case is indeed to provide access to a remote<br> CLI. There hasn't been any separate "telnet interface" since it was<br> merged into the lua CLI.<br><br> Now if we consider your point about text encoding, as far as I can tell<br> there was never any consideration in the code about telnet being limited<br> to ASCII, so we could even argue that there has never been any VLC<br> interface actually implementing a telnet transport.<br><br> It makes no sense to segregate this concern as if telnet was something<br> else's problem, not RC's. And we decided to fix regressions in the<br> CLI such as missing transports - not add regressions like CRLF going<br> unsupported. So logically, we should either port and fix telnet to<br> the C CLI, or consider that it's too broken and unwanted, and drop<br> it altogether from VLC - which would allow finally actually deleting<br> the redundant lua CLI. However, considering that the current telnet<br> interface is fine for lua but no good for the C CLI is a no go.<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">And Telnet clients don't support Unix sockets, which are the<br>recommended access mean - for pretty damn obvious security reasons.<br></blockquote> Recommended by which authority, and in what way? I'm not aware of<br> anywhere stating that, and I'm not sure users are getting that message<br> either. If some given transports are recommended or discouraged, maybe<br> it could at least be stated in the their settings' help text.<br><br> But let's talk about that. Unix sockets indeed allow easily setting<br> up some access control. But TCP sockets also allow setting up access<br> control with iptables or firewall rules. As for telnet, the prominent<br> difference in whatever telnet interface VLC offers is that it takes a<br> password. A simple password without channel encryption is considered<br> secure enough for the web interface, and unlike it telnet isn't<br> even open to cross-site attacks. Moreover, unlike the socket's file<br> permissions or TCP firewalling, telnet doesn't require external set<br> up or tools. So you could say it's actually the better choice on that<br> front!<br><br> So what do we do with our offer of CLI transports?<br><br> --<br> Pierre Ynard<br> "Une âme dans un corps, c'est comme un dessin sur une feuille de papier."<hr> vlc-devel mailing list<br> To unsubscribe or modify your subscription options:<br> <a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a><br></blockquote><hr>vlc-devel mailing list<br>To unsubscribe or modify your subscription options:<br><a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a></pre></blockquote></div><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.</body></html>