[ajross]

> Almost all popular apps on Flathub still come with filesystem=host or filesystem=home permissions

This is way oversold. That's true of "all popular apps" because those apps are legacy things written to run in the host filesystem and store state to the home directory. And there are good reasons to want to do this.

That's not an indictment of the technology, that's just saying that Thunderbird or whatever hasn't been ported to run in a sandbox yet. I mean, yeah. But why complain about the perfectly good sandbox technology and not the app?

Edit: this one is even worse:

> A perfect example is CVE-2019-17498 with public exploit available for some 8 months. The first app on Flathub I find to use libssh2 library is Gitg and, indeed, it does ship with unpatched libssh2.

So, that's a ssh client vulnerability. And indeed, you absolutely want your apps to ship current binaries with vulnerabilities patched, and this app didn't. So isn't it a good thing you deployed that app in a sandbox? Again, why complain about Flatpak when it likely is what's saving you from a client vulnerability?

[masspro]

Devil’s advocate on the last point about the libssh vuln: it would be in a sandbox, but if you do take that with the commentary that most apps have large areas of sandboxing disabled, then the sandbox isn’t effective in stopping exploitation of a vulnerability and the flatpak model has increased the chance of there being a vuln in the first place because bundled outdated deps are the natural end state of a flatpak without constant intervention.

[nxicvyvy]

Flatpack etc sandbox is shoehorned into a system that doesn't expect it.

You can't expect apps to migrate to something that a) promises to support the existing model, and b) also support the existing model.

What these app package formats should be doing is coming up with a new model and then asking people to support their model as if it were a new platform.

Similar to how thunderbird supports Linux Mac and windows.

That might actually result in both an access model that makes sense to end users and actually creates an app package formats that isn't full of trade offs and work arounds.

[yjftsjthsd-h]

>> The first app on Flathub I find to use libssh2 library is Gitg and, indeed, it does ship with unpatched libssh2.

> So isn't it a good thing you deployed that app in a sandbox? Again, why complain about Flatpak when it likely is what's saving you from a client vulnerability?

Because it's not!

https://flathub.org/apps/org.gnome.gitg

> gitg is potentially unsafe

    Full file system read/write access
    Can read and write all data on the file system
    User runtime subfolder keyring
    Can read and write all data in the directory
    Network access
    Has network access

Now instead of the lack of useful sandboxing reducing you to the same absence of protection as native distro packages, you're worse off.

[EdwardDiego]

Yeah, complaining that an IDE wants access to your FS is odd. Like, that's where the files are.

[yencabulator]

An IDE should get access to the specific directory that contains the project, not everything.

[EdwardDiego]

Okay. But I have more than one project. And sometimes, I want to use my IDE to open /tmp/foo.json that I just curled out.

I feel that users like me are far more prevalent than users who want to rigorously audit every path the IDE may want to open.

[brennoflavio]

The article complains about saying that the app is sandboxed. I don't want my ide to be sandboxed anyway, so just flagging that in the store should be enough.

Vscode on snap runs unconfined for example, that's explicit

[yencabulator]

The "portals" mechanism can dynamically allow access to anything you pick in a file open dialog, while helping the app sandboxed.