[PATCHes] Allow using system's copies of libjpeg, libpng and giflib for splashscreen

[Diego 'Flameeyes' Pettenò]

Hi,

On Mon, 14 May 2007 17:03:41 +0400
Anthony Petrov <Anthony.Petrov at Sun.COM> wrote:
> 1. Not every *NIX desktop has these libraries installed. Throwing
> them out means adding more external dependencies that are not
> regularly required now.
Okay, I suppose I can agree on it for giflib that isn't really a common
library, but I'd be very surprised for a Solaris, Linux, or even
FreeBSD and NetBSD *desktop* not to have libpng, or libjpeg.
Of course the keyword here is desktop, as probably OpenJDK is going to
be used not only on desktop systems where the libraries are likely not
to be present (they are not present on my server either, and there I'd
like to run Tomcat sooner or later - that is when I can get OpenJDK to
build on FreeBSD).

But, these patches are thought to be there for distributions building
their own package of OpenJDK, and distributions can put their own
dependencies over and live peacefully.
On the other hand, OpenJDK already uses alsa-lib externally, and so is
going to do for FreeType, standing from what I read from Phil Race on
build-dev.

> 2. Some libraries bundled with the JDK (like the libjpeg) are heavily 
> customized by Sun. Using system copy of such library might cause 
> unexpected behavior of JDK.
This has been and is being discussed on build-dev too; Phil also said
that as far as he knows giflib and libpng are not modified except for
removing extra stuff, which is understandable. The changes in libjpeg
does not seem to be important for the splashscreen support either, and
for those there's still the discussion going; many distributions will
more likely merge the changes in their own libjpeg packages and use
those rather than having an extra internal copy.

> 3. Also using system copies of libraries might be unreliable, and
> thus some bugs could arise that we do not expect. This situation
> would be difficult as it would not be clear whether it's an OpenJDK
> fault, or the library fault. At least until we've got an ability to
> retrieve some specific options (like EXTERNAL_LIBPNG) that were used
> while building OpenJDK from the run-time version (i.e. something like
> a switch 'java -Xprintconfigoptions').
Okay, that is a good point, having a way to tell how something has been
built is certainly helpful; too bad I have no idea how to implement it
myself or I'd do, but I'll see if I can get to look at it.

> And, what's more
> important, what, in your opinion, is the main reason for such an
> addition to OpenJDK?

As I said, Gentoo, Debian, most likely RedHat, as far as I know
also FreeBSD, and probably many other distributions too have a policy
to avoid using internal copies of libraries whenever humanly feasible.
This is due not only for a performance/space reason (a libpng shared
across 20 processes in a KDE desktop has a risible memory cost in term
of shared pages; a copy of it in other ten process having a local copy
each instead is a waste of memory and address space too), but also
because if a bugfix (especially a security one) has to be applied to a
library, using shared libraries you just have to apply it once, and
ship out the new package for the library, rather than having to apply
it on and ship ten or more packages.
Gary Benson from RedHat already shown the case for zlib[1]; I can
provide my experience with the upgrade of FreeType, when they dropped
the internal API: at least three packages had to be updated because
they inlined a copy of SDL_ttf, an old version that was still using the
old API, while SDL_ttf itself was already fixed to use the new one, and
didn't change API by itself; having a way to use the external copy
would have saved a lot of time to both us distributors and to users who
had to recompile them.

Although I suppose that changes in API for libpng/giflib/libjpeg are
unlikely, or would be anyway enough of an hassle to make them
unfeasible on the short term, considering their widespread use,
security concerns aren't really non-existent.
E.g. libpng had a vulnerability discovered last
november[2], jpeg last june[3], while giflib had two in september[4] and
october[5] 2005.

[1]
http://mail.openjdk.java.net/pipermail/build-dev/2007-May/000055.html
[2] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5793
[3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3005
[4] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3350
[5] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2974
-- 
Diego "Flameeyes" Pettenò
http://farragut.flameeyes.is-a-geek.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20070514/d507e985/signature.asc