Red Hat Bugzilla – Full Text Bug Listing
|Summary:||seamonkey < 1.0.5 multiple vulnerabilities; to replace Mozilla|
|Product:||[Retired] Fedora Legacy||Reporter:||Ville Skyttä <scop>|
|Component:||seamonkey||Assignee:||Fedora Legacy Bugs <bugs>|
|Status:||CLOSED CANTFIX||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||fc4||CC:||dcantrell, deisenst, extras-qa, fedora-security-list, kengert, michal|
|Whiteboard:||LEGACY, rh73, rh90, 1, 2, 3, 4, discuss, NEEDSWORK|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2007-04-10 15:40:00 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Ville Skyttä 2006-10-03 13:58:32 EDT
seamonkey 1.0.4 in FE4 is probably affected by CVE-2006-4253, CVE-2006-4340, CVE-2006-4565, CVE-2006-4566, CVE-2006-4568, CVE-2006-4570 and CVE-2006-4571. According to upstream, these are fixed in 1.0.5 (FE5+)
Comment 1 Kai Engert (:kaie) 2006-10-06 20:52:00 EDT
-> 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?
Comment 2 David Eisenstein 2006-10-07 08:53:48 EDT
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?
Comment 3 Kai Engert (:kaie) 2006-10-18 23:29:05 EDT
(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?
Comment 4 David Eisenstein 2006-10-21 02:08:56 EDT
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!
Comment 5 Kai Engert (:kaie) 2006-11-02 12:40:58 EST
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.
Comment 6 Michal Jaegermann 2006-11-03 09:44:11 EST
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.
Comment 7 Kai Engert (:kaie) 2006-11-03 09:52:41 EST
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.
Comment 8 Michal Jaegermann 2006-11-03 11:56:08 EST
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.
Comment 9 David Eisenstein 2006-12-03 19:17:08 EST
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
Comment 10 Michal Jaegermann 2006-12-03 19:49:04 EST
> 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.
Comment 11 David Eisenstein 2006-12-05 08:39:05 EST
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!
Comment 12 David Eisenstein 2006-12-18 16:37:34 EST
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: *** [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
Comment 13 Matthew Miller 2007-04-10 15:40:00 EDT
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.