Live data from Hacker News

Sovereign Tech Agency invests €500k in Flatpak

modal.cx

31–40 of 144 posts

Re: Sovereign Tech Agency invests €500k in Flatpak

#31

My trust in Flatpak diminished after installing the book reader Calibre and finding that despite the sandboxing Calibre was given blanket access to my drive. Apparently a quirk of the developer behind Calibre insisting upon it. No warnings or communication of the exception were given. All trust I had in Flatpak was eroded from that moment on. Curious about the podman options or similar. Having desktop apps in a conta…

> No warnings or communication of the exception were given. All trust I had in Flatpak was eroded from that moment on

This is just wrong. Clients like the flathub website or gnome software show the risk posed by wide ranging access to local files, but Flatpak has to support legacy applications that don't use portals yet and thus they can't block applications having those permissions

https://flathub.org/en-GB/apps/com.calibre_ebook.calibre

> calibre is potentially unsafe

> Full file system read/write access

> Can read and write all data on the file system

Re: Sovereign Tech Agency invests €500k in Flatpak

#32
A lot of Flatpak's design is a great prototype, but it's somewhat worrying (for the ecosystem in general) that this was taken as a final design and being pushed out in all directions.

Portals are just a terrible design for a security boundary: all interfaces clobbered up into one huge daemon, which also deals with a lot of the internals of Flatpak/Snap. If you want your sandbox to use portals, you can't, because it relies on internals of both of these sandboxing mechanisms. The devs have confirmed they won't implement an API for other sandboxing engines to integrate with them.

The whole system also deeply intermixes the package manager and sandboxing engine — to the point where you can't use the sandboxing engine with your favourite package manager, and you can't use the package manager without the sandboxing engine.

It seems that the mentality is: all other distributions are irrelevant, all other sandboxing engines are unsupported.

And then desktop applications start having first-class integration with Flatpak, and start having issues everywhere else.

You already need to set up Flatpak's daemons for using some features in Firefox (like screen sharing, where the native interfaces aren't supported), and it seems that the plan is to do the same for other features.

Re: Sovereign Tech Agency invests €500k in Flatpak

#33
post #8
post #2

I never understood why a program installed in Flatpak is not just a directory on disk. When you install something via Flatpak, it still changes data in god-knows-what places on my disk. And the software itself has read/write access to god-knows-where on my disk. The answer is probably "convenience and efficiency". But I would much prefer a "An application is a directory and by default cannot access anything outside o…

> But I would much prefer a "An application is a directory and by default cannot access anything outside of that directory" approach. That makes sense if the application is the only program that needs to interact with the data. For example: If you have a drawing or photo editing program. You might have downloaded an image from the internet or from your camera. Then you make some edits. Afterwards you want to send the…

Can't it request and be granted that permission, transparently to the app?

E.g. the app does EnumerateDirectories("~/photos") then without requiring modification to the app, the call is interecpted, the user is presented with a permission request UI, and once granted, the app continues?

At least that's how I'd thought it would work. Perhaps this isn't viable?

Re: Sovereign Tech Agency invests €500k in Flatpak

#34
post #19
post #2

I never understood why a program installed in Flatpak is not just a directory on disk. When you install something via Flatpak, it still changes data in god-knows-what places on my disk. And the software itself has read/write access to god-knows-where on my disk. The answer is probably "convenience and efficiency". But I would much prefer a "An application is a directory and by default cannot access anything outside o…

By default, software has a sandboxed location that is exposed to the host in `~/.var/app/[APP]`. Most software needs access to user files. Since most applications aren't written with Flatpak in mind, they will attempt to load files using their own file browser, meaning that for the application to function at all it needs to have access to swaths of extra data. You can see what data the application can access either v…

> Note that you can't magic your way out of this. You can't eg. wait for the program to request access to a file before displaying a "Program wants access to this file. Allow/Deny" because the program doesn't know if this file exists, and the user wouldn't be able to navigate to it via the program's bespoke file browser since it doesn't have access to directories or their contents.

What stops the OS from granting access to read the directory structure by default, but not read/write its contents? It’s imperfect, but better than the alternative.

