I'm not optimistic. Nobody ever even audits the binary contents of flatpaks on flathub (were they actually built from the source? the author attests so!). You don't really even need a fancy delivery mechanism like this backdoor had.
> Nobody ever even audits the binary contents of flatpaks on flathub (were they actually built from the source? the author attests so!).
IME/IIRC There aren't (or shouldn't be) any binary contents on Flathub that are submitted by the author, at least for projects with source available? You're supposed to submit a short, plain-text recipe instead, which then gets automatically built from source outside the control of the author.
> The Flathub service then uses the manifest from your repository to continuously build and distribute your application on every commit.
Usually the recipes should just list the appropriate Git-based URLs to get the source code, or, for proprietary applications, the official .DEBs. Kinda like AUR, but JSON/YAML. Easy to audit if you want:
Plus, if properly configured, Flatpak is supposed to securely sandbox every application anyway, although other systems it needs to be compatible with (E.G. X11) currently prevent that.
I agree there shouldn't be, and it would be fairly easy to check in the json file that it actually does what it "should" do in the build and nothing else, but have you ever actually checked? The only time I've ever even looked was when I wanted to change a build option for some reason, and that's not often.
And then the frequent use of git submodules makes it even worse: that's often a whole lot of code that even the author of the flatpak doesn't have control over.
Hm. You're right. I haven't. And I guess the entire problem is that we shouldn't just assume somebody else has.
The JSON manifest is a much smaller attack surface than uploading random binaries would be though. And the standardized build procedure should make it relatively easy to tell if something's out of the ordinary and should be raising eyebrows, or even automate much of it.
Maybe stick an `alias CheckFlatHub=` for a LLM prompt, or just some plain regexes, in `.bashrc`? Looking for fishing URLs and install commands sounds like a relatively simple problem, as far as security challenges go.
It seems like 75% of people are comfortable installing latest & greatest developer tools with `curl > bash`, so it's no wonder that flatpak and similar have momentum. Really, we desperately need a better sandboxing UX in linux.
"Sandboxing" is an understandable kneejerk reaction to the threat of untrustworthy software, but I think it's the wrong one - the classic "technical solution to a political problem". Software must compose. After all, how would sandboxing have helped here? You cannot sandbox sshd!
In fact we already have a very good solution, and it's simply the infrastructure of a typical Linux distro (replicated by package managers on other systems, such as F-Droid). It's quite an impressive feat really - a diaspora of independently trusted organizations, each with their own governance structures and PGP-enforced webs-of-trust, crafting public repositories of known-good software built from publicly published source code using publicly published build scripts, delivered to the user over strong encryption. On the whole this does an incredible job of keeping malicious or subversive software out, and we've all got so comfortable with just being able to "apt-get install <foo>" without worrying about malware that we've forgotten what a dangerous business running software from the internet used to be.
Which is why this xz attack is so unusual and surprising - it's like the police stopping an attempted murder in the nick of time in a sleepy crime-free town. As shocking as it is, we must ignore the cries of "something must be done" and resist the temptation to put up barbed wire fences all over our nice town.
I very much like distros, but unfortunately they are by nature slow to adopt new versions.
For example, Ubuntu 24.04 will ship without Deno. It will also ship with Cargo 1.75, which is too old to build Deno (there's some weird packaging issue). So, anybody who wants Deno on Ubuntu has to install it using either `curl | bash`, nix (which of course seems promising), or asdf (which I know nothing about). Most devs would choose curl|bash.
Why is Deno not packaged for Ubuntu/Debian? Because it's "hard", and it's hard in different ways for different distros (the debian ticket for this has sat without action for 2-3 years, and I think the Deno ticket a similar amount of time). Cross-distro solutions like flatpak (or nix) are 100% necessary if we are to get rid of curl|bash. But, the sandboxing story with flatpak/snap is currently pretty bad; apps just fail in mysterious ways if they try to access resources they're not allowed access to. Nobody wants Windows Vista, but it has been done reasonably well in various other OSes.
Sandboxing always struck me as missing the main point, since in nearly every case the only actually valuable data is the data the application is supposed to handle. Everything else I can basically reimage for free at any point.
I think Flatpak being a open source effort for a distro independent distribution channel is already pretty dope UX. Having this verification would sure be nice, but Verified publishers now being a thing is also an advantage over some other formats being used
That is better to me than installing a random binary. You can trivially audit the curl. Also, the curl > bash thing usually comes from the project maintainer (as in the case of Bun) vs some rando flatpacker.
Not if the bash part then turns around and installs a random binary, which is often the case. How do you know how thoroughly it's been audited by third parties? Does it have a security patch mechanism built into it?
