Monday June 18, 2007

The problem with shipping 3rd party libraries with your product

The latest releases of StarOffice and OpenOffice.org contain 2 security fixes.

Some information about this can be found in the Sun Alerts 102917 and  102967.

102967 reminds me that we should have a closer look on what 3rd party libraries we ship with the next major versions.

There are 3 reasons for shipping these libraries with SO/OOo, instead of making them a system requirement:

1) It's convenient for the user. Just download and install the productivity suite, don't care about additional downloads and installations.

2) Modified versions. In some cases SO/OOo ship modified versions of 3rd party libraries, because we made some bug fixes which are not available in the official versions from that library right now.

3) No problems with ABI compatibility. Sometimes 3rd party libraries change in a way that they become incompatible with current versions of SO/OOo. Sometimes even in a way that the users doesn't recognize it immediately (application still starts), but some things behave differently (and wrong).
This happens for example when introducing new enum values in the middle of existing values. An example for this can be found in the FreeType library, which was responsible for one of the security vulnerabilities.

 
But in general, there should only be one copy of each library on a system, if possible. Programs shouldn't install "private copies".

 
Funny. I was just searching for some public documentation about our ARC Process, because ARC also checks for private copies, when stumbling over a very recent OpenSolaris blog from a colleague.

Item #5 is exactly what we are talking about here...

Posted by Malte Timmermann ( Jun 18 2007, 02:18:38 PM CEST ) Permalink Comments [0]