Bug 209167 (CVE-2006-4571)

-> Fedora Legacy

What would be necessary to get this done?
Is it as simple as following the standard Fedora Extras build procedures, to
push this build into Fedora Legacy?

Thank you, Kai, for forwarding this to Fedora Legacy.  I've been concerned
for awhile that Legacy users still only have Mozilla 1.7.13 to use.  (As a
matter of fact, that is all I seem to have for the FC5 that I currently run!
Has Seamonkey been released as a Mozilla replacement for FC5? (rather than
FE5?))

I would think that this issue will need some work, but that we can probably
take our cues from the Seamonkey packages that were released for RHEL 2.1,
RHEL 3 and RHEL 4, that Chris Aillon I believe has been working on for RHEL's
Mozilla-suite replacement.

I will put in a Bugzilla (infrastructure) Bug to add "Seamonkey" as a 
component for all Legacy releases so this bug can be properly filed.  AFAIK,
Legacy has been intending to take over Seamonkey's maintenance as a "core"
package (replacing Mozilla), and at that time, I would suppose Seamonkey
could be removed from Fedora Extras.  Does that sound right?  If so, maybe
this Bug Ticket can be our coordinating spot.

Builders:  Since this bug ties in so closely with fixing our already-open
Mozilla Bug #194440 (which has been open since June for all the Red Hat's and
Fedora Core releases 1-3), unless there is objection, I am going to mark this
ticket as being for RHL 7.3, RHL 9, FC1, FC2, in addition to FC3 and FC4,
since the fix for this will fix the same issues in Bug #194440 and then some.
Is that all right with you?

(In reply to comment #2)
> Has Seamonkey been released as a Mozilla replacement for FC5? (rather than
> FE5?))

No, not as real drop in replacement. But you can install seamonkey for FC5 from
Fedora Extras and you can run it instead of Mozilla, and it will use your
existing Mozilla profile.


> I would think that this issue will need some work, but that we can probably
> take our cues from the Seamonkey packages that were released for RHEL 2.1,
> RHEL 3 and RHEL 4, that Chris Aillon I believe has been working on for RHEL's
> Mozilla-suite replacement.

This is more than I had intended with this bug.
You are proposing a full replacement, which is more work than I was proposing to do.

This bug is simply about: Consider to update the SeaMonkey 1.0.4 already
available in FC4 to the newer SeaMonkey 1.0.5

And being not involved in Legacy yet, my question was: What is the exact process
to get that done. Is Legacy still using the same build infrastructure? Is it
sufficient to do a "make build" in the standard cvs/extras/seamonkey/FC-4 directory?

Will such a build end up on the fedora legacy server?

If this is wrong, could you please point me to a document that explains where to
build Extra packages for Legacy? I couldn't find it.


> I will put in a Bugzilla (infrastructure) Bug to add "Seamonkey" as a 
> component for all Legacy releases so this bug can be properly filed.  

Yes, this bug is really meant to be about seamonkey, but as of today, the
seamonkey product is not yet available in Legacy. Or should I still file this
bug against extras?

Changing component to seamonkey, as this was added yesterday or so to the
Bugzilla system.  Thanks, Jesse!

Kai, we're doing some work in Legacy to help open up access for folks to
be able to build packages in an environment like Fedora Extras has -- even-
tually down to even using the same build server infrastructure that Extras
now uses.

However, Legacy's current build team for quite a while has had its own
independent build server, which we are still using.   We are in the pro-
cess of getting to know how CVS works and more about the details of buil-
ding packages in a similar if not nearly identical way that Extras does
it.  I for one am a CVS newbie though.  Legacy folks have been used to
unpacking, repacking, and passing around .src.rpm's for Legacy's QA
activities.

Although we are in the process of migrating to a more extras-like
environment in Legacy, I am not sure how technically far along the
process we are in doing so.  Jesse Keating is the man-in-the-know in
that regard.  I believe Jesse is trying to balance a desire to get 
everything moved to Fedora infrastructure with the fact that there are
a number of people that need to get accustomed to what to us is a new
way of doing things.

Because some other packages in the Fedora Core depend on libraries
provided by Mozilla, and because we are not sure of which and/or how many
Mozilla &c vulnerabilties may lie within the libraries that Mozilla pro-
vides to other packages in Core, I believe we ought to be more interested
in creating replacement packages for Mozilla using seamonkey.  At least
'yelp' and the 'epiphany' browser depend upon Mozilla libraries, but there
may be other packages in Core that do too.

You might be interested in knowing, Kai, that Michal Jaegermann, a Fedora
Legacy contributor, has created a replacement seamonkey srpm package for
FC4.  His email to the fedora-legacy-list about it can be found here:
<http://www.redhat.com/archives/fedora-legacy-list/2006-September/msg00019.html>


Kai, do you have access to Fedora Legacy's cvs?  An example command that I 
was given to access (checkout) a package from that cvs:
   cvs -d :ext:<user>@cvs.fedora.redhat.com:/cvs/legacy co <package>

which should check out the Fedora Core 3 & 4 cvs stuff for <package>.

If you have access, I would welcome your checking in seamonkey 1.0.5
sources and patches and a spec-file there.  After you do that, we can
tweak the spec-file to turn seamonkey into a replacement seamonkey
version for our FC4 and FC3 users.  Then I can build what we've come
up with on Legacy's build server, sign it with the Legacy PGP key, push
it to Legacy's updates-testing repository and ask our legacy folks to
test it.  I certainly will, especially if we can create a FC5 version
of a (replacement) seamonkey while we're at doing these others for FC4
and FC3.

