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

[Phil Race]

So long as the changes don't break/affect our internal build
and can be constrained to non-default build options,
not code changes, they are probably OK.

The security issues are something we should think about.
Certainly we should keep up to date on patches.

libgif and libpng are only in JDK since 1.6, and the same is
true for splashscreen's use of openjdk so there's not too
much history there to worry about yet.

 >> a switch 'java -Xprintconfigoptions').
..
 > having a way to tell how something has been
 > built is certainly helpful;

Maybe we need an RFE on this, although libs in use
should show up in a hotspot log or core.

In the short term, if Gentoo is building for Gentoo, then
putting something in the "build" portion of the string emitted
by -version may be a quick way to tell its a Gentoo-specific build.

BTW, Did you send in your SCA yet?

-phil.


Diego 'Flameeyes' Pettenò wrote:
> 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