Recent Features
| |||||||||||||
Bundled == oldBundled == oldPosted Apr 6, 2012 22:01 UTC (Fri) by david.a.wheeler (subscriber, #72896)In reply to: Wheeler: Insecure open source software libraries? by vonbrand Parent article: Wheeler: Insecure open source software libraries?
In my experience, if it's an embedded ("bundled") library, it's usually obsolete. Perhaps a developer thinks "I will be different, I will keep up with my libraries". But as time marches on, the libraries get updated by the library maintainers.. and the application developers do not update their libraries to match.
We need to make it possible for end-users to know when the libraries are vulnerable and/or obsolete, whether they are embedded or not.
(Log in to post comments)
Bundled == old Posted Apr 6, 2012 22:30 UTC (Fri) by scientes (guest, #83068) [Link]
100% agree. we need to strive for maximum deduplication of code copies. This way instead of patching the same fix 100 times, we can do it ONCE
Bundled == old Posted Apr 7, 2012 2:09 UTC (Sat) by elanthis (guest, #6227) [Link]
That can be in some cases very difficult.
On two of the projects I'm working with lately, we have almost every single library pulled into the source tree. Why? In some cases, we have bugs to fix that will take months just to get upstreamed in the respective project, and possibly years before you find them in all non-legacy releases of the popular Linux distributions.
In other cases, we have have changes or customizations that upstream doesn't even want, requiring that we not only fork the project but then get enough mindshare from the community to have the same support network as well as getting distributions to even package the library.
Yet other cases are libraries that are designed to be bundled because they do not attempt to provide a stable API or sufficient run-time configuration of options (this one happens a lot more often than I'd like).
And yet other cases are small technical integration needs (inlining w/ LTO a matrix math library, for instance, can have such a huge impact on performance that using it as a shared library is downright stupid).
I don't for a second believe any of those are common issues, but they do happen.
Bundled == old Posted Apr 8, 2012 5:24 UTC (Sun) by cmccabe (guest, #60281) [Link]
You make some interesting points.
> Yet other cases are libraries that are designed to be bundled
This sounds like a good reason to use a different library to provide the needed functionality.
> And yet other cases are small technical integration needs
In that case, shouldn't the distributions provide a statically linked version of the library that you can depend on? It seems like there's no technical barrier to doing this.
Bundled == old Posted Apr 8, 2012 11:13 UTC (Sun) by epa (subscriber, #39769) [Link]
By 'inlining' the matrix library I think the other poster meant doing type specialization at compile type, as C++ does, so building a specialized Matrix<Foo> type for your application's type Foo. If you included the library at link time instead, whether by static linking or dynamic linking, it would have to be a Matrix<Foo *> or Matrix<void *> instead, since the Matrix library wasn't built with knowledge of the Foo type. The extra pointer dereferences can slow things down a lot.
Bundled == old Posted Apr 8, 2012 19:47 UTC (Sun) by cmccabe (guest, #60281) [Link]
The Matrix library doesn't have to have knowledge of type Foo. Matrix<Foo> will be instantiated when the application is built. All of that works fine-- yes, even with dynamically linked libraries. Let's not forget, libstdc++ is a dynamically linked library itself, and it's stuffed full of templates.
The problems start when you try to deal with versioning. Basically, templates make creating any kind of backwards-compatible API much harder. This is one reason why the libstdc++ std::string still uses a reference-counted implementation, despite the fact that it's known to be slow on modern multi-threaded machines. Changing std::string (otherwise known as std::basic_string <char, traits, alloc>) would just break too many things.
There are other problems with handling versioning in C++. The KDE guys made a good writeup describing how to make backwards-compatible changes to C++ libraries here: http://techbase.kde.org/Policies/Binary_Compatibility_Iss...
Bundled == old Posted Apr 9, 2012 14:02 UTC (Mon) by HelloWorld (guest, #56129) [Link]
> The Matrix library doesn't have to have knowledge of type Foo. Matrix<Foo> will be instantiated when the application is built. All of that works fine-- yes, even with dynamically linked libraries. Let's not forget, libstdc++ is a dynamically linked library itself, and it's stuffed full of templates.
The template stuff isn't linked dynamically (except maybe for a few explicitly instanciated templates). In fact, many template libraries, such as boost spirit, boost xpressive or Eigen consist solely of headers.
Bundled == old Posted Apr 9, 2012 16:41 UTC (Mon) by cmccabe (guest, #60281) [Link]
Templates may or may not have external linkage. It depends on how they were instantiated. It's perfectly possible, for example, for the shared library to use explicit instantiation to create Matrix<Foo>, Matrix<Bar>, and Matrix<Baz>. On the other hand, since a lot of the benefit of this kind of templating comes from inlining, this would probably not be the style used in a matrix multiplication library.
It's also possible for templates declared in a header file and instantiated in library client code (inline) to call functions from a shared library. This is where most of the version skew problems come from, since when the library client is linked against another version of the shared library, he will not update his inlined templates, but will be using different versions of those functions.
Bundled == old Posted Apr 10, 2012 9:19 UTC (Tue) by epa (subscriber, #39769) [Link]
I'm not sure I understand you rightly, but I always thought that it was impossible for a library to provide Matrix<Foo> unless the author of the library already knew about the Foo type. If Foo is a type specific to your application, it's not going to be something your matrix library knows about. Is that no longer the case with today's C++ toolchains?
Bundled == old Posted Apr 10, 2012 15:22 UTC (Tue) by cmccabe (guest, #60281) [Link]
No, you can't instantiate Matrix<Foo> without knowing about type Foo. I'm just saying that there are a lot of templates out there that aren't inlined.
My biggest point, if I have one, is that mixing the inlined and non-inlined stuff is what creates the versioning problems.
Bundled == old Posted Apr 6, 2012 22:34 UTC (Fri) by scientes (guest, #83068) [Link]
perhaps applications can embed blacklists of known-bad version of libraries, and refuse to run if that is the only version available, printing an appropriate error message. That is about the maximum amount of bundling i can find remotely acceptable.
Bundled == old Posted Apr 7, 2012 7:25 UTC (Sat) by boudewijn (subscriber, #14185) [Link]
It's what we have to do for Calligra right now. All the good Qt hackers seem to be on Qt 5, so Qt 4.8 is pretty bad quality. I've had at least six regressions that affected Krita, but the big one was a regression in editing that made every app that uses the text component crash.
There's a patch and it'll be in Qt 4.8.2.
So what we did is refuse to build against 4.8.0 and 4.8.1, provide an override to that and the patch -- hoping that distributions will patch Qt when they package Calligra.
Bundled == old Posted Apr 7, 2012 23:31 UTC (Sat) by man_ls (subscriber, #15091) [Link] The logic of software development favors the process you outline: bundle, then stabilize, and finally fail to update. Once a developer has code working, they would rather not change it if there is no immediate gain. But updating a bundled library does not provide any (immediate) benefits to users and may destabilize the main software, so why bother? Perhaps there are security issues, but unless there is an active attack vector then maybe the problems cannot be triggered they way the library is used.It always amazes me that "stable" has two different meanings, and that applying both to software yields such a rich interplay: one meaning is "not changing", and the other is "without bugs". But actually you cannot have both: if you solve bugs you induce changes. Those changes may in turn produce other bugs, and the process is not guaranteed to end. So people tend to favor the first meaning of "not changing", when in fact what they want is the second of "without bugs".
|
|||||||||||||