←back to thread

Multiple security issues in GNU Screen

(www.openwall.com)
414 points st_goliath | 1 comments | 13 May 25 11:28 UTC | HN request time: 0s | source
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 #
3036e4 ◴[13 May 25 14:36 UTC] No.43973459[source]▶
The good solution is rock-solid, backwards compatible APIs on all levels. That way the work to maintain software would be much lower, making it possible to focus on doing some rare bug-fixing only. In open source in particular this should be a no-brainier, instead of all projects ruining things for each other by ignoring backwards compatibility.
replies(1): >>43974061 #
immibis ◴[13 May 25 15:32 UTC] No.43974061[source]▶
The rock-solid backwards-compatible API would include, for example, being invoked with the command "screen -x", and being installed with "apt install screen" - at which point it's the same screen project under different management, not a new project.
replies(1): >>43974356 #
1. 3036e4 ◴[13 May 25 15:59 UTC] No.43974356[source]▶
I was referring to the APIs required by screen itself to run. If screen is anything like any software I know anything about a fair amount of limited developer time has to be wasted on keeping up with random third-party stuff changing/breaking. Even if that is not the case, if we get more stable software in general that would mean maintainers of free software could take on more projects each, meaning there would be a higher probability that someone could be around to fix bugs in screen.