From davej at redhat.com Thu Jul 1 18:09:55 2004 From: davej at redhat.com (Dave Jones) Date: Thu, 1 Jul 2004 19:09:55 +0100 Subject: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow Message-ID: <20040701180955.GA4627@redhat.com> This turned up on bugtraq a few days ago, which affects RHL. The same driver was in FC1. I went to go look into fixing this, and found a whole bunch of stuff that almost made me lose my lunch. For FC1, I've not heard a single complaint about this (which means it's either perfect[after reading the code, I very much doubt it], or no-one uses it). For this reason, I'm going to drop it in the next FC1 update. If someone heroic wants to fix it up for RHL, feel free, but this is unlikely to happen in FC, as it was one of the 'we had this in rhl, lets drag it along for fc too'. It never made it into FC2 either, and no-one complained. This hardware is so 'niche' that I doubt anyone will complain if you dropped it from RHL too. Worse case, someone can grab the driver from broadcom if they feel like its worth it. Dave -------------- next part -------------- An embedded message was scrubbed... From: infamous41md at hotpop.com Subject: Linux Broadcom 5820 Cryptonet Driver Integer Overflow Date: Wed, 23 Jun 2004 15:20:59 -0400 Size: 6177 URL: From marcdeslauriers at videotron.ca Thu Jul 1 19:24:44 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 01 Jul 2004 15:24:44 -0400 Subject: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow In-Reply-To: <20040701180955.GA4627@redhat.com> References: <20040701180955.GA4627@redhat.com> Message-ID: <1088709884.23666.2.camel@mdlinux> On Thu, 2004-07-01 at 14:09, Dave Jones wrote: > For FC1, I've not heard a single complaint about this (which > means it's either perfect[after reading the code, I very much > doubt it], or no-one uses it). For this reason, I'm going to drop > it in the next FC1 update. Are you going to drop it in RHEL as well? Marc. From whooperhsd3 at earthlink.net Thu Jul 1 20:10:49 2004 From: whooperhsd3 at earthlink.net (William Hooper) Date: Thu, 1 Jul 2004 16:10:49 -0400 (EDT) Subject: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow In-Reply-To: <1088709884.23666.2.camel@mdlinux> References: <20040701180955.GA4627@redhat.com> <1088709884.23666.2.camel@mdlinux> Message-ID: <4671.12.29.16.103.1088712649.squirrel@12.29.16.103> Marc Deslauriers said: > On Thu, 2004-07-01 at 14:09, Dave Jones wrote: > >> For FC1, I've not heard a single complaint about this (which >> means it's either perfect[after reading the code, I very much doubt it], >> or no-one uses it). For this reason, I'm going to drop it in the next >> FC1 update. >> > > Are you going to drop it in RHEL as well? Is it in RHEL? I don't see it on my RHEL 3 WS install (or in kernel-unsupported). -- William Hooper From marcdeslauriers at videotron.ca Thu Jul 1 21:18:01 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 01 Jul 2004 17:18:01 -0400 Subject: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow In-Reply-To: <4671.12.29.16.103.1088712649.squirrel@12.29.16.103> References: <20040701180955.GA4627@redhat.com> <1088709884.23666.2.camel@mdlinux> <4671.12.29.16.103.1088712649.squirrel@12.29.16.103> Message-ID: <1088716681.26078.1.camel@mdlinux> On Thu, 2004-07-01 at 16:10, William Hooper wrote: > Is it in RHEL? I don't see it on my RHEL 3 WS install (or in kernel-unsupported). If I'm looking right, it's in RHEL 2.1. Marc. From davej at redhat.com Fri Jul 2 00:56:04 2004 From: davej at redhat.com (Dave Jones) Date: Fri, 2 Jul 2004 01:56:04 +0100 Subject: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow In-Reply-To: <1088709884.23666.2.camel@mdlinux> References: <20040701180955.GA4627@redhat.com> <1088709884.23666.2.camel@mdlinux> Message-ID: <20040702005604.GA4865@redhat.com> On Thu, Jul 01, 2004 at 03:24:44PM -0400, Marc Deslauriers wrote: > On Thu, 2004-07-01 at 14:09, Dave Jones wrote: > > For FC1, I've not heard a single complaint about this (which > > means it's either perfect[after reading the code, I very much > > doubt it], or no-one uses it). For this reason, I'm going to drop > > it in the next FC1 update. > > Are you going to drop it in RHEL as well? Not my call to make. I had no idea it was in our enterprise products. I'll ping Jason & Ernie, and see what they intend to do. If it does get fixed up, I've no objection to readding it later, but if its a fedora only thing, I'd rather devote my time to something more productive than fixing up a driver a half dozen people use. Dave From marcdeslauriers at videotron.ca Fri Jul 2 03:50:18 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 01 Jul 2004 23:50:18 -0400 Subject: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow In-Reply-To: <20040702005604.GA4865@redhat.com> References: <20040701180955.GA4627@redhat.com> <1088709884.23666.2.camel@mdlinux> <20040702005604.GA4865@redhat.com> Message-ID: <1088740218.32601.2.camel@mdlinux> On Thu, 2004-07-01 at 20:56, Dave Jones wrote: > If it does get fixed up, I've no objection to readding it later, > but if its a fedora only thing, I'd rather devote my time to something > more productive than fixing up a driver a half dozen people use. I was just curious, that's all. Dropping it is a good idea. Thanks for the heads up on this issue by the way, it's greatly appreciated. Marc. From jkeating at j2solutions.net Fri Jul 2 05:27:03 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 1 Jul 2004 22:27:03 -0700 Subject: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow In-Reply-To: <1088740218.32601.2.camel@mdlinux> References: <20040701180955.GA4627@redhat.com> <20040702005604.GA4865@redhat.com> <1088740218.32601.2.camel@mdlinux> Message-ID: <200407012227.03391.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 01 July 2004 20:50, Marc Deslauriers wrote: > I was just curious, that's all. Dropping it is a good idea. > > Thanks for the heads up on this issue by the way, it's greatly > appreciated. Totally! I plan on dropping that module. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA5PIn4v2HLvE71NURAnLNAJ496u0HxNwxFXOW+fcgsBPeBUpViQCdF0QY 7PBJcMXHtslLFTLL/ojBuUk= =gWqS -----END PGP SIGNATURE----- From J.S.Peatfield at damtp.cam.ac.uk Fri Jul 2 13:17:53 2004 From: J.S.Peatfield at damtp.cam.ac.uk (Jon Peatfield) Date: Fri, 02 Jul 2004 14:17:53 +0100 Subject: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow Message-ID: I see that the new fc1 kernel-2.4.22-1.2197 also includes the nfs fchown fix too though I can't seem to download that src.rpm and the mirrors don't have it yet (well not the ones I've looked at anyway). Does anyone have a pointer just to the patch(es) to fix the nfs problem and disable the Broadcom driver? From J.S.Peatfield at damtp.cam.ac.uk Fri Jul 2 14:00:23 2004 From: J.S.Peatfield at damtp.cam.ac.uk (Jon Peatfield) Date: Fri, 02 Jul 2004 15:00:23 +0100 Subject: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow Message-ID: Ignore that I found a mirror, the patch is indeed tiny. Anyone care to comment on a proposed set of changes to 2.4.20-35.x.legacy? diff -urwN ../rpmbuild.jp107/SOURCES/linux-2.4.18-missing-license-tags.patch ./SOURCES/linux-2.4.18-missing-license-tags.patch --- ../rpmbuild.jp107/SOURCES/linux-2.4.18-missing-license-tags.patch 2003-12-09 22:31:06.000000000 +0000 +++ ./SOURCES/linux-2.4.18-missing-license-tags.patch 2004-07-02 14:50:38.000000000 +0100 @@ -21,15 +21,15 @@ static char *driver_name = "SyncLink PC Card driver"; static char *driver_version = "$Revision: 3.4 $"; -diff -urNp linux-10020/drivers/crypto/bcm/dispatch.c linux-10030/drivers/crypto/bcm/dispatch.c ---- linux-10020/drivers/crypto/bcm/dispatch.c -+++ linux-10030/drivers/crypto/bcm/dispatch.c -@@ -562,3 +562,5 @@ extern void Linux_FreeDMAMemory(void * - - return; - } -+ -+MODULE_LICENSE("GPL"); +#diff -urNp linux-10020/drivers/crypto/bcm/dispatch.c linux-10030/drivers/crypto/bcm/dispatch.c +#--- linux-10020/drivers/crypto/bcm/dispatch.c +#+++ linux-10030/drivers/crypto/bcm/dispatch.c +#@@ -562,3 +562,5 @@ extern void Linux_FreeDMAMemory(void * +# +# return; +# } +#+ +#+MODULE_LICENSE("GPL"); diff -urNp linux-10020/drivers/net/hamradio/soundmodem/sm.c linux-10030/drivers/net/hamradio/soundmodem/sm.c --- linux-10020/drivers/net/hamradio/soundmodem/sm.c 2001-04-18 23:40:05.000000000 +0200 +++ linux-10030/drivers/net/hamradio/soundmodem/sm.c diff -urwN ../rpmbuild.jp107/SOURCES/linux-2.4.27pre-nfs-fchown.patch ./SOURCES/linux-2.4.27pre-nfs-fchown.patch --- ../rpmbuild.jp107/SOURCES/linux-2.4.27pre-nfs-fchown.patch 1970-01-01 01:00:00.000000000 +0100 +++ ./SOURCES/linux-2.4.27pre-nfs-fchown.patch 2004-07-02 14:44:46.000000000 +0100 @@ -0,0 +1,12 @@ +--- linux-2.4.22/fs/attr.c~ 2004-07-01 17:24:21.707391872 +0100 ++++ linux-2.4.22/fs/attr.c 2004-07-01 17:24:40.733499464 +0100 +@@ -33,7 +33,8 @@ + + /* Make sure caller can chgrp. */ + if ((ia_valid & ATTR_GID) && +- (!in_group_p(attr->ia_gid) && attr->ia_gid != inode->i_gid) && ++ (current->fsuid != inode->i_uid || ++ (!in_group_p(attr->ia_gid) && attr->ia_gid != inode->i_gid)) && + !capable(CAP_CHOWN)) + goto error; + diff -urwN ../rpmbuild.jp107/SPECS/kernel-2.4.spec ./SPECS/kernel-2.4.spec --- ../rpmbuild.jp107/SPECS/kernel-2.4.spec 2004-06-23 16:00:44.000000000 +0100 +++ ./SPECS/kernel-2.4.spec 2004-07-02 14:48:34.000000000 +0100 @@ -21,7 +21,7 @@ # that the kernel isn't the stock RHL kernel, for example by # adding some text to the end of the version number. # -%define release 35.9.legacy +%define release 36.9.legacy %define sublevel 20 %define kversion 2.4.%{sublevel} # /usr/src/%{kslnk} -> /usr/src/linux-%{KVERREL} @@ -292,6 +292,7 @@ Patch970: linux-2.4.25pre-selected-patches.legacy.patch Patch980: linux-2.4.26pre-selected-patches.legacy.patch Patch990: linux-2.4.27pre-fix-x86-clear_fpu-macro.patch +Patch991: linux-2.4.27pre-nfs-fchown.patch # # Patches 1000 to 5000 are reserved for bugfixes to drivers and filesystems @@ -760,6 +761,9 @@ # Local DoS fix in clear_fpu macro %patch990 -p1 +# Fix NFS fchown bug +%patch991 -p1 + # # Patches 1000 to 5000 are reserved for bugfixes to drivers and filesystems # @@ -1129,12 +1133,14 @@ %patch5030 -p1 # ECC reporting module %patch5050 -p1 -# Broadcom 5820 driver -%patch5090 -p1 -%patch5091 -p1 -%patch5092 -p1 -%patch5093 -p1 -%patch5094 -p1 +# Disable Broadcom driver at least until there is a proper fix +## Broadcom 5820 driver +#%patch5090 -p1 +#%patch5091 -p1 +#%patch5092 -p1 +#%patch5093 -p1 +#%patch5094 -p1 + # iSCSI driver, and fix %patch5120 -p1 @@ -1948,6 +1954,10 @@ # %changelog +* Thu Jul 1 2004 Dave Jones +- add patch to fix missing checks in fchown() (CAN-2004-0497) +- Drop Broadcom 5820 driver due to code quality concerns. + * Fri Jun 18 2004 Dominic Hargreaves - Fix memory leak in kernel/fork.c. (CAN-2004-0427) - Numerous userspace pointer reference bugs found with the sparse I'll build this up shortly and let people know what I get... -- Jon From dom at earth.li Fri Jul 2 14:14:20 2004 From: dom at earth.li (Dominic Hargreaves) Date: Fri, 2 Jul 2004 15:14:20 +0100 Subject: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow In-Reply-To: References: Message-ID: <20040702141419.GU30964@tirian.magd.ox.ac.uk> On Fri, Jul 02, 2004 at 03:00:23PM +0100, Jon Peatfield wrote: > Ignore that I found a mirror, the patch is indeed tiny. Anyone care > to comment on a proposed set of changes to 2.4.20-35.x.legacy? It shouldn't be allowed to delay the release of 35.x. What is the fsync problem, anyway? I can't find any reference to it with a quick google. Cheers, Dominic. From jkeating at j2solutions.net Fri Jul 2 14:37:45 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 2 Jul 2004 07:37:45 -0700 Subject: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow In-Reply-To: <20040702141419.GU30964@tirian.magd.ox.ac.uk> References: <20040702141419.GU30964@tirian.magd.ox.ac.uk> Message-ID: <200407020737.45757.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 02 July 2004 07:14, Dominic Hargreaves wrote: > It shouldn't be allowed to delay the release of 35.x. What is the fsync > problem, anyway? I can't find any reference to it with a quick google. No, but the newly announced CVE should delay the release: During an audit of the Linux kernel, SUSE discovered a flaw that allowed a user to make unauthorized changes to the group ID of files in certain circumstances. In the 2.4 kernel, as shipped with Fedora Core 1, the only way this could happen is through the kernel nfs server. A user on a system that mounted a remote file system from a vulnerable machine may be able to make unauthorized changes to the group ID of exported files. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0497 to this issue. Only Fedora Core 1 systems that are configured to share file systems via NFS are affected by this issue. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA5XM54v2HLvE71NURAvJHAKCZovEFYj815VVyGMsT8MogZB2eTACdFshy F+nd5R3ydiO0wovtOw+OqVs= =hBwS -----END PGP SIGNATURE----- From dom at earth.li Fri Jul 2 14:57:23 2004 From: dom at earth.li (Dominic Hargreaves) Date: Fri, 2 Jul 2004 15:57:23 +0100 Subject: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow In-Reply-To: <200407020737.45757.jkeating@j2solutions.net> References: <20040702141419.GU30964@tirian.magd.ox.ac.uk> <200407020737.45757.jkeating@j2solutions.net> Message-ID: <20040702145723.GV30964@tirian.magd.ox.ac.uk> On Fri, Jul 02, 2004 at 07:37:45AM -0700, Jesse Keating wrote: > No, but the newly announced CVE should delay the release: I disagree. 35.x should get out the door first. There will be more and more issues that need to be address; I've already explained my thoughts behind this before: the thing will snowball, and already has done. At this rate the kernel work is becoming useless. Dominic. From michal at harddata.com Fri Jul 2 15:07:03 2004 From: michal at harddata.com (Michal Jaegermann) Date: Fri, 2 Jul 2004 09:07:03 -0600 Subject: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow In-Reply-To: <20040702145723.GV30964@tirian.magd.ox.ac.uk>; from dom@earth.li on Fri, Jul 02, 2004 at 03:57:23PM +0100 References: <20040702141419.GU30964@tirian.magd.ox.ac.uk> <200407020737.45757.jkeating@j2solutions.net> <20040702145723.GV30964@tirian.magd.ox.ac.uk> Message-ID: <20040702090703.A19965@mail.harddata.com> On Fri, Jul 02, 2004 at 03:57:23PM +0100, Dominic Hargreaves wrote: > On Fri, Jul 02, 2004 at 07:37:45AM -0700, Jesse Keating wrote: > > > No, but the newly announced CVE should delay the release: > > I disagree. 35.x should get out the door first. I concur. The perfect is an enemy of good. There is really nothing which prevents to have a new release a few days later if urgent issues were discovered. The same applies to other security fixes which linger in various stages for a looong time (although nobody who care about these is likely to be caught running "official" by this time). Michal From simon at nzservers.com Fri Jul 2 15:11:02 2004 From: simon at nzservers.com (Simon Weller) Date: Fri, 2 Jul 2004 10:11:02 -0500 Subject: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow In-Reply-To: <20040702145723.GV30964@tirian.magd.ox.ac.uk> References: <200407020737.45757.jkeating@j2solutions.net> <20040702145723.GV30964@tirian.magd.ox.ac.uk> Message-ID: <200407021011.02448.simon@nzservers.com> I'm with Dominic on this one. It's starting to snowball badly now, and with the qa process the kernel releases get pushed out weeks. Perhaps we need to discuss some sort of ranking system on issues that come up to decide whether they should derail a release or not. I honestly think that delays on important issues (such as the user triggered kernel oops) really dilute the usefulness of the whole process, as right now there are a huge number of servers out there that can be easily crashed by Joe Bloggs because he's pissed off at his web hosting company for increasing his monthly charge by $2. We could get a kernel out now (as by the looks of it, including personal qa that it's stable), and then roll these patches, get another kernel in QA within the next couple of days and get it out late next week assuming it gets through the test process ok. My 2 cents. - Si On Friday 02 July 2004 09:57 am, Dominic Hargreaves wrote: > On Fri, Jul 02, 2004 at 07:37:45AM -0700, Jesse Keating wrote: > > No, but the newly announced CVE should delay the release: > > I disagree. 35.x should get out the door first. There will be more and > more issues that need to be address; I've already explained my thoughts > behind this before: the thing will snowball, and already has done. > > At this rate the kernel work is becoming useless. > > Dominic. > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- Simon Weller LPIC-2, BCIP Systems Engineer NZServers LTD http://www.nzservers.com/ U.S. Branch <- To mess up a Linux box, you need to work at it; to mess up your Windows box, you just need to work on it. - Scott Granneman, Security Focus -> From jkeating at j2solutions.net Fri Jul 2 15:11:41 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 2 Jul 2004 08:11:41 -0700 Subject: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow In-Reply-To: <20040702090703.A19965@mail.harddata.com> References: <20040702145723.GV30964@tirian.magd.ox.ac.uk> <20040702090703.A19965@mail.harddata.com> Message-ID: <200407020811.42003.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 02 July 2004 08:07, Michal Jaegermann wrote: > I concur. ?The perfect is an enemy of good. > > There is really nothing which prevents to have a new release a few > days later if urgent issues were discovered. ?The same applies to > other security fixes which linger in various stages for a looong > time (although nobody who care about these is likely to be caught > running "official" by this time). Ok, you talked me into it. I'll go to testing w/ the current kernel, and begin work on the next kernel. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA5Xst4v2HLvE71NURAvq6AKDCeEZ8P3KxiXNsIoJuBr3Ae2WxMwCfWXnQ ShNglzTqD+R2SaRLEE162iE= =9vaW -----END PGP SIGNATURE----- From sheltren at cs.ucsb.edu Fri Jul 2 15:13:51 2004 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Fri, 02 Jul 2004 08:13:51 -0700 Subject: Linux Broadcom 5820 Cryptonet Driver Integer Overflow In-Reply-To: <20040702145723.GV30964@tirian.magd.ox.ac.uk> Message-ID: I agree with Dominic - get the current kernel out the door first, and then tackle the new issue(s). -Jeff On 7/2/04 7:57 AM, "Dominic Hargreaves" wrote: > On Fri, Jul 02, 2004 at 07:37:45AM -0700, Jesse Keating wrote: > >> No, but the newly announced CVE should delay the release: > > I disagree. 35.x should get out the door first. There will be more and > more issues that need to be address; I've already explained my thoughts > behind this before: the thing will snowball, and already has done. > > At this rate the kernel work is becoming useless. > > Dominic. > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From lists at alpha345.com Fri Jul 2 15:31:06 2004 From: lists at alpha345.com (Matt Dickinson) Date: Fri, 2 Jul 2004 10:31:06 -0500 Subject: Self Introduction: Matthew Dickinson Message-ID: <004601c46049$98949550$6400a8c0@mdickins.dyndns.org> Hi, 1: Matthew Dickinson 2: Missouri, USA 3: Systems Administrator/Programmer 4: Free-Lance 5: RH 8/9 doing Q/A 6: Submitted minor patches to various Open Source projects. C/PHP/Java. I don't expect to be trusted at first, but earn the trust by good work. 7: 7DDD BA0E 60DF A351 9058 C44D 390F 8F3F 2FDF 3938 and 2FDF3938 Thanks, Matt From dom at earth.li Fri Jul 2 15:35:36 2004 From: dom at earth.li (Dominic Hargreaves) Date: Fri, 2 Jul 2004 16:35:36 +0100 Subject: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow In-Reply-To: References: Message-ID: <20040702153536.GX30964@tirian.magd.ox.ac.uk> On Fri, Jul 02, 2004 at 03:00:23PM +0100, Jon Peatfield wrote: > Ignore that I found a mirror, the patch is indeed tiny. Anyone care > to comment on a proposed set of changes to 2.4.20-35.x.legacy? Patch looks okay, if a little messy, but: > %changelog > +* Thu Jul 1 2004 Dave Jones ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Your name here! Although it's perfectly correct to acknowledge Dave, he didn't make the modification to this package, and to say that he did would be confusing IMO. Cheers, Dominic. From J.S.Peatfield at damtp.cam.ac.uk Fri Jul 2 15:58:02 2004 From: J.S.Peatfield at damtp.cam.ac.uk (Jon Peatfield) Date: Fri, 02 Jul 2004 16:58:02 +0100 Subject: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow Message-ID: I didn't follow-up to the list earlier 'cos I hoped that people would take it as fairly obvious that I also don't think that should delay release of the 2.4.20-35.x.legacy update kernels (and I even said so in the bugzilla for 1804). None of the "obvious" tests I carried out with the existing nfs server code allowed me to chgrp a file I didn't own, so I'm not exactly sure under what circumstances the is actually exploitable anyway (maybe it needs root-squash turning off or something, in which case it would only affect hosts you nfs export (rw) to which are untrustworthy). Does anyone actually know the circumstances which can trigger a problem? [ I now have built (one) RH9 kernel with the fchown fix and am running it on a test box... ] Maybe now would be a good time to start thinking about moving (in a few months maybe) to a kernel tree based on 2.4.26/27pre just to reduce the total number of overlapping patches. Now that 2.4 is firmly in "maintenance mode" there won't be any new features added so it should be possible to remove a great number of the existing patches just by using a more modern starting point. e.g. the number of patches in fc1 (based on 2.4.22) is ~106 while we have ~182 in 2.4.20-35.x.legacy Of course without understanding what _all_ of the patches are doing it is always a bit risky to decide which would still need to stay or be changed to be relevant against 2.4.26/27... Currently RedHat (etc) are maintaining kernels based on: RHEL 2.1 2.4.9 RHEL 3 2.4.21 Fedora are maintaining 2.4.22 for fc1 and we have 2.4.20 for RH73/80/9 etc. Wouldn't it make sense to produce a srpm which would be usable for all these systems once fc1 stops being maintained by Fedora? [ I know this will be a lot of work of course! ] -- Jon From J.S.Peatfield at damtp.cam.ac.uk Fri Jul 2 16:04:35 2004 From: J.S.Peatfield at damtp.cam.ac.uk (Jon Peatfield) Date: Fri, 02 Jul 2004 17:04:35 +0100 Subject: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow Message-ID: > Patch looks okay, if a little messy, but: Feel free to improve it! > > %changelog > > +* Thu Jul 1 2004 Dave Jones > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Your name here! Although it's perfectly correct to acknowledge Dave, > he didn't make the modification to this package, and to say that he > did would be confusing IMO. Oops, I just cut/pasted the changelog right out of the fc1 update and didn't even read that bit very carefully. I just wanted a new changelog showing that a change had been made. It was only intended as a suggested patch anyway! I'll correct it to: * Fri Jul 2 2004 Jon Peatfield - loosely based on fc1 changes by Dave Jones - add patch to fix missing checks in fchown() (CAN-2004-0497) - Drop Broadcom 5820 driver due to code quality concerns. -- Jon From jkeating at j2solutions.net Fri Jul 2 16:04:39 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 2 Jul 2004 09:04:39 -0700 Subject: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow In-Reply-To: References: Message-ID: <200407020904.42401.jkeating@j2solutions.net> On Friday 02 July 2004 08:58, Jon Peatfield wrote: > Currently RedHat (etc) are maintaining kernels based on: > > RHEL 2.1 2.4.9 > RHEL 3 2.4.21 > > Fedora are maintaining 2.4.22 for fc1 > > and we have 2.4.20 for RH73/80/9 etc. > > Wouldn't it make sense to produce a srpm which would be usable for > all these systems once fc1 stops being maintained by Fedora? > > [ I know this will be a lot of work of course! ] I don't think I can agree to this. Too much of a change, and it goes against our policy of change as little as possible. If people want a newer kernel, they can either upgrade their base OS, or handle the kernel themselves. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From wstockal at compusmart.ab.ca Fri Jul 2 16:15:35 2004 From: wstockal at compusmart.ab.ca (William Stockall) Date: Fri, 02 Jul 2004 10:15:35 -0600 Subject: Some sort of freeze process? Message-ID: <40E58A27.5000308@compusmart.ab.ca> Should people consider some sort of process for freezing packages which are to be released? For example, all this discussion of whether to include yet another patch in the kernel. What probably should happen is a package is frozen for release testing. After that the only changes that go in are for problems introduced due to the proposed updates. Any further patches should go into the next release. Thoughts? Will. From simon at nzservers.com Fri Jul 2 16:22:34 2004 From: simon at nzservers.com (Simon Weller) Date: Fri, 2 Jul 2004 11:22:34 -0500 Subject: Some sort of freeze process? In-Reply-To: <40E58A27.5000308@compusmart.ab.ca> References: <40E58A27.5000308@compusmart.ab.ca> Message-ID: <200407021122.34412.simon@nzservers.com> On Friday 02 July 2004 11:15 am, William Stockall wrote: > Should people consider some sort of process for freezing packages which > are to be released? For example, all this discussion of whether to > include yet another patch in the kernel. What probably should happen is > a package is frozen for release testing. After that the only changes > that go in are for problems introduced due to the proposed updates. Any > further patches should go into the next release. > > > Thoughts? > yep I agree Will. That's kind of what I suggested a few hours ago as far as how crucial the patch is. Obviously if a massive root compromise comes out, it makes sense to patch it, but for everything else a freeze is logical. - Si > > Will. > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- Simon Weller LPIC-2, BCIP Systems Engineer NZServers LTD http://www.nzservers.com/ U.S. Branch <- To mess up a Linux box, you need to work at it; to mess up your Windows box, you just need to work on it. - Scott Granneman, Security Focus -> From jkeating at j2solutions.net Fri Jul 2 16:23:12 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 2 Jul 2004 09:23:12 -0700 Subject: Some sort of freeze process? In-Reply-To: <40E58A27.5000308@compusmart.ab.ca> References: <40E58A27.5000308@compusmart.ab.ca> Message-ID: <200407020923.12411.jkeating@j2solutions.net> On Friday 02 July 2004 09:15, William Stockall wrote: > Should people consider some sort of process for freezing packages > which are to be released? For example, all this discussion of > whether to include yet another patch in the kernel. What probably > should happen is a package is frozen for release testing. After that > the only changes that go in are for problems introduced due to the > proposed updates. Any further patches should go into the next > release. > > > Thoughts? In all honesty, the first time a package hits updates-testing, thats when it should be considered to be frozen. We just got greedy w/ the kernel package and kept adding stuff into it. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From davej at redhat.com Fri Jul 2 19:25:21 2004 From: davej at redhat.com (Dave Jones) Date: Fri, 2 Jul 2004 20:25:21 +0100 Subject: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow In-Reply-To: References: Message-ID: <20040702192521.GK7101@redhat.com> On Fri, Jul 02, 2004 at 02:17:53PM +0100, Jon Peatfield wrote: > I see that the new fc1 kernel-2.4.22-1.2197 also includes the nfs > fchown fix too though I can't seem to download that src.rpm and the > mirrors don't have it yet (well not the ones I've looked at anyway). > > Does anyone have a pointer just to the patch(es) to fix the nfs > problem and disable the Broadcom driver? fchown was this... --- linux-2.4.22/fs/attr.c~ 2004-07-01 17:24:21.707391872 +0100 +++ linux-2.4.22/fs/attr.c 2004-07-01 17:24:40.733499464 +0100 @@ -33,7 +33,8 @@ /* Make sure caller can chgrp. */ if ((ia_valid & ATTR_GID) && - (!in_group_p(attr->ia_gid) && attr->ia_gid != inode->i_gid) && + (current->fsuid != inode->i_uid || + (!in_group_p(attr->ia_gid) && attr->ia_gid != inode->i_gid)) && !capable(CAP_CHOWN)) goto error; The broadcom bit was disabling teh bcm5820 patch in the kernel-2.4.spec file Dave From marcdeslauriers at videotron.ca Fri Jul 2 20:17:34 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Fri, 02 Jul 2004 16:17:34 -0400 Subject: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow In-Reply-To: References: Message-ID: <1088799454.17049.14.camel@mdlinux> On Fri, 2004-07-02 at 11:58, Jon Peatfield wrote: > Maybe now would be a good time to start thinking about moving (in a > few months maybe) to a kernel tree based on 2.4.26/27pre just to > reduce the total number of overlapping patches. > This would be a major undertaking. For starters, someone would have to backport nptl to work with 2.4.26/27, which would not be an easy task... Besides, it's not FL's mission to evolve the old releases, just to patch them. > Currently RedHat (etc) are maintaining kernels based on: > > RHEL 2.1 2.4.9 > RHEL 3 2.4.21 > > Fedora are maintaining 2.4.22 for fc1 > > and we have 2.4.20 for RH73/80/9 etc. > > Wouldn't it make sense to produce a srpm which would be usable for all > these systems once fc1 stops being maintained by Fedora? FL will only have to maintain two when fc1 stops being maintained by RH: 2.4.20 and 2.4.22. Marc. From rostetter at mail.utexas.edu Sat Jul 3 03:20:40 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 2 Jul 2004 22:20:40 -0500 Subject: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow In-Reply-To: <200407020737.45757.jkeating@j2solutions.net> References: <20040702141419.GU30964@tirian.magd.ox.ac.uk> <200407020737.45757.jkeating@j2solutions.net> Message-ID: <20040702222040.bgxcsg4oscw8swgo@mail.ph.utexas.edu> Quoting Jesse Keating : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Friday 02 July 2004 07:14, Dominic Hargreaves wrote: >> It shouldn't be allowed to delay the release of 35.x. What is the fsync >> problem, anyway? I can't find any reference to it with a quick google. > > No, but the newly announced CVE should delay the release: Why? Why delay important fixes because of other important fixes which will need additional QA testing and possible, probably really, delay the whole process? In other words: * Leave the current test kernel alone and available for QA testing. * Start a new kernel with the new patches, start it in the QA process. * If the first kernel finishes QA before the second, release it first. * If the second kernel finishes QA first, release it and kill off the other. The current kernel keeps getting more and more delayed as we add more and more patches, which makes it harder and harder to test properly... Just my opinion, feel free to ignore it. -- Eric Rostetter From rostetter at mail.utexas.edu Sat Jul 3 03:39:02 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 2 Jul 2004 22:39:02 -0500 Subject: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow In-Reply-To: References: Message-ID: <20040702223902.s338kgw4408cgk8o@mail.ph.utexas.edu> Quoting Jon Peatfield : > Maybe now would be a good time to start thinking about moving (in a > few months maybe) to a kernel tree based on 2.4.26/27pre just to > reduce the total number of overlapping patches. Unless we find that patch conflicts are causing build/maintenance problems for us, I don't see this as a positive move. > Now that 2.4 is firmly in "maintenance mode" there won't be any new > features added so it should be possible to remove a great number of > the existing patches just by using a more modern starting point. While new features won't be added now, have they already been added between our starting point and now? If so, it kind of goes against our policy, unless it facilitates our continued support of the kernel. > Of course without understanding what _all_ of the patches are doing it > is always a bit risky to decide which would still need to stay or be > changed to be relevant against 2.4.26/27... Sounds like maybe we don't need to take that risk... So, unless we have problems with conflicting patches, I'd say stay with what we have. If we go newer than RHEL 3, then our job becomes tougher as we can't take advantage of Red Hat's patches. Staying with our base, or moving only to the RHEL 3 version, gives us 3 years of using RHEL as an aide to our patches. Going newer means we would be on our own much more often... -- Eric Rostetter From davej at redhat.com Sat Jul 3 13:21:01 2004 From: davej at redhat.com (Dave Jones) Date: Sat, 03 Jul 2004 14:21:01 +0100 Subject: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow In-Reply-To: <1088799454.17049.14.camel@mdlinux> References: <1088799454.17049.14.camel@mdlinux> Message-ID: <1088860861.11235.8.camel@delerium.codemonkey.org.uk> On Fri, 2004-07-02 at 21:17, Marc Deslauriers wrote: > On Fri, 2004-07-02 at 11:58, Jon Peatfield wrote: > > Maybe now would be a good time to start thinking about moving (in a > > few months maybe) to a kernel tree based on 2.4.26/27pre just to > > reduce the total number of overlapping patches. > > > > This would be a major undertaking. For starters, someone would have to > backport nptl to work with 2.4.26/27, which would not be an easy task... I did actually intend to do a rebase a while ago when 2.4.25 was current, as it would've meant being able to drop a bunch of patches. (And back then, I was hoping it would fix the 'fc1 smp crashes randomly' bug as folks reported 2.4.25 fixed it for them -- this was before the lowlatency problem was discovered). I spent 2-3 days working off and on battling rejects, and didn't even get close to finishing. I think I may have fixed up the rejects in NPTL and started on execshield. I've no idea if it even would've booted, there's always the danger of introducing new bugs when you rebase to a newer release due to interactions with code in other parts of the kernel which have changed without you realising, or just simple introductions of typos. I gave up in the end (and before anyone asks, I don't have the work-in-progress stuff I did any more). The really invasive patches in FC1 are 2.4.22-ac, NPTL, Exec-shield and the O(1) process scheduler. The -ac patch could probably be dropped with a rebase (apart from maybe a handful of fixes). There is no newer NPTL patch (and there isn't likely to be, as Ingo has enough on his plate). A newer exec-shield exists, and shouldn't be too hard a merge after a rebase. The real painful bit is NPTL. Thankfully from FC2 onwards, support after EOL should be a lot easier for you folks due to the small number of patches, and also do to us constantly tracking upstream anyway. > > Fedora are maintaining 2.4.22 for fc1 > > and we have 2.4.20 for RH73/80/9 etc. > FL will only have to maintain two when fc1 stops being maintained by RH: > 2.4.20 and 2.4.22. One thing I did have planned at one point was to migrate RHL to the FC1 kernel before end of life. I never managed to nail enough critical bugs before end of life of RHL9 though, so this never happened. Todays FC1 kernel is in much better shape, so at some point, you may want to consider it as an update for RHL9. All the nptl switches and the like are still present in the kernel spec too, allowing you to use it for RHL7 updates if desired. (caveat: I've not tried using one of these kernels -- or even built one, so I've no idea if this will just work out of the box). Dave From simon at nzservers.com Sat Jul 3 15:01:44 2004 From: simon at nzservers.com (Simon Weller) Date: Sat, 3 Jul 2004 10:01:44 -0500 Subject: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow In-Reply-To: <1088860861.11235.8.camel@delerium.codemonkey.org.uk> References: <1088799454.17049.14.camel@mdlinux> <1088860861.11235.8.camel@delerium.codemonkey.org.uk> Message-ID: <200407031001.44901.simon@nzservers.com> On Saturday 03 July 2004 08:21 am, Dave Jones wrote: > On Fri, 2004-07-02 at 21:17, Marc Deslauriers wrote: > > On Fri, 2004-07-02 at 11:58, Jon Peatfield wrote: > > > Maybe now would be a good time to start thinking about moving (in a > > > few months maybe) to a kernel tree based on 2.4.26/27pre just to > > > reduce the total number of overlapping patches. > > > > This would be a major undertaking. For starters, someone would have to > > backport nptl to work with 2.4.26/27, which would not be an easy task... > > I did actually intend to do a rebase a while ago when 2.4.25 was > current, as it would've meant being able to drop a bunch of patches. > (And back then, I was hoping it would fix the 'fc1 smp crashes randomly' > bug as folks reported 2.4.25 fixed it for them -- this was before the > lowlatency problem was discovered). > I spent 2-3 days working off and on battling rejects, and didn't even > get close to finishing. I think I may have fixed up the rejects in NPTL > and started on execshield. I've no idea if it even would've booted, > there's always the danger of introducing new bugs when you rebase to a > newer release due to interactions with code in other parts of the kernel > which have changed without you realising, or just simple introductions > of typos. > I gave up in the end (and before anyone asks, I don't have the > work-in-progress stuff I did any more). The phrase 'extremely painful' comes to mind ;-) > > The really invasive patches in FC1 are 2.4.22-ac, NPTL, Exec-shield > and the O(1) process scheduler. > The -ac patch could probably be dropped with a rebase (apart from maybe > a handful of fixes). There is no newer NPTL patch (and there isn't > likely to be, as Ingo has enough on his plate). > A newer exec-shield exists, and shouldn't be too hard a merge after > a rebase. The real painful bit is NPTL. > > Thankfully from FC2 onwards, support after EOL should be a lot > easier for you folks due to the small number of patches, and > also do to us constantly tracking upstream anyway. > > > > Fedora are maintaining 2.4.22 for fc1 > > > and we have 2.4.20 for RH73/80/9 etc. > > > > FL will only have to maintain two when fc1 stops being maintained by RH: > > 2.4.20 and 2.4.22. > > One thing I did have planned at one point was to migrate RHL to the FC1 > kernel before end of life. I never managed to nail enough critical bugs > before end of life of RHL9 though, so this never happened. > Todays FC1 kernel is in much better shape, so at some point, you may > want to consider it as an update for RHL9. All the nptl switches > and the like are still present in the kernel spec too, allowing you > to use it for RHL7 updates if desired. (caveat: I've not tried using one > of these kernels -- or even built one, so I've no idea if this will just > work out of the box). > I'll try and dig out a spare box, put 7.3 on it and give it a go...just have to find some time to do it. But ultimately the less that has to be maintained has got to be a good thing. - Si > Dave > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- Simon Weller LPIC-2, BCIP Systems Engineer NZServers LTD http://www.nzservers.com/ U.S. Branch <- To mess up a Linux box, you need to work at it; to mess up your Windows box, you just need to work on it. - Scott Granneman, Security Focus -> From jedgecombe at carolina.rr.com Sun Jul 4 14:00:20 2004 From: jedgecombe at carolina.rr.com (Jason Edgecombe) Date: Sun, 04 Jul 2004 10:00:20 -0400 Subject: Stress-testing the Linux kernel Message-ID: <40E80D74.5090403@carolina.rr.com> Hi all, Perhaps we could use kernel stress testing in addition to user testing for new kernel rpms. This might help to streanline the kernel rpm relase workflow. http://www-106.ibm.com/developerworks/linux/library/l-stress/?ca=dgr-lnxw06StressLinux Jason Edgecombe From rostetter at mail.utexas.edu Mon Jul 5 20:38:29 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 5 Jul 2004 15:38:29 -0500 Subject: yum for 8.0 In-Reply-To: References: Message-ID: <20040705153829.ypsrwocoow0k0wc8@mail.ph.utexas.edu> Quoting "N. Okan Guney" : > Retrieving > http://download.fedoralegacy.org/redhat/8.0/updates/i386/python-1.5.2-43 > .72.i386.rpm > error: skipping > http://download.fedoralegacy.org/redhat/8.0/updates/i386/python-1.5.2-43 > .72.i386.rpm - transfer failed - Unknown or unexpected error I've removed that line from the web page now. I think it should have been for python-2.x instead of python-1.x for RH 8.0. I don't think you can really install much of RH 8.0 without getting python installed, so I just left it out completely rather than putting a link to the default OS version of python in. > It seems like that package had been removed for some reason? Any > suggestions on how to proceed? It was just a typo or bad link to start with, and is now removed. If you haven't already, try again with the new directions, and let us know if you still have problems. > Thanks, > > Okan -- Eric Rostetter From jkeating at j2solutions.net Thu Jul 8 03:17:36 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 7 Jul 2004 20:17:36 -0700 Subject: Fedora Test Update Notification: kernel Message-ID: <200407072017.40625.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1484 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1484 2004-07-07 - --------------------------------------------------------------------- Name : kernel Version 7.3 : 2.4.20-35.7.legacy Version 9 : 2.4.20-35.9.legacy Summary : The Linux kernel (the core of the Linux operating system) Description : The kernel package contains the Linux kernel (vmlinuz), the core of your Red Hat Linux operating system. The kernel handles the basic functions of the operating system: memory allocation, process allocation, device input and output, etc. - --------------------------------------------------------------------- Update Information: CAN-2004-0427: The do_fork function in Linux 2.4.x and 2.6.x does not properly decrement the mm_count counter when an error occurs after the mm_struct for a child process has been activated, which triggers a memory leak that allows local users to cause a denial of service (memory exhaustion) via the clone (CLONE_VM) system call. CAN-2004-0535: The e1000 driver for Linux kernel 2.4.26 and earlier does not properly initialize memory before using it, which allows local users to read portions of kernel memory. NOTE: this issue was originally incorrectly reported as a "buffer overflow" by some sources. CAN-2004-0003: Unknown vulnerability in Linux kernel before 2.4.22 allows local users to gain privileges, related to "R128 DRI limits checking." CAN-2004-0109: Buffer overflow in the ISO9660 file system component for Linux kernel 2.4.x, 2.5.x and 2.6.x , allows local users with physical access to overflow kernel memory and execute arbitrary code via a malformed CD containing a long symbolic link entry. CAN-2004-0178: The OSS code for the Sound Blaster driver in Linux 2.4.x does not properly handle certain sample sizes, which allows local users to cause a denial of service (crash). CAN-2004-0181: The JFS file system code in Linux 2.4.x has an information leak in which in-memory data is written to the device for an ext3 file system, which allows local users to obtain sensitive information by reading the raw device. CAN-2004-0394: A "potential" buffer overflow exists in the panic() function in Linux 2.4.x, although it may not be exploitable due to the functionality of panic. A few bugfixes related to Nforce2 chipsets. - --------------------------------------------------------------------- Changelog: 7.3: * Fri Jun 18 2004 Dominic Hargreaves - - Fix memory leak in kernel/fork.c. (CAN-2004-0427) - - Numerous userspace pointer reference bugs found with the sparse tool by Al Viro. (CAN-2004-0495) - - Fix e1000 driver information leak. (CAN-2004-0535) * Tue Jun 15 2004 Dominic Hargreaves - - Fix local DoS in "clear_cpu()" macro. (CAN-2004-0554) * Thu May 13 2004 Dominic Hargreaves - - Fix information leak in cpufreq userspace ioctl. (CAN-2004-0228) - - Fix for C1 Halt Disconnect problem on nForce2 systems. * Wed May 05 2004 Dominic Hargreaves - - Fix potential local denial of service in sb16 driver (CAN-2004-0178) - - Fix information leak in JFS (CAN-2004-0181) - - Add range checking to i810_dma() in DRM driver. - - Make ioctl(FBIOGETCMAP) use copy_to_user() rather than memcpy() - - Fix possible buffer overflow in panic() (CAN-2004-0394) * Tue Apr 13 2004 Dave Jones - - Yet another additional r128 DRM check. (CAN-2004-0003) - - Bounds checking in ISO9660 filesystem. (CAN-2004-0109) - - Fix Information leak in EXT3 (CAN-2004-0133) - - Fix local DoS in mremap() * Tue Feb 17 2004 Dave Jones - - Additional r128 DRM checks. (CAN-2004-0003) 9: * Fri Jun 18 2004 Dominic Hargreaves - - Fix memory leak in kernel/fork.c. (CAN-2004-0427) - - Numerous userspace pointer reference bugs found with the sparse tool by Al Viro. (CAN-2004-0495) - - Fix e1000 driver information leak. (CAN-2004-0535) * Tue Jun 15 2004 Dominic Hargreaves - - Fix local DoS in "clear_cpu()" macro. (CAN-2004-0554) * Thu May 13 2004 Dominic Hargreaves - - Fix information leak in cpufreq userspace ioctl. (CAN-2004-0228) - - Fix for C1 Halt Disconnect problem on nForce2 systems. * Wed May 05 2004 Dominic Hargreaves - - Fix potential local denial of service in sb16 driver (CAN-2004-0178) - - Fix information leak in JFS (CAN-2004-0181) - - Add range checking to i810_dma() in DRM driver. - - Make ioctl(FBIOGETCMAP) use copy_to_user() rather than memcpy() - - Fix possible buffer overflow in panic() (CAN-2004-0394) * Tue Apr 13 2004 Dave Jones - - Yet another additional r128 DRM check. (CAN-2004-0003) - - Bounds checking in ISO9660 filesystem. (CAN-2004-0109) - - Fix Information leak in EXT3 (CAN-2004-0133) - - Fix local DoS in mremap() * Tue Feb 17 2004 Dave Jones - - Additional r128 DRM checks. (CAN-2004-0003) - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ 9344cffa6802c7ebffa6a631d4eaa7306617df59 7.3/updates-testing/SRPMS/kernel-2.4.20-35.7.legacy.src.rpm 8cf4a7c4044c367bd2ef3956870e23196af255bb 7.3/updates-testing/i386/kernel-2.4.20-35.7.legacy.athlon.rpm 75e49a453639b57ca295ed687915df718ca4683d 7.3/updates-testing/i386/kernel-2.4.20-35.7.legacy.i586.rpm deb026a34bc1f79446e76880611d2a494084f6e9 7.3/updates-testing/i386/kernel-2.4.20-35.7.legacy.i686.rpm 0330c909d885e223f86116542d3e06cd6cd954e1 7.3/updates-testing/i386/kernel-bigmem-2.4.20-35.7.legacy.i686.rpm cec2602052a215bb0706427c3eb3d21f8798faea 7.3/updates-testing/i386/kernel-BOOT-2.4.20-35.7.legacy.i386.rpm 263bbfab412699eafdb0156044e09026e3a4e9de 7.3/updates-testing/i386/kernel-doc-2.4.20-35.7.legacy.i386.rpm eccb21775efcdf0cdbc2e9d9877d42b8df1f5c13 7.3/updates-testing/i386/kernel-smp-2.4.20-35.7.legacy.athlon.rpm 5da9d54d2e071ee30036f78402f2c88fd69da6e1 7.3/updates-testing/i386/kernel-smp-2.4.20-35.7.legacy.i586.rpm 83a88ed2172fb2bf5d5c05dd6cf11e7a96e350e3 7.3/updates-testing/i386/kernel-smp-2.4.20-35.7.legacy.i686.rpm 65a7083bea4412afa29da8e91d0ba3a03e0f3ac2 7.3/updates-testing/i386/kernel-source-2.4.20-35.7.legacy.i386.rpm b9d094e0be2665affff9c2dab8211c948c38ccf6 9/updates-testing/SRPMS/kernel-2.4.20-35.9.legacy.src.rpm 6374592090c07112200494e9361db824edb4511a 9/updates-testing/i386/kernel-2.4.20-35.9.legacy.athlon.rpm 811b325582853788f37524c4549fd079e2ffc4a6 9/updates-testing/i386/kernel-2.4.20-35.9.legacy.i586.rpm 2050252b57943da552fc17873331d702585488a4 9/updates-testing/i386/kernel-2.4.20-35.9.legacy.i686.rpm 8fb30ead64197f7be966016609ac9a8e8c14b222 9/updates-testing/i386/kernel-bigmem-2.4.20-35.9.legacy.i686.rpm 86becf2d0d1043913374e314b571fd004b005101 9/updates-testing/i386/kernel-BOOT-2.4.20-35.9.legacy.i386.rpm 4a713fdd4c90d3542cd5c9763b3662c0c2b82865 9/updates-testing/i386/kernel-doc-2.4.20-35.9.legacy.i386.rpm 69326a68b8084e09bcc9ab93909b535c2586da2c 9/updates-testing/i386/kernel-smp-2.4.20-35.9.legacy.athlon.rpm 83b867f5d18bbd70c125dbdff6accc661de0dc47 9/updates-testing/i386/kernel-smp-2.4.20-35.9.legacy.i586.rpm 6e4fa22a1d46b0d42a3837a4ce5e3e65fba9ebfe 9/updates-testing/i386/kernel-smp-2.4.20-35.9.legacy.i686.rpm 83d7da718554b818c4828720ead16ba4001260b2 9/updates-testing/i386/kernel-source-2.4.20-35.9.legacy.i386.rpm Please note that this update is also available via yum and apt through the updates-testing channel. Many people find this an easier way to apply updates. - --------------------------------------------------------------------- - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA7LzU4v2HLvE71NURAmXVAJ0T0iZ1rodP7Wq5PYg+IoUoBtd1hQCfSDPu Jp/8ZC0nRG71Ky5R0LgZORo= =6LLc -----END PGP SIGNATURE----- From lludwig-maillist at empoweringmedia.com Thu Jul 8 21:41:04 2004 From: lludwig-maillist at empoweringmedia.com (lludwig-maillist at empoweringmedia.com) Date: Thu, 8 Jul 2004 17:41:04 -0400 Subject: looking to contribute (QA tester, Test RPM packager) Message-ID: <1089322864.40edbf7024bc6@www.emwebmail.com> Hi, I am looking to contribute to the Fedora Legacy project. Specifically QA test and test RPM packager. Our company manages 20+ Red Hat Linux servers (mostly running a trimmed down version of 7.3) I am currently testing the latest kernel on two servers. At the moment on one server I am running the program stress on it. Linux Admin (on a scale 1 - 10 (1 being the worst) - 9 My qualifications? -Running Linux for 8 years -Unix admin 10 years -Currently manage 20+ servers -have created many RPMs -Created our own Red Hat Distro -- Larry Ludwig Empowering Media http://www.empoweringmedia.com hostasite.com - Web Hosting made simple 516-777-8080 -------------------------------------------------- http://www.hostasite.com - Web hosting made simple From jpdalbec at ysu.edu Fri Jul 9 15:19:01 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Fri, 09 Jul 2004 11:19:01 -0400 Subject: RH9 mirror list? Message-ID: <40EEB765.4010002@ysu.edu> This file doesn't exist. http://fedoralegacy.org/download/fedoralegacy-rh9-mirrors.list Shouldn't it? John From rostetter at mail.utexas.edu Fri Jul 9 16:55:13 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 9 Jul 2004 11:55:13 -0500 Subject: RH9 mirror list? In-Reply-To: <40EEB765.4010002@ysu.edu> References: <40EEB765.4010002@ysu.edu> Message-ID: <20040709115513.pdi0mssw8ggkg00g@mail.ph.utexas.edu> Quoting John Dalbec : > This file doesn't exist. > http://fedoralegacy.org/download/fedoralegacy-rh9-mirrors.list Since FL does not have a RH 9 apt program yet, there is no RH9 apt mirror list yet. > Shouldn't it? Not sure, but it doesn't *need* to exist until there is an apt to use it with. I suppose it could exist, but I'm not sure it should. Might confuse people to provide RH9 apt configuration when we don't yet provide a RH9 apt program. > John -- Eric Rostetter From lsomike at futzin.com Fri Jul 9 17:35:57 2004 From: lsomike at futzin.com (Mike Klinke) Date: Fri, 9 Jul 2004 12:35:57 -0500 Subject: RH9 mirror list? In-Reply-To: <40EEB765.4010002@ysu.edu> References: <40EEB765.4010002@ysu.edu> Message-ID: <200407091235.58091.lsomike@futzin.com> On Friday 09 July 2004 10:19, John Dalbec wrote: > This file doesn't exist. > http://fedoralegacy.org/download/fedoralegacy-rh9-mirrors.list > Shouldn't it? > John > I?m not too sure what point you are making John but is this what you're looking for? http://fedoralegacy.org/download/fedoralegacy-mirrors.php Regards, Mike Klinke From dom at earth.li Mon Jul 12 11:58:42 2004 From: dom at earth.li (Dominic Hargreaves) Date: Mon, 12 Jul 2004 12:58:42 +0100 Subject: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow In-Reply-To: References: Message-ID: <20040712115842.GE30964@tirian.magd.ox.ac.uk> On Fri, Jul 02, 2004 at 04:58:02PM +0100, Jon Peatfield wrote: > None of the "obvious" tests I carried out with the existing nfs server > code allowed me to chgrp a file I didn't own, so I'm not exactly sure > under what circumstances the is actually exploitable anyway (maybe it > needs root-squash turning off or something, in which case it would > only affect hosts you nfs export (rw) to which are untrustworthy). I would be most interested on the precise nature of this vulnerability, which I've not been able to find explained anywhere. I'm about to roll out 35.7, but if I can find evidence that the chown bug really does affect our particular setup I'll have to rethink. As Jon says the obvious tests fail with "Operation not permitted" (including when exported no_root_squash). The question is, is the vulnerability relevant when root@ all the NFS clients is trusted? I'd be interested if anyone has any insight. Cheers, Dominic. From jpdalbec at ysu.edu Mon Jul 12 12:35:21 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Mon, 12 Jul 2004 08:35:21 -0400 Subject: RH9 mirror list? In-Reply-To: <20040710160014.8C2E573825@hormel.redhat.com> References: <20040710160014.8C2E573825@hormel.redhat.com> Message-ID: <40F28589.7030802@ysu.edu> Eric Rostetter wrote: > Since FL does not have a RH 9 apt program yet, there is no RH9 apt mirror list > yet. See https://bugzilla.fedora.us/show_bug.cgi?id=1174 795e05585a53e0e31780a5a5676a22fff3d65ba4 apt-0.5.15cnc6-0.fdr.10.rh9.11.legacy.i386.rpm dd3a98c7767c216ddfc7315a02f99b6a785716a2 apt-0.5.15cnc6-0.fdr.10.rh9.11.legacy.src.rpm 250ca1d38aeca25a2a76434a61cc4fb258ed7179 apt-debuginfo-0.5.15cnc6-0.fdr.10.rh9.11.legacy.i386.rpm c3db7e2327628b9a70d231c26649753581e11a62 apt-devel-0.5.15cnc6-0.fdr.10.rh9.11.legacy.i386.rpm How can anyone test these packages when that file doesn't exist? John From J.S.Peatfield at damtp.cam.ac.uk Mon Jul 12 22:14:37 2004 From: J.S.Peatfield at damtp.cam.ac.uk (Jon Peatfield) Date: Mon, 12 Jul 2004 23:14:37 +0100 Subject: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow Message-ID: I'm guessing that anyone with real inside info probably isn't willing to publish it (yet) on such a public forum... As far as I can tell from the patch the only possible case is iff chgrp()ing a file which is in one of the groups of the process to another -- but in the case of the nfsd I'm not sure exactly what that implies. It might be that the simple tests fail 'cos the client also does a check so it would only be a problem if one exported to hosts which were running hacked clients. (I'm guessing here of course). I've been waiting for the -35* kernels to get a bit further -- I see they are now in updates-testing/ so can someone tell me what the procedure is to get them moved into updates/ ? If it just requires a few zillion extra QAs I'll prod the people (in other departments here) who run RH73/9 etc to try the update-testing/ versions. I wouldn't want -36 (or whatever) to cause people not to want to test -35 or there will *never* be a kernel update. Of course I'm happy enough running the versions I patch/build myself but I guess that most RHL users arn't. -- Jon From dom at earth.li Mon Jul 12 22:22:04 2004 From: dom at earth.li (Dominic Hargreaves) Date: Mon, 12 Jul 2004 23:22:04 +0100 Subject: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow In-Reply-To: References: Message-ID: <20040712222204.GH30964@tirian.magd.ox.ac.uk> On Mon, Jul 12, 2004 at 11:14:37PM +0100, Jon Peatfield wrote: > I've been waiting for the -35* kernels to get a bit further -- I see they are > now in updates-testing/ so can someone tell me what the procedure is to get > them moved into updates/ ? If it just requires a few zillion extra QAs I'll > prod the people (in other departments here) who run RH73/9 etc to try the > update-testing/ versions. > > I wouldn't want -36 (or whatever) to cause people not to want to test -35 > or there will *never* be a kernel update. I was going to be able to produce a report confirming the successful installation of a range of the 35.7 kernels running on about 80 machines today, but I ended up applying the chown patch before doing so. The pain required to reboot all the machines is too much to want to do so more than is absolutely necessary, so better safe than sorry. The resultant kernels have been behaving fine so far (except that the NVIDIA installer for their video cards now complains that it cannot insert the module it's just compiled. It might be worth someone else working out where this problem has arisen - I don't have the resources at the moment). Regarding releases.. normally if there haven't been any negative reports packages move to updates/ after about a week. I haven't been able to commit any time to building further updates since I put out 35, there having been a lot of stuff on at work, but if noone else does I'll try and look at the pending issues for the kernel in a week or so. Cheers, Dominic. From rostetter at mail.utexas.edu Mon Jul 12 22:39:11 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 12 Jul 2004 17:39:11 -0500 Subject: RH9 mirror list? In-Reply-To: <40F28589.7030802@ysu.edu> References: <20040710160014.8C2E573825@hormel.redhat.com> <40F28589.7030802@ysu.edu> Message-ID: <20040712173911.h4pzn4okkw8kkckc@mail.ph.utexas.edu> Quoting John Dalbec : > Eric Rostetter wrote: >> Since FL does not have a RH 9 apt program yet, there is no RH9 apt >> mirror list >> yet. > > See > https://bugzilla.fedora.us/show_bug.cgi?id=1174 [...] > How can anyone test these packages when that file doesn't exist? > > John Then I guess it should exist. Though probably not linked on that page, but it should exist for the program to access... So that problem is resolved. Now someone just needs to create the file... -- Eric Rostetter From J.S.Peatfield at damtp.cam.ac.uk Mon Jul 12 23:34:28 2004 From: J.S.Peatfield at damtp.cam.ac.uk (Jon Peatfield) Date: Tue, 13 Jul 2004 00:34:28 +0100 Subject: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow Message-ID: Once my experiments with suse91 get somewhere (or I obtain new machines to use for testing), I'll put a host back for testing/building RH9 packages and build/test more updates kernels etc. I'm not planning to update our ~200 RH8 machines _this_week_ as they have ended up getting kernel updates once a week for the past 4 weeks and some people here are getting slightly miffed. The outstanding updates I know about are: an nfsd problem (which we can't reproduce, and we could always turn off nfs-serving for a few days if it does turn out to be a problem), the addon/qla2200 driver which we don't use I'm planning to wait a week or so before our next major round of kernel updates... The good news is that the suse91 autoyast isn't as bad as I'd thought it might be. With a little luck I might actually be transitioning away from RHL in a few weeks... -- Jon From khismaeel at ecs.gov.eg Tue Jul 13 07:29:28 2004 From: khismaeel at ecs.gov.eg (khaled fawzy) Date: Tue, 13 Jul 2004 10:29:28 +0300 Subject: patching process Message-ID: <00ad01c468ab$248ec850$d90310ac@traderep.com> dear group ; is there a patch for MySQL Authentication Bypass Vulnerability . version 3.23.58 . thanks in advance. From vuhung at hn.is.uec.ac.jp Tue Jul 13 08:58:10 2004 From: vuhung at hn.is.uec.ac.jp (Nguyen Hung Vu) Date: Tue, 13 Jul 2004 17:58:10 +0900 Subject: latest kernel for redhat 7.2 Message-ID: <200407130858.AA00079@dell2004d.hn.is.uec.ac.jp> Hello all, I am running redhat 7.2 with kernel version: 2.4.20-28.7. Is this the latest one or I have to upgrade my kernel? Thank you ---- Nguyen Hung Vu vuhung at hn.is.uec.ac.jp From Axel.Thimm at ATrpms.net Tue Jul 13 09:08:28 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 13 Jul 2004 11:08:28 +0200 Subject: latest kernel for redhat 7.2 In-Reply-To: <200407130858.AA00079@dell2004d.hn.is.uec.ac.jp> References: <200407130858.AA00079@dell2004d.hn.is.uec.ac.jp> Message-ID: <20040713090828.GE12279@neu.nirvana> On Tue, Jul 13, 2004 at 05:58:10PM +0900, Nguyen Hung Vu wrote: > Hello all, > > I am running redhat 7.2 with kernel version: 2.4.20-28.7. Is this the latest one or I have to upgrade my kernel? Upgrade to http://download.fedoralegacy.org/redhat/7.3/updates-testing/i386/kernel-2.4.20-35.7.legacy.i686.rpm or athlon/i586 etc., or use rpmbuild --rebuild --target `uname -m` on http://download.fedoralegacy.org/redhat/7.3/updates-testing/SRPMS/kernel-2.4.20-35.7.legacy.src.rpm Note that it says testing, so officially it is not yet released, but it works nevertheless. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dom at earth.li Tue Jul 13 10:03:59 2004 From: dom at earth.li (Dominic Hargreaves) Date: Tue, 13 Jul 2004 11:03:59 +0100 Subject: patching process In-Reply-To: <00ad01c468ab$248ec850$d90310ac@traderep.com> References: <00ad01c468ab$248ec850$d90310ac@traderep.com> Message-ID: <20040713100359.GK30964@tirian.magd.ox.ac.uk> On Tue, Jul 13, 2004 at 10:29:28AM +0300, khaled fawzy wrote: > is there a patch for MySQL Authentication Bypass Vulnerability . version > 3.23.58 . A brief review of which is I assume the issue you refer to leads me to the conclusion that this only affects 4.1.x and 5.0. Do you have evidence to the contrary? Cheers, Dominic. From vuhung at hn.is.uec.ac.jp Tue Jul 13 10:50:39 2004 From: vuhung at hn.is.uec.ac.jp (Nguyen Hung Vu) Date: Tue, 13 Jul 2004 19:50:39 +0900 Subject: latest kernel for redhat 7.2 In-Reply-To: <20040713090828.GE12279@neu.nirvana> References: <20040713090828.GE12279@neu.nirvana> Message-ID: <200407131050.AA00092@dell2004d.hn.is.uec.ac.jp> Axel Thimm ????????: >On Tue, Jul 13, 2004 at 05:58:10PM +0900, Nguyen Hung Vu wrote: >> Hello all, >> >> I am running redhat 7.2 with kernel version: 2.4.20-28.7. Is this the latest one or I have to upgrade my kernel? > >Upgrade to > >http://download.fedoralegacy.org/redhat/7.3/updates-testing/i386/kernel-2.4.20-35.7.legacy.i686.rpm > >or athlon/i586 etc., or use rpmbuild --rebuild --target `uname -m` on > >http://download.fedoralegacy.org/redhat/7.3/updates-testing/SRPMS/kernel-2.4.20-35.7.legacy.src.rpm > >Note that it says testing, so officially it is not yet released, but it >works nevertheless. Hello Axel Thim, Testing means unstable j/k. Could you point me to the annoucement of that testing upgrade? I just want to know the new kernel fixes what vunnerablilities. Thank you ---- Nguyen Hung Vu vuhung at hn.is.uec.ac.jp From Axel.Thimm at ATrpms.net Tue Jul 13 10:57:12 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 13 Jul 2004 12:57:12 +0200 Subject: latest kernel for redhat 7.2 In-Reply-To: <200407131050.AA00092@dell2004d.hn.is.uec.ac.jp> References: <20040713090828.GE12279@neu.nirvana> <200407131050.AA00092@dell2004d.hn.is.uec.ac.jp> Message-ID: <20040713105712.GQ12279@neu.nirvana> On Tue, Jul 13, 2004 at 07:50:39PM +0900, Nguyen Hung Vu wrote: > Axel Thimm ????????: > >On Tue, Jul 13, 2004 at 05:58:10PM +0900, Nguyen Hung Vu wrote: > >> Hello all, > >> > >> I am running redhat 7.2 with kernel version: 2.4.20-28.7. Is this the latest one or I have to upgrade my kernel? > > > >Upgrade to > > > >http://download.fedoralegacy.org/redhat/7.3/updates-testing/i386/kernel-2.4.20-35.7.legacy.i686.rpm > > > >or athlon/i586 etc., or use rpmbuild --rebuild --target `uname -m` on > > > >http://download.fedoralegacy.org/redhat/7.3/updates-testing/SRPMS/kernel-2.4.20-35.7.legacy.src.rpm > > > >Note that it says testing, so officially it is not yet released, but it > >works nevertheless. > > Hello Axel Thim, > > Testing means unstable j/k. > Could you point me to the annoucement of that testing upgrade? I > just want to know the new kernel fixes what vunnerablilities. Check this list 6 days ago: http://www.redhat.com/archives/fedora-legacy-list/2004-July/msg00032.html -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ataylor at leeuniversity.edu Tue Jul 13 20:38:32 2004 From: ataylor at leeuniversity.edu (Andy Taylor) Date: Tue, 13 Jul 2004 16:38:32 -0400 Subject: redhat 8 Message-ID: I've been subscribed to this list for a little while and I've noticed that the most recent updates have been for Redhat 7.x and 9.x but not for Redhat 8...is the 8.0 part of the Legacy project in need of some more help? -----Original Message----- From: fedora-legacy-list-bounces at redhat.com [mailto:fedora-legacy-list-bounces at redhat.com]On Behalf Of fedora-legacy-list-request at redhat.com Sent: Tuesday, July 13, 2004 12:00 PM To: fedora-legacy-list at redhat.com Subject: fedora-legacy-list Digest, Vol 5, Issue 11 Send fedora-legacy-list mailing list submissions to fedora-legacy-list at redhat.com To subscribe or unsubscribe via the World Wide Web, visit http://www.redhat.com/mailman/listinfo/fedora-legacy-list or, via email, send a message with subject or body 'help' to fedora-legacy-list-request at redhat.com You can reach the person managing the list at fedora-legacy-list-owner at redhat.com When replying, please edit your Subject line so it is more specific than "Re: Contents of fedora-legacy-list digest..." Today's Topics: 1. Re: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow (Jon Peatfield) 2. Re: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow (Dominic Hargreaves) 3. Re: RH9 mirror list? (Eric Rostetter) 4. Re: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow (Jon Peatfield) 5. patching process (khaled fawzy) 6. latest kernel for redhat 7.2 (Nguyen Hung Vu) 7. Re: latest kernel for redhat 7.2 (Axel Thimm) 8. Re: patching process (Dominic Hargreaves) 9. Re: latest kernel for redhat 7.2 (Nguyen Hung Vu) 10. Re: latest kernel for redhat 7.2 (Axel Thimm) ---------------------------------------------------------------------- Message: 1 Date: Mon, 12 Jul 2004 23:14:37 +0100 From: Jon Peatfield Subject: Re: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow To: fedora-legacy-list at redhat.com Cc: J.S.Peatfield at damtp.cam.ac.uk Message-ID: I'm guessing that anyone with real inside info probably isn't willing to publish it (yet) on such a public forum... As far as I can tell from the patch the only possible case is iff chgrp()ing a file which is in one of the groups of the process to another -- but in the case of the nfsd I'm not sure exactly what that implies. It might be that the simple tests fail 'cos the client also does a check so it would only be a problem if one exported to hosts which were running hacked clients. (I'm guessing here of course). I've been waiting for the -35* kernels to get a bit further -- I see they are now in updates-testing/ so can someone tell me what the procedure is to get them moved into updates/ ? If it just requires a few zillion extra QAs I'll prod the people (in other departments here) who run RH73/9 etc to try the update-testing/ versions. I wouldn't want -36 (or whatever) to cause people not to want to test -35 or there will *never* be a kernel update. Of course I'm happy enough running the versions I patch/build myself but I guess that most RHL users arn't. -- Jon ------------------------------ Message: 2 Date: Mon, 12 Jul 2004 23:22:04 +0100 From: Dominic Hargreaves Subject: Re: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow To: Discussion of the Fedora Legacy Project Message-ID: <20040712222204.GH30964 at tirian.magd.ox.ac.uk> Content-Type: text/plain; charset=us-ascii On Mon, Jul 12, 2004 at 11:14:37PM +0100, Jon Peatfield wrote: > I've been waiting for the -35* kernels to get a bit further -- I see they are > now in updates-testing/ so can someone tell me what the procedure is to get > them moved into updates/ ? If it just requires a few zillion extra QAs I'll > prod the people (in other departments here) who run RH73/9 etc to try the > update-testing/ versions. > > I wouldn't want -36 (or whatever) to cause people not to want to test -35 > or there will *never* be a kernel update. I was going to be able to produce a report confirming the successful installation of a range of the 35.7 kernels running on about 80 machines today, but I ended up applying the chown patch before doing so. The pain required to reboot all the machines is too much to want to do so more than is absolutely necessary, so better safe than sorry. The resultant kernels have been behaving fine so far (except that the NVIDIA installer for their video cards now complains that it cannot insert the module it's just compiled. It might be worth someone else working out where this problem has arisen - I don't have the resources at the moment). Regarding releases.. normally if there haven't been any negative reports packages move to updates/ after about a week. I haven't been able to commit any time to building further updates since I put out 35, there having been a lot of stuff on at work, but if noone else does I'll try and look at the pending issues for the kernel in a week or so. Cheers, Dominic. ------------------------------ Message: 3 Date: Mon, 12 Jul 2004 17:39:11 -0500 From: Eric Rostetter Subject: Re: RH9 mirror list? To: fedora-legacy-list at redhat.com Message-ID: <20040712173911.h4pzn4okkw8kkckc at mail.ph.utexas.edu> Content-Type: text/plain; charset="UTF-8"; format="flowed" Quoting John Dalbec : > Eric Rostetter wrote: >> Since FL does not have a RH 9 apt program yet, there is no RH9 apt >> mirror list >> yet. > > See > https://bugzilla.fedora.us/show_bug.cgi?id=1174 [...] > How can anyone test these packages when that file doesn't exist? > > John Then I guess it should exist. Though probably not linked on that page, but it should exist for the program to access... So that problem is resolved------------------------- Message: 4 Date: Tue, 13 Jul 2004 00:34:28 +0100 From: Jon Peatfield Subject: Re: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow To: fedora-legacy-list at redhat.com Cc: J.S.Peatfield at damtp.cam.ac.uk Message-ID: Once my experiments with suse91 get somewhere (or I obtain new machines to use for testing), I'll put a host back for testing/building RH9 packages and build/test more updates kernels etc. I'm not planning to update our ~200 RH8 machines _this_week_ as they have ended up getting kernel updates once a week for the past 4 weeks and some people here are getting slightly miffed. The outstanding updates I know about are: an nfsd problem (which we can't reproduce, and we could always turn off nfs-serving for a few days if it does turn out to be a problem), the addon/qla2200 driver which we don't use I'm planning to wait a week or so before our next major round of kernel updates... The good news is that the suse91 autoyast isn't as bad as I'd thought it might be. With a little luck I might actually be transitioning away from RHL in a few weeks... -- Jon ------------------------------ Message: 5 Date: Tue, 13 Jul 2004 10:29:28 +0300 From: "khaled fawzy" Subject: patching process To: Message-ID: <00ad01c468ab$248ec850$d90310ac at traderep.com> dear group ; is there a patch for MySQL Authentication Bypass Vulnerability . version 3.23.58 . thanks in advance. ------------------------------ Message: 6 Date: Tue, 13 Jul 2004 17:58:10 +0900 From: Nguyen Hung Vu Subject: latest kernel for redhat 7.2 To: fedora-legacy-list at redhat.com Message-ID: <200407130858.AA00079 at dell2004d.hn.is.uec.ac.jp> Content-Type: text/plain; charset=us-ascii Hello all, I am running redhat 7.2 with kernel version: 2.4.20-28.7. Is this the latest one or I have to upgrade my kernel? Thank you ---- Nguyen Hung Vu vuhung at hn.is.uec.ac.jp ------------------------------ Message: 7 Date: Tue, 13 Jul 2004 11:08:28 +0200 From: Axel Thimm Subject: Re: latest kernel for redhat 7.2 To: Discussion of the Fedora Legacy Project Message-ID: <20040713090828.GE12279 at neu.nirvana> Content-Type: text/plain; charset="us-ascii" On Tue, Jul 13, 2004 at 05:58:10PM +0900, Nguyen Hung Vu wrote: > Hello all, > > I am running redhat 7.2 with kernel version: 2.4.20-28.7. Is this the latest one or I have to upgrade my kernel? Upgrade to http://download.fedoralegacy.org/redhat/7.3/updates-testing/i386/kernel-2.4.20-35.7.legacy.i686.rpm or athlon/i586 etc., or use rpmbuild --rebuild --target `uname -m` on http://download.fedoralegacy.org/redhat/7.3/updates-testing/SRPMS/kernel-2.4.20-35.7.legacy.src.rpm Note that it says testing, so officially it is not yet released, but it works nevertheless. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /archives/fedora-legacy-list/attachments/20040713/18a53ed3/attachment.bin ------------------------------ Message: 8 Date: Tue, 13 Jul 2004 11:03:59 +0100 From: Dominic Hargreaves Subject: Re: patching process To: Discussion of the Fedora Legacy Project Message-ID: <20040713100359.GK30964 at tirian.magd.ox.ac.uk> Content-Type: text/plain; charset=us-ascii On Tue, Jul 13, 2004 at 10:29:28AM +0300, khaled fawzy wrote: > is there a patch for MySQL Authentication Bypass Vulnerability . version > 3.23.58 . A brief review of which is I assume the issue you refer to leads me to the conclusion that this only affects 4.1.x and 5.0. Do you have evidence to the contrary? Cheers, Dominic. ------------------------------ Message: 9 Date: Tue, 13 Jul 2004 19:50:39 +0900 From: Nguyen Hung Vu Subject: Re: latest kernel for redhat 7.2 To: Discussion of the Fedora Legacy Project Message-ID: <200407131050.AA00092 at dell2004d.hn.is.uec.ac.jp> Content-Type: text/plain; charset=iso-2022-jp Axel Thimm $B$5$s$O=q$-$^$7$?(B: >On Tue, Jul 13, 2004 at 05:58:10PM +0900, Nguyen Hung Vu wrote: >> Hello all, >> >> I am running redhat 7.2 with kernel version: 2.4.20-28.7. Is this the latest one or I have to upgrade my kernel? > >Upgrade to > >http://download.fedoralegacy.org/redhat/7.3/updates-testing/i386/kernel-2.4.20-35.7.legacy.i686.rpm > >or athlon/i586 etc., or use rpmbuild --rebuild --target `uname -m` on > >http://download.fedoralegacy.org/redhat/7.3/updates-testing/SRPMS/kernel-2.4.20-35.7.legacy.src.rpm > >Note that it says testing, so officially it is not yet released, but it >works nevertheless. Hello Axel Thim, Testing means unstable j/k. Could you point me to the annoucement of that testing upgrade? I just want to know the new kernel fixes what vunnerablilities. Thank you ---- Nguyen Hung Vu vuhung at hn.is.uec.ac.jp ------------------------------ Message: 10 Date: Tue, 13 Jul 2004 12:57:12 +0200 From: Axel Thimm Subject: Re: latest kernel for redhat 7.2 To: Discussion of the Fedora Legacy Project Message-ID: <20040713105712.GQ12279 at neu.nirvana> Content-Type: text/plain; charset="utf-8" On Tue, Jul 13, 2004 at 07:50:39PM +0900, Nguyen Hung Vu wrote: > Axel Thimm ??*?'"????>?????????-??Y: > >On Tue, Jul 13, 2004 at 05:58:10PM +0900, Nguyen Hung Vu wrote: > >> Hello all, > >> > >> I am running redhat 7.2 with kernel version: 2.4.20-28.7. Is this the latest one or I have to upgrade my kernel? > > > >Upgrade to > > > >http://download.fedoralegacy.org/redhat/7.3/updates-testing/i386/kernel-2.4.20-35.7.legacy.i686.rpm > > > >or athlon/i586 etc., or use rpmbuild --rebuild --target `uname -m` on > > > >http://download.fedoralegacy.org/redhat/7.3/updates-testing/SRPMS/kernel-2.4.20-35.7.legacy.src.rpm > > > >Note that it says testing, so officially it is not yet released, but it > >works nevertheless. > > Hello Axel Thim, > > Testing means unstable j/k. > Could you point me to the annoucement of that testing upgrade? I > just want to know the new kernel fixes what vunnerablilities. Check this list 6 days ago: http://www.redhat.com/archives/fedora-legacy-list/2004-July/msg00032.html -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /archives/fedora-legacy-list/attachments/20040713/fd1ad111/attachment.bin ------------------------------ -- fedora-legacy-list mailing list fedora-legacy-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-legacy-list End of fedora-legacy-list Digest, Vol 5, Issue 11 ************************************************* From jcw at wilsonet.com Tue Jul 13 21:19:26 2004 From: jcw at wilsonet.com (Jarod Wilson) Date: Tue, 13 Jul 2004 14:19:26 -0700 Subject: redhat 8 In-Reply-To: References: Message-ID: <200407131419.29101.jcw@wilsonet.com> On Tuesday 13 July 2004 13:38, Andy Taylor wrote: > I've been subscribed to this list for a little while and I've noticed that > the most recent updates have been for Redhat 7.x and 9.x but not for Redhat > 8...is the 8.0 part of the Legacy project in need of some more help? A few things before getting to answers... These are general mailing list etiquette things: 1) Don't start a new thread by replying to another one (or a digest), start a new thread by creating a new email. 2) Don't reply to a digest message and quote the entire digest, especially since your message has nothing to do with most (if any) of it. 3) Please check the mailing list archive before asking questions Check out this thread: http://www.redhat.com/archives/fedora-legacy-list/2004-May/msg00250.html Basically, lack of community involvement has killed off support for 7.2 and 8.0. I can't recall if a final decision to deep six any and all support has been reached or not. -- Jarod C. Wilson, RHCE jcw at wilsonet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From rostetter at mail.utexas.edu Tue Jul 13 22:26:50 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 13 Jul 2004 17:26:50 -0500 Subject: redhat 8 In-Reply-To: References: Message-ID: <20040713172650.4pdu9zqcg8oggoc4@mail.ph.utexas.edu> Quoting Andy Taylor : > I've been subscribed to this list for a little while and I've noticed > that the most recent updates have been for Redhat 7.x and 9.x but not > for Redhat 8...is the 8.0 part of the Legacy project in need of some > more help? RH 8.0 support is unofficially being dropped, unless people do suddenly step up and start supporting it in sufficient numbers. Ditto for RH 7.2 I believe. -- Eric Rostetter From mfedyk at matchmail.com Tue Jul 13 23:49:37 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Tue, 13 Jul 2004 16:49:37 -0700 Subject: redhat 8 In-Reply-To: <20040713172650.4pdu9zqcg8oggoc4@mail.ph.utexas.edu> References: <20040713172650.4pdu9zqcg8oggoc4@mail.ph.utexas.edu> Message-ID: <40F47511.7070504@matchmail.com> Eric Rostetter wrote: > Quoting Andy Taylor : > >> I've been subscribed to this list for a little while and I've noticed >> that the most recent updates have been for Redhat 7.x and 9.x but not >> for Redhat 8...is the 8.0 part of the Legacy project in need of some >> more help? > > > RH 8.0 support is unofficially being dropped, unless people do suddenly > step up and start supporting it in sufficient numbers. > > Ditto for RH 7.2 I believe. The kernels are at least being supported... From vuhung at hn.is.uec.ac.jp Wed Jul 14 06:32:23 2004 From: vuhung at hn.is.uec.ac.jp (Nguyen Hung Vu) Date: Wed, 14 Jul 2004 15:32:23 +0900 Subject: redhat 8 In-Reply-To: <40F47511.7070504@matchmail.com> References: <40F47511.7070504@matchmail.com> Message-ID: <200407140632.AA00099@dell2004d.hn.is.uec.ac.jp> Mike Fedyk ????????: >> RH 8.0 support is unofficially being dropped, unless people do suddenly >> step up and start supporting it in sufficient numbers. >> >> Ditto for RH 7.2 I believe. > >The kernels are at least being supported... > Great! I am happy to hear that. Is there any open jobs/tasks for redhat 7.2 out there I can help? I can do HTML coding, Softwares Patching, RPM packaging ... Vu Hung ---- Nguyen Hung Vu vuhung at hn.is.uec.ac.jp From brian.t.brunner at gai-tronics.com Wed Jul 14 12:14:24 2004 From: brian.t.brunner at gai-tronics.com (Brian T. Brunner) Date: Wed, 14 Jul 2004 08:14:24 -0400 Subject: redhat 8 Message-ID: You have it right; there is some work required for each supported version, and 7.2 and 8 have not received enough help to keep them current. Most users are on 7.3 or 9, and that is where the necessary help has been found. If you're interested in keeping 8, talk to Jesse Keating (he's on this list) about what work load is required to support , and who has expressed interest in sharing that load. Brian Brunner brian.t.brunner at gai-tronics.com (610)796-5838 >>> ataylor at leeuniversity.edu 07/13/04 04:38PM >>> I've been subscribed to this list for a little while and I've noticed that the most recent updates have been for Redhat 7.x and 9.x but not for Redhat 8...is the 8.0 part of the Legacy project in need of some more help? ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.hubbell.com - Hubbell Incorporated From dom at earth.li Wed Jul 14 22:20:52 2004 From: dom at earth.li (Dominic Hargreaves) Date: Wed, 14 Jul 2004 23:20:52 +0100 Subject: redhat 8 In-Reply-To: <40F47511.7070504@matchmail.com> References: <20040713172650.4pdu9zqcg8oggoc4@mail.ph.utexas.edu> <40F47511.7070504@matchmail.com> Message-ID: <20040714222052.GM30964@tirian.magd.ox.ac.uk> On Tue, Jul 13, 2004 at 04:49:37PM -0700, Mike Fedyk wrote: > The kernels are at least being supported... Not any more. The most recent released kernel was release for 7.2 and 8.0; the one currently in preparation won't be. Dominic. From michal at harddata.com Wed Jul 14 23:19:54 2004 From: michal at harddata.com (Michal Jaegermann) Date: Wed, 14 Jul 2004 17:19:54 -0600 Subject: redhat 8 In-Reply-To: <20040714222052.GM30964@tirian.magd.ox.ac.uk>; from dom@earth.li on Wed, Jul 14, 2004 at 11:20:52PM +0100 References: <20040713172650.4pdu9zqcg8oggoc4@mail.ph.utexas.edu> <40F47511.7070504@matchmail.com> <20040714222052.GM30964@tirian.magd.ox.ac.uk> Message-ID: <20040714171954.A15730@mail.harddata.com> On Wed, Jul 14, 2004 at 11:20:52PM +0100, Dominic Hargreaves wrote: > On Tue, Jul 13, 2004 at 04:49:37PM -0700, Mike Fedyk wrote: > > > The kernels are at least being supported... > > Not any more. The most recent released kernel was release for 7.2 and > 8.0; the one currently in preparation won't be. I do not see any real difference in kernels to be used with various 7.x releases (yes, this includes also 7.1 and 7.0). With 8.0 it could be a question of an ntpl support but likely not even that. From dom at earth.li Wed Jul 14 23:22:48 2004 From: dom at earth.li (Dominic Hargreaves) Date: Thu, 15 Jul 2004 00:22:48 +0100 Subject: redhat 8 In-Reply-To: <20040714171954.A15730@mail.harddata.com> References: <20040713172650.4pdu9zqcg8oggoc4@mail.ph.utexas.edu> <40F47511.7070504@matchmail.com> <20040714222052.GM30964@tirian.magd.ox.ac.uk> <20040714171954.A15730@mail.harddata.com> Message-ID: <20040714232248.GN30964@tirian.magd.ox.ac.uk> On Wed, Jul 14, 2004 at 05:19:54PM -0600, Michal Jaegermann wrote: > I do not see any real difference in kernels to be used with various > 7.x releases (yes, this includes also 7.1 and 7.0). With 8.0 it > could be a question of an ntpl support but likely not even that. The 7.x releases are exactly what would be released for 7.2 and 8.0. The same kernels /were/ used for the last erratum. Jesse has made a policy decision not to claim that we support those releases, and we should respect that. AFAIK *no* QA has been done on those kernels on those platforms, and it would be foolish to release on that basis! The arguments for dropping support are still valid even if there are supposed working packages. Dominic. From Axel.Thimm at ATrpms.net Wed Jul 14 23:52:30 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 15 Jul 2004 01:52:30 +0200 Subject: redhat 8 In-Reply-To: <20040714232248.GN30964@tirian.magd.ox.ac.uk> References: <20040713172650.4pdu9zqcg8oggoc4@mail.ph.utexas.edu> <40F47511.7070504@matchmail.com> <20040714222052.GM30964@tirian.magd.ox.ac.uk> <20040714171954.A15730@mail.harddata.com> <20040714232248.GN30964@tirian.magd.ox.ac.uk> Message-ID: <20040714235230.GC8883@neu.nirvana> On Thu, Jul 15, 2004 at 12:22:48AM +0100, Dominic Hargreaves wrote: > On Wed, Jul 14, 2004 at 05:19:54PM -0600, Michal Jaegermann wrote: > > > I do not see any real difference in kernels to be used with various > > 7.x releases (yes, this includes also 7.1 and 7.0). With 8.0 it > > could be a question of an ntpl support but likely not even that. > > The 7.x releases are exactly what would be released for 7.2 and 8.0. > The same kernels /were/ used for the last erratum. Jesse has made a > policy decision not to claim that we support those releases, and we > should respect that. AFAIK *no* QA has been done on those kernels on > those platforms, and it would be foolish to release on that basis! > > The arguments for dropping support are still valid even if there are > supposed working packages. Just as a datapoint, RH 8.0 kernels based on legacy with added v4l2, xfs, lm_sensors etc. are in use by the mythtv community. There are still quite a few people happily running their PVR and don't want to upgrade the distro. That's of course no QA, but the kernels do run quite well on RH8.0 :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rostetter at mail.utexas.edu Wed Jul 14 23:10:18 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 14 Jul 2004 18:10:18 -0500 Subject: RH9 mirror list? In-Reply-To: <20040712173911.h4pzn4okkw8kkckc@mail.ph.utexas.edu> References: <20040710160014.8C2E573825@hormel.redhat.com> <40F28589.7030802@ysu.edu> <20040712173911.h4pzn4okkw8kkckc@mail.ph.utexas.edu> Message-ID: <20040714181018.ns4zr37s4goco8s0@mail.ph.utexas.edu> Quoting Eric Rostetter : >> How can anyone test these packages when that file doesn't exist? >> >> John The file exists now, though I don't know if the contents are correct or not. Can someone try it out, and let me know if it works? -- Eric Rostetter From jpdalbec at ysu.edu Fri Jul 16 16:44:28 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Fri, 16 Jul 2004 12:44:28 -0400 Subject: RH9 mirror list? In-Reply-To: <20040716160007.11F0A73A2B@hormel.redhat.com> References: <20040716160007.11F0A73A2B@hormel.redhat.com> Message-ID: <40F805EC.3040700@ysu.edu> Eric Rostetter wrote: > The file exists now, though I don't know if the contents are correct or > not. Can someone try it out, and let me know if it works? WORKSFORME. Thanks, John From marcdeslauriers at videotron.ca Fri Jul 16 23:15:55 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Fri, 16 Jul 2004 19:15:55 -0400 Subject: Fedora Legacy Bug Status Message-ID: <1090019754.13707.2.camel@mdlinux> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here is the list of Fedora Legacy bugs that still need work to be released. They can be looked at here: https://bugzilla.fedora.us/buglist.cgi?keywords=LEGACY Bugs needing rh9 QA to get to updates-testing: 1237 1257 1373 1550 1604 1708 1726 1748 1831 1832 1833 1840 1868 Bugs needing rh73 QA to get to updates-testing: 1174 1237 1257 1289 1371 1372 1373 1548 1550 1726 1832 1833 1840 1868 Bugs needing rh9 TESTING to get released: 1419 1468 1552 1569 1581 1732 1733 1735 Bugs needing rh73 TESTING to get released: 1325 1419 1468 1547 1549 1552 1581 Bugs needing packages to QA: 1804 1834 Bugs waiting on Jesse to build them for updates-testing: 1269 1719 1737 Bugs waiting on Jesse to push them for release: 1324 1376 1484 1532 1553 1734 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA+GGKLMAs/0C4zNoRAmWdAJ49PjhHulxJdKu14LAgDMvUDxPpUgCeNBQ2 oDzge2lbitv0BN+6ripdKo8= =0/d4 -----END PGP SIGNATURE----- From marcdeslauriers at videotron.ca Fri Jul 16 23:34:42 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Fri, 16 Jul 2004 19:34:42 -0400 Subject: Kernel update advisory text to approve... Message-ID: <1090020882.13707.10.camel@mdlinux> Fedora Legacy will be releasing a kernel update soon. There have been so many changes to the new version, I would like a few people to make sure we've got everything covered in the release write-up. Here's the proposed release announcement. Please compare it to bug #1484 to make sure I didn't leave anything out, or to check my awful grammar. :) Thanks, Marc. ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated kernel resolves security vulnerabilities Advisory ID: FLSA:XXXX Issue date: 2004-07-XX Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1484 CVE Names: CAN-2004-0394, CAN-2004-0133, CAN-2004-0181, CAN-2004-0178, CAN-2004-0228, CAN-2004-0554, CAN-2004-0535, CAN-2004-0495, CAN-2004-0427 ----------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated kernel packages that fix security vulnerabilities are now available. These packages also resolve other minor issues. 2. Relevent releases/architectures: Red Hat Linux 7.3 - i386, i586, i686, athlon Red Hat Linux 9 - i386, i586, i686, athlon 3. Problem description: The Linux kernel handles the basic functions of the operating system. Shaun Colley found a potential buffer overrun in the panic() function. As this function does not ever return, it is unlikely that this is exploitable, but has been fixed nonetheless. The Common Vulnerabilities and Exposures project (cve.mitre.org) assigned the name CAN-2004-0394 to this issue. Arjan van de Ven discovered the framebuffer code was doing direct userspace accesses instead of using correct interfaces to write to userspace. An automated checked from http://www.coverity.com highlighted a range checking bug in the i810 DRM driver. This was fixed by Andrea Arcangeli and Chris Wright. The information leak fixed in the previous errata was also found to affect XFS and JFS. The Common Vulnerabilities and Exposures project (cve.mitre.org) assigned the names CAN-2004-0133 and CAN-2004-0181 respectively. A vulnerability in the OSS code for SoundBlaster 16 devices was discovered by Andreas Kies. It is possible for local users with access to the sound system to crash the machine (CAN-2004-0178). nForce2 users were experiencing a C1 Halt Disconnect problem. A hang would occur when the CPU generated a very fast CONNECT/HALT cycle sequence. A fix has been added to resolve this issue. Brad Spengler found a signedness issue in the cpufreq proc handler which could lead to users being able to read arbitary regions of kernel memory. This was fixed by Dominik Brodowski. The Common Vulnerabilities and Exposures project (cve.mitre.org) assigned the name CAN-2004-0228 to this issue. A problem was found where userspace code could execute certain floating point instructions from signal handlers which would cause the kernel to lock up. The Common Vulnerabilities and Exposures project (cve.mitre.org) assigned the name CAN-2004-0554 to this issue. A memory leak in the E1000 network card driver has been fixed. The Common Vulnerabilities and Exposures project (cve.mitre.org) assigned the name CAN-2004-0535 to this issue. Numerous problems referencing userspace memory were identified in several device drivers by Al Viro using the sparse tool. The Common Vulnerabilities and Exposures project (cve.mitre.org) assigned the name CAN-2004-0495 to this issue. A flaw was discovered in an error path supporting the clone() system call that allowed local users to cause a denial of service (memory leak) by passing invalid arguments to clone() running in an infinite loop of a user's program. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0427 to this issue. All users are advised to upgrade to these errata packages, which contain backported security patches that correct these issues. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/download for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1484 - Various security-related fixes for the kernel 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/XXX i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/XXX http://download.fedoralegacy.org/redhat/7.3/updates/i386/XXX http://download.fedoralegacy.org/redhat/7.3/updates/i386/XXX http://download.fedoralegacy.org/redhat/7.3/updates/i386/XXX i568: http://download.fedoralegacy.org/redhat/7.3/updates/i386/XXX http://download.fedoralegacy.org/redhat/7.3/updates/i386/XXX i686: http://download.fedoralegacy.org/redhat/7.3/updates/i386/XXX http://download.fedoralegacy.org/redhat/7.3/updates/i386/XXX http://download.fedoralegacy.org/redhat/7.3/updates/i386/XXX athlon: http://download.fedoralegacy.org/redhat/7.3/updates/i386/XXX http://download.fedoralegacy.org/redhat/7.3/updates/i386/XXX Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/XXX i386: http://download.fedoralegacy.org/redhat/9/updates/i386/XXX http://download.fedoralegacy.org/redhat/9/updates/i386/XXX http://download.fedoralegacy.org/redhat/9/updates/i386/XXX http://download.fedoralegacy.org/redhat/9/updates/i386/XXX i568: http://download.fedoralegacy.org/redhat/9/updates/i386/XXX http://download.fedoralegacy.org/redhat/9/updates/i386/XXX i686: http://download.fedoralegacy.org/redhat/9/updates/i386/XXX http://download.fedoralegacy.org/redhat/9/updates/i386/XXX http://download.fedoralegacy.org/redhat/9/updates/i386/XXX athlon: http://download.fedoralegacy.org/redhat/9/updates/i386/XXX http://download.fedoralegacy.org/redhat/9/updates/i386/XXX 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------------- XXX These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0394 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0133 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0181 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0178 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0228 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0554 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0535 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0495 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0427 https://bugzilla.fedora.us/show_bug.cgi?id=1484 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org 10. Special Notes: If you use lilo, you will have to edit your lilo.conf file and shorten the label of this kernel. The label is too long for lilo, but not for grub. --------------------------------------------------------------------- From spamtrap433941935136 at anime.net Sat Jul 17 00:08:06 2004 From: spamtrap433941935136 at anime.net (Dan Hollis) Date: Fri, 16 Jul 2004 17:08:06 -0700 (PDT) Subject: apache / php issues Message-ID: http://www.securityfocus.com/bid/10508/discussion/ http://www.securityfocus.com/bid/10619/discussion/ http://www.securityfocus.com/advisories/6948 http://www.securityfocus.com/advisories/6945 Are any of these something fedora-legacy should address? -Dan From dom at earth.li Sat Jul 17 00:14:46 2004 From: dom at earth.li (Dominic Hargreaves) Date: Sat, 17 Jul 2004 01:14:46 +0100 Subject: apache / php issues In-Reply-To: References: Message-ID: <20040717001446.GA30964@tirian.magd.ox.ac.uk> On Fri, Jul 16, 2004 at 05:08:06PM -0700, Dan Hollis wrote: > http://www.securityfocus.com/bid/10508/discussion/ http://bugzilla.fedora.us/show_bug.cgi?id=1737 > http://www.securityfocus.com/bid/10619/discussion/ http://bugzilla.fedora.us/show_bug.cgi?id=1805 > http://www.securityfocus.com/advisories/6948 > http://www.securityfocus.com/advisories/6945 http://bugzilla.fedora.us/show_bug.cgi?id=1868 > Are any of these something fedora-legacy should address? They are being addressed; see above. Dominic. From jkeating at j2solutions.net Tue Jul 20 04:20:56 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 19 Jul 2004 21:20:56 -0700 Subject: [FLSA-2004:1553] Updated sysklogd resolves memory buffer bug Message-ID: <200407192120.56679.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated sysklogd resolves memory buffer bug Advisory ID: FLSA:1553 Issue date: 2004-07-19 Product: Red Hat Linux Keywords: Bugfix Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1553 - ----------------------------------------------------------------------- - --------------------------------------------------------------------- 1. Topic: Updated sysklogd packages that fixes a memory buffer bug are now available. 2. Relevent releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 3. Problem description: The sysklogd package contains two system utilities (syslogd and klogd) that provide support for system logging. Syslogd and klogd run as daemons and log system messages to different places, like sendmail logs, security logs, and error logs. During a code review it was discovered that syslogd does not allocate enough memory to store all its pointers in the crunch list. Without it, the array is not big enough and unexpected results (or core dump) may follow. All users are advised to upgrade to these updated packages, which contain a backported fix and are not vulnerable to this issue. Fedora Legacy would like to thank Rok Papez for reporting this issue. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1553 - syslogd memory allocation error 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/sysklogd-1.4.1-14.legacy.7x.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/sysklogd-1.4.1-14.legacy.7x.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/sysklogd-1.4.1-14.legacy.9.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/sysklogd-1.4.1-14.legacy.9.i386.rpm 7. Verification: SHA1 sum Package Name - --------------------------------------------------------------------------- 3f8e285b96ae0edac5e13ac79ac399370273aabf 7.3/updates/SRPMS/sysklogd-1.4.1-14.legacy.7x.src.rpm f0f67bd5db849a382f6535363b6233f8e72a45c5 7.3/updates/i386/sysklogd-1.4.1-14.legacy.7x.i386.rpm ed1462e72e4ab23e7bb3ec270a4df7fa3216dd5e 9/updates/SRPMS/sysklogd-1.4.1-14.legacy.9.src.rpm 9a5972d1b3485c875b8f57b7b277341a74958d4b 9/updates/i386/sysklogd-1.4.1-14.legacy.9.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org - --------------------------------------------------------------------- - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA/J2o4v2HLvE71NURAkeAAJ9IdnSh7BQykbgGOhX5ZKw7GE3S5QCfVJGU Ai+YcCRdNzDOhOBuZOtPGgA= =haR0 -----END PGP SIGNATURE----- From hgoffin at gmail.com Sun Jul 11 23:21:29 2004 From: hgoffin at gmail.com (Henry Goffin) Date: Sun, 11 Jul 2004 19:21:29 -0400 Subject: old tux bug in kernel 2.4, patch Message-ID: <5ec0c4e6040711162152f61d55@mail.gmail.com> Hello all, There is a long-standing bug in Tux (the built-in kernel http server) which has been driving me nuts. When compression is enabled, Tux sends the Content-Length of the uncompressed content, but only writes the compressed bytes to the output stream. This result in a client timeout; it is especially noticeable on stylesheets under Mozilla, where it can stall a page load for up to 30 seconds. With some digging, I found the following patch from 2002 by Miles Elam: http://www.redhat.com/archives/tux-list/2002-November/msg00029.html The patch looks very low-risk and seems to be the right thing to do. Strangely, it was never acknowledged until this Feb 2004 post by Ingo Molnar: http://www.redhat.com/archives/tux-list/2004-February/msg00011.html I'm sure that backporting all the latest Tux changes is unfeasible, but perhaps Miles' patch could be applied before 2.4.20-35 gets released? - Henry Goffin From jkeating at j2solutions.net Tue Jul 20 03:45:50 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 19 Jul 2004 20:45:50 -0700 Subject: [FLSA-2004:1324] Updated libxml2 resolves security vulnerabilities Message-ID: <200407192045.53404.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated libxml2 resolves security vulnerability Advisory ID: FLSA:1324 Issue date: 2004-07-19 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1324 CVE Names: CAN-2004-0110 - ----------------------------------------------------------------------- - --------------------------------------------------------------------- 1. Topic: Updated libxml2 packages that fix an overflow when parsing remote resources are now available. 2. Relevent releases/architectures: Red Hat Linux 7.3 - i386 3. Problem description: libxml2 is a library for manipulating XML files. Yuuichi Teranishi discovered a flaw in libxml2 versions prior to 2.6.6. When fetching a remote resource via FTP or HTTP, libxml2 uses special parsing routines. These routines can overflow a buffer if passed a very long URL. If an attacker is able to find an application using libxml2 that parses remote resources and allows them to influence the URL, then this flaw could be used to execute arbitrary code. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0110 to this issue. All users are advised to upgrade to these updated packages, which contain a backported fix and are not vulnerable to this issue. Fedora Legacy would like to thank Johnny Strom for reporting this issue. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1324 - libxml2: an overflow when parsing remote resources. 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/libxml2-2.4.19-5.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/libxml2-2.4.19-5.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/libxml2-python-2.4.19-5.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/libxml2-devel-2.4.19-5.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - --------------------------------------------------------------------------- 7ea6c8e40a04c2eafb82d53e8e6931b27348f4ad 7.3/updates/SRPMS/libxml2-2.4.19-5.legacy.src.rpm c325b2b9d03335b41db6b0b462a35d1ed847e56f 7.3/updates/i386/libxml2-2.4.19-5.legacy.i386.rpm c53f70cad435630b3e5b5f5d363c7d425f980a35 7.3/updates/i386/libxml2-devel-2.4.19-5.legacy.i386.rpm 8819fa789731693645839f32f55aac2f2dc27906 7.3/updates/i386/libxml2-python-2.4.19-5.legacy.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0110 https://www.redhat.com/archives/redhat-watch-list/2004-February/msg00007.html http://mail.gnome.org/archives/xml/2004-February/msg00070.html 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org - --------------------------------------------------------------------- - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA/JVx4v2HLvE71NURAk+sAKCtr5UVXfrGLhkoHxfi5BHyDLtBmQCgum0l 5hirw0+x3WPmJhPz+nqydX4= =Xs3j -----END PGP SIGNATURE----- From jkeating at j2solutions.net Tue Jul 20 04:39:17 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 19 Jul 2004 21:39:17 -0700 Subject: [FLSA-2004:1376] Updated wu-ftpd resolves security vulnerabilities Message-ID: <200407192139.17717.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated wu-ftpd resolves security vulnerabilities Advisory ID: FLSA:1376 Issue date: 2004-07-19 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1376 CVE Names: CAN-1999-0997 CAN-2004-0148 CAN-2004-0185 - ----------------------------------------------------------------------- - --------------------------------------------------------------------- 1. Topic: Updated wu-ftpd packages that fixes multiple vulnerabilities are now available. 2. Relevent releases/architectures: Red Hat Linux 7.3 - i386 3. Problem description: The wu-ftpd package contains the Washington University FTP (File Transfer Protocol) server daemon. FTP is a method of transferring files between machines. Glenn Stewart discovered a flaw in wu-ftpd. When configured with "restricted-gid home", an authorized user could use this flaw to circumvent the configured home directory restriction by using chmod. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0148 to this issue. Michael Hendrickx found a flaw in the S/Key login handling. On servers using S/Key authentication, a remote attacker could overflow a buffer and potentially execute arbitrary code. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0185 to this issue. wu-ftp with FTP conversion enabled allows an attacker to execute commands via a malformed file name that is interpreted as an argument to the program that does the conversion, e.g. tar or uncompress. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-1999-0997 to this issue. All users are advised to upgrade to these updated packages, which contain a backported fix and are not vulnerable to this issue. Fedora Legacy would like to thank John Dalbec for reporting this issue. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1376 - wu-ftpd CAN-2004-0148, CAN-2004-0185 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/wu-ftpd-2.6.2-15.7x.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/wu-ftpd-2.6.2-15.7x.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - --------------------------------------------------------------------------- 5b50aa3a91d8bb30aa860ac05ca7b2ea60f91c05 7.3/updates/SRPMS/wu-ftpd-2.6.2-15.7x.legacy.src.rpm 6215a42cadf71683e87a4b7ffa54fd7b37d106a9 7.3/updates/i386/wu-ftpd-2.6.2-15.7x.legacy.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-1999-0997 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0148 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0185 http://rhn.redhat.com/errata/RHSA-2004-096.html 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org - --------------------------------------------------------------------- - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA/KH14v2HLvE71NURAqy6AJ0QCobCIdFzqVPO6SxsubobUY74TgCdHZld XSZlhEXHrfcCmpJiBSJletA= =n8Lp -----END PGP SIGNATURE----- From jkeating at j2solutions.net Tue Jul 20 04:41:10 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 19 Jul 2004 21:41:10 -0700 Subject: [FLSA-2004:1734] Updated mailman resolves security vulnerability Message-ID: <200407192141.10922.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated mailman resolves security vulnerability Advisory ID: FLSA:1734 Issue date: 2004-07-19 Product: Red Hat Linux Keywords: Bugfix Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1734 CVE Names: CAN-2004-0412 - ----------------------------------------------------------------------- - --------------------------------------------------------------------- 1. Topic: Updated mailman packages that fixes a remote security vulnerability are now available. 2. Relevent releases/architectures: Red Hat Linux 9 - i386 3. Problem description: Mailman is software to help manage email discussion lists, much like Majordomo and Smartmail. Unlike most similar products, Mailman gives each mailing list a webpage, and allows users to subscribe, unsubscribe, etc. over the Web. Even the list manager can administer his or her list entirely from the Web. Mailman also integrates most things people want to do with mailing lists, including archiving, mail <-> news gateways, and so on. A flaw in Mailman 2.1.* allows a remote attacker to retrieve the mailman password of any subscriber by sending a carefully crafted email request to the mailman server. A simple patch is available and is fixed upstream in Mailman 2.1.5. All users are advised to upgrade to these updated packages, which contain a backported fix and are not vulnerable to this issue. Fedora Legacy would like to thank Marc Deslauriers for reporting this issue. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1734 - CAN-2004-0412 Mailman password retrieval 6. RPMs required: Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/mailman-2.1.1-7.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/mailman-2.1.1-7.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - --------------------------------------------------------------------------- 4dee398d2d9b1d107850665f04c082073b4465a5 9/updates/SRPMS/mailman-2.1.1-7.legacy.src.rpm 66cbbfcf168869969b0aaa0298d3680c3b8e5a3c 9/updates/i386/mailman-2.1.1-7.legacy.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0412 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=123559 http://mail.python.org/pipermail/mailman-announce/2004-May/000072.html 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org - --------------------------------------------------------------------- - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA/KJm4v2HLvE71NURAnZ1AKCSvZPfi6Xxiyc2TKClJFGRicumbwCcDkNv LSJgsv5aUkMC1FcxHVk6D98= =+s0z -----END PGP SIGNATURE----- From lsomike at futzin.com Tue Jul 20 04:56:57 2004 From: lsomike at futzin.com (Mike Klinke) Date: Mon, 19 Jul 2004 23:56:57 -0500 Subject: [FLSA-2004:1734] Updated mailman resolves security vulnerability In-Reply-To: <200407192141.10922.jkeating@j2solutions.net> References: <200407192141.10922.jkeating@j2solutions.net> Message-ID: <200407192356.57366.lsomike@futzin.com> On Monday 19 July 2004 23:41, Jesse Keating wrote: > > 2. Relevent releases/architectures: > > Red Hat Linux 9 - i386 > > > SRPM: > http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/mailman-2 >.1.1-7.legacy.src.rpm > > i386: > http://download.fedoralegacy.org/redhat/7.3/updates/i386/mailman-2. >1.1-7.legacy.i386.rpm > It seems odd that these aren't found in a RH9.0 download tree rather than RH7.3 .... Regards, Mike Klinke From jkeating at j2solutions.net Tue Jul 20 05:28:59 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 19 Jul 2004 22:28:59 -0700 Subject: [FLSA-2004:1734] Updated mailman resolves security vulnerability In-Reply-To: <200407192356.57366.lsomike@futzin.com> References: <200407192141.10922.jkeating@j2solutions.net> <200407192356.57366.lsomike@futzin.com> Message-ID: <200407192228.59524.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 19 July 2004 21:56, Mike Klinke wrote: > It seems odd that these aren't found in a RH9.0 download tree rather > than RH7.3 .... Er, whoops. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA/K2b4v2HLvE71NURAlxYAJwJCisSKIggLdbSK4Fe6k0MJ9TXrwCfbRTi UmcJxAFkldl+FqaWcXTWgSE= =mslo -----END PGP SIGNATURE----- From jkeating at j2solutions.net Tue Jul 20 05:30:07 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 19 Jul 2004 22:30:07 -0700 Subject: [FLSA-2004:1734] Updated mailman resolves security vulnerability -reissue to fix url- Message-ID: <200407192230.07383.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated mailman resolves security vulnerability Advisory ID: FLSA:1734 Issue date: 2004-07-19 Product: Red Hat Linux Keywords: Bugfix Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1734 CVE Names: CAN-2004-0412 - ----------------------------------------------------------------------- - --------------------------------------------------------------------- 1. Topic: Updated mailman packages that fixes a remote security vulnerability are now available. 2. Relevent releases/architectures: Red Hat Linux 9 - i386 3. Problem description: Mailman is software to help manage email discussion lists, much like Majordomo and Smartmail. Unlike most similar products, Mailman gives each mailing list a webpage, and allows users to subscribe, unsubscribe, etc. over the Web. Even the list manager can administer his or her list entirely from the Web. Mailman also integrates most things people want to do with mailing lists, including archiving, mail <-> news gateways, and so on. A flaw in Mailman 2.1.* allows a remote attacker to retrieve the mailman password of any subscriber by sending a carefully crafted email request to the mailman server. A simple patch is available and is fixed upstream in Mailman 2.1.5. All users are advised to upgrade to these updated packages, which contain a backported fix and are not vulnerable to this issue. Fedora Legacy would like to thank Marc Deslauriers for reporting this issue. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1734 - CAN-2004-0412 Mailman password retrieval 6. RPMs required: Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/mailman-2.1.1-7.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/mailman-2.1.1-7.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - --------------------------------------------------------------------------- 4dee398d2d9b1d107850665f04c082073b4465a5 9/updates/SRPMS/mailman-2.1.1-7.legacy.src.rpm 66cbbfcf168869969b0aaa0298d3680c3b8e5a3c 9/updates/i386/mailman-2.1.1-7.legacy.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0412 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=123559 http://mail.python.org/pipermail/mailman-announce/2004-May/000072.html 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org - --------------------------------------------------------------------- - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD4DBQFA/K3f4v2HLvE71NURAk0gAKCzOPT3HmqWO2U1XWDzO3y9caryIwCYy09y mX442uoSC9FJC7h6ihlt1Q== =gfmi -----END PGP SIGNATURE----- From Bernd.Bartmann at sohanet.de Tue Jul 20 08:47:39 2004 From: Bernd.Bartmann at sohanet.de (Bernd Bartmann) Date: Tue, 20 Jul 2004 10:47:39 +0200 Subject: [FLSA-2004:1734] Updated mailman resolves security vulnerability In-Reply-To: <200407192356.57366.lsomike@futzin.com> References: <200407192141.10922.jkeating@j2solutions.net> <200407192356.57366.lsomike@futzin.com> Message-ID: <40FCDC2B.3000904@sohanet.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mike Klinke wrote: | It seems odd that these aren't found in a RH9.0 download tree rather | than RH7.3 .... And the same problem appears to be in the sysklogd advisory FLSA-2004:1553. Best regards. - -- Dipl.-Ing. (FH) Bernd Bartmann I.S. Security and Network Engineer SoHaNet Technology GmbH / Kaiserin-Augusta-Allee 10-11 / 10553 Berlin Fon: +49 30 214783-44 / Fax: +49 30 214783-46 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFA/NwrkQuIaHu84cIRAt7tAKCDV5023tvSloAUAzP6E3Sl8Qe7owCgmhr8 4wPcmP5HWsQdZyBsDmsKAgo= =NZS0 -----END PGP SIGNATURE----- From dom at earth.li Tue Jul 20 10:19:35 2004 From: dom at earth.li (Dominic Hargreaves) Date: Tue, 20 Jul 2004 11:19:35 +0100 Subject: old tux bug in kernel 2.4, patch In-Reply-To: <5ec0c4e6040711162152f61d55@mail.gmail.com> References: <5ec0c4e6040711162152f61d55@mail.gmail.com> Message-ID: <20040720101935.GO30964@tirian.magd.ox.ac.uk> On Sun, Jul 11, 2004 at 07:21:29PM -0400, Henry Goffin wrote: > I'm sure that backporting all the latest Tux changes is unfeasible, > but perhaps Miles' patch could be applied before 2.4.20-35 gets > released? Hi, We're way past adding things to -35. There are already more fixes pending for the kernel, which will be addressed in due course; if you could a summary to that would make sure it doesn't get forgotten about. Cheers, Dominic. From jkeating at j2solutions.net Wed Jul 21 02:41:42 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 20 Jul 2004 19:41:42 -0700 Subject: [FLSA-2004:1553] Updated sysklogd resolves memory buffer bug -reissue to fix url- Message-ID: <200407201941.45658.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated sysklogd resolves memory buffer bug Advisory ID: FLSA:1553 Issue date: 2004-07-19 Product: Red Hat Linux Keywords: Bugfix Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1553 - ----------------------------------------------------------------------- - --------------------------------------------------------------------- 1. Topic: Updated sysklogd packages that fixes a memory buffer bug are now available. 2. Relevent releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 3. Problem description: The sysklogd package contains two system utilities (syslogd and klogd) that provide support for system logging. Syslogd and klogd run as daemons and log system messages to different places, like sendmail logs, security logs, and error logs. During a code review it was discovered that syslogd does not allocate enough memory to store all its pointers in the crunch list. Without it, the array is not big enough and unexpected results (or core dump) may follow. All users are advised to upgrade to these updated packages, which contain a backported fix and are not vulnerable to this issue. Fedora Legacy would like to thank Rok Papez for reporting this issue. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1553 - syslogd memory allocation error 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/sysklogd-1.4.1-14.legacy.7x.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/sysklogd-1.4.1-14.legacy.7x.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/sysklogd-1.4.1-14.legacy.9.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/sysklogd-1.4.1-14.legacy.9.i386.rpm 7. Verification: SHA1 sum Package Name - --------------------------------------------------------------------------- 3f8e285b96ae0edac5e13ac79ac399370273aabf 7.3/updates/SRPMS/sysklogd-1.4.1-14.legacy.7x.src.rpm f0f67bd5db849a382f6535363b6233f8e72a45c5 7.3/updates/i386/sysklogd-1.4.1-14.legacy.7x.i386.rpm ed1462e72e4ab23e7bb3ec270a4df7fa3216dd5e 9/updates/SRPMS/sysklogd-1.4.1-14.legacy.9.src.rpm 9a5972d1b3485c875b8f57b7b277341a74958d4b 9/updates/i386/sysklogd-1.4.1-14.legacy.9.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org - --------------------------------------------------------------------- - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA/dfp4v2HLvE71NURAma7AJ44zU3Y+8ir1JVo+W7vI+I14cH0xQCgvyjD w85yd3Pej3MpxqhzenFr+XA= =pO5M -----END PGP SIGNATURE----- From stuart at serverpeak.com Thu Jul 22 03:22:56 2004 From: stuart at serverpeak.com (Stuart Low) Date: Thu, 22 Jul 2004 13:22:56 +1000 Subject: New PHP 4.3.8 RPMS Released Message-ID: <1090466575.3453.7.camel@poohbox> Hi there, I've just released PHP RPMs for Redhat 7.3, 9, Enterprise 3 & Fedora Core 1/2. Announcement here: http://www.seekbrain.com/archives/000059.html Repository here: http://www.seekbrain.com/downloads/psa/ Stuart From spamtrap433941935136 at anime.net Thu Jul 22 08:14:30 2004 From: spamtrap433941935136 at anime.net (Dan Hollis) Date: Thu, 22 Jul 2004 01:14:30 -0700 (PDT) Subject: New PHP 4.3.8 RPMS Released In-Reply-To: <1090466575.3453.7.camel@poohbox> Message-ID: On Thu, 22 Jul 2004, Stuart Low wrote: > Hi there, > I've just released PHP RPMs for Redhat 7.3, 9, Enterprise 3 & Fedora > Core 1/2. > Announcement here: http://www.seekbrain.com/archives/000059.html > Repository here: http://www.seekbrain.com/downloads/psa/ Anyone maintaining rh8.0? -Dan From stuart at serverpeak.com Thu Jul 22 08:42:23 2004 From: stuart at serverpeak.com (Stuart Low) Date: Thu, 22 Jul 2004 18:42:23 +1000 Subject: New PHP 4.3.8 RPMS Released In-Reply-To: References: Message-ID: <1090485743.19212.1.camel@dhcpd62.seekbrain.com> > > Announcement here: http://www.seekbrain.com/archives/000059.html > > Repository here: http://www.seekbrain.com/downloads/psa/ > > Anyone maintaining rh8.0? I don't have a RH8 system and to be perfectly honest I wouldn't recommend running a RH8 production system. From memory also Fedora Legacy has discontinued supporting RH8 directly. In either case, you should be able to rebuild the RH9 src.rpm for RH8. Stuart From spamtrap433941935136 at anime.net Thu Jul 22 08:52:39 2004 From: spamtrap433941935136 at anime.net (Dan Hollis) Date: Thu, 22 Jul 2004 01:52:39 -0700 (PDT) Subject: New PHP 4.3.8 RPMS Released In-Reply-To: <1090485743.19212.1.camel@dhcpd62.seekbrain.com> Message-ID: On Thu, 22 Jul 2004, Stuart Low wrote: > I don't have a RH8 system and to be perfectly honest I wouldn't > recommend running a RH8 production system. Why not? > From memory also Fedora Legacy has discontinued supporting RH8 directly. Is there any official announcement to this effect? The fedoralegacy.org website still says RH8 is supported, although I have not seen any RH8 updates for some time. http://fedoralegacy.org/about/faq.php If it is no longer supported by fedoralegacy then the website should probably be updated to reflect that official policy. -Dan From mark at foster.cc Thu Jul 22 16:20:43 2004 From: mark at foster.cc (Mark Foster) Date: Thu, 22 Jul 2004 09:20:43 -0700 Subject: fedora-legacy-list Digest, Vol 5, Issue 18 In-Reply-To: <20040722160012.118D873C05@hormel.redhat.com> References: <20040722160012.118D873C05@hormel.redhat.com> Message-ID: <40FFE95B.8040500@foster.cc> fedora-legacy-list-request at redhat.com wrote: > On Thu, 22 Jul 2004, Stuart Low wrote: > >>I don't have a RH8 system and to be perfectly honest I wouldn't >>recommend running a RH8 production system. > > > Why not? > > >>From memory also Fedora Legacy has discontinued supporting RH8 directly. > > > Is there any official announcement to this effect? The fedoralegacy.org > website still says RH8 is supported, although I have not seen any RH8 > updates for some time. http://fedoralegacy.org/about/faq.php > > If it is no longer supported by fedoralegacy then the website should > probably be updated to reflect that official policy. I have the same concern about 7.2. I recall some messages to the effect that 7.2 support would be dropped but never any official word. The outcome greatly affects my upgrade plans. Please advise. -- Some days it's just not worth chewing through the restraints... Mark D. Foster, CISSP http://mark.foster.cc/ From mic at npgx.com.au Thu Jul 22 23:35:08 2004 From: mic at npgx.com.au (Michael Mansour) Date: Fri, 23 Jul 2004 09:35:08 +1000 Subject: New PHP 4.3.8 RPMS Released In-Reply-To: <1090485743.19212.1.camel@dhcpd62.seekbrain.com> References: <1090485743.19212.1.camel@dhcpd62.seekbrain.com> Message-ID: <20040722233300.M22954@npgx.com.au> Hi Stuart, > > > Announcement here: http://www.seekbrain.com/archives/000059.html > > > Repository here: http://www.seekbrain.com/downloads/psa/ > > > > Anyone maintaining rh8.0? > > I don't have a RH8 system and to be perfectly honest I wouldn't > recommend running a RH8 production system. From memory also Fedora > Legacy has discontinued supporting RH8 directly. > > In either case, you should be able to rebuild the RH9 src.rpm for RH8. > > Stuart That's interesting how you say that, you don't have a RH8 system and you're making a recommendation based on that. Before FL dropped RH8 support, I ran 5 large RH8 production servers, never had a problem with any of them and really never needed to upgrade, they were humming along just fine. Michael. From marcdeslauriers at videotron.ca Fri Jul 23 00:57:24 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 22 Jul 2004 20:57:24 -0400 Subject: New PHP 4.3.8 RPMS Released In-Reply-To: <1090466575.3453.7.camel@poohbox> References: <1090466575.3453.7.camel@poohbox> Message-ID: <1090544244.30586.1.camel@mdlinux> On Wed, 2004-07-21 at 23:22, Stuart Low wrote: > I've just released PHP RPMs for Redhat 7.3, 9, Enterprise 3 & Fedora > Core 1/2. There are some Fedora Legacy php rpm's awaiting QA here: https://bugzilla.fedora.us/show_bug.cgi?id=1868 Marc. From jkeating at j2solutions.net Fri Jul 23 02:10:17 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 22 Jul 2004 19:10:17 -0700 Subject: Fedora Test Update Notification: libxml2 Message-ID: <200407221910.20230.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1324 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1324 2004-07-22 - --------------------------------------------------------------------- Name : libxml2 Version 7.3 : 2.4.19-6.legacy Summary : Library providing XML and HTML support Description : This library allows to manipulate XML files. It includes support to read, modify and write XML and HTML files. There is DTDs support this includes parsing and validation even with complex DtDs, either at parse time or later once the document has been modified. The output can be a simple SAX stream or and in-memory DOM like representations. In this case one can use the built-in XPath and XPointer implementation to select subnodes or ranges. A flexible Input/Output mechanism is available, with existing HTTP and FTP modules and combined to an URI library. - --------------------------------------------------------------------- Update Information: Rebuilt to include python2 content. - --------------------------------------------------------------------- Changelog: 7.3: * Sat May 01 2004 Seth Vidal - - updated patch with patch from bug #1324 comment 4 - - added buildrequires from comment 6 * Fri Feb 27 2004 Dominic Hargreaves - - fixes overflow when parsing remote resources - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ 8a1d844bfb9494c00bd4a6dd2d95a0829daf9f42 7.3/updates-testing/SRPMS/libxml2-2.4.19-6.legacy.src.rpm 41e9e0daaf643f9d3ec96cbba7b050a397d1907e 7.3/updates-testing/i386/libxml2-2.4.19-6.legacy.i386.rpm Please note that this update is also available via yum and apt through the updates-testing channel. Many people find this an easier way to apply updates. - --------------------------------------------------------------------- - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBAHOM4v2HLvE71NURAm+0AJ9PpeI9QaZXQQMW1dtDoFC8NjgTGACdEpCv YYb6YNWDimUfBl3SP0+3xVc= =8AIG -----END PGP SIGNATURE----- From stuart at serverpeak.com Fri Jul 23 02:58:37 2004 From: stuart at serverpeak.com (Stuart Low) Date: Fri, 23 Jul 2004 12:58:37 +1000 Subject: New PHP 4.3.8 RPMS Released In-Reply-To: <20040722233300.M22954@npgx.com.au> References: <1090485743.19212.1.camel@dhcpd62.seekbrain.com> <20040722233300.M22954@npgx.com.au> Message-ID: <1090551517.3448.37.camel@poohbox> > That's interesting how you say that, you don't have a RH8 system and you're > making a recommendation based on that. Before FL dropped RH8 support, I ran 5 > large RH8 production servers, never had a problem with any of them and really > never needed to upgrade, they were humming along just fine. I said I didn't have a RH8 system, not that I had never had one. RH8 has major problems with the RPM database system with RPM transactions benchmarked to take over 4 times longer than RH7.3. Sure.. they'll be just fine if you leave them alone but then so would a Slackware 2.0 machine. :) However, as soon as one attempts to do any sort of RPM development or even update RPMs on a regular basis (I'm in the webhosting arena and PHP, Apache and Control panel updates are common) the RPM system goes to hell. *shrugs* You've switched to RH9 now? Ironic. ;) Stuart From mic at npgx.com.au Fri Jul 23 07:32:40 2004 From: mic at npgx.com.au (Michael Mansour) Date: Fri, 23 Jul 2004 17:32:40 +1000 Subject: New PHP 4.3.8 RPMS Released In-Reply-To: <1090551517.3448.37.camel@poohbox> References: <1090485743.19212.1.camel@dhcpd62.seekbrain.com> <20040722233300.M22954@npgx.com.au> <1090551517.3448.37.camel@poohbox> Message-ID: <20040723064204.M78189@npgx.com.au> Hi Stuart, > > That's interesting how you say that, you don't have a RH8 system and you're > > making a recommendation based on that. Before FL dropped RH8 support, I ran 5 > > large RH8 production servers, never had a problem with any of them and really > > never needed to upgrade, they were humming along just fine. > > I said I didn't have a RH8 system, not that I had never had one. RH8 > has major problems with the RPM database system with RPM > transactions benchmarked to take over 4 times longer than RH7.3. > > Sure.. they'll be just fine if you leave them alone but then so > would a Slackware 2.0 machine. :) However, as soon as one attempts > to do any sort of RPM development or even update RPMs on a regular > basis (I'm in the webhosting arena and PHP, Apache and Control panel > updates are common) the RPM system goes to hell. > > *shrugs* You've switched to RH9 now? Ironic. ;) FC1 actually :). Yeah, RPM has always been an issue in RH8 but for the servers that my company was running that problem didn't play such a big role, remember also that FL released the patched RPM package manager which resolved those issues. For me, I just don't like to see "bad press" about an OS that was production quality and ran in production just fine, sure it had a couple of hiccups, just like any other OS does, but to say the least it was certainly still better than Windows production servers. Michael. From spamtrap433941935136 at anime.net Fri Jul 23 10:17:56 2004 From: spamtrap433941935136 at anime.net (Dan Hollis) Date: Fri, 23 Jul 2004 03:17:56 -0700 (PDT) Subject: New PHP 4.3.8 RPMS Released In-Reply-To: <20040722233300.M22954@npgx.com.au> Message-ID: On Fri, 23 Jul 2004, Michael Mansour wrote: > That's interesting how you say that, you don't have a RH8 system and you're > making a recommendation based on that. Before FL dropped RH8 support, I ran 5 > large RH8 production servers, never had a problem with any of them and really > never needed to upgrade, they were humming along just fine. What I find amusing is that RH8 is not supported, but RH9 with the 'tls and rpm from hell' is...? Weird. -Dan From marcdeslauriers at videotron.ca Fri Jul 23 10:45:15 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Fri, 23 Jul 2004 06:45:15 -0400 Subject: New PHP 4.3.8 RPMS Released In-Reply-To: References: Message-ID: <1090579515.5681.1.camel@mdlinux> On Fri, 2004-07-23 at 06:17, Dan Hollis wrote: > What I find amusing is that RH8 is not supported, but RH9 with the > 'tls and rpm from hell' is...? Weird. The fact that RH8 was dropped had nothing to do with technology. It was simply that no one was volunteering their time to QA the package proposals FL had in bugzilla. It was quite simply lack of community interest. Marc. From brian.t.brunner at gai-tronics.com Fri Jul 23 12:23:44 2004 From: brian.t.brunner at gai-tronics.com (Brian T. Brunner) Date: Fri, 23 Jul 2004 08:23:44 -0400 Subject: New PHP 4.3.8 RPMS Released Message-ID: The real reason RH9 is supported is that there is no RH10 and never will be. FC1 is a different attitude on the part of Red Hat, Brian Brunner brian.t.brunner at gai-tronics.com (610)796-5838 >>> marcdeslauriers at videotron.ca 07/23/04 06:45AM >>> On Fri, 2004-07-23 at 06:17, Dan Hollis wrote: > What I find amusing is that RH8 is not supported, but RH9 with the > 'tls and rpm from hell' is...? Weird. The fact that RH8 was dropped had nothing to do with technology. It was simply that no one was volunteering their time to QA the package proposals FL had in bugzilla. It was quite simply lack of community interest. Marc. -- fedora-legacy-list mailing list fedora-legacy-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-legacy-list ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.hubbell.com - Hubbell Incorporated From michal at harddata.com Fri Jul 23 17:38:33 2004 From: michal at harddata.com (Michal Jaegermann) Date: Fri, 23 Jul 2004 11:38:33 -0600 Subject: why that distro (was: New PHP 4.3.8 RPMS Released) In-Reply-To: <20040723064204.M78189@npgx.com.au>; from mic@npgx.com.au on Fri, Jul 23, 2004 at 05:32:40PM +1000 References: <1090485743.19212.1.camel@dhcpd62.seekbrain.com> <20040722233300.M22954@npgx.com.au> <1090551517.3448.37.camel@poohbox> <20040723064204.M78189@npgx.com.au> Message-ID: <20040723113833.A676@mail.harddata.com> On Fri, Jul 23, 2004 at 05:32:40PM +1000, Michael Mansour wrote: > > For me, I just don't like to see "bad press" about an OS that was production > quality and ran in production just fine, sure it had a couple of hiccups, just > like any other OS does, I bumped into a considerable number of such "hiccups" with RH8. This was a while ago and I may not remember all details but basically regular expressions (grep, perl, awk, sed, ...) were broken and/or extremely slow, emacs and other editors had weird issues, man was broken totally, a strange stuff was happening randomnly on desktops, whatever you touched related on i18n had big chances to misbehave, other problems. Binaries for rpm I replaced very quickly with what was available from www.rpm.org, so this was not a show stopper, but other things kept me from considering that distro for anything but a test installation. I think that a switch to utf8 was underlying most of that and switching to other LANG was not a good enough answer. From my point of view RH9 was a huge step forward. This is what my wife used on her laptop, and this is a tougher coundition that it may sound, :-) although now it is FC2. > but to say the least it was certainly still better > than Windows production servers. Well, by such criteria mostly anything will be acceptable. How this is called? "Damning by a faint praise"? :-) Michal From spamtrap433941935136 at anime.net Fri Jul 23 18:36:07 2004 From: spamtrap433941935136 at anime.net (Dan Hollis) Date: Fri, 23 Jul 2004 11:36:07 -0700 (PDT) Subject: New PHP 4.3.8 RPMS Released In-Reply-To: <1090579515.5681.1.camel@mdlinux> Message-ID: On Fri, 23 Jul 2004, Marc Deslauriers wrote: > On Fri, 2004-07-23 at 06:17, Dan Hollis wrote: > > What I find amusing is that RH8 is not supported, but RH9 with the > > 'tls and rpm from hell' is...? Weird. > The fact that RH8 was dropped had nothing to do with technology. It was > simply that no one was volunteering their time to QA the package > proposals FL had in bugzilla. > It was quite simply lack of community interest. Then whoever maintains the http://www.fedoralegacy.org/ website should remove RH8 from the list of officially supported platforms on the webpage. http://www.fedoralegacy.org/about/faq.php It might confuse people into thinking its actually supported when it isn't. -Dan From rostetter at mail.utexas.edu Fri Jul 23 20:21:20 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 23 Jul 2004 15:21:20 -0500 Subject: New PHP 4.3.8 RPMS Released In-Reply-To: References: Message-ID: <20040723152120.mdqqzw7fr4so440c@mail.ph.utexas.edu> Quoting Dan Hollis : > What I find amusing is that RH8 is not supported, but RH9 with the > 'tls and rpm from hell' is...? Weird. > > -Dan It has nothing to do with the quality of the OS. It is completely dependent on the number of people willing to help support that OS version. Lots of people are actively supporting RH 9 developement/testing. Very few are supporting RH 8 development/testing. Therefore RH 9 stays, and RH 8 gets dropped. Simple. -- Eric Rostetter From spamtrap433941935136 at anime.net Fri Jul 23 21:29:26 2004 From: spamtrap433941935136 at anime.net (Dan Hollis) Date: Fri, 23 Jul 2004 14:29:26 -0700 (PDT) Subject: New PHP 4.3.8 RPMS Released In-Reply-To: <20040723152120.mdqqzw7fr4so440c@mail.ph.utexas.edu> Message-ID: On Fri, 23 Jul 2004, Eric Rostetter wrote: > It has nothing to do with the quality of the OS. It is completely dependent > on the number of people willing to help support that OS version. Lots of > people are actively supporting RH 9 developement/testing. Very few are > supporting RH 8 development/testing. Therefore RH 9 stays, and RH 8 gets > dropped. Simple. Then the erroneous claim on http://www.fedoralegacy.org/about/faq.php that RH 8 is supported should be dropped. Also all references to RH 8 on http://www.fedoralegacy.org/docs/ and http://www.fedoralegacy.org/updates/ should be removed, so that nobody mistakenly believes that fedoralegacy supports RH 8 anymore. -Dan From rostetter at mail.utexas.edu Fri Jul 23 22:10:41 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 23 Jul 2004 17:10:41 -0500 Subject: New PHP 4.3.8 RPMS Released In-Reply-To: References: Message-ID: <20040723171041.71rid4wku80cksck@mail.ph.utexas.edu> Quoting Dan Hollis : > Then whoever maintains the http://www.fedoralegacy.org/ website should That would be me. > remove RH8 from the list of officially supported platforms on the webpage. Not until someone makes an official statement that it is being dropped, which has not been done yet. > It might confuse people into thinking its actually supported when it > isn't. It's currently in limbo. Everytime dropping it is discussed, a bunch of people say they will start supporting it, but then few if any actually do, so we discuss dropping it again, and so on... Eventually an official statement will be made that we are dropping 7.2 and 8.0, and when that is done, the web page will be updated. In the mean time, they are in limbo... > -Dan -- Eric Rostetter From wstockal at compusmart.ab.ca Fri Jul 23 22:18:32 2004 From: wstockal at compusmart.ab.ca (William Stockall) Date: Fri, 23 Jul 2004 16:18:32 -0600 Subject: New PHP 4.3.8 RPMS Released In-Reply-To: <20040723171041.71rid4wku80cksck@mail.ph.utexas.edu> References: <20040723171041.71rid4wku80cksck@mail.ph.utexas.edu> Message-ID: <41018EB8.1020801@compusmart.ab.ca> Eric Rostetter wrote: > Quoting Dan Hollis : > > >> remove RH8 from the list of officially supported platforms on the >> webpage. > > > Not until someone makes an official statement that it is being dropped, > which > has not been done yet. > >> It might confuse people into thinking its actually supported when it >> isn't. > > > It's currently in limbo. Everytime dropping it is discussed, a bunch of > people > say they will start supporting it, but then few if any actually do, so we > discuss dropping it again, and so on... Eventually an official statement > will be made that we are dropping 7.2 and 8.0, and when that is done, the > web page will be updated. In the mean time, they are in limbo... > Could a statement to the effect that support for these platforms is currently suspended due to a shortage of maintainers be added to the web page? >> -Dan > > > -- > Eric Rostetter > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list Will. From jkeating at j2solutions.net Fri Jul 23 22:32:26 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 23 Jul 2004 15:32:26 -0700 Subject: New PHP 4.3.8 RPMS Released In-Reply-To: <20040723171041.71rid4wku80cksck@mail.ph.utexas.edu> References: <20040723171041.71rid4wku80cksck@mail.ph.utexas.edu> Message-ID: <200407231532.29378.jkeating@j2solutions.net> On Friday 23 July 2004 15:10, Eric Rostetter wrote: > Not until someone makes an official statement that it is being > dropped, which has not been done yet. Erik, take this as an official statement. RHL 7.2 and 8 support has been suspended due to lack of community involvement. I don't feel that there will be enough involvement to resume support. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From rostetter at mail.utexas.edu Fri Jul 23 22:39:58 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 23 Jul 2004 17:39:58 -0500 Subject: New PHP 4.3.8 RPMS Released In-Reply-To: References: Message-ID: <20040723173958.wv67lglsv9cww0oo@mail.ph.utexas.edu> Quoting Dan Hollis : > On Fri, 23 Jul 2004, Eric Rostetter wrote: >> It has nothing to do with the quality of the OS. It is completely dependent >> on the number of people willing to help support that OS version. Lots of >> people are actively supporting RH 9 developement/testing. Very few are >> supporting RH 8 development/testing. Therefore RH 9 stays, and RH 8 gets >> dropped. Simple. > > Then the erroneous claim on http://www.fedoralegacy.org/about/faq.php that > RH 8 is supported should be dropped. Not until it is officially dropped. There has been no official statement about it yet. Same for 7.2. > Also all references to RH 8 on http://www.fedoralegacy.org/docs/ and > http://www.fedoralegacy.org/updates/ should be removed, so that nobody > mistakenly believes that fedoralegacy supports RH 8 anymore. No need to throw out all the updates that exist, just because more are not forthcoming, is there? But maybe just putting a disclaimer on them would be sufficient? > -Dan -- Eric Rostetter From rostetter at mail.utexas.edu Fri Jul 23 23:03:41 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 23 Jul 2004 18:03:41 -0500 Subject: New PHP 4.3.8 RPMS Released In-Reply-To: <200407231532.29378.jkeating@j2solutions.net> References: <20040723171041.71rid4wku80cksck@mail.ph.utexas.edu> <200407231532.29378.jkeating@j2solutions.net> Message-ID: <20040723180341.0usa41zopw4swo04@mail.ph.utexas.edu> Quoting Jesse Keating : > On Friday 23 July 2004 15:10, Eric Rostetter wrote: >> Not until someone makes an official statement that it is being >> dropped, which has not been done yet. > > Erik, take this as an official statement. RHL 7.2 and 8 support has > been suspended due to lack of community involvement. I don't feel that > there will be enough involvement to resume support. Statement added to the home page (front page), warning added to the main advisories page, and references removed from the FAQ. If anyone wants to see more warnings, removals, or tweaks, let me know. > -- > Jesse Keating RHCE (geek.j2solutions.net) > Fedora Legacy Team (www.fedoralegacy.org) > GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) > > Was I helpful? Let others know: > http://svcs.affero.net/rm.php?r=jkeating -- Eric Rostetter From spamtrap433941935136 at anime.net Sat Jul 24 00:09:29 2004 From: spamtrap433941935136 at anime.net (Dan Hollis) Date: Fri, 23 Jul 2004 17:09:29 -0700 (PDT) Subject: New PHP 4.3.8 RPMS Released In-Reply-To: <20040723180341.0usa41zopw4swo04@mail.ph.utexas.edu> Message-ID: On Fri, 23 Jul 2004, Eric Rostetter wrote: > If anyone wants to see more warnings, removals, or tweaks, let me know. http://www.fedoralegacy.org/docs/ Also... bugzilla -> http://bugzilla.fedora.us/ -> Connection refused -Dan From rostetter at mail.utexas.edu Sat Jul 24 03:27:40 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 23 Jul 2004 22:27:40 -0500 Subject: New PHP 4.3.8 RPMS Released In-Reply-To: References: Message-ID: <20040723222740.126m8ko4ksggg0gw@mail.ph.utexas.edu> Quoting Dan Hollis : > On Fri, 23 Jul 2004, Eric Rostetter wrote: >> If anyone wants to see more warnings, removals, or tweaks, let me know. > > http://www.fedoralegacy.org/docs/ Okay, what you want me to do with it? > -Dan -- Eric Rostetter From spamtrap433941935136 at anime.net Sat Jul 24 04:04:23 2004 From: spamtrap433941935136 at anime.net (Dan Hollis) Date: Fri, 23 Jul 2004 21:04:23 -0700 (PDT) Subject: New PHP 4.3.8 RPMS Released In-Reply-To: <20040723222740.126m8ko4ksggg0gw@mail.ph.utexas.edu> Message-ID: On Fri, 23 Jul 2004, Eric Rostetter wrote: > Quoting Dan Hollis : > > On Fri, 23 Jul 2004, Eric Rostetter wrote: > >> If anyone wants to see more warnings, removals, or tweaks, let me know. > > http://www.fedoralegacy.org/docs/ > Okay, what you want me to do with it? Put a warning on the page the same as you did with http://www.fedoralegacy.org/updates/ -Dan From mkratz at internode.com.au Sat Jul 24 09:31:31 2004 From: mkratz at internode.com.au (Michael Kratz) Date: Sat, 24 Jul 2004 19:01:31 +0930 Subject: RH7.1->RH7.2 Message-ID: <41022C73.9040906@internode.com.au> Howdy all, I've been steadily upgrading packages on a RH7.1 box that I have to packages from RH7.2. Now I've come to the final list of packages, which I don't really want to do one at a time but rather all at once with a "yum upgrade". What I'd like to know is the opinions of anyone on this list of how likely the box is to break with this final upgrade of packages to bring the box up to RH7.2 Note: all other packages have already been upgraded, here's the final list of packages still to be done. Name Arch Version -------------------------------------------------------------------------------- SysVinit i386 2.78-19 alchemist i386 1.0.18-1 anacron i386 2.3-17 authconfig i386 4.1.19.2-1 autoconf noarch 2.13-14 autofs i386 3.1.7-21 bash i386 2.05-8 bdflush i386 1.5-17 chkconfig i386 1.2.24-1 console-tools i386 19990829-36 crontabs noarch 1.10-1 e2fsprogs i386 1.26-1.72 e2fsprogs-devel i386 1.26-1.72 filesystem noarch 2.1.6-2 glib i386 1.2.10-5 hdparm i386 4.1-2 hotplug i386 2001_04_24-11 initscripts i386 6.43-1 iproute i386 2.4.7-7.72.1 kbdconfig i386 1.9.14-1 kernel i586 2.4.20-30.7.legacy krbafs i386 1.0.9-2 ksymoops i386 2.4.1-1 libstdc++ i386 2.96-112.7.2 libstdc++-devel i386 2.96-112.7.2 libtermcap i386 2.0.8-28 libtermcap-devel i386 2.0.8-28 lilo i386 21.4.4-14 linuxconf i386 1.25r7-3 logrotate i386 3.5.9-1 losetup i386 2.11g-5 m4 i386 1.4.1-5 mingetty i386 0.9.4-18 mkbootdisk i386 1.4.2-3 mktemp i386 1.5-11 mount i386 2.11g-5 ntsysv i386 1.2.24-1 pam i386 0.75-46.7.2 pam-devel i386 0.75-46.7.2 pam_krb5 i386 1.46-1 passwd i386 0.64.1-7 procps i386 2.0.7-11 psmisc i386 20.1-2 psutils i386 1.17-13 pwdb i386 0.61.1-3 python i386 1.5.2-43.72 python-devel i386 1.5.2-43.72 redhat-logos noarch 1.1.3-1 redhat-release noarch 7.2-1 rootfiles noarch 7.2-1 setup noarch 2.5.7-1 setuptool i386 1.8-2 sh-utils i386 2.0.11-5 shadow-utils i386 20000902-9.7 stat i386 2.5-2 syslinux i386 1.52-2 sysstat i386 4.0.1-2 I'd be most grateful for any opinions on this, and how risky it would be :) Cheers, Michael From michal at harddata.com Sat Jul 24 23:41:57 2004 From: michal at harddata.com (Michal Jaegermann) Date: Sat, 24 Jul 2004 17:41:57 -0600 Subject: New PHP 4.3.8 RPMS Released In-Reply-To: <1090466575.3453.7.camel@poohbox>; from stuart@serverpeak.com on Thu, Jul 22, 2004 at 01:22:56PM +1000 References: <1090466575.3453.7.camel@poohbox> Message-ID: <20040724174157.A349@mail.harddata.com> On Thu, Jul 22, 2004 at 01:22:56PM +1000, Stuart Low wrote: > > I've just released PHP RPMs for Redhat 7.3, 9, Enterprise 3 & Fedora > Core 1/2. > > Repository here: http://www.seekbrain.com/downloads/psa/ I tried that on RH7.3 installation and I got, trying to start a server, Cannot load /etc/httpd/modules/libphp4.so into server: /etc/httpd/modules/libphp4.so: undefined symbol: xsltSaveResultToString Not that great, I am afraid. Michal From jimpop at yahoo.com Sun Jul 25 01:09:37 2004 From: jimpop at yahoo.com (Jim Popovitch) Date: Sat, 24 Jul 2004 21:09:37 -0400 Subject: New PHP 4.3.8 RPMS Released In-Reply-To: <20040724174157.A349@mail.harddata.com> References: <1090466575.3453.7.camel@poohbox> <20040724174157.A349@mail.harddata.com> Message-ID: <1090717777.4522.1.camel@ads.pointtroll.com> On Sat, 2004-07-24 at 19:41, Michal Jaegermann wrote: > I tried that on RH7.3 installation and I got, trying to start a > server, > > Cannot load /etc/httpd/modules/libphp4.so into server: > /etc/httpd/modules/libphp4.so: undefined symbol: xsltSaveResultToString > > Not that great, I am afraid. > Stuart's PHP rpms work fine for me. I am using apache-1.3.27-4, what version are you using? -Jim P. From tdiehl at rogueind.com Sun Jul 25 01:39:31 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Sat, 24 Jul 2004 21:39:31 -0400 (EDT) Subject: RH7.1->RH7.2 In-Reply-To: <41022C73.9040906@internode.com.au> References: <41022C73.9040906@internode.com.au> Message-ID: On Sat, 24 Jul 2004, Michael Kratz wrote: > Howdy all, > > I've been steadily upgrading packages on a RH7.1 box that I have to > packages from RH7.2. > > Now I've come to the final list of packages, which I don't really want > to do one at a time but rather all at once with a "yum upgrade". > > What I'd like to know is the opinions of anyone on this list of how > likely the box is to break with this final upgrade of packages to bring > the box up to RH7.2 I never did a yum upgrade from 7.1->7.2 but back in the day I did 7.2-7.3 and some other upgrades via yum. I never had a problem doing that. Generally speaking it should not be a problem if the deps are solved. Just out of couriosity why 7.2 and not at least 7.3. FL is still supporting 7.3 but 7.2 and down are no longer supported. HTH, Tom From mkratz at internode.com.au Sun Jul 25 03:00:02 2004 From: mkratz at internode.com.au (Michael Kratz) Date: Sun, 25 Jul 2004 12:30:02 +0930 Subject: RH7.1->RH7.2 In-Reply-To: References: <41022C73.9040906@internode.com.au> Message-ID: <41032232.4040306@internode.com.au> Tom Diehl wrote: > Just out of couriosity why 7.2 and not at least 7.3. FL is still supporting > 7.3 but 7.2 and down are no longer supported. I'm planning to go 7.1 > 7.2 > 7.3 thats if this box stays doing what its doing for long enough, I want to replace it with a new box and FC2. FWIW I did do "yum upgrade" and all dependencies were resolved okay. I just didn't proceed with it. :) -- Michael From tdiehl at rogueind.com Sun Jul 25 03:06:54 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Sat, 24 Jul 2004 23:06:54 -0400 (EDT) Subject: RH7.1->RH7.2 In-Reply-To: <41032232.4040306@internode.com.au> References: <41022C73.9040906@internode.com.au> <41032232.4040306@internode.com.au> Message-ID: On Sun, 25 Jul 2004, Michael Kratz wrote: > > > Tom Diehl wrote: > > > Just out of couriosity why 7.2 and not at least 7.3. FL is still supporting > > 7.3 but 7.2 and down are no longer supported. > > I'm planning to go 7.1 > 7.2 > 7.3 > > thats if this box stays doing what its doing for long enough, I want to > replace it with a new box and FC2. > > FWIW I did do "yum upgrade" and all dependencies were resolved okay. I > just didn't proceed with it. :) Were it me I would go for it, but it is not my box so the final decision obviously is yours. :-) Tom From stuart at serverpeak.com Sun Jul 25 04:00:52 2004 From: stuart at serverpeak.com (Stuart Low) Date: Sun, 25 Jul 2004 14:00:52 +1000 Subject: New PHP 4.3.8 RPMS Released In-Reply-To: <20040724174157.A349@mail.harddata.com> References: <1090466575.3453.7.camel@poohbox> <20040724174157.A349@mail.harddata.com> Message-ID: <1090728051.10301.2.camel@dhcpd62.seekbrain.com> Heya, Did you upgrade to the latest libxslt and libxml2 I have uploaded too? Stuart On Sun, 2004-07-25 at 09:41, Michal Jaegermann wrote: > On Thu, Jul 22, 2004 at 01:22:56PM +1000, Stuart Low wrote: > > > > I've just released PHP RPMs for Redhat 7.3, 9, Enterprise 3 & Fedora > > Core 1/2. > > > > Repository here: http://www.seekbrain.com/downloads/psa/ > > I tried that on RH7.3 installation and I got, trying to start a > server, > > Cannot load /etc/httpd/modules/libphp4.so into server: > /etc/httpd/modules/libphp4.so: undefined symbol: xsltSaveResultToString > > Not that great, I am afraid. > > Michal > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From mdalek at dsl.pipex.com Sun Jul 25 16:21:49 2004 From: mdalek at dsl.pipex.com (Matthew D'Albert) Date: Sun, 25 Jul 2004 17:21:49 +0100 Subject: RH7.1->RH7.2 In-Reply-To: <41032232.4040306@internode.com.au> Message-ID: <000001c47263$7d4502e0$0500a8c0@dalek> Michael Katz wrote: >I'm planning to go 7.1 > 7.2 > 7.3 I did this not long ago, with yum and apt, my box is still standing :p but I haven't rebooted it yet. I recommend you check all your configs after the procedure, your /etc/ will be littered with .rpmnew and a few .rpmsave From michal at harddata.com Sun Jul 25 16:31:57 2004 From: michal at harddata.com (Michal Jaegermann) Date: Sun, 25 Jul 2004 10:31:57 -0600 Subject: New PHP 4.3.8 RPMS Released In-Reply-To: <1090717777.4522.1.camel@ads.pointtroll.com>; from jimpop@yahoo.com on Sat, Jul 24, 2004 at 09:09:37PM -0400 References: <1090466575.3453.7.camel@poohbox> <20040724174157.A349@mail.harddata.com> <1090717777.4522.1.camel@ads.pointtroll.com> Message-ID: <20040725103157.A19341@mail.harddata.com> On Sat, Jul 24, 2004 at 09:09:37PM -0400, Jim Popovitch wrote: > > Stuart's PHP rpms work fine for me. I am using apache-1.3.27-4, what > version are you using? Actually the later one than that. But this is clearly a libxslt issue and not Apache. Michal From michal at harddata.com Sun Jul 25 16:46:51 2004 From: michal at harddata.com (Michal Jaegermann) Date: Sun, 25 Jul 2004 10:46:51 -0600 Subject: New PHP 4.3.8 RPMS Released In-Reply-To: <1090728051.10301.2.camel@dhcpd62.seekbrain.com>; from stuart@serverpeak.com on Sun, Jul 25, 2004 at 02:00:52PM +1000 References: <1090466575.3453.7.camel@poohbox> <20040724174157.A349@mail.harddata.com> <1090728051.10301.2.camel@dhcpd62.seekbrain.com> Message-ID: <20040725104651.B19341@mail.harddata.com> On Sun, Jul 25, 2004 at 02:00:52PM +1000, Stuart Low wrote: > > Did you upgrade to the latest libxslt and libxml2 I have uploaded too? Here we go. If you have new dependencies then they should be added to "Requires" list with a version which is high enough. The other possibility seems to be to configure in such way that HAVE_DOMXSLT is not defined for RH7.3 Michal From michal at harddata.com Sun Jul 25 18:14:32 2004 From: michal at harddata.com (Michal Jaegermann) Date: Sun, 25 Jul 2004 12:14:32 -0600 Subject: New PHP 4.3.8 RPMS Released In-Reply-To: <1090728051.10301.2.camel@dhcpd62.seekbrain.com>; from stuart@serverpeak.com on Sun, Jul 25, 2004 at 02:00:52PM +1000 References: <1090466575.3453.7.camel@poohbox> <20040724174157.A349@mail.harddata.com> <1090728051.10301.2.camel@dhcpd62.seekbrain.com> Message-ID: <20040725121432.A20380@mail.harddata.com> On Sun, Jul 25, 2004 at 02:00:52PM +1000, Stuart Low wrote: > > Did you upgrade to the latest libxslt and libxml2 I have uploaded too? Missing xsltSaveResultToString is indeed supplied by libxslt-1.1.8-1, which requires libxml2-2.6.11-1, and my guess that source rpms for these are taken from rufus.w3.org as they are do not seem to be present at http://www.seekbrain.com/downloads/psa/ After such changes php-4.3.8-sp.rh73.1 at least starts. :-) Current php for FC1 and FC2 have versions bumped up to 4.3.8 while the first fix provided patches for 4.3.6. Maybe this should be taken as a hint. Michal From i.wells at ntlworld.com Sun Jul 25 20:44:55 2004 From: i.wells at ntlworld.com (Ian Wells) Date: Sun, 25 Jul 2004 21:44:55 +0100 Subject: Fedora Test Update Notification: cvs References: <200406101914.56940.jkeating@j2solutions.net> Message-ID: <001901c47288$3e9dbc60$1500a8c0@eddie> > - --------------------------------------------------------------------- > Fedora Test Update Notification > FEDORA-2004-1735 > Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1735 > 2004-06-10 > - --------------------------------------------------------------------- (from Bugzilla) Status: Resolved Resolution: Pending What is this pending on? Does it need further feedback? (I ask to see if I can help in any way) I have the 7.3 version in daily use without any problems. Ian From guallar at easternrad.com Mon Jul 26 14:56:58 2004 From: guallar at easternrad.com (Josep L. Guallar-Esteve) Date: Mon, 26 Jul 2004 10:56:58 -0400 Subject: RH7.1->RH7.2 In-Reply-To: <41032232.4040306@internode.com.au> References: <41022C73.9040906@internode.com.au> <41032232.4040306@internode.com.au> Message-ID: <200407261057.06433.guallar@easternrad.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 24 July 2004 11:00 pm, Michael Kratz wrote: > Tom Diehl wrote: > > Just out of couriosity why 7.2 and not at least 7.3. FL is still > > supporting 7.3 but 7.2 and down are no longer supported. > > I'm planning to go 7.1 > 7.2 > 7.3 You should be able to do a 7.1 > 7.3 upgrade without much fuss. Check logs and check for any .newrpm /.rpmsave /... on /etc/* (system config files). I did dozens of 7.0/7.1/7.2 > 7.3 back in the day, most (if not all) of them successful. The version upgrades were done using Red Hat installation disks/ftp servers using "upgrade" option. Regards, Josep - -- Josep L. Guallar-Esteve Eastern Radiologists, Inc. Systems and PACS Administration http://www.easternrad.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBBRvBSGQa4/zQ9e8RApQbAKCYVtcJoHf0j8OgkEQDhcfP3+BzugCdExRO jBlrgkm9CII7QccyijgcjEc= =RUn5 -----END PGP SIGNATURE----- From J.S.Peatfield at damtp.cam.ac.uk Mon Jul 26 17:28:33 2004 From: J.S.Peatfield at damtp.cam.ac.uk (Jon Peatfield) Date: Mon, 26 Jul 2004 18:28:33 +0100 Subject: bugzilla.fedora.us Message-ID: is bugzilla.fedora.us known to be down or are we having connectivity problems for other reasons? -- Jon From jpdalbec at ysu.edu Mon Jul 26 21:12:43 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Mon, 26 Jul 2004 17:12:43 -0400 Subject: RH7.1->RH7.2 In-Reply-To: <20040726160012.E74F873FCA@hormel.redhat.com> References: <20040726160012.E74F873FCA@hormel.redhat.com> Message-ID: <410573CB.3060209@ysu.edu> > On Saturday 24 July 2004 11:00 pm, Michael Kratz wrote: > >>Tom Diehl wrote: >> >>>Just out of couriosity why 7.2 and not at least 7.3. FL is still >>>supporting 7.3 but 7.2 and down are no longer supported. >> >>I'm planning to go 7.1 > 7.2 > 7.3 The only 7.1->7.3 gotchas I've noticed: After upgrading glibc (which I did before anything else), I had to restart SSH the next morning because initgroups() had stopped working. After upgrading identd, PostgreSQL ident authentication stopped working because the default was changed to encrypt the account name. I reversed the change and all was well. (Of course it took me several hours of downtime to figure out what the problem was because I had upgraded a number of packages at once.) After upgrading lilo, remember to re-run it! Make sure you have an up-to-date boot floppy just in case. I guess I could have used the rescue CD if the box in question had had a more recent CD-ROM drive. Instead I had to play "guess which partition is /" (no, I didn't have that written down anywhere). John From jkeating at j2solutions.net Tue Jul 27 00:21:14 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 26 Jul 2004 17:21:14 -0700 Subject: bugzilla.fedora.us In-Reply-To: References: Message-ID: <200407261721.17590.jkeating@j2solutions.net> On Monday 26 July 2004 10:28, Jon Peatfield wrote: > is bugzilla.fedora.us known to be down or are we having connectivity > problems for other reasons? Known to be down. It's up now. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From mkratz at internode.com.au Tue Jul 27 00:39:29 2004 From: mkratz at internode.com.au (Michael Kratz) Date: Tue, 27 Jul 2004 10:09:29 +0930 Subject: RH7.1->RH7.2 In-Reply-To: <410573CB.3060209@ysu.edu> References: <20040726160012.E74F873FCA@hormel.redhat.com> <410573CB.3060209@ysu.edu> Message-ID: <4105A441.7090603@internode.com.au> Well i did it last night, I bit the bullet and did the yum upgrade. The only issues I had were: when installing authconfig got this: warning: group lock does not exist - using root I added lock group to my /etc/group manually, but didnt alter authconfig I had to remove the "sa" files too because they were generating errors for some reason. I also had to remove the stuff from automount (/misc stuff) it was causing errors too. But after I did all that, I ran lilo again just to make sure the kernel was in, then rebooted the box and prayed... it came back, no problems since. John Dalbec wrote: >> On Saturday 24 July 2004 11:00 pm, Michael Kratz wrote: >> >>> Tom Diehl wrote: >>> >>>> Just out of couriosity why 7.2 and not at least 7.3. FL is still >>>> supporting 7.3 but 7.2 and down are no longer supported. >>> >>> >>> I'm planning to go 7.1 > 7.2 > 7.3 > > > The only 7.1->7.3 gotchas I've noticed: > After upgrading glibc (which I did before anything else), I had to > restart SSH the next morning because initgroups() had stopped working. > > After upgrading identd, PostgreSQL ident authentication stopped working > because the default was changed to encrypt the account name. I reversed > the change and all was well. (Of course it took me several hours of > downtime to figure out what the problem was because I had upgraded a > number of packages at once.) > > After upgrading lilo, remember to re-run it! Make sure you have an > up-to-date boot floppy just in case. I guess I could have used the > rescue CD if the box in question had had a more recent CD-ROM drive. > Instead I had to play "guess which partition is /" (no, I didn't have > that written down anywhere). > John > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- Michael Kratz Internode Systems Pty Ltd http://www.internode.on.net/ ------------------------------------------------------- Level 3 / 132 Grenfell St. Phone: (08) 8228 2999 PO Box 153 Rundle Mall or: 1300 788 233 Adelaide, Sth Aust 5000 Fax: (08) 8235 6999 ------------------------------------------------------- From rostetter at mail.utexas.edu Tue Jul 27 16:17:51 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 27 Jul 2004 11:17:51 -0500 Subject: New PHP 4.3.8 RPMS Released In-Reply-To: References: Message-ID: <20040727111751.td8pic0wwgcog8wc@mail.ph.utexas.edu> Quoting Dan Hollis : > On Fri, 23 Jul 2004, Eric Rostetter wrote: >> Quoting Dan Hollis : >> > On Fri, 23 Jul 2004, Eric Rostetter wrote: >> >> If anyone wants to see more warnings, removals, or tweaks, let me know. >> > http://www.fedoralegacy.org/docs/ >> Okay, what you want me to do with it? > > Put a warning on the page the same as you did with > http://www.fedoralegacy.org/updates/ > > -Dan I don't like it, but I put it there... Will leave it for a while at least... -- Eric Rostetter From sopwith at redhat.com Tue Jul 27 17:39:17 2004 From: sopwith at redhat.com (Elliot Lee) Date: Tue, 27 Jul 2004 13:39:17 -0400 Subject: Fedora Project Mailing Lists reminder Message-ID: This is a reminder of the mailing lists for the Fedora Project, and the purpose of each list. You can view this information at http://fedora.redhat.com/participate/communicate/ When you're using these mailing lists, please take the time to choose the one that is most appropriate to your post. If you don't know the right mailing list to use for a question or discussion, please contact me. This will help you get the best possible answer for your question, and keep other list subscribers happy! Mailing Lists Mailing lists are email addresses which send email to all users subscribed to the mailing list. Sending an email to a mailing list reaches all users interested in discussing a specific topic and users available to help other users with the topic. The following mailing lists are available. To subscribe, send email to -request at redhat.com (replace with the desired mailing list name such as fedora-list) with the word subscribe in the subject. fedora-announce-list - Announcements of changes and events. To stay aware of news, subscribe to this list. fedora-list - For users of releases. If you want help with a problem installing or using , this is the list for you. fedora-test-list - For testers of test releases. If you would like to discuss experiences using TEST releases, this is the list for you. fedora-devel-list - For developers, developers, developers. If you are interested in helping create releases, this is the list for you. fedora-docs-list - For participants of the docs project fedora-desktop-list - For discussions about desktop issues such as user interfaces, artwork, and usability fedora-config-list - For discussions about the development of configuration tools fedora-legacy-announce - For announcements about the Fedora Legacy Project fedora-legacy-list - For discussions about the Fedora Legacy Project fedora-selinux-list - For discussions about the Fedora SELinux Project fedora-de-list - For discussions about Fedora in the German language fedora-es-list - For discussions about Fedora in the Spanish language fedora-ja-list - For discussions about Fedora in the Japanese language fedora-i18n-list - For discussions about the internationalization of Fedora Core fedora-trans-list - For discussions about translating the software and documentation associated with the Fedora Project German: fedora-trans-de French: fedora-trans-fr Spanish: fedora-trans-es Italian: fedora-trans-it Brazilian Portuguese: fedora-trans-pt_br Japanese: fedora-trans-ja Korean: fedora-trans-ko Simplified Chinese: fedora-trans-zh_cn Traditional Chinese: fedora-trans-zh_tw From maurice at cds-cumberland.org Tue Jul 27 18:52:09 2004 From: maurice at cds-cumberland.org (Maurice) Date: Tue, 27 Jul 2004 14:52:09 -0400 Subject: PGP problems with RH9 and YUM Message-ID: <4106A459.50003@cds-cumberland.org> I have a RH9 server that I'd like to use YUM to update. I started off with: rpm -Uvh gnupg-1.2.1-9.i386.rpm rpm -ivh yum-2.0.3-0.fdr.1.rh90.noarch.rpm Then, I followed the steps listed from the FedoraLegacy project, http://www.fedoralegacy.org/docs/yum-rh9.php But I keep getting the same error(s) related to PGP key(s)... Here's my YUM.conf: # See the yum.conf(5) man page for information the syntax of this file, # including failover setup. [main] cachedir=/var/cache/yum debuglevel=2 logfile=/var/log/yum.log pkgpolicy=newest # Please use nearby mirrors! For a an up to date list of Fedora mirrors, see # . [redhat-os] name=Red Hat Linux $releasever ($basearch) baseurl=http://download.fedora.us/fedora/redhat/$releasever/$basearch/yum/os/ # http://download.fedora.us/fedora/redhat/$releasever/$basearch/yum/os/ # ftp://ftp.ussg.iu.edu/pub/linux/fedora/fedora/redhat/$releasever/$basearch/yum/os/ # http://mirrors.usc.edu/pub/linux/fedora/redhat/$releasever/$basearch/yum/os/ # http://mirrors.kernel.org/fedora/fedora/redhat/$releasever/$basearch/yum/os/ # http://download.fr.fedora.us/fedora/redhat/$releasever/$basearch/yum/os/ # http://sunsite.informatik.rwth-aachen.de/ftp/pub/Linux/fedora/redhat/$releasever/$basearch/yum/os/ # http://wftp.tu-chemnitz.de/pub/linux/fedora/redhat/$releasever/$basearch/yum/os/ # ftp://ftp.g-int.net/apt/redhat/$releasever/$basearch/yum/os/ # http://fedora.quicknet.nl/fedora/redhat/$releasever/$basearch/yum/os/ # http://ftp.iasi.roedu.net/mirrors/fedora.us/fedora/redhat/$releasever/$basearch/yum/os/ gpgcheck=1 failovermethod=priority [redhat-updates] name=Red Hat Linux $releasever ($basearch) updates baseurl=http://download.fedora.us/fedora/redhat/$releasever/$basearch/yum/updates/ # http://download.fedora.us/fedora/redhat/$releasever/$basearch/yum/updates/ # ftp://ftp.ussg.iu.edu/pub/linux/fedora/fedora/redhat/$releasever/$basearch/yum/updates/ # http://mirrors.usc.edu/pub/linux/fedora/redhat/$releasever/$basearch/yum/updates/ # http://mirrors.kernel.org/fedora/fedora/redhat/$releasever/$basearch/yum/updates/ # http://download.fr.fedora.us/fedora/redhat/$releasever/$basearch/yum/updates/ # http://sunsite.informatik.rwth-aachen.de/ftp/pub/Linux/fedora/redhat/$releasever/$basearch/yum/updates/ # http://wftp.tu-chemnitz.de/pub/linux/fedora/redhat/$releasever/$basearch/yum/updates/ # ftp://ftp.g-int.net/apt/redhat/$releasever/$basearch/yum/updates/ # http://fedora.quicknet.nl/fedora/redhat/$releasever/$basearch/yum/updates/ # http://ftp.iasi.roedu.net/mirrors/fedora.us/fedora/redhat/$releasever/$basearch/yum/updates/ gpgcheck=1 failovermethod=priority [fedora-stable] name=Fedora Linux / stable for Red Hat Linux $releasever ($basearch) baseurl=http://download.fedora.us/fedora/redhat/$releasever/$basearch/yum/stable/ # http://download.fedora.us/fedora/redhat/$releasever/$basearch/yum/stable/ # ftp://ftp.ussg.iu.edu/pub/linux/fedora/fedora/redhat/$releasever/$basearch/yum/stable/ # http://mirrors.usc.edu/pub/linux/fedora/redhat/$releasever/$basearch/yum/stable/ # http://mirrors.kernel.org/fedora/fedora/redhat/$releasever/$basearch/yum/stable/ # http://download.fr.fedora.us/fedora/redhat/$releasever/$basearch/yum/stable/ # http://sunsite.informatik.rwth-aachen.de/ftp/pub/Linux/fedora/redhat/$releasever/$basearch/yum/stable/ # http://wftp.tu-chemnitz.de/pub/linux/fedora/redhat/$releasever/$basearch/yum/stable/ # ftp://ftp.g-int.net/apt/redhat/$releasever/$basearch/yum/stable/ # http://fedora.quicknet.nl/fedora/redhat/$releasever/$basearch/yum/stable/ # http://ftp.iasi.roedu.net/mirrors/fedora.us/fedora/redhat/$releasever/$basearch/yum/stable/ gpgcheck=1 failovermethod=priority #[fedora-testing] #name=Fedora Linux / testing for Red Hat Linux $releasever ($basearch) #baseurl= # http://download.fedora.us/fedora/redhat/$releasever/$basearch/yum/testing/ # ftp://ftp.ussg.iu.edu/pub/linux/fedora/fedora/redhat/$releasever/$basearch/yum/testing/ # http://mirrors.usc.edu/pub/linux/fedora/redhat/$releasever/$basearch/yum/testing/ # http://mirrors.kernel.org/fedora/fedora/redhat/$releasever/$basearch/yum/testing/ # http://download.fr.fedora.us/fedora/redhat/$releasever/$basearch/yum/testing/ # http://sunsite.informatik.rwth-aachen.de/ftp/pub/Linux/fedora/redhat/$releasever/$basearch/yum/testing/ # http://wftp.tu-chemnitz.de/pub/linux/fedora/redhat/$releasever/$basearch/yum/testing/ # ftp://ftp.g-int.net/apt/redhat/$releasever/$basearch/yum/testing/ # http://fedora.quicknet.nl/fedora/redhat/$releasever/$basearch/yum/testing/ # http://ftp.iasi.roedu.net/mirrors/fedora.us/fedora/redhat/$releasever/$basearch/yum/testing/ #gpgcheck=1 #failovermethod=priority #[fedora-unstable] #name=Fedora Linux / unstable for Red Hat Linux $releasever ($basearch) #baseurl= # http://download.fedora.us/fedora/redhat/$releasever/$basearch/yum/unstable/ # ftp://ftp.ussg.iu.edu/pub/linux/fedora/fedora/redhat/$releasever/$basearch/yum/unstable/ # http://mirrors.usc.edu/pub/linux/fedora/redhat/$releasever/$basearch/yum/unstable/ # http://mirrors.kernel.org/fedora/fedora/redhat/$releasever/$basearch/yum/unstable/ # http://download.fr.fedora.us/fedora/redhat/$releasever/$basearch/yum/unstable/ # http://sunsite.informatik.rwth-aachen.de/ftp/pub/Linux/fedora/redhat/$releasever/$basearch/yum/unstable/ # http://wftp.tu-chemnitz.de/pub/linux/fedora/redhat/$releasever/$basearch/yum/unstable/ # ftp://ftp.g-int.net/apt/redhat/$releasever/$basearch/yum/unstable/ # http://fedora.quicknet.nl/fedora/redhat/$releasever/$basearch/yum/unstable/ # http://ftp.iasi.roedu.net/mirrors/fedora.us/fedora/redhat/$releasever/$basearch/yum/unstable/ #gpgcheck=1 #failovermethod=priority #[fedora-k12ltsp] #name=K12LTSP for Red Hat Linux $releasever ($basearch) #baseurl= # http://download.fedora.us/fedora/redhat/$releasever/$basearch/yum/k12ltsp/ # ftp://ftp.ussg.iu.edu/pub/linux/fedora/fedora/redhat/$releasever/$basearch/yum/k12ltsp/ # http://mirrors.usc.edu/pub/linux/fedora/redhat/$releasever/$basearch/yum/k12ltsp/ # http://mirrors.kernel.org/fedora/fedora/redhat/$releasever/$basearch/yum/k12ltsp/ # http://download.fr.fedora.us/fedora/redhat/$releasever/$basearch/yum/k12ltsp/ # http://sunsite.informatik.rwth-aachen.de/ftp/pub/Linux/fedora/redhat/$releasever/$basearch/yum/k12ltsp/ # http://wftp.tu-chemnitz.de/pub/linux/fedora/redhat/$releasever/$basearch/yum/k12ltsp/ # ftp://ftp.g-int.net/apt/redhat/$releasever/$basearch/yum/k12ltsp/ # http://fedora.quicknet.nl/fedora/redhat/$releasever/$basearch/yum/k12ltsp/ # http://ftp.iasi.roedu.net/mirrors/fedora.us/fedora/redhat/$releasever/$basearch/yum/k12ltsp/ #gpgcheck=1 #failovermethod=priority [macromedia] name=Macromedia Flash Player for Red Hat Linux $releasever baseurl= http://macromedia.mplug.org/apt/redhat/$releasever/ # http://sluglug.ucsc.edu/macromedia/apt/redhat/$releasever/ # http://ruslug.rutgers.edu/macromedia/apt/redhat/$releasever/ # http://macromedia.rediris.es/apt/redhat/$releasever/ gpgcheck=1 failovermethod=priority I did the rpm --import for these KEYS: rpm --import http://www.fedoralegacy.org/FEDORA-LEGACY-GPG-KEY rpm --import /usr/share/doc/redhat-release-9/RPM-GPG-KEY I've done several yum clean. Here is the console text: [root at penguin2 root]# yum update Gathering header information file(s) from server(s) Server: Fedora Linux / stable for Red Hat Linux 9 (i386) Server: Macromedia Flash Player for Red Hat Linux 9 Server: Red Hat Linux 9 (i386) Server: Red Hat Linux 9 (i386) updates Finding updated packages Downloading needed headers Resolving dependencies Dependencies resolved I will do the following: [update: gkrellm 2.1.19-0.fdr.1.rh90.i386] [update: dia 1:0.91-0.fdr.5.i386] [update: cvs 1.11.2-23.legacy.i386] [update: mailman 3:2.1.1-7.legacy.i386] [update: perl-DateManip 5.42-0.fdr.2.a.rh90.noarch] [update: xchat 1:2.0.4-0.fdr.1.rh90.i386] [update: nmap 2:3.30-0.fdr.1.rh90.i386] [update: sysklogd 1.4.1-14.legacy.9.i386] [update: nmap-frontend 2:3.30-0.fdr.1.rh90.i386] Is this ok [y/N]: y Getting gkrellm-2.1.19-0.fdr.1.rh90.i386.rpm warning: rpmts_HdrFromFdno: V3 DSA signature: NOKEY, key ID 8df56d05 Error: Could not find the GPG Key necessary to validate pkg /var/cache/yum/fedora-stable/packages/gkrellm-2.1.19-0.fdr.1.rh90.i386.rpm Error: You may want to run yum clean or remove the file: /var/cache/yum/fedora-stable/packages/gkrellm-2.1.19-0.fdr.1.rh90.i386.rpm Error: You may also check that you have the correct GPG keys installed So what am I missing??? Thanks -Maurice -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at frields.com Tue Jul 27 19:33:50 2004 From: paul at frields.com (Paul W. Frields) Date: Tue, 27 Jul 2004 15:33:50 -0400 Subject: PGP problems with RH9 and YUM In-Reply-To: <4106A459.50003@cds-cumberland.org> References: <4106A459.50003@cds-cumberland.org> Message-ID: <1090956830.2337.12.camel@berlin.east.gov> On Tue, 2004-07-27 at 14:52, Maurice wrote: [...snip...] > I did the rpm --import for these KEYS: > rpm --import http://www.fedoralegacy.org/FEDORA-LEGACY-GPG-KEY > rpm --import /usr/share/doc/redhat-release-9/RPM-GPG-KEY > > I've done several yum clean. > > Here is the console text: > > [root at penguin2 root]# yum update > Gathering header information file(s) from server(s) > Server: Fedora Linux / stable for Red Hat Linux 9 (i386) > Server: Macromedia Flash Player for Red Hat Linux 9 > Server: Red Hat Linux 9 (i386) > Server: Red Hat Linux 9 (i386) updates > Finding updated packages > Downloading needed headers > Resolving dependencies > Dependencies resolved > I will do the following: > [update: gkrellm 2.1.19-0.fdr.1.rh90.i386] > [update: dia 1:0.91-0.fdr.5.i386] > [update: cvs 1.11.2-23.legacy.i386] > [update: mailman 3:2.1.1-7.legacy.i386] > [update: perl-DateManip 5.42-0.fdr.2.a.rh90.noarch] > [update: xchat 1:2.0.4-0.fdr.1.rh90.i386] > [update: nmap 2:3.30-0.fdr.1.rh90.i386] > [update: sysklogd 1.4.1-14.legacy.9.i386] > [update: nmap-frontend 2:3.30-0.fdr.1.rh90.i386] > Is this ok [y/N]: y > Getting gkrellm-2.1.19-0.fdr.1.rh90.i386.rpm > warning: rpmts_HdrFromFdno: V3 DSA signature: NOKEY, key ID 8df56d05 > Error: Could not find the GPG Key necessary to validate pkg > /var/cache/yum/fedora-stable/packages/gkrellm-2.1.19-0.fdr.1.rh90.i386.rpm > Error: You may want to run yum clean or remove the file: > /var/cache/yum/fedora-stable/packages/gkrellm-2.1.19-0.fdr.1.rh90.i386.rpm > Error: You may also check that you have the correct GPG keys installed [...snip...] The packages in question are signed by a key you don't have in your RPM database, just as the error says. It reports the package in question is signed by the key with ID 8df56d05. If you do: rpm -qa gpg-pubkey ...you'll get a list of all GPG keys in your RPM database. If you don't see "gpg-pubkey-8df56d05-xxxxxxxx" in that list, you've found the problem. The next problem becomes, where do you find that key? I did a couple minutes snooping at fedora.us to find out that the key in question is the Fedora Project key. To import their key: rpm --import http://www.fedora.us/FEDORA-GPG-KEY -- Paul W. Frields, RHCE From b.pennacchi at istc.cnr.it Tue Jul 27 19:42:37 2004 From: b.pennacchi at istc.cnr.it (Barbara Pennacchi) Date: Tue, 27 Jul 2004 21:42:37 +0200 Subject: fedora-legacy-list Digest, Vol 5, Issue 23 In-Reply-To: <20040727160016.D875073527@hormel.redhat.com> References: <20040727160016.D875073527@hormel.redhat.com> Message-ID: <20040727194237.GK3577@sibannac.ip.rm.cnr.it> Just a silly question: am I the only one to receive more than once my daily dose of this mailing list's digest? b. -- +--------------------------------------------------------------------+ | WARNING WARNING WARNING *** EMAIL ADDRESS CHANGED! | | USE EMAIL ADDRESS PROVIDED BELOW | | IF YOU KEEP WRITING TO THE OLD ADDRESS IT IS NOT MY FAULT! | +--------------------------------------------------------------------+ | Barbara Pennacchi b.pennacchi at istc.cnr.it | | Consiglio Nazionale delle Ricerche | | Istituto di Scienze e Tecnologie della Cognizione | | V.le Marx 15, 00137 Roma, Italia | | http://www.istc.cnr.it/ | +--------------------------------------------------------------------+ From maurice at cds-cumberland.org Tue Jul 27 20:08:44 2004 From: maurice at cds-cumberland.org (Maurice) Date: Tue, 27 Jul 2004 16:08:44 -0400 Subject: PGP problems with RH9 and YUM In-Reply-To: <1090956830.2337.12.camel@berlin.east.gov> References: <4106A459.50003@cds-cumberland.org> <1090956830.2337.12.camel@berlin.east.gov> Message-ID: <4106B64C.3070704@cds-cumberland.org> Paul W. Frields wrote: >On Tue, 2004-07-27 at 14:52, Maurice wrote: >[...snip...] > > >>I did the rpm --import for these KEYS: >>rpm --import http://www.fedoralegacy.org/FEDORA-LEGACY-GPG-KEY >>rpm --import /usr/share/doc/redhat-release-9/RPM-GPG-KEY >> >>I've done several yum clean. >> >>Here is the console text: >> >>[root at penguin2 root]# yum update >>Gathering header information file(s) from server(s) >>Server: Fedora Linux / stable for Red Hat Linux 9 (i386) >>Server: Macromedia Flash Player for Red Hat Linux 9 >>Server: Red Hat Linux 9 (i386) >>Server: Red Hat Linux 9 (i386) updates >>Finding updated packages >>Downloading needed headers >>Resolving dependencies >>Dependencies resolved >>I will do the following: >>[update: gkrellm 2.1.19-0.fdr.1.rh90.i386] >>[update: dia 1:0.91-0.fdr.5.i386] >>[update: cvs 1.11.2-23.legacy.i386] >>[update: mailman 3:2.1.1-7.legacy.i386] >>[update: perl-DateManip 5.42-0.fdr.2.a.rh90.noarch] >>[update: xchat 1:2.0.4-0.fdr.1.rh90.i386] >>[update: nmap 2:3.30-0.fdr.1.rh90.i386] >>[update: sysklogd 1.4.1-14.legacy.9.i386] >>[update: nmap-frontend 2:3.30-0.fdr.1.rh90.i386] >>Is this ok [y/N]: y >>Getting gkrellm-2.1.19-0.fdr.1.rh90.i386.rpm >>warning: rpmts_HdrFromFdno: V3 DSA signature: NOKEY, key ID 8df56d05 >>Error: Could not find the GPG Key necessary to validate pkg >>/var/cache/yum/fedora-stable/packages/gkrellm-2.1.19-0.fdr.1.rh90.i386.rpm >>Error: You may want to run yum clean or remove the file: >>/var/cache/yum/fedora-stable/packages/gkrellm-2.1.19-0.fdr.1.rh90.i386.rpm >>Error: You may also check that you have the correct GPG keys installed >> >> >[...snip...] > >The packages in question are signed by a key you don't have in your RPM >database, just as the error says. It reports the package in question is >signed by the key with ID 8df56d05. If you do: > > rpm -qa gpg-pubkey > >...you'll get a list of all GPG keys in your RPM database. If you don't >see "gpg-pubkey-8df56d05-xxxxxxxx" in that list, you've found the >problem. The next problem becomes, where do you find that key? I did a >couple minutes snooping at fedora.us to find out that the key in >question is the Fedora Project key. To import their key: > > rpm --import http://www.fedora.us/FEDORA-GPG-KEY > > > That did it... Thank you, I was really stumped -- each day I learn something new about the Linux OS. I ran rpm -qa gpg-pubkey and seem to have 28 Keys on the system, but not the one that I needed - many of the Keys listed were duplicates... Imported the Key and ran yum update (again), installed the 18 dependencies without an issue. Thanks, again -Maurice -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimpop at yahoo.com Wed Jul 28 04:04:22 2004 From: jimpop at yahoo.com (Jim Popovitch) Date: Wed, 28 Jul 2004 00:04:22 -0400 Subject: perl-libwww-perl oddity Message-ID: <1090987462.3711.34.camel@ads.pointtroll.com> This is really meant more as an FYI, but I am also interested in knowing if anyone has seen this same issue. I have multiple RH7.3 servers that are kept updated as expected. Today, while doing a box-by-box comparison, I noticed that one box had an older version of /usr/bin/GET which is "owned" by libwww-perl (rpm -qf /usr/bin/GET) The older file (v1.39) from box A is dated 14-Aug-2002 and is 14363 bytes. The one on box B (v1.40) is dated 27-Jul-2004 and is 14360 bytes. BOTH boxes report the file is owned by perl-libwww-perl-5.63-9. The only difference between these files (other than version number) is this one line which is used to detect bad URLs: v1.40 --> $@ =~ s/ at .* line \d+.*//; v1.39 --> $@ =~ s/at\s+\S+\s+line\s\d+//; So, somewhere over the years, while trying to keep these boxes updated, something didn't go smoothly. -Jim P. From dom at earth.li Wed Jul 28 10:12:56 2004 From: dom at earth.li (Dominic Hargreaves) Date: Wed, 28 Jul 2004 11:12:56 +0100 Subject: perl-libwww-perl oddity In-Reply-To: <1090987462.3711.34.camel@ads.pointtroll.com> References: <1090987462.3711.34.camel@ads.pointtroll.com> Message-ID: <20040728101256.GN30964@tirian.magd.ox.ac.uk> On Wed, Jul 28, 2004 at 12:04:22AM -0400, Jim Popovitch wrote: > I have multiple RH7.3 servers that are kept updated as expected. Today, > while doing a box-by-box comparison, I noticed that one box had an older > version of /usr/bin/GET which is "owned" by libwww-perl (rpm -qf > /usr/bin/GET) > > The older file (v1.39) from box A is dated 14-Aug-2002 and is 14363 > bytes. The one on box B (v1.40) is dated 27-Jul-2004 and is 14360 > bytes. BOTH boxes report the file is owned by perl-libwww-perl-5.63-9. It sounds like someone has frobbed that file without paying attention to the fact that it is RPM-managed. Maybe someone has been careless with CPAN.pm (as recently as yesterday judging by the modification time you state). There have been no Red Hat or Fedora Legacy updates to the package you mention, so this isn't a packaging issue. Your statements are also inconsistent from what I'm observing on my boxes. Redhat 7.3 shipped with version 1.40 which has the following properties: -r-xr-xr-x 1 root root 14360 Mar 30 2002 /usr/bin/GET 8e2c784307f467a2ae8bb8a4cb7f8b61 /usr/bin/GET So it seems like you have got mixed up somewhere. Dominic. From john at chattanooga.net Sat Jul 31 21:58:18 2004 From: john at chattanooga.net (John Aldrich) Date: Sat, 31 Jul 2004 17:58:18 -0400 Subject: HELP!!! KMail messed up Message-ID: <200407311758.18067.john@chattanooga.net> I'm running RH9 and I just had to change my video card (old one apparently decided to start dying today...) and now my KMail is messed up... The subject, from, to, date, etc are all over a colored background and the font is HUGE. I've tried everything I can think of, including reconfiguring the fonts for KMail, etc, but the font is still huge and the solid color background suddenly appeared after I changed video cards... Everything else looks fine except for KMail. And it only does that in the "preview" pane. It doesn't do that when I compose an email. I switched from a Voodoo2 PCI to a Graphics Blaster Riva TNT AGP, if it matters. Kudzu recognized the change and immediately changed things for me... I even figured out how to run "redhat-config-xfree86" and configure my video settings. Oh, one other thing. I'm on a Sun monitor, but I specified that when I set up my XFree86. Thanks... John