Bug 155510

Must be based on gtk2 packages in updates-testing.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Packages to fix the gdk-pixbuf problem; FC2 update was already released.
RHL9 and FC1 use the RHEL3 patch, RHL73 required backporting.
Unfortunately, the packages are not signed.  Note that RHL73 has not
been compile-tested.
 
http://staff.csc.fi/psavola/fl/gtk2-2.0.2-4.1.legacy.2.src.rpm (RHL73)
http://staff.csc.fi/psavola/fl/gtk2-2.2.1-4.1.legacy.2.src.rpm (RHL9)
http://staff.csc.fi/psavola/fl/gtk2-2.2.4-10.1.legacy.src.rpm (FC1)
 
b3d44da9dc4b5450812061405175e986255df332  gtk2-2.0.2-4.1.legacy.2.src.rpm
030ffec320315797a56329d66d6cf4df2f6158c9  gtk2-2.2.1-4.1.legacy.2.src.rpm
4d75906cb9da4963babecef4a9cf007906080695  gtk2-2.2.4-10.1.legacy.src.rpm
 
* Wed May 11 2005 Pekka Savola <pekkas> 2.2.1-4.1.legacy.2
- - Add BMP loader double free crash from RHEL3 (CAN-2005-0891), #155510
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
 
iD8DBQFCgchMGHbTkzxSL7QRAk++AJwOjvaE0zg3HJdNh5VsafR/KY/ukgCdElVq
I7nXVA22hpcVeCYk+wQglkc=
=gst+
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I did QA on the RHL73 and RHL9 package.

b3d44da9dc4b5450812061405175e986255df332  gtk2-2.0.2-4.1.legacy.2.src.rpm
030ffec320315797a56329d66d6cf4df2f6158c9  gtk2-2.2.1-4.1.legacy.2.src.rpm

Used invalid .bmp from the gnome bugzilla entry, the RH73 gqview does not lock up.

RH9 gqview does still lock up and spin.

+PUBLISH gtk2-2.0.2-4.1.legacy.2.src.rpm,
- -PUBLISH gtk2-2.2.1-4.1.legacy.2.src.rpm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)

iD8DBQFCsiTGTnwK660bsQMRAu0SAJ9cAKINlRdy3b9VKYyAQK91sgYMBACbBsxp
XsYVcCgWJY4TKE7ug8KqIQ4=
=4IxX
-----END PGP SIGNATURE-----

FC1 publishes, anyone?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I did QA on the FC1 package.

4d75906cb9da4963babecef4a9cf007906080695  gtk2-2.2.4-10.1.legacy.src.rpm

Used rpm-build-compare to compare the above versions to the previous versions.

Only patch addition is CAN-2005-468_469.patch.

Patch is as expected.

specfile changes are significant.  Path changes, removal of a great deal of
changelog, changes to buildrequires and and building scripting.  Almost
looks like a spec file rewrite.

+PUBLISH FC1

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)

iD8DBQFCtIgbTnwK660bsQMRAl5zAKC1/mFla0gTxq424hnbc/bq5QGFRQCfQBKR
eLdslLv2oRvMmSf41Lqw2zc=
=Zd1w
-----END PGP SIGNATURE-----

Thanks!

*** Bug 152783 has been marked as a duplicate of this bug. ***

This one didn't get a publish for rh9 as the corrupted bmp file locked it up.
Can someone test fc1 and try and figure out if the patch from RHEL actually works?

Ooops, sorry I didn't catch that.  Too bad I don't have X-enabled access to RHL9
so I can't test the packages now..

For RH7.3 and RH9, is this bug essentially a continuation of FL bug # 2073
    <http://bugzilla.fedora.us/show_bug.cgi?id=2073>?  

In February, Dominic announced a test update notification for gtk2 (RH7.3, RH9)
for FL #2073 (see list message at
    <http://tinyurl.com/9ayeg> ),

indicating that they were published in updates-testing, but that seemed to be
the end of the matter.

If this is a continuation of FL Bug 2073, then at least for the RH7.3 and RH9
packages, we'll need to indicate that this bug also fixes CAN-2004-0753,
CAN-2004-0782, CAN-2004-0783, and CAN-2004-0788.

