Indeed, Flatpak is its own repo. It might be more, or it might be less up to date than your favorite distro. Debian, for instance, was once notorious for packaging ancient versions (tho this has improved lately).
The saving grace of Flatpak is that it’s still better isolated.
If native Chrome decides to start emitting your crypto wallet’s privkeys as a part of its push for Better Customer Experience and More Precisely Targeted Ads, you won’t even know or notice it. This is technically very easy to do. It might make itself hard to dislodge by injecting itself into ~/.bashrc or the desktop environment’s startup system, or Systemd services.
If Flatpakked Chrome starts misbehaving, it might mine crypto on your CPU (wasting your electricity), or rent out all your disk space, or turn your PC into a node in a botnet, but it won’t have access to read or write anything other than your ~/Downloads. It’s also easy to uninstall, as it hasn’t had a chance to spread its seed.
Sorry for the long rant… What was the original question again? Outdated dependencies? Not an expert, but I hear the whole reason AppImage, Snap, FlatPak, Yarn locks and Go language was invented was to make it easier to have outdated dependencies. You never know what’s available in $Distribution, you depend on goodwill of maintainers of $Distribution to package your app and all deps. In AUR you can find older versions of Lua libs (lua51-filesystem) which someone had to add to make Mudlet run - Mudlet didn’t see fit to upgrade to the latest Lua.
While it is indeed somewhat true that a library (that many apps depend on) can be patched to fix a security issue, and apps won’t need to be rebuilt, it only works if the lib was a sufficiently recent version. And if the distro maintainer is more diligent than the Flatpak maintainer. Otherwise, the authors of said lib are going to ask you to upgrade to a supported version where that bug has already been fixed, defenestrating the whole argument-in-favor. This completely breaks down in NixOS, too, where your package would get rebuilt from source as inputs changed.
Indeed, Flatpak is its own repo. It might be more, or it might be less up to date than your favorite distro. Debian, for instance, was once notorious for packaging ancient versions (tho this has improved lately).
The saving grace of Flatpak is that it’s still better isolated.
If native Chrome decides to start emitting your crypto wallet’s privkeys as a part of its push for Better Customer Experience and More Precisely Targeted Ads, you won’t even know or notice it. This is technically very easy to do. It might make itself hard to dislodge by injecting itself into ~/.bashrc or the desktop environment’s startup system, or Systemd services.
If Flatpakked Chrome starts misbehaving, it might mine crypto on your CPU (wasting your electricity), or rent out all your disk space, or turn your PC into a node in a botnet, but it won’t have access to read or write anything other than your ~/Downloads. It’s also easy to uninstall, as it hasn’t had a chance to spread its seed.
Sorry for the long rant… What was the original question again? Outdated dependencies? Not an expert, but I hear the whole reason AppImage, Snap, FlatPak, Yarn locks and Go language was invented was to make it easier to have outdated dependencies. You never know what’s available in $Distribution, you depend on goodwill of maintainers of $Distribution to package your app and all deps. In AUR you can find older versions of Lua libs (lua51-filesystem) which someone had to add to make Mudlet run - Mudlet didn’t see fit to upgrade to the latest Lua.
While it is indeed somewhat true that a library (that many apps depend on) can be patched to fix a security issue, and apps won’t need to be rebuilt, it only works if the lib was a sufficiently recent version. And if the distro maintainer is more diligent than the Flatpak maintainer. Otherwise, the authors of said lib are going to ask you to upgrade to a supported version where that bug has already been fixed, defenestrating the whole argument-in-favor. This completely breaks down in NixOS, too, where your package would get rebuilt from source as inputs changed.