If you don't have access to Legacy's cvs, you can get access by being
added to the 'cvslegacy' group through the Fedora Accounts system,
   <http://fedoraproject.org/wiki/Infrastructure/AccountSystem>.
Jesse Keating will be the one to approve your access there; I would
think that should be no problem.

Does this sound like a plan?  Thoughts / Suggestions anyone?

Thanks!

David,

thanks for your explanation. I fear the task to provide mozilla -> seamonkey
replacement packages is not a priority for me. I propose you file a separate bug
for that task, which might be everything from a little to a lot work to get it
right.

At this time my offer is limited to help getting the separate seamonkey FC4
package as is updated to 1.0.5.

I learn that you use your own build environment, and that you can use a .src.rpm
as an input.

I have produced such a source rpm and uploaded it to:
  http://kuix.de/misc/seamonkey-1.0.5-0.4.fc4.src.rpm

(Please allow 20 minutes after this post for my upload to complete)

35940238 bytes
sha1sum: f0f5ef5cd6b70504acd8124bef605443fa5792e0

In the hope this works and helps you to produce a binary update package for
seamonkey fc4.

I peeked into a spec of http://kuix.de/misc/seamonkey-1.0.5-0.4.fc4.src.rpm
from comment $5.  It does not look to me that what this produces will
work as a replacement and a security update of mozilla.  Results could
be installed side-by-side with an old mozilla, extras style, and do not
provide 'mozilla' named binary.  This leaves all problems open as it is
not possible on FC4 and earlier to delete 'mozilla'  without doing the
same with a number of other packages.  Did I miss something in that spec?
A package given in
http://www.redhat.com/archives/fedora-legacy-list/2006-September/msg00019.html
may need improvents but it does not suffer from the affliction above.

It is true that replacing 'mozilla' requires new versions/recompilation
of other things (yelp for sure, thunderbird I think, maybe more) but they
use at least mozilla provided libraries and if there are security holes
there then these old versions are affected in the same way.

You did not miss something.
I was NOT attempting to update or replace mozilla.

All this does is: provide an update to seamonkey package 1.0.4, currently
available in fedora extras.

OK, thanks, but an update to a seamonkey package from extras is, frankly,
trivial and solves zilch in installation security issues.

Yes, I realize that bug 195318 is still sitting there as NEW but it is
hard for Legacy to worry about FC5.

Michael, I have tried to get the newest Seamonkey going for FC4, FC3, but have
run into some issues.  Have you managed to get it to compile and run for
FC4 or FC3?   I think it is seamonkey 1.0.6 now....

-David

> I have tried to get the newest Seamonkey going for FC4, FC3, but have
> run into some issues.

Hard to comment about unspecified issues.  I am not aware of any
beyond a disk space needed to recompile that.  IIRC something in a 2 Gig
range.

> I think it is seamonkey 1.0.6 now....

Correct; for roughly a month now.

I do not have around FC4 or FC3 machines anymore.  Recompilation
of 1.0.6 on FC5 system (this requires some minor spec changes
as nss and nspr libraries are there "external") is not a problem.
I mean here a mozilla replacement and not keeping an obsolete component
with seamonkey-1.0.6 package from "extras" added.

OTOH I do no see what trouble can be caused by a recompilation
of RHEL current packages on FC3/4; possibly after small spec tweaks.

Also that seamonkey-1.0.5-0.4.fc4.0.mj.src.rpm I proposed in September
most likely needs just a replacement of seamonkey-1.0.5.source.tar.bz2
with seamonkey-1.0.6.source.tar.bz2, small edits in a spec file
and it should compile (or very nearly so) AFAICT.

Thanks, Michael!  I don't know why I hadn't thought to use your source 
packages as a baseline!  Duh!  :)

I'll go and do that now.  Thanks!

Although the Legacy project is supposed to be shutting down, I thought I
would try to get Seamonkey going as a Mozilla replacement at least for our
FC4 users.

There are build problems.  Although much of the build seems to go okay,
it gets hung up on a linking step while compiling for the x86_64 architec-
ture.  It might compile for the i386 arch, but it doesn't get that far in
mock/plague, evidentally plague's deciding to abort any other builds in
process if one arch it's building for fails.

The error that it reports is:

> c++ -I/usr/X11R6/include -fno-rtti -fno-exceptions -Wall -Wconversion -
Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-
privacy -Wno-non-virtual-dtor -Wno-long-long -pedantic -g -fshort-wchar -
pthread -pipe  -DNDEBUG -DTRIMMED -O2 -fPIC -shared -Wl,-h -Wl,libmozz.so -o 
libmozz.so  adler32.o compress.o crc32.o deflate.o gzio.o infback.o inffast.o 
inflate.o inftrees.o trees.o uncompr.o zutil.o        -ldl -lm    
> /usr/bin/ld: deflate.o: relocation R_X86_64_PC32 against 
`memcpy@@GLIBC_2.2.5' can not be used when making a shared object; recompile 
with -fPIC
> /usr/bin/ld: final link failed: Bad value
> collect2: ld returned 1 exit status
> gmake[2]: *** [libmozz.so] Error 1

More of the log file is available here:
http://turbosphere.fedoralegacy.org/logs/fedora-4-core/188-seamonkey-1.0.6-
0.4.fc4.legacy/x86_64/build.log

and the .src.rpm is here:

http://turbosphere.fedoralegacy.org/logs/fedora-4-core/188-seamonkey-1.0.6-
0.4.fc4.legacy/seamonkey-1.0.6-0.4.fc4.legacy.src.rpm

Anyone have any clues?     -David

Fedora Core 4 is now completely unmaintained. These bugs can't be fixed in that
version. If the issue still persists in current Fedora Core, please reopen.
Thank you, and sorry about this.