Applications and bundled libraries

Posted Mar 18, 2010 10:15 UTC (Thu) by __alex (guest, #38036)
Parent article: Applications and bundled libraries

Why are these programs not just linked statically to the library variants they need?

to post comments

Applications and bundled libraries

Posted Mar 18, 2010 10:56 UTC (Thu) by hummassa (guest, #307) [Link] (3 responses)

That would be even worse, both in terms of memory consumption and in terms
of security patching.

Applications and bundled libraries

Posted Mar 18, 2010 12:20 UTC (Thu) by __alex (guest, #38036) [Link] (2 responses)

I suppose for multiple instances of a program static libraries aren't going to help memory usage. I'm
not sure why it would effect security patches though.

I wonder if people would still be complaining if Google had implemented their versions of some of
the things they depend on instead of using existing libraries with their own patches. It seems like
just because Chromium depends on things that have the same name as things already in the distro
that everyone thinks they *are* the same thing. sqlite is a pretty good example of this. Upstream
don't want the changes. So essentially the 'sqlite' used in Chromium isn't 'sqlite' anymore. It's an
entirely new project tied to Chromium. It makes no sense to think of it as a library now.

Applications and bundled libraries

Posted Mar 18, 2010 17:55 UTC (Thu) by dlang (guest, #313) [Link]

the reason it affect security patching is that the next time there is a zlib vulnerability (to pick on one particular library that has suffered from this exact problem), how do you know what applications need to bat updated/rebuilt?

if all the applications link to the system library you update that and everything just works.

if an application ships it's own copy of the library, you have a chance of finding it if you search for it and can then replace that copy (although if it's been tweaked, you may still break that application, but at least you know that application is unsafe after that point)

if an application statically links the library, you have no way of knowing that the application is using that library, and unless the application developer notices the security alert and ships an update to the application, you won't be able to patch the vulnerability, but even worse, you won't be able to find out that the application is vulnerable in the first place.

Applications and bundled libraries

Posted Mar 19, 2010 10:57 UTC (Fri) by hummassa (guest, #307) [Link]

About why it affects security patching: because then you have to patch it in two places, instead of
one.
About modified-sqlite: yes, it is a library. if it is required by chrome and supercedes regular-sqlite
(without any api/abi incompatibilities), it should be packaged as another, modified, version (and
SONAMEd accordingly); else, it should be packaged as another package altogether (and anyway, yes,
security patching must be done in each package, regular-sqlite and chrome-sqlite, but in the first
case, you can have only chrome-sqlite in memory even if another program wants to use sqlite)

Applications and bundled libraries

Posted Mar 18, 2010 12:54 UTC (Thu) by clugstj (subscriber, #4020) [Link] (1 responses)

Because, bundling is all about developer (individual and corporate) expedience, nothing more, nothing less.

All other options like
1) Getting fixes upstream
2) Changing the name of forked libraries
3) Linking staticly
all require more work on the part of the developer, so they skip out on doing it and just bundle mystery versions with their product and push the headache down to the distributors/users.

Applications and bundled libraries

Posted Mar 19, 2010 15:28 UTC (Fri) by mgedmin (guest, #34497) [Link]

Linking statically would not be an improvement over bundling.