AppImageUpdate lets you update AppImages in a decentral way using information embedded in the AppImage itself. No central repository is involved. This enables upstream application projects to release AppImages that can be updated easily. Since AppImageKit uses delta updates, the downloads are very small and efficient.
I haven't dug far enough into this specific project to know if it's static or dynamic linking, but that just doesn't matter.
Each app has it's own copy of libssl etc embedded into the prepackaged "binary" which is executed.. That's enough to know it's going to lead to all sorts of suffering when you actually try and rid yourself of $CVE of the month.
So, yea.. As I said, in this context, it just doesn't matter if your statically or dynamically linked against glibc, every single AppImage published before Feb 15th or so requires an update.
What percent of AppImage's in the wild have shipped an update? Of those, how many have updated previous stable releases rather than just the latest version? I suspect very few.
Maybe not, but Since "Every AppImage contains an app and all the files the app needs to run." Even if you were dynamically linking, you'd be linking against a lib contained in the AppImage. So, each app would still have its own glibc that would have to be updated.
The problem with that should be obvious. Package managers can, right now, update the library that multiple applications use without updating the applications/executables too. One update rather than hundreds or thousands.
You could also just not update, but then you'll have massive security holes in your computer.
There's a reason Linux adopted the shared library model.
I'm not hrtghrth3, so can't speak for him... but..
Yes, I have a problem with that. I trust I can count on Debian/Ubuntu/RHEL will ship a new package for every critical CVE promptly, without forcing me to upgrade to the latest upstream version. I have zero faith upstream maintainers will do the same - which leaves me with two choices
1) Pretend there is no CVE
2) Use the latest app version, bringing with it all new bugs, workarounds, incompatibilities and so forth - and hey, the latest version might not even have the fixed code in it.
> I trust I can count on Debian/Ubuntu/RHEL will ship a new package for every critical CVE promptly, without forcing me to upgrade to the latest upstream version.
There was an article just a couple of weeks ago pointing out that distributions frequently don't fix security issues:
No doubt it's better for high-profile applications, but there are far more applications that people want to use than distros have the resources to issue security updates for.
Sure, you're boned if the security flaw is in the custom protocol handler of some random package of which you are one of 37 total users. Typically, however, security code does not reside in such packages. They typically link to popular libraries for e.g. TLS support. Those popular libraries are kept current by reputable distros. You shouldn't be using low-volume packages that implement their own security, anyway.
One of the packages in the article I linked above was Wordpress, which is not exactly low volume. I work on the Jupyter/IPython notebook - we found a security bug last summer, got a CVE (CVE-2015-5607), issued patches... and the version in Debian unstable hasn't been fixed, seven months later.
If distros can't do security maintenance for the software people use, claiming that they shouldn't use that software at all is no kind of an answer.
I didn't even know that Debian has a WordPress package. I always downloaded it from here https://wordpress.org/download/ and applied updates as soon as my WP servers ask me to. I don't trust Debian mantainers to be faster than that.
As a comparison: WordPress is at 4.4.2, Debian 8 has it a 4.1 and Debian 7 at 3.6.1. You can't use those, you must use the one from the developers.
Same thing for example with Ruby: Debian 8 is stuck with 2.1.5 (November 2014), which is not even the latest one of the 2.1 series. The current version of the language is 2.3. And Node.js? 0.10.29 (June 2014). Again, you can't use the packaged versions and you must go to the developers, maybe through rvm, nvm or other language specific package managers. I really don't understand why they bother packaging those languages. They should have tiny packages that explicitly tell that you are on your own and redirect to the appropriate package manager for the language.
If one can't build a server app from source then one shouldn't be connecting it to the internet all by oneself. There are any number of companies who are happy to host WordPress for reasonable fees. Keeping software updated is hard work, and those who do it for free will keep their own schedules. I'm sure it's frustrating to maintain a package that's "in the middle": too popular to just say "install with pip", not enough volunteers to maintain the Debian package in-house. Perhaps that means that Debian is too accepting of packages. I don't think it's an indictment of the idea of a package manager. I also doubt that lots more free labor will appear now that there is yet another new zipfile format to keep maintained.
If building it from source is acceptable, why would using packages direct from the maintainers not be? For anything in an interpreted language, there's little difference anyway.
I agree that Debian is too accepting of packages. We don't recommend that anyone installs Jupyter/IPython with apt, and I wouldn't mind if Debian removed it from the repos. But if there are all these packages that shouldn't be distributed through Debian, we need some other way for users to get them conveniently. We often use language package managers like pip, but they're not great for desktop applications - they can't easily set up a launcher entry, for instance. That's where something like AppImage comes in.
I think it's perfectly acceptable for project maintainers to provide rpms, debs, ppas, etc. as long as those artifacts are organized in largely the same way that distro maintainers would organize them. (I doubt any distro maintainers would disagree.) I don't think it's a good idea to pack lots of already-distro-packaged libraries into those artifacts. Building for many distro formats is a pain, but I doubt that building this new format in a universal way will be easy either. If you have a different AppImage for each distro/version combo, is that an improvement?
For the packages you've mentioned, live active projects with maintainers who can produce this distribution format but can't deal with apt, maybe the giant ball of wax is okay. I won't be installing anything this way, but clearly I'm not the target user. It seems certain, however, that in future we'll be hearing about lots of vulnerabilities attributed to AppImages linking in old library versions.
