ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
Company has quit [Quit: Leaving]
xantoz has quit [Ping timeout: 480 seconds]
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
maxzor has joined #wayland
bim9262 has quit [Quit: ZNC - https://znc.in]
bim9262 has joined #wayland
maxzor has quit [Ping timeout: 480 seconds]
xantoz has joined #wayland
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
bim9262 has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
<wlb> weston Merge request !1389 closed (replace weston_signal_emit_mutable with wl_signal_emit_mutable)
ascent12 has quit [Ping timeout: 480 seconds]
<wlb> weston Merge request !1391 opened by HeYong (HeYong) replace weston_signal_emit_mutable with wl_signal_emit_mutable https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1391
ascent12 has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
ascent12 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
ascent12 has joined #wayland
RAOF has quit [Ping timeout: 480 seconds]
caveman has quit [Ping timeout: 480 seconds]
kts has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
caveman has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
privacy has quit [Remote host closed the connection]
lsd|2 has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
kts has quit [Read error: Connection reset by peer]
bim9262 has quit [Ping timeout: 480 seconds]
RAOF has joined #wayland
bim9262 has joined #wayland
kts has joined #wayland
kts has quit [Ping timeout: 480 seconds]
ErrorNoI1ternet has joined #wayland
glennk has joined #wayland
ErrorNoInternet has quit [Ping timeout: 480 seconds]
<DemiMarie> Is wlroots known to use the GPU inefficiently, or are the benchmarks in <https://github.com/CuazroSoftware/Louvre> bad?
<bl4ckb0ne> the link is 404
ErrorNoI1ternet has quit [Remote host closed the connection]
nerdopolis has quit [Ping timeout: 480 seconds]
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
<i509vcb> swap c and z
<DemiMarie> https://github.com/CuarzoSoftware/Louvre claims to use the CPU and GPU more efficiently than Sway or Weston, and their benchmarks appear to show Sway using the GPU very inefficiently.
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
<fluix> I'm curious about the FPS claims: is it saying wlroots rendering can drop to half the refresh rate (when there's lots of moving surfaces)?
<fluix> kind of odd that it also only happens between... 2-19ish and 25+ surface
<kchibisov> it's kind of odd that both weston and sway dropped to exactly 30 fps.
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
<kchibisov> I'd assume it's because renderer can't make it in time, so it waits for next vblank?
<DemiMarie> exactly @_oftc_kchibisov:matrix.org
<DemiMarie> (also which Matrix room are you using?)
<kchibisov> I don't use matrix.
NepNepdmsalwaysopen[m] is now known as NepNep[m]
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
privacy has joined #wayland
tzimmermann has joined #wayland
rv1sr has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
pstch has joined #wayland
<pstch> hi there
<pstch> what is the preferred protocol now to ensure that input to other clients is inhibited ? there is wlr-input-inhibitor-unstable-v1 (implemented in sway), but it's been deprecated in favor of a session locking protocol
sima has joined #wayland
sevz17 has quit [Quit: WeeChat 4.1.1]
<pstch> I'm trying to design some form of secure password prompt, in an overlay layer-shell surface with a transparent background
<soreau> is a transparent background secure if sensitive information could potentially show through?
<fluix> it's a prompt, not a lockscreen
bim9262 has quit [Ping timeout: 480 seconds]
<leon-p> pstch: are you writing a layer-shell pinentry? Because then I have some prior art: https://git.sr.ht/~leon_plickat/wayprompt
<leon-p> whether your surface gets keyboard focus is compositor policy
<leon-p> you could watch for keyboard enter/leave events and maybe indicate in the UI whether your surface has focus
bim9262 has joined #wayland
leon-anavi has joined #wayland
qaqland is now known as Guest7309
qaqland has joined #wayland
mvlad has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
Guest7309 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
<pq> DemiMarie, Weston definitely has (had? there has been some very recent work on the area) damage handling bugs that cause excessive texture uploads from wl_shm buffers which is definitely expensive.
<MrCooper> emersion: heh, "that's not the issue" and then goes on to describe what could be explained by that issue :/
<pq> Like, a simple surface move can cause a texture re-upload even without any damage. Would be worth re-testing on latest RC release, I think.
<pq> Louvre has written a benchmark I have wanted to see for years. :-)
<Ermine> Looks interesting
<pstch> leon-p: well it is compositor policy if there is no protocol that provides it, but there were proposals for input inhibition
<pstch> soreau: I mean secure as "the password cannot be stolen" not "hiding other screen contents"
<pq> pstch, IOW, a globally modal dialog.
<pstch> leon-p: yes I've looked at that :) but I'm afraid that its focus could be stolen by other apps
<pstch> pq: yes and no, as I also want to dim the background (everything other than the dialog), and prevent other apps from stealing focus (by opening a new window)
<pq> that's a globally modal dialog, indeed
<pstch> dimming the background is to prove to the user that we are not an impersonating app, as fullscreen windows can't show a transparent background
<soreau> so says the spec, hehe
<pq> There is also the concern of an app locking out the user from their machine by displaying a globally modal dialog, which even without any malice can be annoying (cannot rearrange other windows in order to see what you want to answer the dialog). This is usability trade-off.
<pstch> because of that, I think I need to use layer-shell, and combine that with the upcoming security-context protocol
<pstch> pq: yes I've thought of that, but it's not a problem in my case
<pq> ok
<pstch> ah but maybe I'm wrong in thinking that I need input inhibition..
<pstch> if I display a surface using layer-shell, in 'overlay', and no other app can use layer-shell, then no other app can steal the focus, right ?
<pq> pstch, you mean you have a plan how to disallow random apps from using your dialog for random things?
<pstch> pq: yes
<pstch> all other apps would be sandboxed in that case, using a combination of kernel namespaces and wayland's security-context protocol
<pq> cool
<pq> A much more Wayland'y design would be to have an extension saying "This window is a passphrase input dialog." than trying to piece together a new use case from existing extensions that were perhaps never meant to be used that way. After all, Wayland design aims for policy, not mechanism, as much as possible.
<soreau> I typically think input inhibiting in terms of compositor bindings. If you have something bound to KEY_A and that's part of the password or unlock sequence, input inhibition can be convenient
<pstch> I'm just not sure how I can ensure that during the execution of the password prompt no other app can have access to input events (e.g. by stealing focus)
<pq> OTOH, if you're just making an ad hoc system off what you happen to have, it's fine.
<soreau> but also, what if you want to grab a new keybinding and ignore all compositor bindings from getting in the way?
<pstch> pq: ah right, yes that would be an interesting thing to do. OTOH, prototyping using existing protocols can help define a future extension
<pq> these questions around input inhibition are a good example: you're trying to figure out what all things you need to do in a client in order to stop a compositor from doing the wrong thing. If that responsibility was put onto the compositor instead, you would not need to guess what all is enough.
<pq> oh, prototyping, sure
<pstch> yes, very true
<pq> although... what's there to prototype? If the protocol ends up being completely different, what did the prototype give you?
<pstch> but still a bit frustrating that the screen-locking protocol seems to do everything I need, except that... I don't want to lock the session
<pq> heh
<pstch> I've been prototyping using the replacement for input-inhibition (screen-locking), and for now just assume my process wont crash
<kchibisov> pstch: compositor is the one responsible for given focus.
<kchibisov> also, layer-shell surface grabbing keyboard usually can't lose focus.
<kchibisov> if it's on overlay, etc.
<kchibisov> it's also all up to compositor policy.
<pstch> kchibisov: right, but as I understand, there are protocols (and extensions) for asking the compositor to do that
<kchibisov> and you have namespaces.
<kchibisov> i don't know if there's a single one.
<pstch> kchibisov: this "usually" is what I want to investigate
<kchibisov> I mean, you can't protect against broken protocols.
<kchibisov> you can't also protect against user having access to /dev/input.
<kchibisov> if you know how to protect against user being in /dev/input, clearly you control a lot for your user already.
<pstch> but users don't have access /dev/input do they ?
<kchibisov> I can add myself to input group.
<kchibisov> some users add themselves to it.
<pstch> oh right, but by "users" here I mean sandboxed apps, which would be running using defined privileges
<kchibisov> but sandboxed apps shouldn't have access to special protocols anyway.
<pstch> they won't
<kchibisov> then you don't have focus steeling.
<pstch> ah right. I was confused.
<kchibisov> And it's again a compositor policy.
<kchibisov> usually compositor gives focus to a newly created window.
<kchibisov> on the same workspace.
<kchibisov> basically how wl-clipboard.
<pstch> yes, this is the kind of issues I want to protect against
<kchibisov> only compositor can protect against that.
<pstch> as some existing protocols mandate that the compositor must not open new windows (or give them focus)
<pstch> hmmm that's very unclear
<kchibisov> I mean, why pinentry should prevent me to open window.
<kchibisov> sounds like I won't use this pinentry.
<pstch> because if a new window can be opened it would be able to steal input events from the pinentry ?
glennk has joined #wayland
<kchibisov> but I need a new window to get a password.
<kchibisov> because I don't know it.
<kchibisov> I can only fetch it, but I don't know my passwords.
<pstch> in this case, it's a disk decryption password that would not make sense to store on the system itself
bim9262 has quit [Ping timeout: 480 seconds]
<kchibisov> disks are decrypted usually early on.
<kchibisov> without any compositor running.
<pstch> not in this case
<kchibisov> unless you mount an encrypted disk.
bim9262 has joined #wayland
<kchibisov> but why wouldn't I store key in my keychain?
<kchibisov> Like I'm not sure what your use case is with focus steeling.
<kchibisov> if user typing manually they are not affected by it.
<kchibisov> so you likely trying to handle paste from clipboard focus stealing?
<pstch> because it's the key for a layered plausibly-deniable encryption system, and the password being stored somewhere it would break the plausible-deniability of the data
<kchibisov> So you type it manually?
<pstch> why would users typing manually not be affected by it ?
<kchibisov> because they don't see a responce that they type?
<pstch> at that point it's already too late
<kchibisov> one character leaking is too late for a massive password?
<pstch> yes
<pstch> because in my threat model, I need to protect the information of the existence of the password
<pstch> if one character leaks, we know that there is a password starting by a specific letter
<kchibisov> and how does it know whether it's a password or user just slammed a keyboard?
<pstch> then the user can be coerced to provide that password, thwarting the efforts made to preserve the plausible deniability of the data unlocked by the password
<kchibisov> Do you control compositor?
<pstch> yes
<kchibisov> then never give focus to anyone.
<pstch> well when the password prompt is not in use, I still want the user to be able to open new applications and let the compositor give them focus
<kchibisov> Define a layer-shell namespace where you never transfer focus to anyone.
<pstch> both the input-inhibition and screen-locking protocols work well for my use case, except the first one is obsolete, and screen-locking... locks the screen, which is problematic in case the password prompt crashes
<kchibisov> which will be a compositor policy.
<kennylevinsen> pstch: screen locking also explicitly renders no other content visible
<kennylevinsen> so rather than "screen locking does everything I need", it seems more like "screen locking does one thing (focus stealing) that I need" :)
<kchibisov> if it's "pinentry" your compositor never transfers focus out of it.
<pstch> kennylevinsen: yes, with screen locking the "dimmed background" needs to be implemented using a screenshot, indeed
<kchibisov> Like if you control all the stack it's already possible to do what you want.
<pstch> kchibisov: oh that's very interesting, I missed that feature of layer-shell
<emersion> a keyboard-interactive overlay layer surface will keep focus
<kchibisov> Can't you still with another overlay layer-shell?
floof58 has quit [Ping timeout: 480 seconds]
<pstch> kchibisov: in my case it's not a problem, as adversaries cannot use layer-shell
<pstch> right so I was just worried for nothing about focus stealing since layer surfaces already protect me from that
<pstch> thanks for your help everyone
<kennylevinsen> kchibisov: yes, other clients from a higher layer will get priority - or if you get in front of the current surface on the same layer
<pstch> (all this protocol/extensions definition and specification is absolutely beautiful to me)
<kchibisov> yeah, so you need some policy for such case as well.
<kennylevinsen> but yeah, layer-shell is meant to be privileged anyhow, and doesn't have protections against other layer-shell users
<kchibisov> but if they don't expose layer-shell it's likely fine...
manuel_ has joined #wayland
<pstch> is a protocol being privileged something that is defined in the protocols themselves ?
<pstch> or is i
<pstch> or is it compositor policy to define which protocols are privileged ?
<emersion> it's mostly compositor policy
<emersion> some protocols have a warning "hey btw this proto is pretty dangerous if free-for-all"
<kchibisov> Can you have a priv. protocol in xdg/wp namespace?
<pstch> layer-shell doesn't, unfortunately
<emersion> keyboard-shortcut-inhinit is… somewhat privileged but not really
<emersion> maybe some compositors want set_fullscreen to be privileged
<emersion> (as in, require something in the app manifest to allow fullscreen)
<kchibisov> Ah, there's no serial in those requests.
<kchibisov> So the app can fullscreen/unfullscreen in a loop.
floof58 has joined #wayland
<pstch> so I wager a possible future extension of security-context would be to allow specifying the set of protocols available in the context ?
AnuthaDev has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
<kennylevinsen> pstch: why would that be needed? the compositor controles what protocols it exposes
<kennylevinsen> and there's a mechanism to filter globals
<kennylevinsen> (wl_display_set_global_filter)
<pstch> because a sandboxing engine may want to run an app and prevent it accessing some protocols
<emersion> pstch: security-context is just about client identification, nothing more
<emersion> the compositor is free to implement access control on top
<pstch> ah, right
<pstch> but then the sandboxing policy of a sandboxing engine actually depend on the compositor in use
<kchibisov> Shouldn't compositor be in charge on how much to disable?
<pstch> it's always in charge of everything, but it can be useful to allow the sandboxing engine to have a say in that
<kchibisov> nah.
<pstch> the sandboxing engine knows that an app is supposed to use some of the privileged protocols, the compositor doesn't
<kchibisov> I mean, compositor just disables all of them.
<pstch> all protocols ?
<kchibisov> so you're stuck with just xdg-shell and that's about it.
<kchibisov> and core.
<kchibisov> like why would you advertise questionable protocols to untrusted clients.
<emersion> at some point would be nice to allow a sandboxed app to get some select privileged globals
<kchibisov> yeah, but it could be defined in compositor config.
<pstch> right, so what compositors do right now is to consider everything that is not core/xdg-shell a privileged protocol that is then not exposed in security contexts ?
<emersion> i wouldn't say that
<kchibisov> pstch: they can do whatever, it's just _they have a way_ to do that now.
<emersion> there are tons of non-privileged protos
<emersion> xdg-deco, presentation-time, etc etc
<pstch> kchibisov: the user of the system may want to allow a sandboxed app to access some protocols
<kchibisov> pstch: write a config inside compositor.
<kennylevinsen> pstch: that is possible, it's just now defined in the protocol how the compositor decides its policy
<kchibisov> if sandboxed && appid == XYZ => allow layer-shell.
<kennylevinsen> it could read a manifest, have its own config, etc.
<emersion> there are multiple options yeah'
<kchibisov> it's just the issue was to identify clients.
<kchibisov> not to restrict them.
<kchibisov> because if you can identify you can restrict.
<pstch> but this ties the sandboxing engine to a single compositor with a compatible policy, wouldn't that be problematic with flatpak for example ?
<pstch> I mean, how is security-context useful to flatpak if flatpak cannot rely on protocols not being available in the sandbox ?
<kennylevinsen> it does not tie them together - any sandbox just specifies what app it runs, and the compositor decides what apps are allowed what
<kennylevinsen> e.g., on sway I could have a config to allow specific apps screen share access
<pstch> well this kind of policy decision is usually the role of the sandboxing engine
<kennylevinsen> on gnome, you might have an option in the system config panel
<kchibisov> kennylevinsen: and then our screenshare goes via dbus side channel, so security context is useless.
<emersion> a lot of this hasn't been thought out yet
<pstch> kchibisov: not necessarily, dbus can be isolated as well, it's just more config
<kennylevinsen> pstch: not really, the final say is always in the service provider. Your sandbox might give filesystem access, but the filesystem enforces privileges. Sandbox gives wayland access, compositor enforces privileges, etc.
<kchibisov> pstch: you better not see what terminals in flatpak do.
AnuthaDev has quit []
bim9262 has joined #wayland
<kchibisov> Like they clearly shouldn't even exist there.
<kchibisov> yet we have a mechanism allowing them to 'run everything and access root'.
<kennylevinsen> pstch: and while sandbox config specifies what the application *wants*, compositor specifies what the user *grants*
<pstch> that depends on the system configuration, in this system I'm describing it would not be the case
<pstch> ^ kchibisov
<kchibisov> I just like this "No network" and "arbitrary perms" https://paste.rs/IZ4cU.png
<kchibisov> like this app can do network, gain root in child process, etc.
<kennylevinsen> one thing that one could consider is a way to request a not currently offered global from inside a security context
<kennylevinsen> if supported and confirmed by the user, the global is then advertised
<pstch> kennylevinsen: for that make sense, would'nt we also need a way to prevent global from being offered inside a security context
<emersion> better just always provide the global, and then ask questions when it's used?
<kchibisov> you already can do that.
<kennylevinsen> pstch: wl_display_set_global_filter
<pstch> that prevents from being offered everywhere, not inside a specific security context
<kennylevinsen> emersion: you could, but then each protocol would need an appropriate soft error I assume
<kchibisov> pstch: it's for the client.
<emersion> we've been trying to always allow compositors to deny requests in our protocols
<emersion> like layer shell can send closed immediately etc
<kennylevinsen> pstch: it is called each time a global is about to be offered to a client
<kennylevinsen> sway for example hides xwayland_shell_v1 from all clients except the xwayland instance it started itself
<kchibisov> kde does the same for input_method_v2 iirc.
<kennylevinsen> I wonder if clients would need to know that it failed due to privilege
<emersion> kennylevinsen: why would they?
<kennylevinsen> say you want to present the user with an appropriate error, or in case of layer shell fall back to an xdg window
<kennylevinsen> could be obscure for the user that the application just thinks the user immediately closed the window
<kennylevinsen> (well, in case of layer shell a normal close would likely be "output disconnected", but you get the idea)
* emersion shrugs
<emersion> hard to say anyways, none of this exists
<kennylevinsen> yup
i509vcb has quit [Quit: Connection closed for inactivity]
<pstch> taking a concrete example : if flatpak wanted to provide a specific permission for inhibiting keyboard shortcuts (access to keyboard-shortcuts-inhibit), it would indeed need a mechanism to ensure that the protocol is available in a security context it created
<pstch> but it would also need to know that this protocol is not generally accessible, otherwise the permission cannot actually be implemented
AnuthaDev has joined #wayland
<kennylevinsen> pstch: whether an application gets permission to inhibit keyboard shortcuts is arguably user preference rather than a sandboxing decision
<kennylevinsen> sandboxing is more about limiting which domains can be accessed, not enforcing fine-grained privileges (including user decisions) within those domains
<pstch> ah, yes
<pstch> still unfortunate for the pinentry in this sytem : it is needed that it is the only app having access to some protocols (the one enabling prompt impersonation)
<pstch> ones*
<pstch> of course it can be patched all of the compositors provided by the OS, but that's a lot of work
<emersion> hm i'm not following
<pstch> I'm trying to write an environment where the user can launch untrusted apps without fear of them impersonating the password prompt
<pstch> of course, I can also chooose to only provide compositors with definitions (of which protocol is privileged) compatible with my use-case
<emersion> you'll need to launch each untrusted app inside a sandbox, and then it's fine?
<pstch> emersion: well that's what is done, but the sandboxing engine cannot know that layer-shell is not available *in* the sandbox, since it is an implementation detail of the compositor and neither something specified in the protools themselve nor something that can be configured for specific apps
<pstch> (and this applies to all "privileged" protocols, not only layer-shell)
fmuellner has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
Fxzxmic has joined #wayland
bim9262 has joined #wayland
AnuthaDev has quit []
rasterman has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
Moprius has joined #wayland
bindu has quit [Remote host closed the connection]
bindu has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
Company has joined #wayland
manuel_ is now known as manwag
Fxzxmic has quit [Read error: Connection reset by peer]
Fxzxmic has joined #wayland
cmichael has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
fmuellner has quit []
<kchibisov> If compositor sends a wl_keyboard::keymap what happens to the modifier state it send before? Is it discarded?
<kchibisov> The situation we have is that user types with virtual keyboard, but then compositor could also do input itself. So you need to change keymaps between virtual-keyboard and compositor input.
bim9262 has quit [Ping timeout: 480 seconds]
<kchibisov> I think the modifiers must be resend for the focused client when you change keymaps, since they are tied to it?
bim9262 has joined #wayland
glennk has joined #wayland
nerdopolis has joined #wayland
manuel_ has joined #wayland
Moprius has quit [Remote host closed the connection]
bnason6 has joined #wayland
manwag has quit [Ping timeout: 480 seconds]
bnason6 is now known as bnason
maxzor has joined #wayland
Fxzxmic has quit [Read error: Connection reset by peer]
Fxzxmic has joined #wayland
Fischmiep has joined #wayland
Fxzx_mic has joined #wayland
Fxzxmic has quit [Ping timeout: 480 seconds]
bim9262 has quit [Quit: ZNC - https://znc.in]
bim9262 has joined #wayland
maxzor has quit [Ping timeout: 480 seconds]
Fxzx_mic is now known as Fxzxmic
Fxzxmic has quit [Read error: Connection reset by peer]
Fxzxmic has joined #wayland
Fxzxmic is now known as Fxzx_mic
Fxzx_mic is now known as Fxzxmic
sevz has joined #wayland
kts has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
maxzor has joined #wayland
privacy has quit [Quit: Leaving]
mohit8158 has quit [Quit: Ping timeout (120 seconds)]
bluetail has quit [Quit: Ping timeout (120 seconds)]
maxzor has quit [Ping timeout: 480 seconds]
rappet has quit [Remote host closed the connection]
trclst has quit [Remote host closed the connection]
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
rappet has joined #wayland
bluetail has joined #wayland
leon-anavi has quit [Quit: Leaving]
trclst has joined #wayland
bim9262 has joined #wayland
kts has quit [Ping timeout: 480 seconds]
sgm has joined #wayland
AnuthaDev has joined #wayland
manuel_ has quit [Quit: Leaving]
joe_ has joined #wayland
joe_ has quit []
flom84 has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
flom84 has quit []
Fxzxmic has quit [Quit: Konversation exit!]
flom84 has joined #wayland
bim9262 has joined #wayland
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
flom84 has quit [Remote host closed the connection]
tzimmermann has quit [Quit: Leaving]
AnuthaDev has quit []
lbia has quit [Quit: lbia]
fmuellner has joined #wayland
<DemiMarie> pstch: it sounds like you are trying to make something similar to Qubes OS. I’m a Qubes OS developer.
<DemiMarie> Qubes OS use X11 right now (technical debt) but will support Wayland eventually.
<DemiMarie> I recommend requiring layer shell support in the compositor. Otherwise, you won’t be able to do privileged UI (like custom menus) in a cross-compositor way.
lbia has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
<pstch> DemiMarie: yes, Qubes has been and is a big inspiration for this project
<DemiMarie> pstch: thanks! If I may ask, why not use Qubes itself? Also, have you heard of Spectrum OS (https://spectrum-os.org)?
<pstch> my main focus is on the integration of the ShuffleCake LPDS in a desktop environment
Moprius has joined #wayland
<pstch> yes, both were big inspirations for me
Moprius has quit []
<DemiMarie> pstch: ShuffleCake would be a useful addition to both, IMO. Though logs would need to be avoided.
<pstch> I didn't use Qubes because I wanted tighter integration between the applications sandboxes and the host system
<DemiMarie> Valid
<pstch> NixOS enabled me to quickly configure an immutable-root system, and allows the use of store overlays so that software can be reused through the layers while still maintaining PD
<pstch> SpectrumOS takes a much more radical approach to isolation (by defining a light custom TCB), that would make it a bit harder for me to experiment with practical uses of PD
<pstch> PD is one of these things that seem really useful at first, but I find that in practice it's not easy to actually make it work
<pstch> (the existence of a layer can leak through a quite formidable number of ways)
<pstch> right now it's more of a toy project to see how far it's possible to go in this direction (wayland-proxy-virtwl
<pstch> right now it's more of a toy project to see how far it's possible to go in this direction (AppVMs using wayland-proxy-virtwl + wayland security contexts + MergerFS + namespaced mounts and a custom GUI shell), but the practical long-term plan is to bring these changes to an existing project, so that the features can be used in a plausibly-deniable way
<pstch> (using a toy OS centered around PD decreases the plausability of the denial, while one can always say that they didn't know that their sandboxed OS uses PD-storage by default, for example)
<DemiMarie> This all seems really similar to SpectrumOS :)
<pstch> it is, but I think there are significant differences appearing, and I do a lot of compromises that SpectrumOS's dev chose not to make
floof58 has quit [Ping timeout: 480 seconds]
floof58 has joined #wayland
cmichael has quit [Quit: Leaving]
Kerr has quit [Quit: Bye.]
joe_ has joined #wayland
joe_ has left #wayland [#wayland]
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
Kerr has joined #wayland
privacy has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
sima has quit [Ping timeout: 480 seconds]
i509vcb has joined #wayland
Brainium has joined #wayland
sgm has left #wayland [#wayland]
nerdopolis has quit [Ping timeout: 480 seconds]
bim9262 has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
LaserEyess has quit [Remote host closed the connection]
LaserEyess has joined #wayland
___nick___ has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
glennk has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
fmuellner has joined #wayland
mvlad has quit [Remote host closed the connection]
bim9262 has quit [Ping timeout: 480 seconds]
rv1sr has quit []
bim9262 has joined #wayland
lsd|2 has joined #wayland
i509vcb has quit [Quit: Connection closed for inactivity]
bim9262 has quit [Quit: ZNC - https://znc.in]
bim9262 has joined #wayland
Brainium has joined #wayland
AJC_Z0 has joined #wayland
AJ_Z0 has quit [Read error: Connection reset by peer]
AJC_Z0 is now known as AJ_Z0
Guest7173 has quit [Remote host closed the connection]
AJ_Z0 has quit [Read error: Connection reset by peer]
AJ_Z0 has joined #wayland
cool110 has joined #wayland
cool110 is now known as Guest7377