GNU Screen’de bulunan çeşitli güvenlik sorunları

• GNU Screen güvenlik incelemesinde, özellikle Screen 5.0.0 ve setuid-root kurulumları etrafında yerel yetki yükseltme, TTY ele geçirme, bilgi sızması, sinyal gönderiminde yarış durumu ve komut gönderimi sırasında çökme doğrulandı
• En ciddi sorun olan CVE-2025-23395, logfile_reopen()’ın kullanıcı tarafından sağlanan yolu root yetkileriyle işlemesi nedeniyle, rastgele konumlarda root sahipliğinde dosya oluşturmayı veya mevcut dosyalara günlük eklemeyi mümkün kılıyor
• Çok kullanıcılı modun eski davranışları da sorun olarak ortaya çıktı; Attach() TTY’yi geçici olarak 0666 yaptığı için diğer kullanıcıların okuma-yazma yapması ve girdi enjekte etmesi mümkün hale geliyor
• Dağıtıma göre risk, kurulum yöntemine bağlı olarak değişiyor; Arch Linux ve NetBSD 10.1, Screen 5.0.0’ı setuid-root olarak sunduğundan başlıca açıkların etkisine büyük ölçüde maruz kalıyor
• Mevcut öneri, Screen’i setuid-root olarak kurmamak; çok kullanıcılı işlev içinse güvenilir grup tabanlı opt-in, varsayılan yetki düşürme, sınırlı yetki yükseltme ve ortam değişkenlerinin temizlenmesi gerekiyor

---

Açıklama arka planı ve yamalar

• Temmuz 2024’te upstream Screen yöneticisi mevcut kod tabanının incelenmesini istedi; gerçek güvenlik incelemesi ise Ocak 2025’te başladı
• İnceleme sonucunda Screen 5.0.0 büyük güncellemesinde, setuid-root dağıtımlarını etkileyen yerel root exploit’i bulundu
• Ayrıca daha düşük ciddiyette sorunlar tespit edildi; bunların bazıları birçok dağıtımda hâlâ bulunan Screen 4.9.1 ve önceki sürümleri de etkiliyor
• Sorunlar 30 Nisan 2025’te distros posta listesiyle paylaşıldı ve 12 Mayıs 2025’te kamuya açıklandı
• Rapora sürüme göre yama paketleri eklendi
  • screen-4.9.1-patches.tar.gz
  • screen-5.0.0-patches.tar.gz

Screen yapılandırması ve çok kullanıcılı mod

• Screen 5.0.0, Ağustos 2024’te upstream tarafından büyük bir sürüm olarak yayımlandı; Arch Linux, Fedora 42 ve NetBSD 10.1 bu sürümü sunuyor
• Birçok Linux ve UNIX dağıtımı, yazım anında hâlâ Screen 4.9.1 kullanıyor
• Screen’in çok kullanıcılı modu, uygun kimlik bilgileri olduğunda başka bir kullanıcıya ait Screen oturumuna attach etmeyi mümkün kılıyor
  • Bu özellik yalnızca Screen setuid-root bitiyle kurulduğunda kullanılabiliyor
  • Karmaşık Screen kodu root yetkileriyle çalıştığından saldırı yüzeyi büyüyor
• İncelenen sistemler arasında Arch Linux, FreeBSD ve NetBSD, Screen’i setuid-root olarak kuruyor
• Gentoo Linux’ta "multiuser" USE bayrağı ayarlanırsa setuid-root biti uygulanıyor
• Bazı dağıtımlar setuid yerine setgid kullanıyor
  • Gentoo Linux’un varsayılanı setgid-utmp; bu sayede Screen sistem genelindeki utmp veritabanına oturum kaydı oluşturabiliyor
  • Fedora Linux setgid-screen kullanıyor; bu sayede Screen /run/screen altındaki sistem genelindeki dizine soket koyabiliyor

CVE-2025-23395: logfile_reopen() yerel root exploit’i