Since I run FC1, I'll download Pekka's FC1 updated .src.rpm and see if it works
okay here within the next week or so.  (Assuming I have the resources to build a
new gtk2 here!)   -David

Yes, this is a continuation of the old updates-testing packages.

I didn't find an application which could be used to test the BMP file.

The RHEL patch which we use is the same as was listed in the gnome bug report,
so it seems a bit puzzling why it wouldn't work.

Created attachment 117894 [details]
4bpp-no-palette.bmp -- corrupted bmp file to test gtk2 with

For easy reference, this attachment is the .bmp file that causes processes that
use gtk2 library (or more specficially, the libgdk_pixbuf-2.0.so.0 component of
the gtk2 library) to freeze up.

On my Fedora Core 1 machine, this file causes Eye of Gnome (eog) to enter an
infinite loop, and nautilus to freeze up nicely when using the gtk2 package I
currently have installed (still using gtk2-2.2.4-5.1 from Nov, 2003).  

(I suspect maybe the eog hang is from an older problem that was fixed with
Fedora Core 1 Update FEDORA-2004-288 by Mathhias Clasen of RedHat on
15-Sep-2004
<http://www.redhat.com/archives/fedora-announce-list/2004-September/msg00019.html>.
 So am going to update my gtk2 rpm to that before proceeding with analysis.)

Why on earth do we have TWO gtk+ libraries and TWO gdk_pixbuf libraries??  At
least I assume we do in RedHat 9.0 -- we sure do in Fedora Core 1.

