That would provide no benefits.
> Not to mention that container images are still mostly built by using regular packages
Yes, and because of the bundling they are a security disaster, as proven by many researchers:
e.g. https://www.infoq.com/news/2020/12/dockerhub-image-vulnerabi... https://www.darkreading.com/threat-intelligence/malicious-or...
Ok, say a wild CVE appears and it says libblip versions 1.3 through 2.0.4 have a severity-10 RCE vulnerability and should be patched ASAP. If the container images and flatpaks are not opaque, I presume you have a simple command that lists all vulnerable library versions that are present on all the machines you administer? And, subsequently, that you have an easy procedure to patch them all?
Users don't run CVE checkers [0], at best they reluctantly click on the update button. Of course the authoritarian evergreen auto-update thing is what actually works in practice.
For example as much as snap's UX sucks it does auto update by default.
[0] Though they could, as files in container images are trivially accessible, after all it's their purpose. Plus there are metadata based approaches: https://github.com/TingPing/flatpak-cve-checker (plus the Flatpak project already spends some energy on ensuring that the base image is chechekd against CVEs https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/jobs/18... ) of course duplicating this effort, and building a parallel world besides packages is not ideal
Just pretend that all Flatpak apps were statically linked. Would you have the same complaints? Or would you say that version $x of this app is also affected by the CVE?
In one situation you run apt update and another you run flatpak update.
Yes. The work required to backport and test security fixes in any library or any other component in every stable release train of a flatpak (or a fat binary) is simply not being done.
Most upstreams barely handle vulnerabilities affecting #head.
