Posts by AdrianVovk@fosstodon.org
 (DIR) Post #B5zHOkHo7IpDlwhv3w by AdrianVovk@fosstodon.org
       0 likes, 1 repeats
       
       @zeenix @pid_eins I think there are valid things to criticize Rust for, and std's filesystem APIs is one of those things. Rust also eliminates a massive category of vulnerabilities and significantly improves security posture. Both can be true at once.Pretending that it's not a problem isn't going to help push projects like systemd towards a direction where we start using Rust. In fact, probably the opposite.
       
 (DIR) Post #B6dAGxFD7xZqHwEBU0 by AdrianVovk@fosstodon.org
       0 likes, 0 repeats
       
       @bb010g @navi @novenary @swick I expect that we'll have a dependency on systemd through systemd-appd at least. I also wouldn't be surprised if certain parts of the sandbox would have to be turned off if systemd services are unavailable. Of course it's hard to speculate about code that doesn't exist. I would say that you can probably expect similar things to what happened with GNOME's increased systemd dependency.
       
 (DIR) Post #B6dAGxcxheZlTbL9VI by AdrianVovk@fosstodon.org
       0 likes, 0 repeats
       
       @bb010g @navi @novenary @swick I would expect the need for polyfills of Varlink services, rather than code added upstream. Frankly, the ratio of support burden to people benefitting for non-systemd environments is simply too high for us to deal with upstream. Flatpak Next is an exercise in ultimately reducing the amount of code we have, and that means making stronger use of the dependencies we have available to usAgain all very preliminary thoughts about a codebase that doesn't yet exist
       
 (DIR) Post #B6fSD8V00ScctEbzua by AdrianVovk@fosstodon.org
       0 likes, 0 repeats
       
       Another day in Linux: everyone's too busy squabbling over init systems to organize against the real enemy: Microsoft, Apple, and GoogleLook I don't expect everyone to be strategic with their use of their own time. Do whatever you want. But to hurl vitriol at the people who are focused on making Linux win rather than on your chosen issue is not appropriateIf you're out here calling people bad faith corpo shills you should take a good hard look in the mirror and realize who your behavior helps
       
 (DIR) Post #B6iScYOpQf6Bvsj2ky by AdrianVovk@fosstodon.org
       0 likes, 0 repeats
       
       @valpackett @swick IMO security-context is closer to appd than to capabilities as you mean them. It's all about attaching the app's identity to the socket connection. The compositor knows who the app is and this can enforce policy on itappd is the same thing, but made generic. Instead of having N protocol-specific ways to attach an app's identity to a given socket connection, we build out a mechanism to query an app's identity given any connectionThus they're fundamentally the same thing
       
 (DIR) Post #B6iScYqpkXV5KjpPPM by AdrianVovk@fosstodon.org
       0 likes, 0 repeats
       
       @valpackett @swick Sounds like anti-capabilities :p. Holding the special socket takes away your capability to do privileged actions, rather than granting you the capability to do the actionsAnyway on a more practical note the Wayland compositor can do exactly the same thing with appd. Check if the incoming client is any sandboxed app, if yes hide the privileged protocols, if no don't. No need to look at all the metadata if you don't need it. But boy is it useful to have right there if you do
       
 (DIR) Post #BAJKiMG3Pj6V2Ho0zw by AdrianVovk@fosstodon.org
       0 likes, 0 repeats
       
       @ariadne This is pretty much exactly the goal of end-user GNOME OShttps://blogs.gnome.org/adrianvovk/2024/10/25/a-desktop-for-all/