• CVE-2025-23395, Screen 5.0.0 setuid-root yetkileriyle çalıştırıldığında etkili oluyor
• logfile_reopen() fonksiyonu, kullanıcı tarafından sağlanan yolu işlerken yetkileri düşürmüyor
• Yetkisiz bir kullanıcı, rastgele bir konumda şu özelliklere sahip dosya oluşturabiliyor
  • Sahip: root
  • Grup: çağıran kullanıcının gerçek grubu
  • Dosya modu: 0644
• Zaten var olan dosyalar da kötüye kullanılabiliyor
  • Screen PTY’ye yazılan veri ilgili dosyaya append ediliyor
  • Mevcut dosyanın modu ve sahipliği değiştirilmiyor
• Screen günlük dosyasını ilk açarken yetkileri doğru biçimde düşürüyor; ancak günlük dosyasının yeniden açılması gerektiğine karar verdiği anda yetki yükseltme olasılığı ortaya çıkıyor
• stolen_logfile() kontrolünde, özgün günlük dosyasının link count’u 0 olursa veya boyutu beklenmedik biçimde değişirse logfile_reopen() çağrılıyor
• Bu koşul yetkisiz kullanıcı tarafından bilerek tetiklenebiliyor
• Screen 5.0.0 için patch 0001, günlük dosyasını reopen sürecinde güvenli dosya işlemeyi yeniden devreye alıyor
• Bu sorun, eski commit 441bca708bd içinde lf_secreopen()’ın kaldırılmasıyla oluştu ve ilgili değişiklik 5.0.0 sürümüne dahil edildi

CVE-2025-46802: Çok kullanıcılı oturuma attach sırasında TTY ele geçirme

• CVE-2025-46802, multiattach bayrağı ayarlanmış Attach() fonksiyonunda ortaya çıkıyor
• Screen, çok kullanıcılı oturuma attach sırasında mevcut TTY için chmod() ile modu 0666 olarak değiştiriyor
• TTY yolu /dev altında olup olmadığı ve isatty() koşulu gibi kontrollerle doğrulandığından, bu davranış tek başına ayrı bir yerel root exploit’i oluşturmuyor
• Sorun, TTY izinleri geçici olarak gevşetilirken diğer kullanıcıların ilgili TTY’yi okuyup yazabileceği bir yarış durumu oluşması
• Linux inotify API’sine dayalı basit bir testte, bir Python betiğinin her iki-üç denemede bir etkilenen TTY’yi açabildiği görüldü
• Saldırgan şunları yapabilir
  • TTY’ye girilen verileri ele geçirebilir
  • TTY’ye veri enjekte edebilir
  • Kullanıcıyı parola girmesi için yanıltabilir
  • Denetim dizileri enjekte ederek kurbanın kafasını karıştırabilir veya ilgili terminal emülatörü sorunlarını hedefleyebilir
• Attach() içindeki bazı return yollarında özgün TTY modu geri yüklenmiyor
  • Örnek: hedef oturum bulunamadıysa ve "quiet" argümanı ayarlıysa
• Yama, geçici chmod() işlemini kaldırıyor
  • Screen 4.9.1 için patch 0001
  • Screen 5.0.0 için patch 0004
• Açıklamadan hemen önce bu yamanın bazı reattach kullanım örneklerini bozabileceği belirlendi; ancak söz konusu kullanım örneklerinin Screen 4.9.1’de de zaten bozuk olduğu doğrulandı
• Bu sorun en az 2005’ten beri Screen sürümlerinde mevcut ve setuid-root ile çok kullanıcılı destek sunan Linux dağıtımlarını ve BSD’leri etkiliyor
• setuid-root olmadığında da kullanıcı kendi TTY’sinin modunu değiştirme yetkisine sahip olduğundan teorik olarak etkilenir; ancak Screen root yetkisi olmadan başka kullanıcıların oturumlarında ilerlemiyor

CVE-2025-46803: Screen 5.0.0’da world-writable PTY varsayılanı

