A KDE Developer Is Experimenting With XDG-App Sandboxing

[phoronix]

Phoronix: A KDE Developer Is Experimenting With XDG-App Sandboxing

To date most of the XDG-App talk for application sandboxing has been within the GNOME camp, but it's great to see a KDE developer is now looking at supporting this important technology outside of the GNOME space...

http://www.phoronix.com/scan.php?page=news_item&px=KDE-XDG-App-Experimenting

[bkor]

From a talk with someone at DevConf.cz, a person mentioned that sandboxing KDE/Qt (forgot which) isn't so easy. It would need a dbus proxy because Qt exposes lots of things over dbus which other bits use. The person that worked on this raised this, but as changing how KDE/Qt uses dbus would break API and the use case is so unique (xdg-app), he didn't get much response on it. That conference is quite recent, so wondering if this is really sandboxed or not.

[mcirsta]

Honestly I don't care one bit about this feature and were it available I'd disable it. I don't want to sandbox my Linux apps, they should be secure enough. Windows apps for which I don't even have the source code for yes, those I would sandbox.

[winie]

Honestly I don't care one bit about this feature and were it available I'd disable it. I don't want to sandbox my Linux apps, they should be secure enough. Windows apps for which I don't even have the source code for yes, those I would sandbox.

So you're saying it's only needed for applications that you can't trust and you don't trust closed source apps.
But can you trust something just because it's open source? and how do you define secure enough?

[Bluesm@n]

Honestly I don't care one bit about this feature and were it available I'd disable it. I don't want to sandbox my Linux apps, they should be secure enough. Windows apps for which I don't even have the source code for yes, those I would sandbox.

Sandboxing is not mandatory for XDG-Apps. The more interesting part in this project is the ability to develop software that can run across all distributions.

[ssokolow]

Honestly I don't care one bit about this feature and were it available I'd disable it. I don't want to sandbox my Linux apps, they should be secure enough. Windows apps for which I don't even have the source code for yes, those I would sandbox.

You're much more confident in your apps than I am... but then, I'm a programmer. I have first-hand experience with how easy it is to introduce a serious bug entirely by accident, despite being an obsessive perfectionist. (Try writing a full-coverage unit test suite for something. You'll be surprised how many corner cases have serious bugs that you just happened to never trigger.)

This and Rust (a C/C++ alternative obsessed with memory safety... to the point of being very frustrating when you realize it was right and you were wrong about how safe something was) are long overdue.

[Serafean]

The way this is going to go is :
Sandboxed apps. Apps need some capabilities (read files, access to emails etc...).
Stuff will get exposed through IPC API (dbus?).
API will be the guardian of data. SeLinux like access control will be implemented on top of API.
Apps will always ask for all capabilities (because devs can't be bothered).
BFU will simply grant them.
AFAIK this is how it is done on Android. It sucks, I hate it but it seems the way we're headed.

[Awesomeness]

From a talk with someone at DevConf.cz, a person mentioned that sandboxing KDE/Qt (forgot which) isn't so easy. It would need a dbus proxy because Qt exposes lots of things over dbus which other bits use. The person that worked on this raised this, but as changing how KDE/Qt uses dbus would break API and the use case is so unique (xdg-app), he didn't get much response on it. That conference is quite recent, so wondering if this is really sandboxed or not.

Noooo, Gnome developers would never call something "cross desktop" and then do implementation and trials only with Gnome software…

[anda_skoa]

It would need a dbus proxy because Qt exposes lots of things over dbus which other bits use.

I doubt that Qt uses D-Bus internally, since that would not be possible e.g. on Windows.

That is most likely for desktop integration, e.g. calling D-Bus API provided by the shell, but that is the same as for e.g. GTK applications, so the xdg-apps environment will have solutions for that already.

Cheers,
_

[carewolf]

I doubt that Qt uses D-Bus internally, since that would not be possible e.g. on Windows.

That is most likely for desktop integration, e.g. calling D-Bus API provided by the shell, but that is the same as for e.g. GTK applications, so the xdg-apps environment will have solutions for that already.

Well DBUS possible to use on Windows and OS X, it is just not very useful, and Qt only uses it to talk to system services. You can of course use the Qt DBUS API to as an IPC system, Qt does not really start multiple processes on its own (except for QtWebEngine's Chromium process, but that uses Chromium's IPC system).