Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

First fully sandboxed Linux desktop app

blogs.gnome.org

Post reply on HN
Print view View original

131–136 of 136 posts

Re: First fully sandboxed Linux desktop app

#131

Post by davexunit »

kayamon wrote: post #116
edohyiez wrote: post #59

Earlier quoted context omitted.

The main argument against this kind of bundling (apart from higher disk usage) is about security updates of libraries. E.g. if many applications ship their own copy of OpenSSL and another vulnerability is discovered, you have to update every application individually. And it is unlikely that all developers/vendors will provide such updates fast enough. But if all applications use the same OpenSSL that is managed by dp…

Right, but there's a difference between things that the OS is expected to provide (OpenSSL, GTK, etc) which the app should not bundle, and things like libpng which the app basically should bundle. e.g. Windows supplies KERNEL/USER/GDI as builtins, but doesn't supply libpng. Pretty much the whole point of an OS is to provide a guaranteed stable base. Anything that isn't guaranteed or stable should be bundled with the…

I would argue that you shouldn't bundle any libraries at all. As a package maintainer, I get real annoyed at projects that bundle things like libpng and don't provide an easy way to use an already built version.

Re: First fully sandboxed Linux desktop app

#132

Post by edohyiez »

kayamon wrote: post #116
edohyiez wrote: post #59

Earlier quoted context omitted.

The main argument against this kind of bundling (apart from higher disk usage) is about security updates of libraries. E.g. if many applications ship their own copy of OpenSSL and another vulnerability is discovered, you have to update every application individually. And it is unlikely that all developers/vendors will provide such updates fast enough. But if all applications use the same OpenSSL that is managed by dp…

Right, but there's a difference between things that the OS is expected to provide (OpenSSL, GTK, etc) which the app should not bundle, and things like libpng which the app basically should bundle. e.g. Windows supplies KERNEL/USER/GDI as builtins, but doesn't supply libpng. Pretty much the whole point of an OS is to provide a guaranteed stable base. Anything that isn't guaranteed or stable should be bundled with the…

GTK indirectly depends on libpng, so that probably wasn't the best example ;)

The thing is that Linux distributions traditionally don't make any difference between the OS and apps. Everything is split into relatively small packages. Like everything this model has some advantages (e.g. security updates) but also some disadvantages (it's harder to distribute/install software outside the distribution).

Re: First fully sandboxed Linux desktop app

#133

Post by greggman »

alexlarsson wrote: post #119
greggman wrote: post #92

Earlier quoted context omitted.

Maybe I'm missing it but I don't see how DRI is really sandboxing OpenGL. Note: I helped write the OpenGL sandbox in Chrome and it's certainly possible I don't know the details of DRI enough to understand how it sandboxes but I do know what we had to do to sandbox OpenGL in Chrome, that includes re-writing shaders since we can't trust the driver, clearing buffers since OpenGL doesn't and so you can read other process…

At the moment we grant all of /dev/dri, but long term we want only the render nodes accessible. That gives us no modesetting or DRM master capabilities, only rendering. It is true though that the drivers could very well have leaks in them, but the userspace sandbox is not the place to fix that, it is the drivers themselves. The intent is for the dri driver APIs to give guarantees about client separation, but I'm sure…

The drivers will never be fixed. Chrome doesn't trust them. It's not in their interest to fix them since sales are determined by performance not by security.

Re: First fully sandboxed Linux desktop app

#134

Post by digi_owl »

jbk wrote: post #2

It's really nice to see that happening, but every time I raised the subject with the Gnome team to see how we could run VLC in it, it's a no-go. Indeed, for a complete media player, I need: - access to files not directly opened by the user (playlists, MKV, DCP, MXF), - access (and unique probably) to raw devices read-only (DVD, AudioCD, Blu-Rays, webcams-v4l2, SDI, DVB), - direct access to raw audio output, - access…

Yeah, if this sandboxing is anything like the Storage Access Framework that Google introduced in Android 4.4, i'll pass...

Re: First fully sandboxed Linux desktop app

#135

Post by tonyedgecombe »

mempko wrote: post #58
edohyiez wrote: post #36

Earlier quoted context omitted.

No. Why would it? The user can still grant full access to the machine to applications they trust (like they do now). In fact, the traditional Unix security model (root vs. regular users) was about "not trusting the user" and securing the machine from the user. This "new" kind of sandbox is about the user being able to apply different levels of trust to different applications.

I can see this being useful for running proprietary and non free software. However, we should strive for all software to be free software instead. Because if I download free software, I have the community of developers to vouch for it. If I download proprietary software, I can't really trust it.

As a programmer who makes his living selling software I'm not particularly keen on "all software to be free".

Re: First fully sandboxed Linux desktop app

#136

Post by MaulingMonkey »

jbk wrote: post #127
MaulingMonkey wrote: post #106

Earlier quoted context omitted.

> Experience from OS X and WinRT is that they aren't powerful. And I'm not suggesting that the current state of things is sufficient. > What about mkv linked files or .mpc lossless complements? Or cue/bin complements? > What about m3u that have mp3, ogg and flac interleaved? In my case? As I don't use these formats, these are signs of bad things are happening (fishing for file format specific overflows in the parser?…

> In my case? As I don't use these formats, these are signs of bad things are happening (fishing for file format specific overflows in the parser?), and it is that simple. You don't use mkv or playlists with mixed content? You don't use subtitles? > the ability to grant ~/music/.../.{mp3,ogg,flac} [...] If it is, your codebase is suffering from some serious bitrot... I sympathize, but whitelisting isn't the problem a…

> You don't use mkv or playlists with mixed content? You don't use subtitles?

No MKV, mp3-only playlists, and then only subtitles I use are those embedded within the .avi / .mp4. I'll certainly admit I'm not VLC power-user.

> Your first idea is that our codebase is bitrot? Seriously?

You've chopped far too much context. I'm assuming your codebase supports neither whitelist in it's current form - reasonable, nothing needs it yet. That is my first idea.

I'm also meaning to imply that you're overstating how difficult it would be, if your codebase did support interacting with the standbox to request .mp3 whitelisting, to request other formats as well. That is my second idea.

My third* idea, at best, is that your codebase has bitrot. This is not me intending to slight you, your project, your contributors, your former contributors, or any of the choices involved. This is not me saying I am better than any of that. This is me, where half of my last job was dealing with bitrot, some caused by my own hand - trying to relate, while trying to identify where such a hypothetical, assumed to be serious problem, would actually lay.

> And you know, it's been a long time we don't rely on extensions for format detection.

You might not, but windows still does. Is this dialog gone?

http://cdn5.howtogeek.com/wp-content/uploads/2013/02/vlc-fil...

> Sorry, but your comment is very arrogant (limit insulting), and you speak of things you don't understand.

I apologize if it came off that way, and for touching a nerve. But please understand me. The sin you're looking for is Envy, not Arrogance, within me if you've had that leisure - of dealing only with pristine codebases without serious problems.

Post reply on HN