• CVE-2025-46803, Screen 5.0.0’da Screen’in ayırdığı PTY’nin varsayılan modunun 0620’den 0622’ye değişmesi sorunudur
• Bu varsayılanda sistemdeki herkes Screen PTY’ye yazabilir
• Güvenlik açısından CVE-2025-46802’ye benzer bir sorun doğar, ancak bilgi sızması boyutu hariçtir
• Screen 4.9.1’de kod düzeyindeki varsayılan 0622 olsa da autotools yapılandırmasının varsayılanı 0620 uygulandığı için güvenli varsayılan kullanılıyordu
• Screen 5.0.0’da configure.ac yeniden yazılırken autoconf düzeyindeki 0620 varsayılanı kayboldu; daha sonra pty-mode configure anahtarı varsayılan 0622 ile yeniden eklendi
• 5.0.0 sürüm notları doğrulanamadı, yalnızca ChangeLog içinde bazı kayıtlar vardı; PTY modu varsayılanındaki değişiklik bilinçli bir karar gibi görünmüyor
• Screen 5.0.0 için patch 0002, configure.ac içinde güvenli varsayılan PTY modunu geri getiriyor
  • Değişikliğin uygulanması için autoreconf çalıştırılması gerekiyor
• Paketleyicilere --with-pty-mode=0620 configure anahtarını açıkça geçmeleri öneriliyor
• Gentoo Linux ve Fedora Linux güvenli --with-pty-mode değerini açıkça geçiriyor
• Arch Linux ve NetBSD bu anahtarı geçirmediğinden yeni varsayılan uygulanıyor ve açık etkili oluyor

CVE-2025-46804: Soket yolu hata mesajıyla dosya varlığının sızması

• CVE-2025-46804, Screen setuid-root yetkileriyle çalıştığında oluşan düşük önem dereceli bir bilgi sızıntısıdır
• Eski Screen sürümleri ve 5.0.0’da doğrulandı
• Screen, SocketPath değerini root yetkileriyle denetliyor ve yetkisiz kullanıcının normalde bilemeyeceği yol bilgilerini hata mesajıyla açığa çıkarıyor
• SCREENDIR ortam değişkeni kullanılarak şu bilgiler çıkarılabilir
  • /root/.lesshst normal bir dosya mı
  • /root/.cache dizini var mı
  • /root/test yolu mevcut değil mi
• Yama, setuid-root kurulumlarında hedef yol sürecin gerçek UID’si tarafından kontrol edilmiyorsa yalnızca genel bir hata mesajı basacak şekilde değiştiriyor
  • Screen 4.9.1 için patch 0002
  • Screen 5.0.0 için patch 0005
• İncelenen tüm dağıtımlar etkileniyor

CVE-2025-46805: Sinyal gönderiminde TOCTOU yarış durumu

• CVE-2025-46805, setuid-root bağlamında kullanıcı tarafından sağlanan PID’ye sinyal gönderirken ortaya çıkan bir TOCTOU yarış durumudur
• CheckPid(), gerçek kullanıcı ID’siyle yetkileri düşürdükten sonra çekirdeğin hedef PID’ye sinyal gönderimine izin verip vermediğini kontrol ediyor
• Gerçek sinyal daha sonra Kill() üzerinden gönderiliyor ve bu sırada root yetkileri kullanılabiliyor
• Kontrol ile gerçek gönderim arasında, daha önce kontrol edilen PID başka bir privileged process ile değiştirilebilir
• privileged Screen daemon sürecini kendi kendine sinyal göndermeye kandırma olasılığı da var
• Şu anda yalnızca SIGCONT ve SIGHUP gönderilebildiğinden etkinin yerel hizmet reddi veya düşük düzeyde bütünlük ihlali alanında kalması muhtemel
• Bu sorun, CVE-2023-24626 için yapılan eksik düzeltmeden kaynaklanıyor
  • O düzeltmeden önce yarış durumu olmadan da rastgele süreçlere söz konusu sinyaller gönderilebiliyordu
