<qyliss>
Re cage, wayland-virtfs: It's possible, but I need to look into it more. I'm guessing that they currently, for example, share the clipboard. That would be Extremely Not Okay in Spectrum, and I don't know how easy changing that would be.
<qyliss>
Hopefully it would be easy enough, but I don't know for sure.
<hyperfekt>
Read it! Thanks for the update c:
<hyperfekt>
qyliss: I'm not sure the post makes sufficiently apparent that virtio wayland and virtfs are two distinct things
<qyliss>
Oh shit I got the name wrong didn’t i
<qyliss>
I meant to link it too
<puck>
qyliss: so like. the clipboard probably transfers over wayland, so your compositor (which would be a pretty trusted piece of software anyways) would have to be aware of this, and could have a "clipboard transfer" feature that allows you to see the clipboard of each window
<puck>
oh actually. not sure wayland clipboards work over virtio-wayland?
<puck>
the way the format works is that you create a wl_data_source, and the receiving end gets a wl_data_offer; the two can then transfer arbitrary (?) data over a file descriptor. This is also how drag&drop works
<qyliss>
ooh
<qyliss>
that sounds good
<qyliss>
oh
<qyliss>
well then
<qyliss>
lol
<qyliss>
Anyway, not sure I actually have a good link for virtio-wayland, so I guess I'll just remove the link and fix the name.
<qyliss>
Fixed.
<hyperfekt>
Not sure. According to the docs a file descriptor is used to transfer the data so it needs some extra support to copy and translate that between host and guest. I would assume the Googlers either already implemented it or will do so soon because they would probably like clipboards to work. 🤷♀️
<puck>
this is pretty dependent on compositor support, so i bet a compositor could maybe limit transfer to e.g. text/plain, and "sanitized" image files?
<qyliss>
that would be rad
<puck>
hyperfekt: yeah, I think virtio-wl gets you basically file descriptors with slightly arbitrary settings, but this is not quite clear to me rn
<qyliss>
would be amazing if we could implicitly do something like Qubes PDF rasterization in a DispVM. Would be a big step up.
<samueldr>
yes, tell the http server it should serve it
<samueldr>
(doing it)
<qyliss>
hyperfekt: veeery interesting. Will keep an eye on it. Could be useful to us.
<hyperfekt>
qyliss: I think the real challenge is making file descriptors between VMs work. I don't know much Linux kernel stuff yet. But the idea of strict site isolation + per-process VMs elates me :b
<qyliss>
Yeah file descriptors
<qyliss>
Between VMs could cause us trouble
<qyliss>
If that’s how clipboards work
<samueldr>
qyliss: should work now, my server will generate let's encrypt certs so don't be too spooked in the cert transparency reports :)
<samueldr>
though there's one issue I need to fix: the server doesn't know it's serving from another domain name, I think it all ends up being localhost due to proxypass
<samueldr>
Shell: it could also be something about using a unix domain socket instead of tcp socket
<samueldr>
done; the domain name it sees, with `server unix:/.../....sock` is whatever `upstream NAME {}` is set
aranea has joined #spectrum
<puck>
<qyliss> If that’s how clipboards work <- it's just "feed the file descriptor your mime type-defined content, read it out the other end" -- so letting everything go through a local file descriptor would be fine