> Screen offers a multi-user mode which allows to attach to Screen
sessions owned by other users in the system (given the proper
credentials). These multi-user features are only available when Screen
is installed with the setuid-root bit set. This configuration of Screen
results in highly increased attack surface, because of the complex
Screen code that runs with root privileges in this case
I wasn't aware of such a feature but I guess it's what makes stuff like tmate possible. Speaking of which, I wonder if tmux is affected by the same kind of vulnerability.
dooglius · 4h ago
No, tmux uses unix domain sockets. I have no idea why screen chose to take the setuid approach instead here; it seems totally unnecessary to have root privileges.
EDIT: Further down, TFA gives a plausible explanation: the current screen devs are not fully familiar with the code base. If so, the setuid-root approach was probably the easiest way to make the feature work in lieu of such familiarity.
JdeBP · 4h ago
screen has a lot of architectural baggage that can be traced back to its initial 1987 comp.sources.unix/mod.sources versions in some cases. Being set-UID to the superuser is one of them. See the doco for screen as it was posted in volume 10:
Kind of nuts that a tool that hasn't fixed nearly 40-year old practices is in common usage among developers. Never tell me engineers are rational people.
JdeBP · 2h ago
It's a combination of factors:
* The original author of the project has not been involved in it since 1990. The people who took it over and made it a GNU project then largely stopped working on it in 2004. The people who are now working on it are something like its 3rd or 4th wave of developers.
* Learning the internals of screen now from scratch is a lot harder than when I did it in 1987. There's an awful lot more operating system historical and portability factors, now. In 1987, it was works-on-4.3BSD-might-not-on-your-Unix.
* If you deal with pseudo-terminals cross-platform, there are still huge variations on how pseudo-terminals work and how the long-standing security issues of pseudo-terminals, identified in the 1990s, have been addressed in operating systems.
* screen is encumbered by a lot of 1980s Think. It still today diligently manages, and puts quite a lot of effort into constructing, a generated-on-the-fly TERMCAP environment variable, for example.
* Attitudes to security have changed. At least one security hole in the headlined report was actually a neat-o feature of terminals in Unix in the 1970s and 1980s.
No comments yet
entropie · 3h ago
For me it felt (!) like screen is pretty much obsolute since 10+ years. When tmux came I switched and never looked back and I know a few that handled it the same.
dbdoskey · 1h ago
A similar process is happening with zellij and tmux. Since I switched over I feel that tmux is obsolete.
fullstop · 51m ago
I hadn't used Zellij before, but I tried it out. Visually it works better than tmux and it shares enough key bindings with tmux to make it a pretty seamless transition.
With that being said, the binary is huge. I get that zellij is statically linked, but tmux is about 900KiB and has minimal dependencies. I'm flabbergasted that a terminal multiplexer, stripped, is 38MiB.
lxgr · 1h ago
What does it do better than tmux?
Or is it more of a fish vs. zsh type of situation, where neither is obsolete, but the target audience is just very different?
eblume · 1h ago
Definitely more of a fish vs zsh situation, in my opinion.
tmux, to me, feels like "modern screen". It has some cool features, but at the end of the day, it just wants to be a terminal multiplexer. Great!
Zellij on the other hand seems to offer terminal multiplexing as an obvious first-class use case but "not the whole point". At the surface, Zellij is an opinionated terminal multiplexer that uses a nice TUI to give discoverability which you can turn off when you're ready to gain screen real estate. It's easy to make Zellij behave exactly like tmux/screen, and it's easy to configure via a single config file.
Where Zellij takes a turn in to a different direction, however, is that the workspaces you can configure with it can do all sorts of interesting things. For instance I once built[0] a python cli app which had a command that would launch a zellij workspace with various tabs plugged in to other entrypoints of that same python cli, basically allowing me to develop a multi-pane TUI as a single python Typer app. In one pane I had the main ui, and then in another stacked pane I had some diagnostic info as well as a chat session with an llm that can do tool-calling back out to the python cli again to update the session's state.
I think wrapping up a project's dev environment as a combination of mise (mise.jdx.dev) and zellij or nix+zellij to quickly onboard devs to, say, a containerized development environment, seems like a really neat idea.
A quick example is that mouse scrolling works by default. I see it more like ripgrep vs grep. Either can do almost anything the other can, but one has much more modern, ergonomic defaults.
Thankfully you can configure it. I had the same initial difficulty.
noosphr · 2h ago
Screens main use case is to open an emacs session remotely.
Tmux's main use case is to be glue for a unix IDE.
The two use cases are rather different and the tools are very specialized for them.
jstanley · 1h ago
Nah, screen's main use case is as an ad-hoc method to daemonise random scripts.
fnordpiglet · 18m ago
Yeah this is 100% of when I reach for screen. “I’m not willing/ready to make this a service, screen detach here I come”
skydhash · 2h ago
I switched to dtach for the first case.
kps · 2h ago
dtach for session persistence. “Do one thing well.”
penguin_booze · 2h ago
> Screens main use case is to open an emacs session remotely.
Not an emacs user, but for this, what does screen do that tmux can't?
kstrauser · 1h ago
Nothing at all. I’ve used emacs over tmux (and now zellij) for many years. Emacsserver can replace both of them, but that’s a different story.
johnmaguire · 1h ago
I'm confused by this statement. Are you claiming this is the projects' stated goal? Their primary use in the wild?
anthk · 2h ago
Emacs can work as a daemon.
noosphr · 2h ago
It also has tramp mode which means you can use all your local packages remotely.
taeric · 1h ago
When I realized how powerful TRAMP was, I don't think I ever used screen/tmux again. I'm sure there are uses, mind. Just TRAMP fully hit all of my needs.
kstrauser · 1h ago
It really is magical, isn’t it? And although I rarely need to use it, I love the multihop setups where you can ssh to this system, then ssh again to this other, then mount an SMB filesystem using these credentials, and start editing.
UI_at_80x24 · 38m ago
We usually wait for a version written in Rust for this kind of cruft removal.
nine_k · 23m ago
The problems here are more about the architecture. You can write 100% memory-safe but completely insecure code in Rust, Java. Haskell, Erlang, Smalltalk, bash, you name it. For instance, running a setuid binary may add problems to code written in any language.
90s_dev · 3h ago
Nostalgia and novelty are powerful narcotics.
guappa · 2h ago
On my sistems screen doesn't have setuid.
rixed · 1h ago
Same here (speaking more specifically about debian)
1vuio0pswjnm7 · 36m ago
Engineers are rational people. Software developers calling themselves "engineers" are not.
chasil · 2h ago
In the EPEL versions of screen, I am seeing the setgid bit set only. I am guessing that later versions setuid to root?
CVE-2025-46802 can impact earlier releases, but all the other vulnerabilities are for the latest.
fzzzy · 3h ago
screen has used setuid root for multiuser for at least 20 years. Used to use it in multiuser for remote pair programming.
fullstop · 3h ago
I guess I'm glad that I switched to tmux ages ago.
thanatos519 · 1h ago
It's a great feature! I have used it in training sessions by giving each student their own login on my laptop, with the ssh shell restricted to 'screen -x <specific user's window>' - the only window that user could use based on screen's ACLs. Then during exercises I (as the owner of the screen) could switch to each student's screen on the projector so the class could see what they had done.
Not surprised to hear it's full of security holes. :)
trollied · 4h ago
Yup, screen -x
qwertox · 4h ago
The problem isn't with the use of `screen -x ...` itself, but rather if `ls -l "$(which screen)"` returns something like `-rwsr-xr-x 1 root root ... /usr/bin/screen`, where the `s` in the fourth position indicates the setuid bit is set.
That means the screen binary runs with root privileges.
trollied · 3h ago
I am well aware of setuid. I was informing the parent comment of which arg to use for the actual functionality.
johnmaguire · 1h ago
I was surprised to hear OP wasn't aware of it as it was the first reason I ever had to use screen (shared remote debugging session.)
teddyh · 4h ago
Note: In Debian, GNU screen is not installed with setuid-root privileges.
perlgeek · 3h ago
And the package in Debian Stable (aka bookworm) is too old to be affected by the vulnerabilities in 5.0.0.
I used to hate that Debian always was behind on software versions, but now I use different package sources for the few applications where I really don't want to rely on old software (like browsers), and otherwise doing great with the old stuff :-)
If you're running Firefox on Debian please make sure you manually update it since the package repo's been down for a while. I filed a 'support' ticket first ( https://support.mozilla.org/en-US/questions/1510388 ) since it seemed to be the proper place, but no one seems to look at those.
sillystuff · 17m ago
The repo appears to be working for installing/updating packages. Mozilla should allow file listing which should fix the 404s, and make this repo behave as expected when manually browsed (Apparently hosted on a Google webserver; maybe Google forbids this?).
apt-get changelog firefox
Get:1 store: firefox 138.0.3~build1 Changelog
Fetched 129 B in 0s (0 B/s)
firefox (138.0.3~build1) UNRELEASED; urgency=medium
* N/A
-- Mozilla <release@mozilla.com> Mon, 12 May 2025 12:40:33 -0000
date
Tue May 13 08:56:09 AM PDT 2025
Or, to really prove it to yourself, you can re-download the package:
Likewise in Gentoo. But in Gentoo it has SETGID for utmp group. Though I'm not sure what the implications are.
JdeBP · 3h ago
If one is in group utmp, one can mess with the login accounting database: the table of currently active logins, the log of log-ons/log-offs, and the table of per-user last logins.
The login accounting system that Linux-based operating systems have inherited from Unix really has never reconciled its initial real-terminal-login-only superuser-managed design with the fact that non-superuser programs that allocate pseudo-terminals (e.g. any local terminal emulator, NeoVIM, tmux, screen) want to (over)write entries for those pseudo-terminals in the login accounting database to make the output of the "who" command (and its ilk) more complete.
The best approach I've seen was to re-think the idea; have the pseudo-terminal-using programs run entirely unprivileged and use a client-server model where only the server actually has access to the database files.
Laurent Bercot did this. It fixes many holes, including that the log of log-ons/log-offs is made truly append-only (modulo superuser access to the underlying files). But it has the same architectural problem that any client in the group can overwrite any currently active login record if it knows the record ID, which by design (and the Single Unix Specification) there's an API for enumerating.
Tmux has been in OBSD base side several releases and documented since the first one.
CelestialMystic · 2h ago
I know. I suggest you read the Q&A I posted.
nmz · 14m ago
If you're worried about security, A less than 10k lines of SOC is your aim. mtm, abduco, dvtm achieve this. screen? Impossible for it to ever be secure. You'll be playing an endless game of whack-a-mole.
lionkor · 2m ago
lines of code is a measure of complexity in your argument; its better to call it that. Increased complexity, depending on the language, isn't necessarily lines of code, but can have the same effect
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?
jzb · 3h ago
Upstream requested that the SUSE team take a look at it. It seems that development is understaffed and the upstream may not have the expertise to maintain it properly. Which, if true, is sad -- I know that tmux and others exist, but a lot of people have used Screen for many many years. It sucks when a tool bitrots.
marcosdumay · 2h ago
Looks like a tech-debt ridden large piece of software that new developers just can't understand.
If that's the case, it's not really about it being "understaffed". Instead, it's doomed to rot until it's replaced of rewritten. There's no scenario where more maintainers will help, except for marginally delaying it.
The good news is that there are almost perfect replacements out there, and most of them are leaner.
Involved only insofar as shipping it as setuid-root counts. Distros that configure it like this are vulnerable, others aren't. Very thin involvement I'd say. Distros patch if upstream is too slow.
mmsc · 4h ago
TFA says upstream asked for the review.
croemer · 2h ago
Right, I got the direction wrong.
criddell · 2h ago
It’s not necessarily sad for GNU tool development to stop (other than bug fixes, of course). I would take that as a sign that they are basically complete.
kstrauser · 1h ago
Not quite in this case. Tmux was started by someone who wanted to update screen with new features but wasn’t able to bend the code that far. I say this not out of spite or meanness, as I used screen for many happy years, but I’d say it’s less complete and more abandoned. It still has maintainers but it seems to me that they’re more “keep the lights on” than actively developing it.
lxgr · 1h ago
Whether constant development is necessary or not largely depends on the surface area of your tool, both in terms of formal APIs it uses and external data formats and services.
Trasmatta · 4h ago
> Due to difficulties in the
communication with upstream we do not currently have detailed
information about bugfixes and releases published on their end.
It sounds like they requested the security review, but have been difficult to keep in touch with? I'm not sure what the whole story is there.
mmsc · 3h ago
Seems like a prime target for Jia Tan.
tecleandor · 4h ago
Yep, from the timeline it looks like lack of communication (and maybe also capabilities/resources/time/will, not sure) [0]
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.
unixplumber · 43m ago
> 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.
I've followed the Audacity situation over the last few years. Before the Muse Group bought the rights to the trademarks and took over development, Audacity development had pretty much stagnated.
The new developers did not replace it with something entirely different. What they did was fix longstanding bugs and add new features/enhancements (and changing the way some things work, for better or worse). Sure, they introduced new bugs here and there with the new features/enhancements, but last I checked they fixed those. And yes, they could have done a better job at marking new versions as "beta" rather than pushing them out as stable releases (old hands know to avoid a new version until a couple minor versions later). That's really my biggest gripe with their development/release process.
3036e4 · 1h ago
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.
immibis · 58m ago
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.
3036e4 · 31m ago
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.
Wowfunhappy · 3h ago
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).
marcosdumay · 2h ago
You can reconfigure the key-bindings, that I guess would be the largest annoyance for a new user. But there are many fundamental differences between them that you just can't hide.
kevin_thibedeau · 2h ago
Tmux doesn't support serial ports.
PhilipRoman · 2h ago
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.
JdeBP · 1h ago
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.
kevin_thibedeau · 1h ago
It isn't separate functionality. Terminals connected via serial port is a valid use case for a terminal multiplexor.
PhilipRoman · 1h ago
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.
nottorp · 2h ago
I'm sure a rewrite of screen in Rust will be 105% secure. And won't support serial ports either.
im3w1l · 42m ago
What is a serial port and what do you use it for?
genewitch · 15m ago
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).
tmux is in OpenBSD base since 4.6 IIRC and is/has been audited. It's a good alternative for those who want something a bit more secure.
j45 · 1h ago
Seeing screen popup reminded me of that one time I switched to tmux and forgot to use screen.
sundarurfriend · 57m ago
Zellij is a really nice, modern alternative to screen and tmux, and they've done a great job at having good defaults as well as making the UI easily discoverable. I'd highly recommend it to anyone else who felt dubious about the benefit-to-effort ratio of terminal multiplexers.
I gave it a shot a couple years ago -- pretty slick. But the latency was noticeable compared to tmux, which I remain using today. I admit that I'm kind of sensitive to it, as at the time I was already on a latent connection.
Scene_Cast2 · 2h ago
I use byobu (for the keybinds) on top of tmux. But Zellij (modern Rust-based alternative to tmux) has been looking quite interesting for a while.
lemonwaterlime · 54m ago
1. How many developers run all the most popular open source tools?
2. How much money is in the industries that use those tools?
warpeggio · 4h ago
So ... my tmux lifestyle is objectively superior in this one respect. Excellent.
exploderate · 3h ago
Yes, that's why all the cool kids switched to tmux 17 years ago. The only argument the screen camp had was "no serial port support in tmux". To which we answered something about a smaller more modern code base...
remram · 51m ago
I switched to tmux and I switched back due to the weird server/session/window/pane model that makes no sense and prevents me from showing different windows or layouts on different clients. 4 levels of objects is ridiculous and when you end up with less capabilities than screen, what are we doing?
I would love to switch to a modern, maintained terminal multiplexer, but it would need to, well, be good at multiplexing.
kstrauser · 1h ago
I haven’t done serial port stuff in many years, so I ask this in ignorance and I give you permission to laugh at my naïveté. Can’t you just run tip or something in a tmux or zellij window and have basically the same thing?
pengaru · 56m ago
> The only argument the screen camp had was "no serial port support in tmux".
No, the screen camp has the valid argument that licenses matter and tmux is not GPL software.
lowbloodsugar · 35m ago
In 1990 we got told to stop using screen because other people could get into your sessions. Never used it again after that.
mistrial9 · 3h ago
so it appears that packaged Debian `screen` is not installed with root execution, therefore this entire situation is not a problem on Debian?
anthk · 2h ago
Then:
Unix: Small, light, mediocre OS for underpowered microcomputers. Either crash silently, or cut down the bloat.
MIT/GNU: Correct systems first. Plenty or resources. Lisp. Detect the errors, fix and step over them, continue the process.
Now:
GNU=Ugly bloated umUnix like, mega light Elisp editor but s l o w and prone to lock. Good FS' on Linux.
FDo it's mainly Red Hat bloatware.
Screen does too much.
OpenBSD=Correctness, ISC licensed mainly. Unix bound, small tools, but so-so FFSv2. Sndio works. Audio, video and so on perms work, no DBUS needed. CWM it's really fast and much easier than I3.
Dumb config, fvwm looks like rocket science.
Tmux, no screen(1) except for ports. Snappy, easy to config and script. Use damn cu(1) for serial, thanks.
Trasmatta · 4h ago
Only tangentially related, but I'm always fascinated that mailing lists are still a thing in 2025.
teddyh · 4h ago
Please, inform us of an alternative which is:
• Non-proprietary
• Federated
• Archivable
• Accessible
• Not dependent on a specific company
zoobab · 3h ago
GIT promised to be "Non-proprietary, Decentralized" but still does not have a built-in issue tracker :-)
HappMacDonald · 3h ago
GIT is non-proprietary and decentralized so it keeps that promise.
And having a built-in issue tracker
1. isn't related to those properties, and
2. isn't truly within the scope of a source code version control management solution.
That's the domain of project management.
graemep · 2h ago
Fossil has one. If its something you want use Fossil - which I think is a great alternative for small teams, on the other hand, this is probably not something large teams (which are a high priority for git) want.
somat · 3h ago
Shouldn't the git native issue tracker be as simple as adding file pr/the_problem_i_am_having
badmintonbaseba · 2h ago
Issues shouldn't really live in the same source tree, IMO. But AFAIK there are forges that keep the issues in the same repository, just not in the same tree of commits that the source tree has, git notes style.
rixed · 1h ago
Any user without commit permission should be able to create tickets and comment on them.
What's wrong with debbugs? :)
delfinom · 3h ago
For large projects like the Linux kernel as an example out of many, I would assume the built-in issue tracker would end up 100x the size of the code base in storage space. lol
Trasmatta · 4h ago
I wasn't criticizing the use of them, I just find it fascinating that we still use them. They'll probably still be around in some form in another 3 decades.
walterbell · 4h ago
Email is a root-of-trust for authentication in most non-email systems.
KolmogorovComp · 4h ago
My qualm against them is rather different. Why, after so much time, are they still so user-hostile, both in their web appearance and more generally usage?
It's rhetorical of course, it's because their users are completely blind to their pitfalls after decades of use, and it seems that generation-renewal is not a priority.
Discord servers and other contemporary solutions are much worse on the long run, but it does not matter. Software is like startups, long term is not a goal when you are not sure to survive (or in that case, being used and having contributors) next week.
skydhash · 3h ago
I don’t think GitHub adds that much over using and contributing to software. I generally prefer when the project have its own website and a proper about and documentation section.
As far as contributing go, coding a bug fix or a new features takes way longer than figuring how sending patch over mail works (for the extreme case) and you only need to do it once.
And opensource is not a popularity contest.
jzb · 3h ago
"Discord servers and other contemporary solutions are much worse on the long run, but it does not matter. Software is like startups, long term is not a goal when you are not sure to survive (or in that case, being used and having contributors) next week."
I don't think I've read anything that I disagree with so strongly in a while. "Software is like startups" is about as user and contributor-hostile a concept as they come.
The long term absolutely matters and projects choosing convenience today over long-term thinking are screwing over their future. It's damn near impossible to find information about these projects outside the proprietary silos they've dug themselves into and they will regret the choice one of these days when Discord or whatever proprietary service starts tightening the screws to make money.
I'm not sure what you find hostile about their web appearance. It's a light, clean page with text that doesn't throw tons of JS at you, pop-ups, or a cookie accept/reject/ponder bullshit dialog. It could use a bit of a copy edit / redo and a screenshot (I always complain when a project doesn't have screenshots...), but I don't find it hostile in the least.
mistrial9 · 3h ago
> The long term absolutely matters and projects choosing convenience today
I would be happy to engage on that thought, but here on this thread there is a lynchmob gathering to declare an emergency to remove all GPL-connected code everywhere, again.. because `screen`
immibis · 3h ago
A mailing list is just a kind of public group chat. You're probably in many public group chats, including this one right now. Mailing lists, IRC, traditional web forums, Discord, WhatsApp are all implementations of the same basic concept.
Like any implementation, it comes with certain affordances which differ from other implementations.
Messages feel "heavy" for several reasons: sending one involves a lot of clicks (or keypresses); if you send a very high number you may be banned from your email provider, and unable to communicate with anyone.
Messages often arrive instantly, but can be delayed up to hours or days, so conversation round-trips are kept to a minimum.
Messages are all the same - there are no "lite messages" such as emoji reactions - so any message must contain enough content to justify being a full-fledged message, or it won't be sent at all. (Sometimes an "emoji reaction" is felt to be enough content to justify a full-fledged message, which is sent.)
Being off the web increases the barrier to entry, reducing the eternal september effect (ironically, Usenet is one of the least eternal-september-ish of the public discussion boards currently in existence).
Overall, the feel of the system tends to somewhat discourage quantity and encourage per-message quality.
WesolyKubeczek · 32m ago
> Messages are all the same - there are no "lite messages" such as emoji reactions - so any message must contain enough content to justify being a full-fledged message, or it won't be sent at all. (Sometimes an "emoji reaction" is felt to be enough content to justify a full-fledged message, which is sent.)
Haven't you heard about the abomination which is Office365? They recently bolted emoji reactions onto email!
phyzix5761 · 2h ago
I brought up some security issues similar to these years ago to the Screen community and they laughed at me saying I was being paranoid. Nice to see they're finally doing something about it.
> Screen offers a multi-user mode which allows to attach to Screen sessions owned by other users in the system (given the proper credentials). These multi-user features are only available when Screen is installed with the setuid-root bit set. This configuration of Screen results in highly increased attack surface, because of the complex Screen code that runs with root privileges in this case
I wasn't aware of such a feature but I guess it's what makes stuff like tmate possible. Speaking of which, I wonder if tmux is affected by the same kind of vulnerability.
EDIT: Further down, TFA gives a plausible explanation: the current screen devs are not fully familiar with the code base. If so, the setuid-root approach was probably the easiest way to make the feature work in lieu of such familiarity.
https://sources.vsta.org/comp.sources.unix/volume10/screen/
* The original author of the project has not been involved in it since 1990. The people who took it over and made it a GNU project then largely stopped working on it in 2004. The people who are now working on it are something like its 3rd or 4th wave of developers.
* Learning the internals of screen now from scratch is a lot harder than when I did it in 1987. There's an awful lot more operating system historical and portability factors, now. In 1987, it was works-on-4.3BSD-might-not-on-your-Unix.
* If you deal with pseudo-terminals cross-platform, there are still huge variations on how pseudo-terminals work and how the long-standing security issues of pseudo-terminals, identified in the 1990s, have been addressed in operating systems.
* screen is encumbered by a lot of 1980s Think. It still today diligently manages, and puts quite a lot of effort into constructing, a generated-on-the-fly TERMCAP environment variable, for example.
* Attitudes to security have changed. At least one security hole in the headlined report was actually a neat-o feature of terminals in Unix in the 1970s and 1980s.
No comments yet
With that being said, the binary is huge. I get that zellij is statically linked, but tmux is about 900KiB and has minimal dependencies. I'm flabbergasted that a terminal multiplexer, stripped, is 38MiB.
Or is it more of a fish vs. zsh type of situation, where neither is obsolete, but the target audience is just very different?
tmux, to me, feels like "modern screen". It has some cool features, but at the end of the day, it just wants to be a terminal multiplexer. Great!
Zellij on the other hand seems to offer terminal multiplexing as an obvious first-class use case but "not the whole point". At the surface, Zellij is an opinionated terminal multiplexer that uses a nice TUI to give discoverability which you can turn off when you're ready to gain screen real estate. It's easy to make Zellij behave exactly like tmux/screen, and it's easy to configure via a single config file.
Where Zellij takes a turn in to a different direction, however, is that the workspaces you can configure with it can do all sorts of interesting things. For instance I once built[0] a python cli app which had a command that would launch a zellij workspace with various tabs plugged in to other entrypoints of that same python cli, basically allowing me to develop a multi-pane TUI as a single python Typer app. In one pane I had the main ui, and then in another stacked pane I had some diagnostic info as well as a chat session with an llm that can do tool-calling back out to the python cli again to update the session's state.
I think wrapping up a project's dev environment as a combination of mise (mise.jdx.dev) and zellij or nix+zellij to quickly onboard devs to, say, a containerized development environment, seems like a really neat idea.
0: https://github.com/eblume/mole/blob/main/src/mole/zonein.py -- but this is mostly derelict code now, I've moved on and don't use zellij much currently.
https://arcan-fe.com/2025/01/27/sunsetting-cursed-terminal-e...
Tmux's main use case is to be glue for a unix IDE.
The two use cases are rather different and the tools are very specialized for them.
Not an emacs user, but for this, what does screen do that tmux can't?
CVE-2025-46802 can impact earlier releases, but all the other vulnerabilities are for the latest.
Not surprised to hear it's full of security holes. :)
I used to hate that Debian always was behind on software versions, but now I use different package sources for the few applications where I really don't want to rely on old software (like browsers), and otherwise doing great with the old stuff :-)
If you're running Firefox on Debian please make sure you manually update it since the package repo's been down for a while. I filed a 'support' ticket first ( https://support.mozilla.org/en-US/questions/1510388 ) since it seemed to be the proper place, but no one seems to look at those.
https://jdebp.uk/FGA/unix-login-database.html
The login accounting system that Linux-based operating systems have inherited from Unix really has never reconciled its initial real-terminal-login-only superuser-managed design with the fact that non-superuser programs that allocate pseudo-terminals (e.g. any local terminal emulator, NeoVIM, tmux, screen) want to (over)write entries for those pseudo-terminals in the login accounting database to make the output of the "who" command (and its ilk) more complete.
The best approach I've seen was to re-think the idea; have the pseudo-terminal-using programs run entirely unprivileged and use a client-server model where only the server actually has access to the database files.
Laurent Bercot did this. It fixes many holes, including that the log of log-ons/log-offs is made truly append-only (modulo superuser access to the underlying files). But it has the same architectural problem that any client in the group can overwrite any currently active login record if it knows the record ID, which by design (and the Single Unix Specification) there's an API for enumerating.
* https://skarnet.org/software/utmps/
Both the BSDs and M. Bercot have improved the situation with pututxline(), but it's still not out of the woods yet.
lrwxrwxrwx 1 root root 12 Feb 11 2022 /usr/bin/screen -> screen-4.9.0
-rwxr-xr-x 1 root root 455016 Feb 1 2022 /usr/bin/screen-4.9.0
no suid
http://www.zoobab.com/screenrc
GNU need a better issue tracking system :-)
https://undeadly.org/cgi?action=article&sid=20090712190402
https://security.opensuse.org/2025/05/12/screen-security-iss...
Does screen have the functionality to add a new window to an existing screen without attaching to the screen yet?
If that's the case, it's not really about it being "understaffed". Instead, it's doomed to rot until it's replaced of rewritten. There's no scenario where more maintainers will help, except for marginally delaying it.
The good news is that there are almost perfect replacements out there, and most of them are leaner.
https://git.savannah.gnu.org/cgit/screen.git/tree/src
A few 2kLOC files and the rest is rather small.
It sounds like they requested the security review, but have been difficult to keep in touch with? I'm not sure what the whole story is there.
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.
I've followed the Audacity situation over the last few years. Before the Muse Group bought the rights to the trademarks and took over development, Audacity development had pretty much stagnated.
The new developers did not replace it with something entirely different. What they did was fix longstanding bugs and add new features/enhancements (and changing the way some things work, for better or worse). Sure, they introduced new bugs here and there with the new features/enhancements, but last I checked they fixed those. And yes, they could have done a better job at marking new versions as "beta" rather than pushing them out as stable releases (old hands know to avoid a new version until a couple minor versions later). That's really my biggest gripe with their development/release process.
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.
USB is a serial BUS, which allows multiple devices; serial ports are single device (if my memory serves).
https://zellij.dev https://github.com/zellij-org/zellij
2. How much money is in the industries that use those tools?
I would love to switch to a modern, maintained terminal multiplexer, but it would need to, well, be good at multiplexing.
No, the screen camp has the valid argument that licenses matter and tmux is not GPL software.
Unix: Small, light, mediocre OS for underpowered microcomputers. Either crash silently, or cut down the bloat.
MIT/GNU: Correct systems first. Plenty or resources. Lisp. Detect the errors, fix and step over them, continue the process.
Now:
GNU=Ugly bloated umUnix like, mega light Elisp editor but s l o w and prone to lock. Good FS' on Linux. FDo it's mainly Red Hat bloatware. Screen does too much.
OpenBSD=Correctness, ISC licensed mainly. Unix bound, small tools, but so-so FFSv2. Sndio works. Audio, video and so on perms work, no DBUS needed. CWM it's really fast and much easier than I3. Dumb config, fvwm looks like rocket science. Tmux, no screen(1) except for ports. Snappy, easy to config and script. Use damn cu(1) for serial, thanks.
• Non-proprietary
• Federated
• Archivable
• Accessible
• Not dependent on a specific company
And having a built-in issue tracker
1. isn't related to those properties, and
2. isn't truly within the scope of a source code version control management solution.
That's the domain of project management.
What's wrong with debbugs? :)
It's rhetorical of course, it's because their users are completely blind to their pitfalls after decades of use, and it seems that generation-renewal is not a priority.
Discord servers and other contemporary solutions are much worse on the long run, but it does not matter. Software is like startups, long term is not a goal when you are not sure to survive (or in that case, being used and having contributors) next week.
As far as contributing go, coding a bug fix or a new features takes way longer than figuring how sending patch over mail works (for the extreme case) and you only need to do it once.
And opensource is not a popularity contest.
I don't think I've read anything that I disagree with so strongly in a while. "Software is like startups" is about as user and contributor-hostile a concept as they come.
The long term absolutely matters and projects choosing convenience today over long-term thinking are screwing over their future. It's damn near impossible to find information about these projects outside the proprietary silos they've dug themselves into and they will regret the choice one of these days when Discord or whatever proprietary service starts tightening the screws to make money.
I'm not sure what you find hostile about their web appearance. It's a light, clean page with text that doesn't throw tons of JS at you, pop-ups, or a cookie accept/reject/ponder bullshit dialog. It could use a bit of a copy edit / redo and a screenshot (I always complain when a project doesn't have screenshots...), but I don't find it hostile in the least.
I would be happy to engage on that thought, but here on this thread there is a lynchmob gathering to declare an emergency to remove all GPL-connected code everywhere, again.. because `screen`
Like any implementation, it comes with certain affordances which differ from other implementations.
Messages feel "heavy" for several reasons: sending one involves a lot of clicks (or keypresses); if you send a very high number you may be banned from your email provider, and unable to communicate with anyone.
Messages often arrive instantly, but can be delayed up to hours or days, so conversation round-trips are kept to a minimum.
Messages are all the same - there are no "lite messages" such as emoji reactions - so any message must contain enough content to justify being a full-fledged message, or it won't be sent at all. (Sometimes an "emoji reaction" is felt to be enough content to justify a full-fledged message, which is sent.)
Being off the web increases the barrier to entry, reducing the eternal september effect (ironically, Usenet is one of the least eternal-september-ish of the public discussion boards currently in existence).
Overall, the feel of the system tends to somewhat discourage quantity and encourage per-message quality.
Haven't you heard about the abomination which is Office365? They recently bolted emoji reactions onto email!