• Yama, gerçek sinyali de CheckPid() gibi gerçek UID yetkileriyle gönderecek şekilde değiştiriyor
  • Screen 4.9.1 için patch 0003
  • Screen 5.0.0 için patch 0006
• İncelenen tüm dağıtımlar etkileniyor

Screen 5.0.0’da strncpy() kullanımı nedeniyle komut gönderimi çökmesi

• Screen 5.0.0’da güvenlik sorunu olarak görülmese de öncelikle düzeltilmesi gereken strncpy() ile ilgili bir problem var
• commit 0dc67256 içinde birçok strcpy() çağrısı strncpy() ile değiştirildi
• strncpy() güvenli string işleme için bir fonksiyon değil, sabit uzunluklu buffer’ı 0 ile padding yapan bir fonksiyondur; bu nedenle ilk \0 baytından sonra da hedef buffer’ın sonuna kadar 0 yazar
• attacher.c içindeki komut satırı argümanı işleme döngüsünde, ilk iterasyondan sonra da hedef boyutu olarak MAXPATHLEN geçiriliyor
• p işaretçisi zaten ilerlemiş olsa da aynı boyut geçirildiği için sonraki strncpy() çağrıları buffer sonunu aşarak \0 baytları yazıyor
• Arch Linux’ta çalışan bir Screen oturumuna birden fazla komut argümanı gönderildiğinde, _FORTIFY_SOURCE açık derlemelerde şu hata gözlemlendi
  • *** buffer overflow detected***: terminated
  • Aborted (core dumped)
• _FORTIFY_SOURCE yoksa görünür hata olmayabilir ve -fsanitize=address ile de hata görünmeyebilir
• Çağıran, cmd buffer’ının arkasındaki MAXPATHLEN baytı 0 ile ezebilir; ancak arkasında aynı boyutta writeback[MAXPATHLEN] buffer’ı bulunduğundan saldırgan lehine istismar olasılığı olmadığı değerlendiriliyor
• Screen 5.0.0 için patch 0003, strncpy()’yi snprintf() ile değiştiriyor ve kalan hedef buffer boyutunu doğru biçimde geçiriyor
• Screen 5.0.0 sunan tüm dağıtımlar etkileniyor

Dağıtıma göre etki kapsamı

Sistem	Screen sürümü	Özel yetki	Etki
Arch Linux	5.0.0	setuid-root	3.a, 3.b, 3.c, 3.d, 3.e, 3.f
Debian 12.10	4.9.0	yok	3.b kısmen
Ubuntu 24.04.2	4.9.1	yok	3.b kısmen
Fedora 42	5.0.0	setgid-screen	3.b kısmen, 3.f
Gentoo	4.9.1	setgid-utmp, multiuser USE bayrağı ayarlandığında setuid-root	3.b kısmen
openSUSE TW	4.9.1	yok	3.b kısmen
FreeBSD 14.2	4.9.1	setuid-root	3.b, 3.d, 3.e
NetBSD 10.1	5.0.0	setuid-root	3.a, 3.b, 3.c, 3.d, 3.e, 3.f
OpenBSD 7.7	4.9.1	yok	3.b kısmen

setuid-root tasarımına ilişkin kaygılar ve öneriler

• Screen çok kullanıcılı modunda üç UID yer alıyor
  • privileged operation için effective UID 0
  • oturumu oluşturan kullanıcının gerçek UID’si
  • oturuma attach eden kullanıcının gerçek UID’si
