2023/07/19

2023-07-19 00:06:43 +0200 <u8353v[m]> <geekosaur> "well, some of them. if it..." <- no - i was told wayland is more secure than X11
2023-07-19 00:06:43 +0200 <u8353v[m]> but X11 just works!
2023-07-19 00:06:43 +0200 <u8353v[m]> i want to know how can i harden it's security?
2023-07-19 00:06:43 +0200 <u8353v[m]> or this comes down to hardening the OS?
2023-07-19 00:08:18 +0200 <geekosaur> it needs a major server redesign, its security model is from the 1980s
2023-07-19 00:08:32 +0200liskin[m](~liskinmat@2001:470:69fc:105::768)
2023-07-19 00:10:56 +0200 <geekosaur> I mean, even the IPC it uses is insecure, AF_UNIX sockets the only security is uid-based filesystem access and INET sockets even less. a modern protocol would take advantage of dbus, polkit, etc.
2023-07-19 00:12:52 +0200 <geekosaur> any client with any kind of access to the server can observe any event not sent under a server grab, which means passwords can be sniffed by any process
2023-07-19 00:15:59 +0200sagax(~sagax_nb@user/sagax) (Ping timeout: 246 seconds)
2023-07-19 00:16:35 +0200 <geekosaur> if you sit down and redesign X11 to fix its security flaws, multiscreen shortcomings, etc., you'll come out with something looking a lot like wayland-the-protocol
2023-07-19 00:16:53 +0200 <geekosaur> it's wayland-the-implementation that I don't trust…
2023-07-19 00:19:12 +0200 <geekosaur> well, I shouldn't say "don't trust", aside from stability. I question what they've done with what they have; it seems like wayland has failed to actually improve on X11 in many areas where it should easily be able to
2023-07-19 00:19:23 +0200ft(~ft@p3e9bc856.dip0.t-ipconnect.de)
2023-07-19 00:22:38 +0200 <geekosaur> I also have doubts about how far additional security will get you when people don't make use of it
2023-07-19 00:43:55 +0200 <geekosaur> Don't get me wrong — I'd love to see someone pick up and modernize X11. I just think the result will be Wayland.
2023-07-19 02:23:20 +0200ml|(~ml|@user/ml/x-5298235) (Ping timeout: 250 seconds)
2023-07-19 02:36:29 +0200ml|(~ml|@user/ml/x-5298235)
2023-07-19 03:02:25 +0200hightower3(~hightower@213-202-64-66.dsl.iskon.hr)
2023-07-19 03:04:57 +0200hightower2(~hightower@141-136-175-55.dsl.iskon.hr) (Ping timeout: 245 seconds)
2023-07-19 03:47:38 +0200obimod(~weechat@user/obimod) (Ping timeout: 240 seconds)
2023-07-19 04:27:34 +0200td_(~td@i53870919.versanet.de) (Ping timeout: 272 seconds)
2023-07-19 04:28:46 +0200td_(~td@i5387092E.versanet.de)
2023-07-19 04:42:14 +0200terrorjack(~terrorjac@2a01:4f8:c17:87f8::) (Quit: The Lounge - https://thelounge.chat)
2023-07-19 04:45:18 +0200terrorjack(~terrorjac@2a01:4f8:c17:87f8::)
2023-07-19 04:48:46 +0200thunderrd(~thunderrd@183.182.111.104) (Ping timeout: 245 seconds)
2023-07-19 04:52:33 +0200 <absta[m]> Oh do you think Wayland protocol of monolithic compositor is inevitable?
2023-07-19 06:15:26 +0200geekosaur[c](sid609282@xmonad/geekosaur) (Ping timeout: 246 seconds)
2023-07-19 06:19:22 +0200geekosaur[c](sid609282@xmonad/geekosaur)
2023-07-19 08:09:23 +0200 <geekosaur> yes
2023-07-19 08:09:26 +0200 <geekosaur> and necessary
2023-07-19 08:10:19 +0200 <geekosaur> X11's compositor setup is an ugly hack that will always perform horribly and be weirdly unstable
2023-07-19 08:11:06 +0200 <geekosaur> "the compositor is the display server" is the same thing as "the display server is the compositor" which is how it should have been to begin with
2023-07-19 08:12:00 +0200 <geekosaur> but with X11's 1980s architecture it isn't possible
2023-07-19 08:15:46 +0200mncheck(~mncheck@193.224.205.254)
2023-07-19 08:16:02 +0200 <geekosaur> the only real problem with wayland is it'll take 5-10 years to mature
2023-07-19 08:17:16 +0200 <geekosaur> (well, the real real problem with it is monolithic gnome being rammed down everyone's throats, but that's rh/gnome, not something required by wayland)
2023-07-19 08:47:50 +0200 <geekosaur> I suspect what will happen is gnome and maybe kde will use their own monoliths and everyone else will standardize on wlroots or similar; in fact it's already happening
2023-07-19 08:50:10 +0200 <geekosaur> (and indeed I just checked and KDE seems to be moving to wlroots)
2023-07-19 08:51:28 +0200 <geekosaur> so in the end wlroots is likely to become a more traditional display server, with the compositor baked in because it needs to be tight up with the low level display drivers to work well
2023-07-19 08:52:19 +0200 <geekosaur> and KDE, Sway, Enlightenment, and presumably some form of xmonad among others will use it
2023-07-19 09:00:47 +0200 <geekosaur> what I hope is that standardization will see something usable in manageHooks to come back; currently gnome doesn't use it so nobody implements it
2023-07-19 10:56:38 +0200ft(~ft@p3e9bc856.dip0.t-ipconnect.de) (Quit: leaving)
2023-07-19 12:46:05 +0200 <absta[m]> I thought gnome went that way because of Wayland, not the other way around ;P
2023-07-19 12:47:08 +0200 <absta[m]> It makes sense how compositor and display server is tied together, but I am yet to see why window management and various functionalities like taskbar would be tied up to the compositor. Wish wlroots would become a proper compositor!
2023-07-19 13:10:07 +0200tv(~tv@user/tv) (Quit: derp)
2023-07-19 13:13:36 +0200tv(~tv@user/tv)
2023-07-19 13:30:22 +0200obimod(~weechat@user/obimod)
2023-07-19 14:11:30 +0200tv1(~tv@user/tv)
2023-07-19 14:11:32 +0200tv(~tv@user/tv) (Ping timeout: 240 seconds)
2023-07-19 16:04:47 +0200 <geekosaur> I thought it was
2023-07-19 16:05:11 +0200 <geekosaur> wlroots is the compositor component of sway but has been adopted by a number of other wayland window managers
2023-07-19 16:05:26 +0200unclechu(~unclechu@2001:470:69fc:105::354)
2023-07-19 16:06:22 +0200 <geekosaur> window management doesn't need to be directly tied to the compositor; it wants better integration than X11 offers but that's because it's not part of the window system core / the display driver
2023-07-19 17:16:10 +0200gar[m](~randyorto@2001:470:69fc:105::3:85fa)
2023-07-19 17:19:58 +0200 <gar[m]> Can I open certain sites on opening browser on a particular workspace and login to them using selenium with xmonad
2023-07-19 17:21:34 +0200 <geekosaur> I would expect yes, although you would need to do some work
2023-07-19 17:22:16 +0200 <geekosaur> https://hackage.haskell.org/package/webdriver may be of interest
2023-07-19 18:10:12 +0200liskin[m](~liskinmat@2001:470:69fc:105::768) (Remote host closed the connection)
2023-07-19 18:37:32 +0200unclechu(~unclechu@2001:470:69fc:105::354) (Remote host closed the connection)
2023-07-19 19:30:33 +0200jeeeun(~jeeeun@78.40.148.178) (Quit: The Lounge - https://thelounge.chat)
2023-07-19 19:35:58 +0200jeeeun(~jeeeun@78.40.148.178)
2023-07-19 20:02:43 +0200scrungus(~scrungus@70.24.87.181)
2023-07-19 20:03:44 +0200 <scrungus> Does anyone here use window swallowing? I have this issue where when I launch an application through dmenu it swallows whatever terminal window happened to be focused
2023-07-19 20:04:00 +0200liskin[m](~liskinmat@2001:470:69fc:105::768)
2023-07-19 20:04:14 +0200unclechu(~unclechu@2001:470:69fc:105::354)
2023-07-19 20:07:46 +0200scrungus(~scrungus@70.24.87.181) (Quit: WeeChat 4.0.2)
2023-07-19 20:12:54 +0200scrungus(~scrungus@70.24.87.181)
2023-07-19 20:17:46 +0200geekosaur(~geekosaur@xmonad/geekosaur) (Killed (NickServ (GHOST command used by allbery_b)))
2023-07-19 20:17:46 +0200allbery_b(~geekosaur@xmonad/geekosaur)
2023-07-19 20:17:49 +0200allbery_bgeekosaur
2023-07-19 20:19:17 +0200xmonadtrack(~xmonadtra@user/geekosaur/bot/xmonadtrack) (Ping timeout: 246 seconds)
2023-07-19 20:36:39 +0200scrungus(~scrungus@70.24.87.181) (Quit: WeeChat 4.0.2)
2023-07-19 20:41:28 +0200xmonadtrack(~xmonadtra@069-135-003-034.biz.spectrum.com)
2023-07-19 20:41:28 +0200xmonadtrack(~xmonadtra@069-135-003-034.biz.spectrum.com) (Changing host)
2023-07-19 20:41:28 +0200xmonadtrack(~xmonadtra@user/geekosaur/bot/xmonadtrack)
2023-07-19 23:19:40 +0200ft(~ft@p3e9bc856.dip0.t-ipconnect.de)