Announcement

Collapse
No announcement yet.

Snaps & Ubuntu Core Desktop Talked Up At FOSDEM 2024

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Daktyl198
    replied
    Originally posted by ssokolow View Post

    [citation needed]
    Flatpaks are the same age as snaps (a decade old!) and have almost all of the same issues that snaps have. The only area Flatpaks are better are speed (and they’re still slower than standard packages, sometimes by a lot) and slightly better permission control.

    Red Hat has just managed to brainwash people into saying that Ubuntu is a bad company while RH are the magical saviors of Linux, so anything Ubuntu is bad and anything RH does is good.

    Tell me when Flatpaks are stable (don’t introduce bugs) and are also ACTUALLY sandboxed, since 95% of applications distributed as Flatpaks break out of the sandbox by default because of point 1: bugs.

    Leave a comment:


  • Artim
    replied
    Originally posted by user1 View Post
    Yes, of course I know about containerisation / sandboxing, but as you can see from the other comments, it's still subpar in both SNAP and Flatpak for various reasons. For example, some apps need to have lax permissions, because otherwise they won't work properly. I know that at least Flatpak strives to use portals as much as possible instead of raw filesystem access, but AFAIK, at this stage not all apps are able to utilise them. Maybe in the far future all Flatpak apps will finally be adapted to use portals. Also, instead of the current state of permission management, it needs a dynamic permission system, similar to what Android already has.
    Still you aren't running anything as root. With the traditional distribution methods, the package manager runs as root, and at least in .deb packages, probably in others too, you can have all sorts of scripts running at install time. With distro packages you can be quite sure that they are safe, but lots of stuff can only be installed from third parties. With them trust isn't always given, hence the example. So whatever script would be put into a flatpak, it can only run with the permissions of the Flatpak, never with root permissions (sure, you can run/install Flatpaks and probably AppImages and Snaps as root, but the point is that you usually don't, they are primarily designed to be installed only user wide, not system wide).

    Leave a comment:


  • user1
    replied
    Originally posted by Artim View Post
    I doubt security in this context is the main benefit, but in another. Distributions - and especially Debian is known to do so - can enforce sensible best practices. E.g. they will force the app to have its configuration in /etc, not just some stupid location deep inside /var or /usr nobody usually checks
    Yes, I know about this, which is why I disagree with the statement that "a packager will never be smarter than the developer" that was mentioned earlier. A developer may know his own app better than the packager, but that doesn't necessarily mean he knows or cares about the best practices.

    Originally posted by Artim View Post
    But Flatpak does have one big advantage, security wise but also trust wise - snap does too, but to a lesser degree. Flatpaks are containerized, they can't access the system - e.g. not replace other programs, like MS (I think) was caught a few years back with their deb repo - and you can very easily manage permissions with Flatseal. E.g. WPS Office sometimes has best MS Office file support, yet I'd never let some shady chinese Office run wild on my system. With the Flatpak version, I just remove internet access and be done with it.
    Yes, of course I know about containerisation / sandboxing, but as you can see from the other comments, it's still subpar in both SNAP and Flatpak for various reasons. For example, some apps need to have lax permissions, because otherwise they won't work properly. I know that at least Flatpak strives to use portals as much as possible instead of raw filesystem access, but AFAIK, at this stage not all apps are able to utilise them. Maybe in the far future all Flatpak apps will finally be adapted to use portals. Also, instead of the current state of permission management, it needs a dynamic permission system, similar to what Android already has.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by Artim View Post

    To be fair, they have one point for them, snaps can be used on servers and there is the possibility of auto updates - although enforced. If Flatpaks would open up to services and what not, it might be a viable use case for some edge case software otherwise not available through repos (or maybe only through the likes of AUR, but who's insane enough to run Arch on a server). Right now you can only use snap, which is just bad. Also the containerization of Flatpak might be a good alternative to docker containers if you don't want to containerize everything but only a few apps.
    1. You can use Flatpak for containerized non-desktop stuff... it's just not something they promote as a use-case they want to optimize for. (eg. Some CLI tools for flatpak package maintainers, such as org.freedesktop.appstream-glib are distributed through Flatpak... they just only show up in flatpak search, not the Flathub web UI.)
    2. If you don't need containerization (i.e. If you want an equivalent to unconstrained snaps), that's what OSTree via something like rpm-ostree is for. Flatpak is OSTree plus containerization and XDG Portals.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by TheJackiNonster View Post
    I've also made the experience with a flatpak from me, where I restricted the permission requirements to not be marked as "unsafe" on the Flathub page, that a user wasn't able to use it as intended anymore without manually adjusting permissions. The permission systems for both flatpaks and snaps are still horrible in my opinion because you either have to much access or too little - especially when it comes to filesystem access.
    "Manifest permissions" for the filesystem are considered a necessary evil for breaking the chicken-and-egg dilemma of growing an ecosystem and the plan is to treat them as deprecated and encourage packagers to not use them as more portals are developed for various niches currently unsatisfied, such as needing to access the sibling .bin/.ogg/whatever when you open a .cue or needing access to everything under ~/src/foo when you open ~/src/foo/foo.ide_project.

    The network permissions are a single on/off toggle because they're still trying to find/advocate for a solution for doing it in a more granular way that doesn't require running flatpak run <appID> as root.

    The "grant all under /dev" permission is a proxy for "we're still trying to work around libudev considering the API that, architecturally, must straddle the host/sandbox boundary (if we want working input device hotplug detection) to be internal and unstable. (Their plan to work around that is to make a USB device portal so libudev can be fully on the host side, and then add support for it to SDL and other gamepad-using things.)

    Continued uptake of Pipewire will solve needing "grant all under /dev"​ for webcams.

    etc. etc. etc.

    TL;DR: Odds are, they don't like it either and are being held back by API limitations lower in the stack that they're still trying to negotiate solutions to.
    Last edited by ssokolow; 07 February 2024, 10:03 AM.

    Leave a comment:


  • Artim
    replied
    Originally posted by Alexmitter View Post
    I love how Canonical just has to double down on a double down on a double down. Years of wild ideas, and still the fundamental issues of snap aren't addressed at all, at best worked around with changes on the app.
    To be fair, they have one point for them, snaps can be used on servers and there is the possibility of auto updates - although enforced. If Flatpaks would open up to services and what not, it might be a viable use case for some edge case software otherwise not available through repos (or maybe only through the likes of AUR, but who's insane enough to run Arch on a server). Right now you can only use snap, which is just bad. Also the containerization of Flatpak might be a good alternative to docker containers if you don't want to containerize everything but only a few apps.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by Daktyl198 View Post

    I have bad news for you if you’re a fan of Flatpaks, buddy.
    [citation needed]

    Leave a comment:


  • Sesivany
    replied
    Originally posted by TheJackiNonster View Post

    I made a different experience. On Flathub I never received any hint to lower permission requirements. Neither I did notice anyone checking my app for changes after initial verification. With snaps on the other hand my apps are continuously verified manually which I get notified about after a new build and they automatically notify me about outdated dependencies in my apps. Flathub doesn't seem to care at all about deprecated dependencies which is why a lot of apps probably contain known security issues inside.
    Good for you that you never hit it. A manifest of every flatpak goes through a fairly thorough automated checks before every build and if the criteria is not met, the build is blocked. Also I do receive notifications about outdated dependencies or even pull requests from Flathub community.

    Leave a comment:


  • Artim
    replied
    Originally posted by user1 View Post

    During the last 1.5 years or so, I've heard such propaganda a lot from advocates of both Snaps and Flatpaks. You know, about all the benefits of getting the software directly from the developer and that repackaging it for different distros is a waste of time.

    Recently, I've scrutinised the distro packaging process (previously I didn't know at all about how packages are made) and it made me appreciate traditional packages like never before. Particularly, I like the fact that packaging provides additional wall of security which you don't have if you get the software directly from the developer. What if the developer makes his software do something malicious and no one catches it before it gets to the user?
    I also like the fact that at least some distros like Debian work closely with upstream. For example, Debian packagers may find bugs and report them to upstream. One thing I dislike about open source software in general is the over-reliance on users for reporting bugs. At least with distros like Debian, the packagers essentially also participate in bug reporting, not just the users. Again, something that's impossible if you get the software directly from the developer.
    I doubt security in this context is the main benefit, but in another. Distributions - and especially Debian is known to do so - can enforce sensible best practices. E.g. they will force the app to have its configuration in /etc, not just some stupid location deep inside /var or /usr nobody usually checks. Also, they can force an app to put dependencies into packages (if there are any that aren't yet). The latter enables security patches by just patching the dependency. The first one isn't relevant with flatpaks, only with snaps, as Flatpak is pretty much useless on a server with mostly CLI usage. With snap and flatpak it's up to you if you include dependencies into your monolithic software.

    But Flatpak does have one big advantage, security wise but also trust wise - snap does too, but to a lesser degree. Flatpaks are containerized, they can't access the system - e.g. not replace other programs, like MS (I think) was caught a few years back with their deb repo - and you can very easily manage permissions with Flatseal. E.g. WPS Office sometimes has best MS Office file support, yet I'd never let some shady chinese Office run wild on my system. With the Flatpak version, I just remove internet access and be done with it.

    Leave a comment:


  • Sesivany
    replied
    Originally posted by user1 View Post
    I've looked at the sandbox permissions of a lot of Flathub apps and I have to say many of them are too lax. Like why in the world does LibreOffice and image viewers have full filesystem read/write access when it should at the very least be limited just to your home directory? Maybe the fact that your app has been 3 years on Flathub is most likely the reason why at some point someone scrutinised your app and asked you to remove unnecessary permissions.
    There are now over 2400 apps on Flathub, which is a lot, so I think there's no way someone constantly sits and manually checks if every single app has proper permissions.
    It's an automated test that every flatpak has to pass before the build. You can get an exception, but you have to request it and explain why the permission is needed.

    Leave a comment:

Working...
X