• Mevcut Screen kodu bu ayrımı uygun biçimde yansıtması zor bir yapıda görünüyor
• root tarafından oluşturulan Screen çok kullanıcılı oturumu, oturum oluşturucusunun gerçek UID’si olan 0’a “yetki düşürdüğü” için pratikte yetki düşürme gerçekleşmiyor
• Screen 5.0.0’ın yeniden düzenlenmesi sırasında uzun süredir var olan güvenlik mantığı bozuldu ve bunun sonucunda CVE-2025-23395 ile CVE-2025-46803 ortaya çıktı
• Ek refactoring öncesinde, uygulamanın güvenlik özelliklerini doğrulayabilecek bir test suite gerekiyor
• setuid-root binary’lerle çalışan geliştiricilerin bu alanın risklerini anlaması gerekiyor
• Screen, yükseltilmiş yetkilerle çalışmaya devam ediyor ve yalnızca riskli gördüğü işlemlerde seçici olarak yetki düşürüyor
• Sağlam bir setuid-root programı varsayılan olarak yetki düşürmeli ve yalnızca gerçekten yükseltilmiş yetki gerektiren işlemlerde yetki yükseltmelidir
• setuid-root bağlamında yalnızca açıkça izin verilen ortam değişkenlerini bırakıp diğerlerini kaldıran bir mantık gerekiyor
• PATH gibi ortam değişkenleri yalnızca güvenilir sistem dizinlerini gösterecek şekilde temizlenmeli
• Şimdilik yalnızca Screen 5.0.0’ın değil, önceki 4.9 serisinin de setuid-root olarak kurulmaması öneriliyor
• Alternatif olarak çok kullanıcılı işlev opt-in biçimde sunulabilir ve yalnızca güvenilir grup üyelerinin çok kullanıcılı Screen sürümünü çalıştırmasına izin verilebilir

Açıklama koordinasyon süreci ve upstream durumu

• Şubat 2025’te sorunlar Screen upstream’e özel olarak bildirildi ve koordineli açıklama önerildi
• upstream, kamuya açıklanmadan önce hataları düzeltmek için sorunları gizli tutmakla ilgilendiğini belirtti ve 1-2 aya ihtiyaç duyduğunu iletti
• Yaklaşık bir ay sonra upstream tarafında faaliyet ve yama tartışmaları başladı, ancak tartışmalar yeterince verimli olmadı
• En fazla 90 günlük embargo süresi yaklaşana kadar ek iletişim olmadı; bu arada NetBSD gibi dağıtımlar Screen 5.0.0’a güncellendi ve CVE-2025-23395’ten tamamen etkilenir hale geldi
• upstream’in Screen kod tabanına yeterince aşina olmadığı ve bildirilen güvenlik sorunlarını tam olarak anlamadığı kanaatine varıldı
• upstream, bazı sorunlar çözülmemişken daha erken açıklama istedi; bunun üzerine taslak hızla distros posta listesine iletildi
• Sonrasında SUSE tarafı eksik düzeltmeleri doğrudan geliştirdi; upstream’de taslak biçimde tartışılan yamalar da ayarlanıp belgelendi
• Adanmış upstream kapasitesi olsaydı koordineli açıklama sürecinin yaklaşık 2 hafta içinde tamamlanabileceği değerlendiriliyor
• Screen upstream’in insan gücü ve uzmanlık eksikliği yaşadığı görülüyor; yaygın kullanılan bir açık kaynak yardımcı araç olduğu düşünüldüğünde bu büyük bir kaygı yaratıyor

Önemli tarihler

• 2024-07-01: upstream’in inceleme isteği iletildi
• 2025-01-08: güvenlik inceleme çalışması başladı
• 2025-02-07: Screen upstream’e özel rapor ve koordineli açıklama önerisi yapıldı
• 2025-02-11: GNU Savannah hata takip sisteminde gizli hata oluşturuldu
• 2025-04-30: CVE atama kararı ve taslak distros posta listesiyle paylaşıldı
• 2025-05-07: Screen 4.9.1 ve 5.0.0 için tamamlanmış yamalar distros posta listesi ve upstream ile paylaşıldı
• 2025-05-12: Rapor blogda ve oss-security posta listesinde kamuya açıldı

[GN⁺]

Hacker News yorumları