Also, macOS does it somehow, or at least seems to. I get the prompt you’re describing all the time as of a few years ago (I’m fuzzy on when it started)

Re: Sovereign Tech Agency invests €500k in Flatpak

#35

A lot of Flatpak's design is a great prototype, but it's somewhat worrying (for the ecosystem in general) that this was taken as a final design and being pushed out in all directions. Portals are just a terrible design for a security boundary: all interfaces clobbered up into one huge daemon, which also deals with a lot of the internals of Flatpak/Snap. If you want your sandbox to use portals, you can't, because it r…

In the beginning, Flatpak was seen as savior for the Linux desktop ecosystem by making more applications available for more distributions, possibly packaged by the upstream maintainer, but they didn't realize that Flatpak resp. Flathub are actually just another distro with its own builds, repository, package manager, package format and community.

On the security side it was also seen as the only way forward, but it's just opt-in sandboxing. That's still possible to achieve without flatpak by using the underlying sandboxing tool (bubblewrap), but not as user friendly as using the flatpak provided defaults.

Re: Sovereign Tech Agency invests €500k in Flatpak

#36
post #8

Earlier quoted context omitted.

> But I would much prefer a "An application is a directory and by default cannot access anything outside of that directory" approach. That makes sense if the application is the only program that needs to interact with the data. For example: If you have a drawing or photo editing program. You might have downloaded an image from the internet or from your camera. Then you make some edits. Afterwards you want to send the…

Can't it request and be granted that permission, transparently to the app? E.g. the app does EnumerateDirectories("~/photos") then without requiring modification to the app, the call is interecpted, the user is presented with a permission request UI, and once granted, the app continues? At least that's how I'd thought it would work. Perhaps this isn't viable?

It’s how sandboxed Mac apps work today.

Re: Sovereign Tech Agency invests €500k in Flatpak

#37
post #13

Waste of money. "For Modal, a robust app sandboxing story is essential to creating a Free Software OS that is competitive with modern mobile platforms." Why? Focus should be desktop, not mobile. We have enough mobile stuff that creeped in already.

This is focus on desktop. They just want as good app sandboxing as it is on mobile platforms.

Re: Sovereign Tech Agency invests €500k in Flatpak

#39
I’m thankful for the STF. Germany is one of the few countries doing something. But it is not strategic software-development.

    * They don’t employ software-developers. No safety for the developers. No control over developers.
    * It is only temporary.
    * The projects need to apply repeatingly for funding. Wasting time and resources and chausing worries.

The how planet needs Linux, BSD, cURL, ffmpeg, Flatpak. We need to ensure that this work for the people.

We feed for 30 years constantly money into monopolies. We shall feed the next century constantly money into things the people need.

Many developers of Linux and GCC are paid. Because companies decided it is necessary.

Re: Sovereign Tech Agency invests €500k in Flatpak

#40
post #34
post #19

Earlier quoted context omitted.

By default, software has a sandboxed location that is exposed to the host in `~/.var/app/[APP]`. Most software needs access to user files. Since most applications aren't written with Flatpak in mind, they will attempt to load files using their own file browser, meaning that for the application to function at all it needs to have access to swaths of extra data. You can see what data the application can access either v…

> Note that you can't magic your way out of this. You can't eg. wait for the program to request access to a file before displaying a "Program wants access to this file. Allow/Deny" because the program doesn't know if this file exists, and the user wouldn't be able to navigate to it via the program's bespoke file browser since it doesn't have access to directories or their contents. What stops the OS from granting acc…

> What stops the OS from granting access to read the directory structure by default, but not read/write its contents? It’s imperfect, but better than the alternative.

Not much, it is entirely possible to do. But it also does have security implications like exposing SSH keys and such, which is why something like this isn't the default for flatpak. Though IIRC in a recent GUADEC or LAP(? too many talks recently happened) there were talks about moving "flatpak v2" to be either fully sandboxed and portal usage is a hard requirement or having the app basically be entirely unconstrained with probably only /usr/ or /opt/ mounted over or something like that (I think).

Post reply on HN