You can use firejail or other sandoxes with any application packaged in any distribution.

I am well aware of it. It is an example of the traditional distribution workflow preventing a backdoor from landing into Debian Stable and other security-focused distributions. Of course the backdoor could have been spotted sooner, but also much later, given its sophistication.

In the specific case of xz, “Jia Tan” had to spend years of efforts in gaining trust and then to very carefully conceal the backdoor (and still failed to reach Debian Stable and other distributions). Why so much effort? Because many simpler backdoors or vulnerabilities have been spotted sooner. Also many less popular FOSS projects from unknown or untrusted upstream authors are simply not packaged.

Contrast that with distributing large “blobs”, be it containers from docker hub or flatpak, snap etc, or statically linked binaries or pulling dependencies straight from upstream repositories (e.g. npm install): any vulnerability or backdoor can reach end users quickly and potentially stay unnoticed for years, as it happened many times.

There has been various various reports and papers published around the topic, for example https://www.securityweek.com/analysis-4-million-docker-images-shows-half-have-critical-vulnerabilities/

They have to watch hundreds to thousands of packages so having them do security checks for each package is simply not feasible.

That is what we do and yes, it takes effort, but it is still working better than the alternatives. Making attacks difficult and time consuming is good security.

If there is anything to learn from the xz attack is that both package maintainers and end users should be less lenient in accepting blobs of any kind.

They do now have a verified tick in Flathub to show if a Flatpak is official

Jia Tan liked your comment

Without the traditional distribution workflow what prevents flatpaks to be full of security issues? Unfortunately sandboxing cannot protect the data you put in the application.

A speech-to-text / dictation system geared towards writing documentation.

I would love a text based ActivityPub client focused on meaningful discussions: threaded view, ability to follow threads or branches, highlight posts based on keywords.

This is debatable. The GPL allow redistribution of a given version of the software without additional restriction. If the user receives that copy knowing in advance that redistribution will lead to retaliatory actions this can be treated as an additional restriction.

Context is important. It’s possible that the software is distributed without any warning like that and that the termination of the support contract is done without citing the redistribution of previous versions as a reason. OTOH if the customers could prove that there’s widespread knowledge of the retaliatory termination that could be equivalent to a (non-written) restriction that is indeed incompatible with the GPL

Terminating a support contract, in itself, is not a GPL violation. The restrictions only affects the ability to receive future updates.

Edit: Red Hat indeed claims that no GPL violation is happening, yet they inform their customers that sharing updates leads to contract termination, which clearly breaches the GPL at least in spirit: https://sfconservancy.org/blog/2023/jun/23/rhel-gpl-analysis/