Appimages totally suck, because many developers think they were a real packaging format and support them exclusively.
Their use case is tiny, and in 99% of cases Flatpak is just better.
I could not find a single post or article about all the problems they have, so I wrote this.
This is not about shaming open source contributors. But Appimages are obviously broken, pretty badly maintained, while organizations/companies like Balena, Nextcloud etc. don’t seem to get that.
AppImage is great at what it does - provide an ultra-low effort packaging solution for ad-hoc app distribution that enables a developer who won’t spend the time to do rpm/deb/flatpak packaging. There are obvious problems, security and otherwise, that arise if you try using it for a large software collection. But then again some people use things like Homebrew and pacstall unironically so …
Great, now tell me why your appimage is complaining about not having some .so file on my system
The developer made extra low effort and missed a lib. 😅
No, the problem is more subtle, the developer assumed I have the same libs in the same locations as a mainstream distro like Ubuntu, but I do not
I actually have several versions of each library in different hashed folders (my distro does this) and I just steam-run normal Linux executables
Except I can’t do that when using this appimage thing so it doesn’t directly work on my system
Well, theoretically if the developer had bundled the libs they assumed would be present on Ubuntu into the AppImage, maybe it would have worked. Would it be larger? Sure. 😂
Thank you for mentioning this! Unfortunately a quick search on the internet didn’t yield any pointers. Would you mind elaborating upon the security problems of Homebrew(/Linuxbrew)? Thanks in advance 😊!
Post about homebrew by Jorge Castro
I am not sure how secure it is.
I am aware that Homebrew has become the go-to solution for installing CLI applications on Bluefin. Which is exactly why I feel compelled to ask the question in my previous comment.
Btw, I don’t really understand why you felt the need to share Jorge Castro’s blog post on Homebrew? AFAIK it doesn’t go over any security implications. Sharing the article would only make sense if Jorge Castro is regarded as some authority that’s known to be non-conforming when security is concerned. While I haven’t seen any security related major mishaps from him or the projects he works on, the search for the CLI-counterpart to Flatpak seemed to be primarily motivated by facilitating (what I’d refer to as) ‘old habits’; which is exactly what Homebrew allows. It’s worth noting that, during the aforementioned search process, they’ve made the deliberate choice to rely on Wolfi (which is known for upholding some excellent security standards) rather than Alpine (which -in all fairness- has also been utilized by Jorge for boxkit). IIRC, people working on uBlue and related projects have even contributed to upstream (read Distrobox) for patches related to Wolfi. So, there’s reason to believe that the uBlue team takes security seriously enough to work, contribute and deliver on more secure alternatives as long as it doesn’t come with a price to be paid by convenience. Which, in all fairness, is IMO exactly why Homebrew is used for in the first place (besides their recent utilization of technologies that have similarities to the ‘uBlue-way’ of doing things)…
I’m not a security expert but I do know that the Homebrew is working with openssf on security: https://openssf.org/blog/2023/11/06/alpha-omega-grant-to-help-homebrew-reach-slsa-build-level-2/
Boxkit predates wolfi so it’s still alpine, I’ll probably replace it at some point but most of the forks of boxkit are because people want the premade github actions and they end up replacing it with whatever distro they want anyway. The wolfi connection is because I know the people who work there (including a ublue maintainer) and we have similar goals/ideas on how linux distros should be put together. My ideal dream is a wolfi userspace systemd-sysext on top of fedora base, then we can have our cake and eat it too!
We’re not security experts but lots of us work in the field and that gives us access to peer review from experts when we set things up. We sign every artifact with sigstore so users can verify that the code used in github is what’s on their image, that sort of thing. And most of our practices utilize CNCF governance templates that lots of other projects use.
I learned quite some things from this talk
https://youtube.com/watch?v=4WuYGcs0t6I&t=456
Appimages are damn broken
I mean, I’m not saying they aren’t. I think the original argument is valid. I just think they’re better than the alternative, which isn’t Flatpak but self-extracting .sh files.
Yes thats true. But that talk specifically mentioned the horrible security practice of appimages, and that they dont run everywhere at all
No argument. The security aspect is something that seemingly a lot of people in this thread don’t get. The some-person-creates-a-package-I-install model works as reliably as it does without sandboxing only when that person is a well known trusted individual or group. For example the Debian maintainers team. It’s a well known group of people who are trusted due to their track record to not produce malware-ridden packages intentionally or unintentionally. That is the line of defense you got. If you remove that, you end up in download-random-removed-on-Windows land in regards of security.
What’s worse, this extends to the bundled libraries. Unlike central systems with shared libraries like Debian, bundling libraries means that the problem extends to the sources of those libraries! Package A and package B both include libjpeg-v1, it’s got a remote exploit gaping hole. Developer A has time to follow CVEs and updates theirs. Developer B doesn’t or has moved on. The system gets a patched libjpeg-v1, app A gets it, assuming it can be auto-updated. App B remains open for exploitation.
Therefore given all that, sandboxing is a requirement for safely using packages from random people. Even when the packages from those come from a central source like Flathub or Snap Store. Sandboxing is why this model works without major security incidents on Android.
Anyway, won’t be the first bad practice advocated by some in this community.
This matches very well with this talk of an OpenSuse microOS maintainer doing a followup on his thoughts of Appimages, Snaps and Flatpak.
Spoiler: Flatpaks are the only ones that work.
Here is an alternative Piped link(s):
this talk
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source; check me out at GitHub.
Snaps work too if you use Ubuntu and trust Canonical, as he mentions. I’m a bit annoyed at Flatpak for being inferior to Snap in that it can’t be used to install system components. Snap allows for a completely snappy system, without the need to build the base OS one way and the user apps another. The OS from-traditional-packages, user-apps-from-Flatpaks model is an unfortunate compromise but I guess we’re gonna get to live with it long term. It’s better than the status quo.
BTW I completely disagree with him that everyone should be using rolling releases. As a software developer, user, and unpaid IT support, this is a mind boggling position.
Yesno. Snaps are not sandboxed at all, which is a nogo for normal application distribution.
So while I think it also sounds nice to pack an OS into different immutable parts, if the entire system is flawed, its not worth it.
Flatpak is good for app distribution, the rest is job of the OS.
not rolling release but normal stable release, not some random LTS. Not every software is like Firefox ESR (which honestly is not needed as Firefox doesnt break), but Debian etc. often just randomly dont ship updates.
Fedora is a bit too rolling, but if you always stay on the older supported version, thats okay. Especially with atomic.
Here is an alternative Piped link(s):
https://piped.video/watch?v=4WuYGcs0t6I&t=456
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source; check me out at GitHub.