GD is an open source code library for the dynamic creation of images by programmers. GD is written in C, and “wrappers” are available for Perl, PHP and other languages. GD creates PNG, JPEG and GIF images, among other formats. GD is commonly used to generate charts, graphics, thumbnails, and most anything else, on the fly. While not restricted to use on the web, the most common applications of GD involve web site development.
See the GD website for more informations.
FS#143 — bgd.dll may be affected by security vulnerability from libpng
Opened by George Horlacher (george.horlacher) - Friday, 11 January 2008, 01:08 GMT+2
|
DetailsI could not find if the libpng has been updated since this security alert went out. I believe it’s included in bdg.dll which for windows binary the last date is 2/7/2007 while the security alert is 5/11/2007. Report from the CERT Security Team: We have published vulnerability note VU#684664 “libpng denial of service vulnerability” and think that you may be affected. This note is available to the public here: http://www.kb.cert.org/vuls/id/684664 A report of a denial of service vulnerability in libpng versions 0.90 to 1.2.16. Need to make sure a newer version is being used and a windows binary is made available with update. |
hi!
Thanks for this report!
We can't change past releases, especially when the problem is in a dependency.
I wonder if it would make sense to provide dynamically linked dlls (even if we can bundle the dependencies). On the same topic, we definitively need a more reliable system for windows. Our current build uses VC6 and thread safe crt. It is not exactly the common tools for what I hear. It would be nice to see what we can provide to actually help our windows users. Comments or ideas (or even help! :) welcome :)
So I don't want to commit to anything, but I am interested enough to see if I can at least build it with your existing tools and attempt to get the security update into a build, then explore updating tools. Can you help me get the existing build environment up and running for Windows? Which CVS branch would be best to use at this point and where is the best build information for setting it up? Thanks.
Sure, what do you use as compiler tools on windows?
There is a makefile for VC6 in the win32 directory. CMake supports almost all windows tool (mingw, icc, devc+, vc++ 6 to 8).
2.0.36 is about to be released, I will try to provide again updated dlls.
So I have VC6 and VC8, and could setup mingw tools if you recommend me going that way instead. I also found your page: http://www.libgd.org/FAQ_C_Compile and will try to follow it's win32 instructions.
When do you think 2.0.36 will be released and will the dll have this security fix from libpng?
Thanks for the help.
I would recommend to use ming or VC6, that's the easiest way to create compatible DLLs.
The DLLs for 2.0.35 should be available shortly after the release or at the same time.
Any word on releasing the DLLs for 2.0.35? I built the bgd.dll using vc6 and some of the versions are different now then they are documented in the C compiler FAQ. Also I had some warnings and to modify the make files for some things. The test blows up when I try to run it, but I don't know if that is meant to run on windows. Compiling a debug version to dig into that did not work so far. So I can give you more details and try go to continue on, but if your going to release pretty soon, I would rather trust your build of it.
Which Makefile do you use? Can you provide patches please?
The tests work well on windows, but you have to use CMake to build the library and the tests. The 2.0 branch is missing features check, that means it will try to run JPEG tests even if JPEG support is not ebabled. It has ot be fixed but after 2.0.36 (HEAD is fixed already).
Can you try using 2.0.36RC2 (http://pierre.libgd.org/qa/gd-2.0.36RC2.tar.gz) and CVS HEAD. I would recommend to use CMake in HEAD.
Once 2.0.36 is out (src release will be done tomorrow, I'm already a week late on this one :P ), I can try to build the DLL again, with static and dynamic linking to the respective dependency.
Are you still planning on building an updated windows dll?