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

[Anthony Petrov]

Hello Diego,

The reasons are quite reasonable. We think we can apply the patch. 
However, we should wait a bit until some bureaucracy is done to make 
sure your signed SCA has been properly enlisted. Thank you!

--
best regards,
Anthony


On 05/15/2007 12:34 AM Diego 'Flameeyes' Pettenò wrote:
> On Mon, 14 May 2007 12:32:20 -0700
> Phil Race <Phil.Race at Sun.COM> wrote:
> 
>> The security issues are something we should think about.
>> Certainly we should keep up to date on patches.
> That is probably a wise decision, whatever the outcome of the usage of
> external libraries is :)
> For what it's worth, I can give a couple of suggestion about it through
> my experience with xine: move all the contributed code in a different
> directory, don't put the sources for your own code in that tree, and
> always keep an updated diff between the original code and your imported
> code in there, so that if you need to upgrade you can just apply the
> diff over it.
> 
> Of course it would also help to send the changes to the original
> projects so that they can include them as soon as possible, skipping
> over the need to fix the patches if a new version changes the source
> code a bit in organisation.
> 
>> 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.
> Well, at least the code of libpng is in the b12 package of OpenJDK *is*
> vulnerable to CVE-2006-5793. Unfortunately I wasn't able to find a
> proof of concept of it to actually check if the release 1.6 had that
> problem, but the codepath is unchanged, the libpng version is older
> than the current release, quite older. I suppose you can probably
> either import a new version of libpng or apply the simple patch to fix
> the issue.
> 
>> 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.
> Well, unless the user is playing with options (which would make it
> difficult anyway to find out what the user is doing), it's already
> possible to identify a build out of Gentoo's ebuild:
> 
> openjdk version "1.7.0-internal"
> OpenJDK Runtime Environment (build
> 1.7.0-internal-portage_14_may_2007_15_18-b00) OpenJDK 64-Bit Server VM
> (build 1.7.0-internal-portage_14_may_2007_15_18-b00, mixed mode)
> 
> you embed already the user under which OpenJDK is built; for Gentoo,
> that user will usually be 'portage'.
> 
>> BTW, Did you send in your SCA yet?
> I didn't before, but I just sent it in a few minutes ago.
> 
> Regards,