Don -- the problem you were having (in comment #3) getting gqview to work with
the updated gtk2?  It appears that the gqview program exercises the wrong libraries.

gqview-0.8.1-5 for RH7.3 uses the gtk+ library, gtk+-1.2.10 (providing
/usr/lib/libgtk-1.2.so.0 and /usr/lib/libgdk-1.2.so.0) and the imlib library
(providing /usr/lib/libgdk_imlib.so.1).  RH7.3's gqview program doesn't appear
to use RH7.3's gtk2 package with its ligbdk_pixbuf.  The gtk2 package provides
/usr/lib/libgdk_pixbuf-2.0.so.0.

gqview-1.2.1-3 for RH 9 also uses the gtk+ library gtk+-1.2.10, and it uses the
gdk-pixbuf-0.xx.00 library (providing /usr/lib/libgdk_pixbuf.so.2, which was
what Bug #154272 errata should have fixed).  So RH9's gqview program doesn't use
gtk2's gdk-pixbuf either.

  *sigh*  Can anyone say, "DLL Hell"??  Why do they *DO* this to us? :-)

Don, does Red Hat 7.3 or 9 have the Eye of Gnome (eog) program?  I believe eog
does link in with gtk2's brand of libgdk_pixbuf and should exercise the code for
this bug.  RH9's nautilus probably does also; at least it does on my FC1.

Since I've gotten started with this bug, I would like to do a source level
"publish"-type review for FC1's gtk2 that Pekka made, then compile and install
it...  just to make sure it *does* fix this for FC1.  (It will take a few days,
though.  I don't have a real fast processor and don't have mach build environment.)

Created attachment 117935 [details]
side-by-side diff of specfiles -- gtk2-2.2.4-10 (left) & gtk2-2.2.4-10.1 (right)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Source-level QA on FC1 package.

In the enclosed attachment, the left side is the gtk2.spec from Red Hat's
gtk2-2.2.4-10.src.rpm for Fedora Core 1, published Sep 15th, 2004 by
Matthias Classen.  The right side is the gtk2.spec from the .src.rpm
from comment #2, reviewed here.

http://staff.csc.fi/psavola/fl/gtk2-2.2.4-10.1.legacy.src.rpm

4d75906cb9da4963babecef4a9cf007906080695  gtk2-2.2.4-10.1.legacy.src.rpm

The specfile included in this .src.rpm appears to be an incorrect spec-file.
The gtk2.spec file looks like the specfile for RH7.3's .src.rpm that Dominic
published to updates-testing <http://tinyurl.com/9ayeg>.   The base_version
variable is defined to 2.0.2; patches 4-12 are not included; the bmpcrash
patch isn't mentioned; and the top entry in the changelog is Dominic's.

I will go ahead and cobble up a gtk2.spec file that should work and submit
it here for your review.  Will also submit a new .src.rpm.

  FC1 PUBLISH--

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFDBmzjxou1V/j9XZwRAlncAJ0ans2Efv+T4mSDBjgeDTqW6XuU3QCgvH9j
sdC4OxN2lNDtOCYysnQWSuQ=
=uaet
-----END PGP SIGNATURE-----

Yeah, for some odd reason the FC1 spec file appears to be pretty weird..

Created attachment 118054 [details]
gtk2.spec - new spec-file for FC1's gtk2-2.2.4-10.2.legacy rpms

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Enclosed is a corrected spec file for Fedora Core 1's gtk2.

sha1sum 				  File
========================================  =========
5955e26bb21a40f45d6ea59e0d2727f5d5864ae6  gtk2.spec

I've built gtk2-2.2.4-10.2.legacy.src.rpm using this spec-file, as
well as binary rpm's that install and work well.  After installing
the new gtk2 package, every program now issues an error when given
the corrupted bmp file in attachment #117894 [details], instead of hanging.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFDDG3Oxou1V/j9XZwRAthrAKCuXTv7ewtRLe9UIbvE271SM14FjwCgmkZc
6KfsHDcIrPYvB3TWJBeMWt0=
=QA2i
-----END PGP SIGNATURE-----

$ cat (comment #16) | expand | sed -e "s/ \[edit\]//" | gpg --verify

*sigh*  --David

Package compiles with new specfile. Pekka, do you need to do a repackage for
publish votes?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Here is a new Fedora Core 1 package to test for Publish votes:

http://members.gtw.net/~deisenst/legacy/FC1/SRPMS/gtk2-2.2.4-10.2.legacy.src.rpm

fc69e935b50d4f1a80dbea3088216dadb86889f4  gtk2-2.2.4-10.2.legacy.src.rpm

Changelog:

* Sat Aug 20 2005 Dave Eisenstein <deisenst> 2.2.4-10.2.legacy
- - Specfile damaged in 2.2.4-10.1.legacy.  Redo specfile. Bug #155510.

* Wed May 11 2005 Pekka Savola <pekkas> 2.2.4-10.1.legacy
- - Add BMP loader double free crash from RHEL3 (CAN-2005-0891), #155510

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFDDQvgxou1V/j9XZwRAvt9AKCVvi1gwUSfNRQIH3JYvsWVDxpv+ACgzlcA
wGn13lcySlNf3TEPfWWXu6k=
=Y7Pe
-----END PGP SIGNATURE-----

The concerns over whether RHL9 package fixed the problems appear to be moot, as
the application tested was using wrong libs, so we could go ahead and rebuild
this now...

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
QA w/ rpm-build-compare.sh:
 - source integrity good
 - spec file changes minimal
 - patch verified to comes from RHEL
 
+PUBLISH FC1
 
fc69e935b50d4f1a80dbea3088216dadb86889f4  gtk2-2.2.4-10.2.legacy.src.rpm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
 
iD8DBQFDDqi8GHbTkzxSL7QRAhGqAJ48EcpuIjLS0ZT76utSzTO9xMxgKwCglyfM
ngRN6fnoDu0UULNGUvkdflc=
=l0gs
-----END PGP SIGNATURE-----

Note: we probably need packages for gtk+ as well (shipped in RHL73, RHL9, FC1).
 RHL73 also had an even older version, "gtk+10".. (not sure if this should be
done as a separate report or not)


However, I note that RHEL3 update of gtk+ is from July 2004, while the latest
gtk2 update is from March 2005.

Regarding comment #21:  I don't think we need new packages for gtk+.  The 
vulerabilities that we are fixing here (in the gtk2 package) are all in gtk+'s
companion gdk-pixbuf package.  These issues were already patched in RHL73's, 
RHL9's and FC1's gdk-pixbuf.

  RHL7.3, RHL9:
    - FLSA-2005:2005 fixed CAN-2004-0753,0782,0783,0788
      on Febr 23rd:    <http://tinyurl.com/bget4>, 
      Packages gdk-pixbuf-0.22.0-7.73.2.legacy,
               gdk-pixbuf-0.22.0-7.90.2.legacy

    - FLSA-2005:154272 fixed CAN-2005-0891
      on July 15th:    <http://tinyurl.com/8gw5d>
      Packages gdk-pixbuf-0.22.0-7.73.3.legacy,
               gdk-pixbuf-0.22.0-7.90.3.legacy

  FC1:
    - FEDORA-2004-286 fixed CAN-2004-0753,0782,0783,0788
      on 15-Sep-2004:  <http://tinyurl.com/9e24d>,
      Package  gdk-pixbuf-0.22.0-11.2.2

    - FLSA-2005:154272 fixed CAN-2005-0891
      on July 15th:    <http://tinyurl.com/8gw5d>,
      Package  gdk-pixbuf-0.22.0-11.3.4.1.legacy

RHEL3's gtk+ probably hasn't been updated because this bug is in
RHEL3's gdk-pixbuf - gdk-pixbuf-0.22.0-12.el3 was issued to fix this.
See RHSA-2005:343-01 <http://rhn.redhat.com/errata/RHSA-2005-343.html>.

Ok, great.

This still needs to be built so people can do verify QA so this can get released.
It has been waiting since late August.

I have moved gtk2-2.2.4-10.2.legacy.src.rpm from members.gtw.net to
fedoralegacy.org.  It now resides at:

http://fedoralegacy.org/contrib/gtk2/gtk2-2.2.4-10.2.legacy.src.rpm

Should have the same sha1sum as mentioned in comment 19.

*ping* on this issue.

I'll build these tonight

pushed to updates-testing.

No FC2 packages to verify, so 
   VERIFY FC2 ++  :-)

Gosh, I wish all our packages were this simple to verify.  *lol*

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

QA for FC1 gtk2 packages in updates-testing:

be0ba4a1776f9849cd5734ccb655b9dabb97011b  gtk2-2.2.4-10.3.legacy.i386.rpm
501aa3181b863c6904004ec8ef5c9e38cef77652  gtk2-devel-2.2.4-10.3.legacy.i386.rpm

   *  Packages install fine
   *  gtk2 libraries seem to work fine
   *  Tested gtk2 for the CVE-2004-0753 vulnerability with the corrupted BMP
      image with both eog and nautilus.  In both applications, attempts to
      read the corrupted BMP file properly popped up an error message rather
      than causing a DoS or infinite loop.
   *  Using the gtk2-devel package in building ethereal.  No problems yet en-
      countered.

  VERIFY++ FC1   

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFDcW1ixou1V/j9XZwRApseAJ4/qv9xd+FSCFX0WX1RjKoLyY6eBgCfVDLu
VcwGLPyapwUy8wQ9dPjCcrI=
=Ap8g
-----END PGP SIGNATURE-----

Timeout in 4 weeks.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
QA for RHL9.  Signatures OK.  Installs OK.  'Pan' using gtk2 runs fine.
I see the following minor diff (related to the buildsystem?) when running
rpm-build-compare.sh on the devel binary, but I don't think that's a major
issue.
 
+VERIFY RHL9
 
 
- --- gtk2-devel-2.2.1-4.i386.rpm-root/usr/lib/pkgconfig/gtk+-x11-2.0.pc
2005-11-16 12:53:40.000000000 +0200
+++ gtk2-devel-2.2.1-4.2.legacy.i386.rpm-root/usr/lib/pkgconfig/gtk+-x11-2.0.pc
2005-11-16 12:53:40.000000000
@@ -5,7 +5,7 @@
 target=x11
                                                                               
                                
 gtk_binary_version=2.2.0
- -gtk_host=i386-redhat-linux-gnu
+gtk_host=i686-pc-linux-gnu
                                                                               
                                
 Name: GTK+
 Description: GIMP Tool Kit (${target} target)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
 
iD8DBQFDexCaGHbTkzxSL7QRAmmtAJoDiEZoi7MxQ1RDLEGWwtaKHWIPKgCfQsXX
cIa5Fr7+AuiOFrSqV/P0tNw=
=I2Z5
-----END PGP SIGNATURE-----

Timeout reduced to 2 weeks from the first verify.

Timeout over.

Packages were released.