5 ms·

So every time there is glibc / openssl / anything else security update, We will have to update all appimage programs as well ?

kiallmacinnes 11y ago
As near as I can tell, yes.
- tosseraccount 11y ago
  Application binaries must statically link libc and ssl when making programs for packging into appimage?
  - hundchenkatze 11y ago
    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.
    - tosseraccount 11y ago
      "The AppImage needs to include all libraries and other dependencies that are not part of all of the base systems that the AppImage is intended to run on" [ https://github.com/probonopd/AppImageKit/wiki/Creating-AppImages https://github.com/probonopd/AppImageKit/wiki/Creating-AppIm... ]
  - kiallmacinnes 11y ago
    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.
    - probonopd 11y ago
      You can use either static or dynamic linking. An AppImage is really just an ISO container wrapping around your binaries.
      - kiallmacinnes 11y ago
        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. [EDIT - Typos]
        jjuhl 11y ago
        Regardless of dynamic or static linking there's the fact that "users dont upgrade" so you've lost either way.
        deleted 11y ago
        [deleted]
wereHamster 11y ago
Do you have any specific problem with that?
- striking 11y ago
  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.
- kiallmacinnes 11y ago
  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.
  - takluyver 11y ago
    > 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: https://statuscode.ch/2016/02/distribution-packages-considered-insecure/ https://statuscode.ch/2016/02/distribution-packages-consider... 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.
    - jessaustin 11y ago
      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.
et1337 11y ago
Follow-up question: is there a built-in app update mechanism? If not, this isn't really a replacement for package systems.
- probonopd 11y ago
  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. https://github.com/probonopd/AppImageKit/tree/master/AppImageUpdate.AppDir https://github.com/probonopd/AppImageKit/tree/master/AppImag...
dorfsmay 11y ago
With the new "statically link all the things" trend from go and rust, that's coming anyway.
- kibwen 11y ago
  Rust has always been capable of dynamically linking, and I believe that Go is gaining support for dynamic linking sometime in the future as well.
matzipan 11y ago
Yes. But it's still better, since your distribution package manager can just pull directly from upstream rather than rebuilding by themselves. Edit: Come to think of it, considering how many applications out there haven't had any updates in years... that might not be such a good idea.

kiallmacinnes 11y ago

As near as I can tell, yes.

tosseraccount 11y ago
Application binaries must statically link libc and ssl when making programs for packging into appimage?
- hundchenkatze 11y ago
  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.
  - tosseraccount 11y ago
    "The AppImage needs to include all libraries and other dependencies that are not part of all of the base systems that the AppImage is intended to run on" [ https://github.com/probonopd/AppImageKit/wiki/Creating-AppImages https://github.com/probonopd/AppImageKit/wiki/Creating-AppIm... ]
- kiallmacinnes 11y ago
  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.
  - probonopd 11y ago
    You can use either static or dynamic linking. An AppImage is really just an ISO container wrapping around your binaries.
    - kiallmacinnes 11y ago
      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. [EDIT - Typos]
      - jjuhl 11y ago
        Regardless of dynamic or static linking there's the fact that "users dont upgrade" so you've lost either way.
      - deleted 11y ago
        [deleted]

wereHamster 11y ago

Do you have any specific problem with that?

striking 11y ago
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.
kiallmacinnes 11y ago
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.
- takluyver 11y ago
  > 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: https://statuscode.ch/2016/02/distribution-packages-considered-insecure/ https://statuscode.ch/2016/02/distribution-packages-consider... 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.
  - jessaustin 11y ago
    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.

et1337 11y ago

Follow-up question: is there a built-in app update mechanism? If not, this isn't really a replacement for package systems.

probonopd 11y ago
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. https://github.com/probonopd/AppImageKit/tree/master/AppImageUpdate.AppDir https://github.com/probonopd/AppImageKit/tree/master/AppImag...

dorfsmay 11y ago

With the new "statically link all the things" trend from go and rust, that's coming anyway.

kibwen 11y ago
Rust has always been capable of dynamically linking, and I believe that Go is gaining support for dynamic linking sometime in the future as well.

matzipan 11y ago

Yes. But it's still better, since your distribution package manager can just pull directly from upstream rather than rebuilding by themselves. Edit: Come to think of it, considering how many applications out there haven't had any updates in years... that might not be such a good idea.