• Screen’de böyle bir çok kullanıcılı mod olduğunu bilmiyordum; tmate gibi araçları mümkün kılan şey muhtemelen bu özellik olmalı
  Uygun kimlik bilgileri varsa, başka bir kullanıcının sahip olduğu Screen oturumuna bağlanabiliyorsunuz; bu özellik de yalnızca Screen setuid-root olarak kurulduysa mümkünmüş
  Bu yüzden tmux’un da aynı tür güvenlik açıklarından etkilenip etkilenmediğini merak ettim

  • tmux Unix domain socket kullandığı için bu durum geçerli değil
    screen’in burada neden setuid yaklaşımını seçtiğini bilmiyorum; root yetkisi hiç gerekmiyor gibi görünüyor
    Yazının alt tarafında, mevcut screen geliştiricilerinin kod tabanına tamamen hâkim olmadığına dair makul bir açıklama var; öyleyse özelliği çalıştırmanın en kolay yolu setuid-root olmuş olabilir
  • Oldukça iyi bir özellik
    Eğitim oturumlarında her öğrenciye dizüstü bilgisayarımda bir oturum açma hesabı verip SSH shell’ini screen -x ile sınırladığım, ardından screen’in erişim denetim listesiyle her öğrencinin yalnızca kendi penceresini kullanmasını sağladığım olmuştu
    Uygulama sırasında screen sahibi olarak her öğrencinin ekranını projektöre yansıtıp tüm sınıfın sonucu görmesini sağlayabiliyordum
    Çok sayıda güvenlik deliği varsa şaşırmam
  • Evet, screen -x

• Debian’da GNU screen setuid-root yetkisiyle kurulmaz

  • Debian Stable, yani bookworm’daki paket çok eski olduğu için 5.0.0 güvenlik açığından etkilenmiyor
    Eskiden Debian’ın yazılım sürümlerinde sürekli geride kalmasından hoşlanmazdım; artık tarayıcılar gibi gerçekten çok eski yazılımlara bağımlı olmak istemediğim birkaç uygulama için başka paket kaynakları kullanıp geri kalanında eski paketlerle gayet iyi idare ediyorum
  • Slackware 15’te /usr/bin/screen, screen-4.9.0’ı gösteriyor ve çalıştırılabilir dosya da suid değil
  • Gentoo’da da aynı
    Ancak Gentoo’da utmp grubu için SETGID var; bunun etkisinin ne olduğundan pek emin değilim
  • Fedora’da setuid-root gibi görünüyor

• Render edilmiş blog yazısı burada: https://security.opensuse.org/2025/05/12/screen-security-iss...

• GNU Screen yazarına dosyaya günlükleme özelliğinin düzgün belgelenmediğini söyleyen bir e-posta göndermiştim: http://www.zoobab.com/screenrc
  GNU’nun daha iyi bir issue takip sistemine ihtiyacı var

  • Tmux yazarıyla bir Soru-Cevap vardı; yaklaşık 16 yıl önce bile dokümantasyon eksikliğinden şikâyet ediyordu
    https://undeadly.org/cgi?action=article&sid=20090712190402
  • GNU screen kılavuzunda ayrıntılı biçimde belgelenmiş: https://www.gnu.org/software/screen/manual/screen.html#Log
  • Eski projelerin önemli bir kısmında, sorunların dizine eklenmemiş e-posta listelerinin sonsuz derinliklerine gömülmesi problemi var
    Discord’un bu tür bilgileri erişilemez hâle getirdiği için eleştirilmesi haklı; ama bazı projelerin hâlâ kullandığı IRC aslında bundan iki kat daha kötü
    Bu projelerin Gitea, Forgejo, Codeberg, GitLab, GitHub gibi yerlere taşınıp ilgili içerikleri bir araya getirmesini ve keşfedilebilirlik sağlamasını isterdim

