Most active commenters

    ←back to thread

    Multiple security issues in GNU Screen

    (www.openwall.com)
    414 points st_goliath | 12 comments | 13 May 25 11:28 UTC | HN request time: 0.6s | source | bottom
    Show context
    mmsc ◴[13 May 25 12:05 UTC] No.43971967[source]▶
    It's surprising that upstream was involved in this. Around 5 years ago, I came to the (sad) conclusion that GNU screen development had completely halted. Is that still not the case?

    Does screen have the functionality to add a new window to an existing screen without attaching to the screen yet?

    replies(5): >>43972042 #>>43972071 #>>43972387 #>>43972604 #>>43972925 #
    immibis ◴[13 May 25 13:16 UTC] No.43972604[source]▶
    Open source does have a problem with inertia whenever one piece of software ends and another piece is created to replace it, but there's no immediate incentive to switch, because it is a switch, not an update.

    Though conversely, when someone buys the trademark for an existing piece of software, and replaces it with something entirely different, like what happened with Audacity, that's also bad. So there's no good solution.

    replies(3): >>43972716 #>>43973459 #>>43974235 #
    Wowfunhappy ◴[13 May 25 13:27 UTC] No.43972716[source]▶
    Isn't this what distros are for? So e.g. Debian could decide to replace screen with tmux, possibly with some sort of compatibility package that takes all the same command line arguments as screen but uses tmux under the hood. (I've used screen very little and have never used tmux so I'm not sure if that would make sense in this context).
    replies(4): >>43972924 #>>43973023 #>>43974844 #>>43975292 #
    1. kevin_thibedeau ◴[13 May 25 13:44 UTC] No.43972924[source]▶
    Tmux doesn't support serial ports.
    replies(4): >>43973045 #>>43973196 #>>43974241 #>>43982081 #
    2. PhilipRoman ◴[13 May 25 13:56 UTC] No.43973045[source]▶
    I'm not sure what made "screen" integrate the two separate pieces of functionality - you can use something minimal like "tio" for serial port access and it's much more elegant.
    replies(2): >>43973413 #>>43973708 #
    3. nottorp ◴[13 May 25 14:11 UTC] No.43973196[source]▶
    I'm sure a rewrite of screen in Rust will be 105% secure. And won't support serial ports either.
    4. kevin_thibedeau ◴[13 May 25 14:31 UTC] No.43973413[source]▶
    It isn't separate functionality. Terminals connected via serial port is a valid use case for a terminal multiplexor.
    replies(1): >>43973724 #
    5. JdeBP ◴[13 May 25 15:00 UTC] No.43973708[source]▶
    It's not separate functionality. The back end (so-called "master" side) of a pseudo-terminal is almost (bar initialization of line speed, hardware flow control, and framing settings) indistinguishable from a "null-modem" call-out serial port or parallel port terminal device. Write a software terminal emulation program for the former, which of course is what screen has, and you already have one for the latter.
    6. PhilipRoman ◴[13 May 25 15:01 UTC] No.43973724{3}[source]▶
    In theory you're correct, but by that logic you'd also have to add ssh (probably by far the most common way of connecting to a remote terminal today). I guess you'd end up with something like mobaXTerm which is a valid approach for sure, but doesn't compose as well.

    Personally I live by the maxim "if it can be separated without significant drawbacks, then it should be separate" but GNU tends to see it differently.

    replies(1): >>43989062 #
    7. im3w1l ◴[13 May 25 15:47 UTC] No.43974241[source]▶
    What is a serial port and what do you use it for?
    replies(3): >>43974541 #>>43976309 #>>43980115 #
    8. genewitch ◴[13 May 25 16:15 UTC] No.43974541[source]▶
    It is a port that has two data lines, RX and TX, and data is sent in a serial fashion across those data lines. It is used today for embedded systems, routers and switches et al, and getting a console on any machine that doesn't have a gpu with a monitor attached.

    USB is a serial BUS, which allows multiple devices; serial ports are single device (if my memory serves).

    9. spauldo ◴[13 May 25 18:51 UTC] No.43976309[source]▶
    When most people use the term "serial port" they're referring to a DB-25 or DE-9 port you find on older computers or USB dongles. It's also seen in 8P8C (aka "RJ45") form sometimes, especially in industrial equipment. It can send and receive "characters" (anywhere from 5-8 bits each) one at a time at a fixed rate, either half duplex or full duplex. They usually implement one or more of the RS232, RS422, or RS485 standards.

    Originally, you communicated with the computer using a teletype or video terminal connected to a serial port. Whatever you typed went to the computer, and whatever the computer sent back was printed on your terminal screen (or paper in the case of a teletype).

    The UNIX (and thus, Linux) command line environment still works this way, except the serial line is virtual.

    10. cozzyd ◴[14 May 25 02:31 UTC] No.43980115[source]▶
    console=ttyS0,115200
    11. immibis ◴[14 May 25 08:01 UTC] No.43982081[source]▶
    Just use minicom
    12. throwaway173738 ◴[14 May 25 20:49 UTC] No.43989062{4}[source]▶
    I dont think you understand what a terminal is. What you’re talking about is a shell running in a console. What we’re talking about is the terminal to connect to the console serial port running the shell.

    EG https://en.m.wikipedia.org/wiki/VT220