• Zellij, screen ve tmux’a modern bir alternatif olarak oldukça iyi; varsayılanları da harika ve arayüzü kolay keşfedilebilir olacak şekilde iyi tasarlanmış
  Terminal çoklayıcılarda harcanan çabaya karşılık alınan faydanın belirsiz olduğunu düşünenlere öneririm
  https://zellij.dev
  https://github.com/zellij-org/zellij

  • Birkaç yıl önce denemiştim, oldukça pürüzsüzdü
    Ama tmux’a kıyasla gecikme göze çarpıyordu; hâlâ tmux kullanmaya devam ediyorum
    O sırada zaten gecikmeli bir bağlantı kullandığım için biraz hassas davranmış da olabilirim
  • Zellij’e en son baktığımda çoklayıcı ekosisteminde harika yeni bir proje gibi görünüyordu, ancak tamamen klavye tabanlı kopyala/yapıştır mekanizmasını desteklemiyordu
    Bu özelliği çok yoğun kullandığım için onsuz kullanamam; eklenene kadar tmux kullanmak zorundayım
  • Güzel ama screen’i gerçekten seviyorum ve komutları artık kas hafızama yerleşmiş durumda
    20 yılı aşkın süredir kullanıyorum

• Upstream’in buna dahil olması şaşırtıcı
  Yaklaşık 5 yıl önce GNU screen geliştirmesinin tamamen durduğuna üzülerek karar vermiştim; hâlâ öyle olup olmadığını merak ediyorum
  screen’de hâlâ mevcut screen’e bağlanmadan yeni pencere ekleme özelliği var mı bilmiyorum

  • Upstream, SUSE ekibinden buna bakmasını istemiş
    Geliştirici gücü yetersiz ve upstream’in düzgün bakım yapacak uzmanlığı olmayabilir gibi görünüyor
    Doğruysa üzücü. tmux ve başka alternatifler olduğunu biliyorum ama birçok kişi Screen’i çok uzun zamandır kullanıyor; bir aracın yavaş yavaş çürümesi üzücü
  • Upstream ile iletişimin zor olduğu, bu yüzden onların yaptığı hata düzeltmeleri ve sürümler hakkında şu anda ayrıntılı bilgiye sahip olmadıkları belirtiliyor
    Güvenlik incelemesi istemişler ama iletişimi sürdürmek zor olmuş gibi; tüm durumu iyi bilmiyorum
  • Dahil olma dedikleri, setuid-root olarak dağıtmış olmaları ölçüsünde
    Bu şekilde yapılandıran dağıtımlar savunmasız, yapılandırmayanlar değil
    Bence çok yüzeysel bir dahil olma. Upstream çok yavaşsa dağıtımlar yama yapar
  • GNU araç geliştirmesinin durması illa üzücü bir şey değil; elbette hata düzeltmeleri hariç
    Temelde bunun tamamlanmış bir araç olduğunun işareti olarak kabul edilebilir
  • Açık kaynakta bir yazılımın ömrü sona erip onun yerine başka bir yazılım üretildiğinde atalet oluşması gibi bir sorun var
    Hemen geçiş yapmak için teşvik yok; çünkü bu bir güncelleme değil, geçiş
    Tersinden, birinin mevcut yazılımın ticari markasını satın alıp Audacity’de olduğu gibi onu tamamen başka bir şeye dönüştürmesi de kötü
    Bu yüzden iyi bir çözüm yok gibi görünüyor

• Render edilmiş sürüm: https://security.opensuse.org/2025/05/12/screen-security-iss...

• Yanlış hatırlamıyorsam tmux, OpenBSD 4.6’dan beri temel sisteme dahil ve denetlenmiş ya da denetlenegelen bir araç
  Biraz daha güvenli bir alternatif isteyenler için iyi

  • screen’in yeniden gündeme geldiğini görünce, bir zamanlar tmux’a geçip screen’i unuttuğum dönem aklıma geldi

• Gözlemlenen davranış en azından 2005’ten bu yana Screen sürümlerinde vardı; o kadar uzun süredir bir anti-pattern idi ve rkhunter gibi araçlar da bunu ele almıştı
  Yine de screen’in 90’larda da setuid root olduğunu sanıyorum

• En popüler açık kaynak araçları gerçekte kaç geliştirici yürütüyor?
  Bu araçları kullanan sektörlerde ne kadar para var?