From karl at nncc.info Wed Feb 1 09:10:03 2006 From: karl at nncc.info (Karl Lattimer) Date: Wed, 01 Feb 2006 09:10:03 +0000 Subject: x86_64 support Message-ID: <1138785003.8479.13.camel@despair.kent-music.com> Hi there, It seems there is no x86_64 support for AMD opteron/athlon 64bit? Is this intentional or is it an oversight? I am running an old Fedora Core 2 server with an ath64 in it. I don't get any updates anymore, luckily it is behind a firewall and because of the nature of the server I can't upgrade it entirely very easily, I would however like to make sure that I've got all available security updates. Kind regards, Karl, From sheltren at cs.ucsb.edu Wed Feb 1 10:24:00 2006 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Wed, 1 Feb 2006 06:24:00 -0400 Subject: x86_64 support In-Reply-To: <1138785003.8479.13.camel@despair.kent-music.com> References: <1138785003.8479.13.camel@despair.kent-music.com> Message-ID: On Feb 1, 2006, at 5:10 AM, Karl Lattimer wrote: > Hi there, > It seems there is no x86_64 support for AMD opteron/athlon 64bit? Is > this intentional or is it an oversight? I am running an old Fedora > Core > 2 server with an ath64 in it. I don't get any updates anymore, luckily > it is behind a firewall and because of the nature of the server I > can't > upgrade it entirely very easily, I would however like to make sure > that > I've got all available security updates. > > Kind regards, > Karl, > Hi Karl, currently FL does not provide x86_64 packages. I believe that once the new build system is in use (currently it's being tested), then we will start pushing out x86_64 packages for FC2 and FC3, and this also means we'll be rebuilding the current packages to x86_64 as well. -Jeff From jkeating at j2solutions.net Wed Feb 1 17:07:10 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 01 Feb 2006 09:07:10 -0800 Subject: [Fwd: ImageMagick in FC3] Message-ID: <1138813630.2642.0.camel@ender> -------- Forwarded Message -------- From: Stefan Neufeind, PEAR To: secnotice at fedoralegacy.org Subject: ImageMagick in FC3 Date: Wed, 01 Feb 2006 17:49:18 +0100 Hi, would it be possible that somebody takes care of an ImageMagick-update? Afaik the vuln also relates to FC3. However the bug in bugzilla of redhat still remained untouched ("new"), since FC3 is now in legacy. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176926 Some short feedback would be really, really nice! Thank you, Stefan -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From david.houlder at anu.edu.au Thu Feb 2 23:41:13 2006 From: david.houlder at anu.edu.au (David Houlder) Date: Fri, 03 Feb 2006 10:41:13 +1100 Subject: kde kjs vulnerabiity? Message-ID: <43E29899.6020804@anu.edu.au> Hi... Am I right in thinking that this... http://www.kde.org/info/security/advisory-20060119-1.txt ...currently affects FC3? Thanks -- David.Houlder at anu.edu.au ANU Supercomputer Facility Phone: +61 2 6125 0578 and APAC National Facility Fax: +61 2 6125 8199 Leonard Huxley Bldg (No. 56) Australian National University Canberra, ACT, 0200, Australia From deisenst at gtw.net Fri Feb 3 01:14:16 2006 From: deisenst at gtw.net (David Eisenstein) Date: Thu, 2 Feb 2006 19:14:16 -0600 (CST) Subject: [Fwd: ImageMagick in FC3] Message-ID: On Wed, 1 Feb 2006, Jesse Keating wrote: > -------- Forwarded Message -------- > From: Stefan Neufeind, PEAR > To: secnotice at fedoralegacy.org > Subject: ImageMagick in FC3 > Date: Wed, 01 Feb 2006 17:49:18 +0100 > > Hi, > > would it be possible that somebody takes care of an ImageMagick-update? > Afaik the vuln also relates to FC3. However the bug in bugzilla of > redhat still remained untouched ("new"), since FC3 is now in legacy. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176926 > > Some short feedback would be really, really nice! Thank you, > > Stefan This issue has been transferred from Fedora Core to Fedora Legacy in Bugzilla. The issues is entitlted "CVE-2006-0082 ImageMagick format string vulnerability." See below for more. -David ---------- Forwarded message ---------- From: bugzilla at redhat.com To: bugs at fedoralegacy.org Date: Thu, 2 Feb 2006 04:41:01 -0500 Subject: [Bug 176926] CVE-2006-0082 ImageMagick format string vulnerability. Summary: CVE-2006-0082 ImageMagick format string vulnerability. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176926 deisenst at gtw.net changed: What |Removed |Added ---------------------------------------------------------------------------- Product|Fedora Core |Fedora Legacy Status Whiteboard|reported=20060104,public=200|impact=moderate, LEGACY, |60104,source=debian,impact=m|rh73, rh90, 1, 2, 3, |oderate |NEEDSWORK Component|ImageMagick |ImageMagick AssignedTo|mclasen at redhat.com |bugs at fedoralegacy.org CC| |bugzilla.redhat at neufeind.net | |, deisenst at gtw.net ------- Additional Comments From deisenst at gtw.net 2006-02-02 04:40 EST ------- Changing this bug over to the Fedora Legacy product. Thanks for the heads up, Stefan! CVE-2005-0397 stated: "Format string vulnerability in the SetImageInfo function in image.c for ImageMagick before 6.0.2.5 may allow remote attackers to cause a denial of service (application crash) and possibly execute arbitrary code via format string specifiers in a filename argument to convert, which may be called by other web applications." This issue was fixed in FLSA:152777 for RHL 7.3, RHL 9, FC1. The issue was fixed in FC2's ImageMagick by Matthias Clasen's upgrading it to version 6.2.0.7. CVE-2006-0082: "Format string vulnerability in the SetImageInfo function in image.c for ImageMagick 6.2.3, and other versions, allows user- complicit attackers to cause a denial of service (crash) and possibly execute arbitrary code via a numeric format string specifier such as %d in the file name, a variant of CVE-2005-0397, and as demonstrated using the convert program." This issue should affect these versions of ImageMagick which Fedora Legacy maintains: * RHL7.3 - ImageMagick-5.4.3.11-12.7.x.legacy * RHL 9 - ImageMagick-5.4.7-18.legacy * FC 1 - ImageMagick-5.5.6-13.legacy * FC 2 - ImageMagick-6.2.0.7-2.fc2.4.legacy * FC 3 - ImageMagick-6.2.0.7-2.fc3 From deisenst at gtw.net Fri Feb 3 02:27:11 2006 From: deisenst at gtw.net (David Eisenstein) Date: Thu, 2 Feb 2006 20:27:11 -0600 (CST) Subject: kde kjs vulnerabiity? In-Reply-To: <43E29899.6020804@anu.edu.au> Message-ID: On Fri, 3 Feb 2006, David Houlder wrote: > Hi... > > Am I right in thinking that this... > http://www.kde.org/info/security/advisory-20060119-1.txt > ...currently affects FC3? > Thanks > You are correct. Thanks for bringing it up. A bug report has already been entered into Bugzilla (ticket #178606) for this vulnerability. This is also known as "CVE-2006-0019 kjs encodeuri/ decodeuri heap overflow vulnerability." The Red Hat Security Team rated this as a critical vulnerability in their postings. See: This CVE-2006-0019 vulnerability appears to only affect FC2 and FC3, and not RHL 7.3, RHL 9, nor FC1. There have evidentally been a whole number of other KDE security bugs appear for all 5 distros that Fedora Legacy maintains since the last time Fedora Legacy has issued any KDE errata in Febr., 2005. See for a list of potential vulnerabilities that we have for KDE at the moment. These bugs will affect multiple KDE .src.rpm's for the 5 distros we work with. I have started a Tracker ticket (Bug #179804) to track each .src.rpm package separately. Marc Deslauriers indicated that it would probably be best to address all of those vulnerabilities at once instead of just this CVE-2006-0010 vulnerability by itself (which affects the kdelibs .src.rpm). Am planning to start working up some .src.rpm packages for our community to look at in Bugzilla within a few days for RHL7.3, RHL9, FC1, FC2, and FC2. Am currently working up a spreadsheet to help with the process, which I intend to post to the KDE Tracker bug when it is completed, so we can have one Bug Ticket open per affected .src.rpm package. If anyone would like to help in applying patches to .src.rpm's for some of the distros, I would welcome the help! Thanks. Warm regards, David From mike.mccarty at sbcglobal.net Fri Feb 3 04:07:10 2006 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Thu, 02 Feb 2006 22:07:10 -0600 Subject: kde kjs vulnerabiity? In-Reply-To: References: Message-ID: <43E2D6EE.2030207@sbcglobal.net> David Eisenstein wrote: > On Fri, 3 Feb 2006, David Houlder wrote: > > >>Hi... >> >>Am I right in thinking that this... >>http://www.kde.org/info/security/advisory-20060119-1.txt >>...currently affects FC3? >>Thanks >> > > > You are correct. Thanks for bringing it up. A bug report has already [snip] > Am planning to start working up some .src.rpm packages for our community > to look at in Bugzilla within a few days for RHL7.3, RHL9, FC1, FC2, and > FC2. Am currently working up a spreadsheet to help with the process, I suppose you meant to say "FC3". > which I intend to post to the KDE Tracker bug when it is completed, so we > can have one Bug Ticket open per affected .src.rpm package. > > If anyone would like to help in applying patches to .src.rpm's for some > of the distros, I would welcome the help! I don't use KDE, but I'm willing to help edit source and/or rebuild, if that's what you need. I use FC2. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From purbon at abra.uab.es Thu Feb 2 13:18:36 2006 From: purbon at abra.uab.es (=?ISO-8859-1?Q?Pere_Urb=F3n_Bayes?=) Date: Thu, 02 Feb 2006 14:18:36 +0100 Subject: Disableing the MX resolution on sendmail Message-ID: <43E206AC.8090204@deic.uab.es> Hello to everybody, could any one of you tell me how to disable the MX resolution on sendmail? I'm looking for it during all the day without luck! -_-! Regards Pere -- |---------------------------------------------------------------.--. |Pere Urb?n Bayes JabberID: purbon at jabber.org |o_o | |Dept. of Information and Communication's Engineering |:_/ | |E.T.S. d'Enginyeria. Autonomous University of Barcelona // \ \ |08193 Bellaterra, Cerdanyola del Valles (Catalonia) (| | ) |Tel: +34935813573 QC/2005 (Combinatoric and Coding Group) /'\_ _/`\ |-----------------------------------------------------------\___)=(___/ From shiva at sewingwitch.com Fri Feb 3 05:39:22 2006 From: shiva at sewingwitch.com (Kenneth Porter) Date: Thu, 02 Feb 2006 21:39:22 -0800 Subject: Disableing the MX resolution on sendmail In-Reply-To: <43E206AC.8090204@deic.uab.es> References: <43E206AC.8090204@deic.uab.es> Message-ID: <4352435FB01DDE0ECA87BF29@[10.169.6.226]> On Thursday, February 02, 2006 2:18 PM +0100 Pere Urb?n Bayes wrote: > Hello to everybody, could any one of you tell me how to disable the MX > resolution on sendmail? I'm looking for it during all the day without > luck! -_-! Not sure what you're asking. I'm guessing you need entries in the mailertable map. Post on comp.mail.sendmail with more details about what you're trying to achieve. From ralph+fedora at strg-alt-entf.org Fri Feb 3 11:03:52 2006 From: ralph+fedora at strg-alt-entf.org (Ralph Angenendt) Date: Fri, 3 Feb 2006 12:03:52 +0100 Subject: Disableing the MX resolution on sendmail In-Reply-To: <43E206AC.8090204@deic.uab.es> References: <43E206AC.8090204@deic.uab.es> Message-ID: <20060203110352.GK6697@br-online.de> Pere Urb?n Bayes wrote: > Hello to everybody, could any one of you tell me how to disable the MX > resolution on sendmail? I'm looking for it during all the day without > luck! -_-! [host.na.me] in whatever table your trying to do that. But this really isn't the list to ask stuff like that. Regards, Ralph -- Ralph Angenendt......ra at br-online.de | .."Text processing has made it possible Bayerischer Rundfunk...80300 M?nchen | ....to right-justify any idea, even one Programmbereich.Bayern 3, Jugend und | .which cannot be justified on any other Multimedia.........Tl:089.5900.16023 | ..........grounds." -- J. Finnegan, USC -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Feb 4 16:57:38 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 4 Feb 2006 17:57:38 +0100 Subject: Pruning old vendor update packages? In-Reply-To: <20051023203747.GH15406@neu.nirvana> References: <20051023150617.GE15406@neu.nirvana> <1098559128.28454.66.camel@yoda.loki.me> <20051023203747.GH15406@neu.nirvana> Message-ID: <20060204165738.GG15286@neu.nirvana> My mirror is hitting the ceiling in the FL mount, and I still see 2 1/2 GB of such slack space. Would it help if I mail a list of the packages to be deleted? Just to make it clear: I'm referring to old updates that were obsoleted during RH's maintenance, e.g. which do not exist on redhat.com anymore, because RH ships a newer one in its updates folder. Last time I suggested this someone though that I was referring to vendor packages that had been superceeded by FL, that's not the case! Thanks! On Sun, Oct 23, 2005 at 10:37:47PM +0200, Axel Thimm wrote: > On Sat, Oct 23, 2004 at 12:18:48PM -0700, Jesse Keating wrote: > > On Sun, 2005-10-23 at 17:06 +0200, Axel Thimm wrote: > > > fedoralegacy.org does not remove old update packages. These make > 3GB > > > for Fedora releases. > > > > > > Could that be fixed? Mirrors would be grateful, and the use of such > > > before-EOL-obsoleted packages is very small. > > > > Yes, I'm working w/ Red Hat on this one. Currently the Yum version on > > the master server is not new enough to use the yum-utils package. > > Thanks! Why do you need yum-utils? Doesn't rsync --delete do the job? -- 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 jkeating at j2solutions.net Sat Feb 4 18:11:46 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 04 Feb 2006 10:11:46 -0800 Subject: Pruning old vendor update packages? In-Reply-To: <20060204165738.GG15286@neu.nirvana> References: <20051023150617.GE15406@neu.nirvana> <1098559128.28454.66.camel@yoda.loki.me> <20051023203747.GH15406@neu.nirvana> <20060204165738.GG15286@neu.nirvana> Message-ID: <1139076706.3188.5.camel@yoda.loki.me> On Sat, 2006-02-04 at 17:57 +0100, Axel Thimm wrote: > > Just to make it clear: I'm referring to old updates that were > obsoleted during RH's maintenance, e.g. which do not exist on > redhat.com anymore, because RH ships a newer one in its updates > folder. Last time I suggested this someone though that I was referring > to vendor packages that had been superceeded by FL, that's not the > case! Please do a new check. I thought I pruned everything that wasn't on the RH download site. I haven't pruned stuff that FL has since replaced, I kind of wanted to keep what RH left and just add to it. But I'll take a look at the list you come up with. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Sat Feb 4 18:53:09 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 4 Feb 2006 19:53:09 +0100 Subject: Pruning old vendor update packages? In-Reply-To: <1139076706.3188.5.camel@yoda.loki.me> References: <20051023150617.GE15406@neu.nirvana> <1098559128.28454.66.camel@yoda.loki.me> <20051023203747.GH15406@neu.nirvana> <20060204165738.GG15286@neu.nirvana> <1139076706.3188.5.camel@yoda.loki.me> Message-ID: <20060204185309.GI15286@neu.nirvana> On Sat, Feb 04, 2006 at 10:11:46AM -0800, Jesse Keating wrote: > On Sat, 2006-02-04 at 17:57 +0100, Axel Thimm wrote: > > > > Just to make it clear: I'm referring to old updates that were > > obsoleted during RH's maintenance, e.g. which do not exist on > > redhat.com anymore, because RH ships a newer one in its updates > > folder. Last time I suggested this someone though that I was referring > > to vendor packages that had been superceeded by FL, that's not the > > case! > > Please do a new check. That *was* a new check. :) -- 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 jkeating at j2solutions.net Sat Feb 4 19:27:09 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 04 Feb 2006 11:27:09 -0800 Subject: Pruning old vendor update packages? In-Reply-To: <20060204185309.GI15286@neu.nirvana> References: <20051023150617.GE15406@neu.nirvana> <1098559128.28454.66.camel@yoda.loki.me> <20051023203747.GH15406@neu.nirvana> <20060204165738.GG15286@neu.nirvana> <1139076706.3188.5.camel@yoda.loki.me> <20060204185309.GI15286@neu.nirvana> Message-ID: <1139081230.2745.0.camel@ender> On Sat, 2006-02-04 at 19:53 +0100, Axel Thimm wrote: > > Please do a new check. > > That *was* a new check. :) Care to share the results? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Sat Feb 4 20:38:27 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 4 Feb 2006 21:38:27 +0100 Subject: Pruning old vendor update packages? In-Reply-To: <1139081230.2745.0.camel@ender> References: <20051023150617.GE15406@neu.nirvana> <1098559128.28454.66.camel@yoda.loki.me> <20051023203747.GH15406@neu.nirvana> <20060204165738.GG15286@neu.nirvana> <1139076706.3188.5.camel@yoda.loki.me> <20060204185309.GI15286@neu.nirvana> <1139081230.2745.0.camel@ender> Message-ID: <20060204203827.GJ15286@neu.nirvana> On Sat, Feb 04, 2006 at 11:27:09AM -0800, Jesse Keating wrote: > On Sat, 2006-02-04 at 19:53 +0100, Axel Thimm wrote: > > > Please do a new check. > > > > That *was* a new check. :) > > Care to share the results? Please double-check before really wiping them: download.fedoralegacy.org/fedora/1/updates/SRPMS/cvs-1.11.15-1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/cvs-1.11.15-5.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/ethereal-0.10.0a-0.1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/gdk-pixbuf-0.22.0-11.2.2.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/gaim-0.75-1.3.0.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/gaim-0.76-1.FC1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/gaim-0.77-2.FC1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/gaim-0.78-1.FC1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/gaim-0.79-0.FC1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/gaim-0.80-1.FC1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/gaim-0.81-0.FC1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/ghostscript-7.07-15.1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/ghostscript-7.07-15.3.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/httpd-2.0.48-1.2.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/kdelibs-3.1.4-5.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/kernel-2.4.22-1.2174.nptl.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/kernel-2.4.22-1.2179.nptl.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/kernel-2.4.22-1.2188.nptl.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/kernel-2.4.22-1.2194.nptl.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/kernel-2.4.22-1.2197.nptl.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/krb5-1.3.3-6.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/kudzu-1.1.36.1-1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/lha-1.14i-12.1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/libpng-1.2.2-20.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/libpng10-1.0.13-11.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/mailman-2.1.4-1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/mc-4.6.0-14.10.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/mc-4.6.0-8.4.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/neon-0.24.5-1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/openoffice.org-1.1.0-15.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/perl-5.8.3-10.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/php-4.3.4-1.1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/rsync-2.5.7-2.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/samba-3.0.2-7.FC1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/samba-3.0.4-1.FC1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/samba-3.0.6-2.FC1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/squid-2.5.STABLE3-1.fc1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/subversion-0.32.1-2.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/tcpdump-3.7.2-8.fc1.1.src.rpm download.fedoralegacy.org/fedora/1/updates/i386/arpwatch-2.1a11-8.fc1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/cvs-1.11.15-1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/cvs-1.11.15-5.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/ethereal-0.10.0a-0.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/ethereal-0.10.3-0.1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/ethereal-gnome-0.10.0a-0.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/ethereal-gnome-0.10.3-0.1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/gaim-0.75-1.3.0.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/gaim-0.76-1.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/gaim-0.77-2.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/gaim-0.78-1.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/gaim-0.79-0.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/gaim-0.80-1.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/gaim-0.81-0.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/gaim-0.81-1.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/gdk-pixbuf-0.22.0-11.2.2.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/gdk-pixbuf-devel-0.22.0-11.2.2.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/gdk-pixbuf-gnome-0.22.0-11.2.2.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/ghostscript-7.07-15.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/ghostscript-7.07-15.2.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/ghostscript-7.07-15.3.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/ghostscript-devel-7.07-15.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/ghostscript-devel-7.07-15.2.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/ghostscript-devel-7.07-15.3.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/ghostscript-gtk-7.07-15.3.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/glibc-2.3.2-101.1.i686.rpm download.fedoralegacy.org/fedora/1/updates/i386/httpd-2.0.48-1.2.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/hpijs-1.5-4.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/hpijs-1.5-4.2.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/httpd-2.0.49-1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/httpd-devel-2.0.48-1.2.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/httpd-devel-2.0.49-1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/httpd-manual-2.0.48-1.2.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/httpd-manual-2.0.49-1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2140.nptl.i586.rpm download.fedoralegacy.org/fedora/1/updates/i386/kdelibs-3.1.4-5.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kdelibs-devel-3.1.4-5.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2140.nptl.i686.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2174.nptl.athlon.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2174.nptl.i586.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2174.nptl.i686.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2179.nptl.athlon.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2179.nptl.i586.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2179.nptl.i686.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2188.nptl.athlon.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2188.nptl.i586.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2188.nptl.i686.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2194.nptl.athlon.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2194.nptl.i586.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2194.nptl.i686.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2197.nptl.athlon.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2197.nptl.i586.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2197.nptl.i686.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-BOOT-2.4.22-1.2174.nptl.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-BOOT-2.4.22-1.2179.nptl.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-BOOT-2.4.22-1.2188.nptl.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-BOOT-2.4.22-1.2194.nptl.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-BOOT-2.4.22-1.2197.nptl.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-doc-2.4.22-1.2174.nptl.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-doc-2.4.22-1.2179.nptl.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-doc-2.4.22-1.2188.nptl.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-doc-2.4.22-1.2194.nptl.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-doc-2.4.22-1.2197.nptl.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2140.nptl.i686.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2174.nptl.athlon.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2174.nptl.i686.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2179.nptl.athlon.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2179.nptl.i686.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2188.nptl.athlon.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2188.nptl.i686.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2194.nptl.athlon.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2194.nptl.i586.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2194.nptl.i686.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2197.nptl.athlon.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2197.nptl.i586.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2197.nptl.i686.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-source-2.4.22-1.2174.nptl.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-source-2.4.22-1.2179.nptl.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-source-2.4.22-1.2188.nptl.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-source-2.4.22-1.2194.nptl.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-source-2.4.22-1.2197.nptl.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/krb5-workstation-1.3.3-6.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/krb5-devel-1.3.3-6.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/krb5-libs-1.3.3-6.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/krb5-server-1.3.3-6.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kudzu-1.1.36.1-1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kudzu-devel-1.1.36.1-1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/lha-1.14i-12.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/libpcap-0.7.2-8.fc1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/libpng-1.2.2-20.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/libpng-1.2.5-4.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/libpng-devel-1.2.2-20.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/libpng-devel-1.2.5-4.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/libpng10-1.0.13-11.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/libpng10-1.0.15-4.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/libpng10-devel-1.0.13-11.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/libpng10-devel-1.0.15-4.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/mailman-2.1.4-1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/mc-4.6.0-14.10.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/mc-4.6.0-8.4.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/mod_dav_svn-0.32.1-2.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/mod_ssl-2.0.48-1.2.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/mod_ssl-2.0.49-1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/neon-devel-0.24.5-1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/neon-0.24.5-1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/openoffice.org-i18n-1.1.0-15.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/openoffice.org-1.1.0-15.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/openoffice.org-libs-1.1.0-15.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/perl-5.8.3-10.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/perl-suidperl-5.8.3-10.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-4.3.4-1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-4.3.6-1.3.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-devel-4.3.4-1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-devel-4.3.6-1.3.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-domxml-4.3.4-1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-domxml-4.3.6-1.3.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-imap-4.3.4-1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-imap-4.3.6-1.3.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-ldap-4.3.4-1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-ldap-4.3.6-1.3.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-mysql-4.3.4-1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-mysql-4.3.6-1.3.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-odbc-4.3.4-1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-odbc-4.3.6-1.3.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-pgsql-4.3.4-1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-pgsql-4.3.6-1.3.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-snmp-4.3.4-1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-snmp-4.3.6-1.3.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-xmlrpc-4.3.4-1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-xmlrpc-4.3.6-1.3.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/samba-client-3.0.2-7.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/rsync-2.5.7-2.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/rsync-2.5.7-5.fc1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/samba-3.0.2-7.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/samba-3.0.4-1.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/samba-3.0.6-2.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/samba-client-3.0.4-1.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/samba-client-3.0.6-2.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/samba-common-3.0.2-7.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/samba-common-3.0.4-1.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/samba-common-3.0.6-2.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/samba-swat-3.0.2-7.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/samba-swat-3.0.4-1.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/samba-swat-3.0.6-2.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/squid-2.5.STABLE3-1.fc1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/strace-4.5.1-1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/subversion-devel-0.32.1-2.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/subversion-0.32.1-2.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/tcpdump-3.7.2-8.fc1.1.i386.rpm download.fedoralegacy.org/fedora/2/updates/SRPMS/devhelp-0.9.1-0.2.2.src.rpm download.fedoralegacy.org/fedora/2/updates/SRPMS/dovecot-0.99.10.5-0.FC2.src.rpm download.fedoralegacy.org/fedora/2/updates/SRPMS/epiphany-1.2.7-0.2.2.src.rpm download.fedoralegacy.org/fedora/2/updates/SRPMS/ethereal-0.10.5-0.2.2.src.rpm download.fedoralegacy.org/fedora/2/updates/SRPMS/ethereal-0.10.9-1.FC2.1.src.rpm download.fedoralegacy.org/fedora/2/updates/SRPMS/gaim-1.1.4-1.FC2.src.rpm download.fedoralegacy.org/fedora/2/updates/SRPMS/gdk-pixbuf-0.22.0-11.3.5.src.rpm download.fedoralegacy.org/fedora/2/updates/SRPMS/gtk2-2.4.14-1.fc2.src.rpm download.fedoralegacy.org/fedora/2/updates/SRPMS/initscripts-7.55.1-1.src.rpm download.fedoralegacy.org/fedora/2/updates/SRPMS/ipsec-tools-0.2.5-4.src.rpm download.fedoralegacy.org/fedora/2/updates/SRPMS/kdebase-3.2.2-6.FC2.src.rpm download.fedoralegacy.org/fedora/2/updates/SRPMS/kernel-2.6.10-1.770_FC2.src.rpm download.fedoralegacy.org/fedora/2/updates/SRPMS/kdelibs-3.2.2-12.FC2.src.rpm download.fedoralegacy.org/fedora/2/updates/SRPMS/kdelibs-3.2.2-8.FC2.src.rpm download.fedoralegacy.org/fedora/2/updates/SRPMS/krb5-1.3.4-6.src.rpm download.fedoralegacy.org/fedora/2/updates/SRPMS/krb5-1.3.6-1.src.rpm download.fedoralegacy.org/fedora/2/updates/SRPMS/mailman-2.1.5-7.src.rpm download.fedoralegacy.org/fedora/2/updates/SRPMS/mailman-2.1.5-8.fc2.src.rpm download.fedoralegacy.org/fedora/2/updates/SRPMS/mod_python-3.1.3-1.fc2.1.src.rpm download.fedoralegacy.org/fedora/2/updates/SRPMS/mozilla-1.7.3-0.2.0.src.rpm download.fedoralegacy.org/fedora/2/updates/SRPMS/mozilla-1.7.6-1.2.2.src.rpm download.fedoralegacy.org/fedora/2/updates/SRPMS/mysql-3.23.58-9.1.src.rpm download.fedoralegacy.org/fedora/2/updates/SRPMS/pcmcia-cs-3.2.7-1.8.2.1.src.rpm download.fedoralegacy.org/fedora/2/updates/SRPMS/php-4.3.8-2.1.src.rpm download.fedoralegacy.org/fedora/2/updates/SRPMS/squid-2.5.STABLE8-1.FC2.1.src.rpm download.fedoralegacy.org/fedora/2/updates/SRPMS/squirrelmail-1.4.3a-6.FC2.src.rpm download.fedoralegacy.org/fedora/2/updates/SRPMS/sylpheed-1.0.3-0.FC2.src.rpm download.fedoralegacy.org/fedora/2/updates/SRPMS/xorg-x11-6.7.0-11.src.rpm download.fedoralegacy.org/fedora/2/updates/SRPMS/openoffice.org-1.1.3-11.4.0.fc2.src.rpm download.fedoralegacy.org/fedora/2/updates/i386/devhelp-0.9.1-0.2.2.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/devhelp-devel-0.9.1-0.2.2.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/epiphany-1.2.7-0.2.2.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/ethereal-0.10.9-1.FC2.1.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/ethereal-gnome-0.10.9-1.FC2.1.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/gaim-1.1.4-1.FC2.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/gdk-pixbuf-0.22.0-11.3.5.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/gdk-pixbuf-devel-0.22.0-11.3.5.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/gdk-pixbuf-gnome-0.22.0-11.3.5.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/gtk2-2.4.14-1.fc2.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/gtk2-devel-2.4.14-1.fc2.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/kdelibs-devel-3.2.2-12.FC2.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/kdelibs-3.2.2-12.FC2.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/kernel-doc-2.6.10-1.770_FC2.noarch.rpm download.fedoralegacy.org/fedora/2/updates/i386/kernel-2.6.10-1.770_FC2.i586.rpm download.fedoralegacy.org/fedora/2/updates/i386/kernel-2.6.10-1.770_FC2.i686.rpm download.fedoralegacy.org/fedora/2/updates/i386/kernel-sourcecode-2.6.10-1.770_FC2.noarch.rpm download.fedoralegacy.org/fedora/2/updates/i386/kernel-smp-2.6.10-1.770_FC2.i586.rpm download.fedoralegacy.org/fedora/2/updates/i386/kernel-smp-2.6.10-1.770_FC2.i686.rpm download.fedoralegacy.org/fedora/2/updates/i386/krb5-devel-1.3.6-1.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/krb5-libs-1.3.6-1.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/krb5-server-1.3.6-1.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/krb5-workstation-1.3.6-1.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/mailman-2.1.5-8.fc2.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/mozilla-dom-inspector-1.7.3-0.2.0.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/mozilla-1.7.3-0.2.0.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/mozilla-1.7.6-1.2.2.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/mozilla-chat-1.7.3-0.2.0.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/mozilla-chat-1.7.6-1.2.2.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/mozilla-devel-1.7.3-0.2.0.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/mozilla-devel-1.7.6-1.2.2.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/mozilla-dom-inspector-1.7.6-1.2.2.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/mozilla-js-debugger-1.7.3-0.2.0.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/mozilla-js-debugger-1.7.6-1.2.2.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/mozilla-mail-1.7.3-0.2.0.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/mozilla-mail-1.7.6-1.2.2.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/mozilla-nspr-1.7.3-0.2.0.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/mozilla-nspr-1.7.6-1.2.2.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/mozilla-nspr-devel-1.7.3-0.2.0.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/mozilla-nspr-devel-1.7.6-1.2.2.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/mozilla-nss-1.7.3-0.2.0.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/mozilla-nss-1.7.6-1.2.2.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/mozilla-nss-devel-1.7.3-0.2.0.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/mozilla-nss-devel-1.7.6-1.2.2.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/squid-2.5.STABLE8-1.FC2.1.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/squirrelmail-1.4.3a-6.FC2.noarch.rpm download.fedoralegacy.org/fedora/2/updates/i386/sylpheed-1.0.3-0.FC2.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-100dpi-fonts-6.7.0-11.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-ISO8859-2-75dpi-fonts-6.7.0-11.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-6.7.0-11.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-75dpi-fonts-6.7.0-11.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/mysql-3.23.58-9.1.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-ISO8859-14-100dpi-fonts-6.7.0-11.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-ISO8859-14-75dpi-fonts-6.7.0-11.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-ISO8859-15-100dpi-fonts-6.7.0-11.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-ISO8859-15-75dpi-fonts-6.7.0-11.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-Mesa-libGL-6.7.0-11.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-ISO8859-2-100dpi-fonts-6.7.0-11.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-ISO8859-9-100dpi-fonts-6.7.0-11.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-ISO8859-9-75dpi-fonts-6.7.0-11.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-Mesa-libGLU-6.7.0-11.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-Xnest-6.7.0-11.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-Xvfb-6.7.0-11.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-base-fonts-6.7.0-11.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-cyrillic-fonts-6.7.0-11.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-devel-6.7.0-11.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-doc-6.7.0-11.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-font-utils-6.7.0-11.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-libs-6.7.0-11.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-libs-data-6.7.0-11.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-sdk-6.7.0-11.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-syriac-fonts-6.7.0-11.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-tools-6.7.0-11.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-truetype-fonts-6.7.0-11.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-twm-6.7.0-11.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-xauth-6.7.0-11.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-xdm-6.7.0-11.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-xfs-6.7.0-11.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/mysql-bench-3.23.58-9.1.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/mysql-devel-3.23.58-9.1.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/mysql-server-3.23.58-9.1.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/openoffice.org-1.1.3-11.4.0.fc2.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/openoffice.org-i18n-1.1.3-11.4.0.fc2.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/openoffice.org-kde-1.1.3-11.4.0.fc2.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/openoffice.org-libs-1.1.3-11.4.0.fc2.i386.rpm download.fedoralegacy.org/fedora/3/updates/SRPMS/cups-1.1.22-0.rc1.8.8.src.rpm download.fedoralegacy.org/fedora/3/updates/SRPMS/fetchmail-6.2.5.4-1.fc3.src.rpm download.fedoralegacy.org/fedora/3/updates/SRPMS/ethereal-0.10.13-1.FC3.1.src.rpm download.fedoralegacy.org/fedora/3/updates/SRPMS/netpbm-10.28-1.FC3.2.src.rpm download.fedoralegacy.org/fedora/3/updates/SRPMS/ruby-1.8.3-2.fc3.src.rpm download.fedoralegacy.org/fedora/3/updates/SRPMS/system-config-bind-4.0.0-31.src.rpm download.fedoralegacy.org/fedora/3/updates/SRPMS/system-config-netboot-0.1.33-1_FC3.src.rpm download.fedoralegacy.org/fedora/3/updates/i386/cups-1.1.22-0.rc1.8.8.i386.rpm download.fedoralegacy.org/fedora/3/updates/i386/cups-devel-1.1.22-0.rc1.8.8.i386.rpm download.fedoralegacy.org/fedora/3/updates/i386/ethereal-0.10.13-1.FC3.1.i386.rpm download.fedoralegacy.org/fedora/3/updates/i386/ethereal-gnome-0.10.13-1.FC3.1.i386.rpm download.fedoralegacy.org/fedora/3/updates/i386/fetchmail-6.2.5.4-1.fc3.i386.rpm download.fedoralegacy.org/fedora/3/updates/i386/irb-1.8.3-2.fc3.i386.rpm download.fedoralegacy.org/fedora/3/updates/i386/netpbm-devel-10.28-1.FC3.2.i386.rpm download.fedoralegacy.org/fedora/3/updates/i386/netpbm-progs-10.28-1.FC3.2.i386.rpm download.fedoralegacy.org/fedora/3/updates/i386/rdoc-1.8.3-2.fc3.i386.rpm download.fedoralegacy.org/fedora/3/updates/i386/ri-1.8.3-2.fc3.i386.rpm download.fedoralegacy.org/fedora/3/updates/i386/ruby-1.8.3-2.fc3.i386.rpm download.fedoralegacy.org/fedora/3/updates/i386/ruby-devel-1.8.3-2.fc3.i386.rpm download.fedoralegacy.org/fedora/3/updates/i386/ruby-docs-1.8.3-2.fc3.i386.rpm download.fedoralegacy.org/fedora/3/updates/i386/ruby-mode-1.8.3-2.fc3.i386.rpm download.fedoralegacy.org/fedora/3/updates/i386/ruby-tcltk-1.8.3-2.fc3.i386.rpm download.fedoralegacy.org/fedora/3/updates/i386/system-config-netboot-0.1.33-1_FC3.i386.rpm download.fedoralegacy.org/fedora/3/updates/x86_64/cups-1.1.22-0.rc1.8.8.x86_64.rpm download.fedoralegacy.org/fedora/3/updates/x86_64/cups-devel-1.1.22-0.rc1.8.8.x86_64.rpm download.fedoralegacy.org/fedora/3/updates/x86_64/cups-libs-1.1.22-0.rc1.8.8.x86_64.rpm download.fedoralegacy.org/fedora/3/updates/x86_64/ethereal-0.10.13-1.FC3.1.x86_64.rpm download.fedoralegacy.org/fedora/3/updates/x86_64/ethereal-gnome-0.10.13-1.FC3.1.x86_64.rpm download.fedoralegacy.org/fedora/3/updates/x86_64/fetchmail-6.2.5.4-1.fc3.x86_64.rpm download.fedoralegacy.org/fedora/3/updates/x86_64/irb-1.8.3-2.fc3.x86_64.rpm download.fedoralegacy.org/fedora/3/updates/x86_64/netpbm-10.28-1.FC3.2.x86_64.rpm download.fedoralegacy.org/fedora/3/updates/x86_64/netpbm-devel-10.28-1.FC3.2.x86_64.rpm download.fedoralegacy.org/fedora/3/updates/x86_64/netpbm-progs-10.28-1.FC3.2.x86_64.rpm download.fedoralegacy.org/fedora/3/updates/x86_64/rdoc-1.8.3-2.fc3.x86_64.rpm download.fedoralegacy.org/fedora/3/updates/x86_64/ri-1.8.3-2.fc3.x86_64.rpm download.fedoralegacy.org/fedora/3/updates/x86_64/ruby-1.8.3-2.fc3.x86_64.rpm download.fedoralegacy.org/fedora/3/updates/x86_64/ruby-devel-1.8.3-2.fc3.x86_64.rpm download.fedoralegacy.org/fedora/3/updates/x86_64/ruby-docs-1.8.3-2.fc3.x86_64.rpm download.fedoralegacy.org/fedora/3/updates/x86_64/ruby-libs-1.8.3-2.fc3.x86_64.rpm download.fedoralegacy.org/fedora/3/updates/x86_64/ruby-mode-1.8.3-2.fc3.x86_64.rpm download.fedoralegacy.org/fedora/3/updates/x86_64/ruby-tcltk-1.8.3-2.fc3.x86_64.rpm download.fedoralegacy.org/fedora/3/updates/x86_64/system-config-netboot-0.1.33-1_FC3.x86_64.rpm -- 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 pekkas at netcore.fi Sat Feb 4 22:48:07 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Sun, 5 Feb 2006 00:48:07 +0200 (EET) Subject: issues list(s) Message-ID: Remember, there's always a need for folks to do some QA testing. See the wiki for instructions and how to get started: http://www.fedoraproject.org/wiki/Legacy/QATesting Personally, I'd like to get special attention at: - there's gaim, squid, mod_auth_pgsql, and auth_ldap sitting at "VERIFY" pile. Especially if you use any of the last three, PLEASE report success/failure. - I'd like to pinpoint folks to the recent two critical mozilla vulns, which I filed as #180036 See the full lists at: http://www.netcore.fi/pekkas/buglist.html (all) http://www.netcore.fi/pekkas/buglist-rhl73.html http://www.netcore.fi/pekkas/buglist-rhl9.html http://www.netcore.fi/pekkas/buglist-core1.html http://www.netcore.fi/pekkas/buglist-fc2.html http://www.netcore.fi/pekkas/buglist-fc3.html -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From will at jxxtech.net Mon Feb 6 06:52:56 2006 From: will at jxxtech.net (Will Lane) Date: Mon, 06 Feb 2006 01:52:56 -0500 Subject: Sendmail 8.12.8 Message-ID: <43E6F248.8020109@jxxtech.net> Hello I have a RH9 box happily chugging away running sendmail 8.12.8 for the last 2 years. It is setup under the legacy project yum and is up to date with the legacy project's patches. So my question is, is this secure? Even thought 8.12.8 is not the latest version of sendmail? Sorry for the question, i feel so naive... Thanks Will From gene.heskett at verizon.net Mon Feb 6 09:31:01 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Mon, 06 Feb 2006 04:31:01 -0500 Subject: KMail and its UI freezes while fetching/sorting mail Message-ID: <200602060431.02060.gene.heskett@verizon.net> Greetings; This has about worn me out, to the extent that I'm looking for another email agent that can fetch from the local /var/spool/mail/user spoolfile fetchmail uses, run it thru SA, and deposit it for reading in the /root/Mail directory 100% compatible with the kmail way of doing things. Thunderbird can't, sylpheed can't that I can figure out. Are there any other email agents with as friendly a gui as kmail but do all the housekeeping 100% in the background? Alternatively, is there a way to make fetchmail do the SA invocation, leaving the sorting to kmail? That would help considerably. It seems to me there really should be something out there thats usable for someone used to kmail, or could, it it uses a different folder mechanism, import the kmail folders when the transition is done. -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From nils at lemonbit.nl Mon Feb 6 09:43:13 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Mon, 6 Feb 2006 10:43:13 +0100 Subject: KMail and its UI freezes while fetching/sorting mail In-Reply-To: <200602060431.02060.gene.heskett@verizon.net> References: <200602060431.02060.gene.heskett@verizon.net> Message-ID: <0CE8887B-12D5-4EAD-A429-D2949B2EDD2B@lemonbit.nl> Gene Heskett wrote: > This has about worn me out, to the extent that I'm looking for another > email agent that can fetch from the local /var/spool/mail/user > spoolfile fetchmail uses, run it thru SA, and deposit it for > reading in > the /root/Mail directory 100% compatible with the kmail way of doing > things. > > Thunderbird can't, sylpheed can't that I can figure out. Are there > any > other email agents with as friendly a gui as kmail but do all the > housekeeping 100% in the background? I know evolution uses spamassassin to filter spam. Thunderbird has its own spam filter system, so if you don't really need SA specifically you could use that. I don't know how these clients work with local spoolfiles though. > Alternatively, is there a way to make fetchmail do the SA invocation, > leaving the sorting to kmail? That would help considerably. Maybe use procmail? Nils. From ad+lists at uni-x.org Mon Feb 6 15:36:56 2006 From: ad+lists at uni-x.org (Alexander Dalloz) Date: Mon, 06 Feb 2006 16:36:56 +0100 Subject: Sendmail 8.12.8 In-Reply-To: <43E6F248.8020109@jxxtech.net> References: <43E6F248.8020109@jxxtech.net> Message-ID: <1139240216.5948.13.camel@serendipity.dogma.lan> Am Mo, den 06.02.2006 schrieb Will Lane um 7:52: > I have a RH9 box happily chugging away running sendmail 8.12.8 for > the last 2 years. It is setup under the legacy project yum and is up to > date with the legacy project's patches. So my question is, is this > secure? Even thought 8.12.8 is not the latest version of sendmail? > Sorry for the question, i feel so naive... > Will There were no major security bugs within Sendmail after that patched version you are running. The upstream Sendmail version without the severe bug is 8.12.9, but Red Hat applied the fix to the version it shipped before. Alexander -- Alexander Dalloz | Enger, Germany | GPG http://pgp.mit.edu 0xB366A773 legal statement: http://www.uni-x.org/legal.html Fedora Core 2 GNU/Linux on Athlon with kernel 2.6.11-1.35_FC2smp Serendipity 16:34:08 up 13:02, 16 users, 0.48, 0.28, 0.15 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From fossmaker at yahoo.com Mon Feb 6 19:40:14 2006 From: fossmaker at yahoo.com (Deepan Chakravarthy) Date: Mon, 6 Feb 2006 11:40:14 -0800 (PST) Subject: upgrading kernel alone In-Reply-To: <1139240216.5948.13.camel@serendipity.dogma.lan> Message-ID: <20060206194014.3570.qmail@web34509.mail.mud.yahoo.com> hi, Am running FC3 now.. i want to upgrade the kernel alone without upgrading to FC4. how do i go about? Thanks ------------------------------------------------------------------- Deepan Chakravarthy N http://users.kaski-net.net/~deepan/ __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From ad+lists at uni-x.org Mon Feb 6 20:32:36 2006 From: ad+lists at uni-x.org (Alexander Dalloz) Date: Mon, 06 Feb 2006 21:32:36 +0100 Subject: upgrading kernel alone In-Reply-To: <20060206194014.3570.qmail@web34509.mail.mud.yahoo.com> References: <20060206194014.3570.qmail@web34509.mail.mud.yahoo.com> Message-ID: <1139257956.5948.42.camel@serendipity.dogma.lan> Am Mo, den 06.02.2006 schrieb Deepan Chakravarthy um 20:40: > Am running FC3 now.. i want to upgrade the kernel > alone without upgrading to FC4. how do i go about? Please do not hijack another list thread by replying to a different mail while starting a new topic. yum update `man yum' for details. Alexander -- Alexander Dalloz | Enger, Germany | GPG http://pgp.mit.edu 0xB366A773 legal statement: http://www.uni-x.org/legal.html Fedora Core 2 GNU/Linux on Athlon with kernel 2.6.11-1.35_FC2smp Serendipity 21:31:40 up 17:59, 16 users, 0.13, 0.23, 0.23 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From lists at benjamindsmith.com Mon Feb 6 23:09:42 2006 From: lists at benjamindsmith.com (Benjamin Smith) Date: Mon, 6 Feb 2006 15:09:42 -0800 Subject: issues list(s) In-Reply-To: References: Message-ID: <200602061509.42200.lists@benjamindsmith.com> The process of QA testing is a pain, and fraught with potential errors. I see no reason why this should be - two members of this list have come up with a good foundation for scripts that automate much of the process of determining test packages that are installed. Both parties (myself being one of them) have expressed strong interest in working with the FL website maintainers to make submitting this information easy, painless, and relatively error-free. In short, give us a URI template that we can write a script to go to in order to report packages that are in test that are installed, and we'll happily make it easy to setup/use. Making it easier to do will result in more people doing it! Whattaya say? -Ben On Saturday 04 February 2006 14:48, Pekka Savola wrote: > Remember, there's always a need for folks to do some QA testing. See the wiki > for instructions and how to get started: > > http://www.fedoraproject.org/wiki/Legacy/QATesting > > Personally, I'd like to get special attention at: > > - there's gaim, squid, mod_auth_pgsql, and auth_ldap sitting at > "VERIFY" pile. Especially if you use any of the last three, PLEASE > report success/failure. > > - I'd like to pinpoint folks to the recent two critical mozilla > vulns, which I filed as #180036 > > See the full lists at: > > http://www.netcore.fi/pekkas/buglist.html (all) > http://www.netcore.fi/pekkas/buglist-rhl73.html > http://www.netcore.fi/pekkas/buglist-rhl9.html > http://www.netcore.fi/pekkas/buglist-core1.html > http://www.netcore.fi/pekkas/buglist-fc2.html > http://www.netcore.fi/pekkas/buglist-fc3.html > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > -- "The best way to predict the future is to invent it." - XEROX PARC slogan, circa 1978 From jkeating at j2solutions.net Mon Feb 6 23:17:18 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 06 Feb 2006 15:17:18 -0800 Subject: issues list(s) In-Reply-To: <200602061509.42200.lists@benjamindsmith.com> References: <200602061509.42200.lists@benjamindsmith.com> Message-ID: <1139267838.2697.0.camel@ender> On Mon, 2006-02-06 at 15:09 -0800, Benjamin Smith wrote: > In short, give us a URI template that we can write a script to go to in order > to report packages that are in test that are installed, and we'll happily > make it easy to setup/use. Making it easier to do will result in more people > doing it! > > Whattaya say? > Just installing the package is not enough. I could do that myself on the build server and call it good. The package actually needs to be used and that requires human interaction. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From lists at benjamindsmith.com Tue Feb 7 05:35:49 2006 From: lists at benjamindsmith.com (Benjamin Smith) Date: Mon, 6 Feb 2006 21:35:49 -0800 Subject: issues list(s) In-Reply-To: <1139267838.2697.0.camel@ender> References: <200602061509.42200.lists@benjamindsmith.com> <1139267838.2697.0.camel@ender> Message-ID: <200602062135.50530.lists@benjamindsmith.com> On Monday 06 February 2006 15:17, Jesse Keating wrote: > Just installing the package is not enough. ?I could do that myself on > the build server and call it good. ?The package actually needs to be > used and that requires human interaction. Jesse, I have a Fedora Core 1 server that I use fairly heavily, and I've set up the yum repos to include updates-testing, so that testing RPMs get installed anytime I update with yum. I've had zero performance/reliability issues since doing so in the past 6-9 months, (THANKS GUYS!) and I figured it might be worthwhile to report this fact. Except: 1) What testing packages are installed that you'd even care about? 2) What changes should I test for? 3) Looks good, how do I report it? So, I wrote a script to at least tell me what packages were officially "testing" and which were released. And, it seems to me that it's a fairly trivial step from there to take that output, and automate the feedback delivery step, if there's some kind of HTTP URI I can interface with to get the results to you. Otherwise, trying to tell the difference between XFree86-ISO8859-2-75dpi-fonts-4.3.0-59.1.legacy.i386.rpm XFree86-ISO8859-2-75dpi-fonts-4.3.0-59.2.legacy.i386.rpm out of potentially hundreds of packages is enough to bugger my eyes out, especially when, for some packages (EG: Kernel) I may have several installed. All I'm asking for is a framework for making it easier for somebody to help you out. Once you know what testing packages have been installed, an `rpm -ql *rpm` would tell what commands have been updated, and it might make sense to parse the results of the `history` command, and ask for feedback on logout. Or, maybe it'd be better to keep a sqlite database of files and fileatimes, and if they change in a login session, ask about it. I dunno. All I know is that I work all day long in my day job trying to gather information from clients, and have long ago learned to make such information gathering as stupid simple as possible, or it just won't happen. As it is, I spent some time trying to figure out WTF to do and where, and got frustrated. Perhaps this sounds dumb, and maybe you don't want my input, but rule #1 for volunteers is to make it easy to do the "right thing", and as a volunteer, I'd like to make this possible. I encourage you to look in the archives for my little PHP script that solves question #1 above, I'd like to take this (or the perl script volunteered by somebody else) and put together something that hopefully makes reporting success/failure a little more straightforward. If you want, I'll find it and resend. -Ben -- "The best way to predict the future is to invent it." - XEROX PARC slogan, circa 1978 From pekkas at netcore.fi Tue Feb 7 05:52:03 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 7 Feb 2006 07:52:03 +0200 (EET) Subject: issues list(s) In-Reply-To: <200602062135.50530.lists@benjamindsmith.com> References: <200602061509.42200.lists@benjamindsmith.com> <1139267838.2697.0.camel@ender> <200602062135.50530.lists@benjamindsmith.com> Message-ID: On Mon, 6 Feb 2006, Benjamin Smith wrote: > 1) What testing packages are installed that you'd even care about? > 2) What changes should I test for? > 3) Looks good, how do I report it? > > So, I wrote a script to at least tell me what packages were officially > "testing" and which were released. And, it seems to me that it's a fairly > trivial step from there to take that output, and automate the feedback > delivery step, if there's some kind of HTTP URI I can interface with to get > the results to you. ... (Yes, I agree that this needs to be more straightforward. As I've said from the start, "put a GPG-signed message w/ VERIFY vote to bugzilla" _does not_ cut it. It's way too complicated if we want to involve a lot of folks.) Personally, I think the script should print out the list of testing updates currently installed, and then send it to the administrator of that system, basically asking "These are the testing RPMs and here's when they were installed. Which ones do you _know_ that have been used since that date?" Then the admin would send a mail to fedora-legacy-list or appropriate bugzilla entry saying, "yes, we're installed the package since XXX, gpg signature is OK, and it's in active use." That would go a long way in checking that updates-testing packages have been used and found working, instead of just having been installed. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From rostetter at mail.utexas.edu Tue Feb 7 19:01:00 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 7 Feb 2006 13:01:00 -0600 Subject: issues list(s) In-Reply-To: <200602061509.42200.lists@benjamindsmith.com> References: <200602061509.42200.lists@benjamindsmith.com> Message-ID: <20060207130100.cmqy5gkacnc4oosk@mail.ph.utexas.edu> Quoting Benjamin Smith : > The process of QA testing is a pain, and fraught with potential errors. I agree it is a pain, I'm not sure what potential errors you mean, or how your solution would not be fraught with potential errors. > I see no reason why this should be - two members of this list have come up > with a good foundation for scripts that automate much of the process of > determining test packages that are installed. Both parties (myself being one > of them) have expressed strong interest in working with the FL website > maintainers to make submitting this information easy, painless, and > relatively error-free. Then run with it. Don't wait for someone else to take up the cause. > In short, give us a URI template that we can write a script to go to in order > to report packages that are in test that are installed, and we'll happily > make it easy to setup/use. Making it easier to do will result in more people > doing it! Okay. Tell me what you expect that URI template to do, and I'll consider it. Not enough information above for me to do anything. > Whattaya say? More info needed. > -Ben -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From rostetter at mail.utexas.edu Tue Feb 7 19:10:23 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 7 Feb 2006 13:10:23 -0600 Subject: issues list(s) In-Reply-To: References: <200602061509.42200.lists@benjamindsmith.com> <1139267838.2697.0.camel@ender> <200602062135.50530.lists@benjamindsmith.com> Message-ID: <20060207131023.lhvbe4q3zhckw040@mail.ph.utexas.edu> Quoting Pekka Savola : > (Yes, I agree that this needs to be more straightforward. As I've said > from the start, "put a GPG-signed message w/ VERIFY vote to bugzilla" > _does not_ cut it. It's way too complicated if we want to involve a > lot of folks.) Why is that? Would something like a script that would do the following be useful: * generate a GPG key for them if they didn't already have one * register their GPG key on pgp.mit.edu if not already there * If both of the above were done, then prompt them for the info for the "self-introduction" e-mail and generate the self-intro they need to send to the mailing list > Personally, I think the script should print out the list of testing > updates currently installed, and then send it to the administrator of > that system, basically asking "These are the testing RPMs and here's > when they were installed. Which ones do you _know_ that have been used > since that date?" Or an interactive script which does the same, ignoring any that were installed less than some-yet-to-be-decided-time-interval-in-the-past, and generates the needed output to be mailed or submitted to bugzilla? > Then the admin would send a mail to fedora-legacy-list or appropriate > bugzilla entry saying, "yes, we're installed the package since XXX, gpg > signature is OK, and it's in active use." We would either need a volunteer who would move the mailing list posting into the bugzilla for such messages, or it would have to go to the bugzilla instead of the list. To go to the bugzilla, we need to find a way to automate the finding of the bug number for the update, no? Also, this still has to be GPG signed, so we should do that here as well. > That would go a long way in checking that updates-testing packages have > been used and found working, instead of just having been installed. Agreed, but I think we're still missing some steps. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From rostetter at mail.utexas.edu Tue Feb 7 19:22:58 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 7 Feb 2006 13:22:58 -0600 Subject: Auto-reporting of successful testing packages In-Reply-To: <200601201539.42781.lists@benjamindsmith.com> References: <200601201539.42781.lists@benjamindsmith.com> Message-ID: <20060207132258.utz0smu6i45c80k4@mail.ph.utexas.edu> Quoting Benjamin Smith : > Attached is a PHP script that, when run at the command line, returns > a list of > "testing" packages currently installed. I just looked at your script now. In it, it says: yum list installed puts a number and a colon at the beginning of the version info. I don't know what it's for, but it makes the packages fail pattern matching, so it's gotta go. That number and colon is the "Epoch" number of the RPM. Normally not used, but it shouldn't really be ignored in case it is used. I think the legacycheck.pl script is a better base to start with than yours (just my humble opinion), so there may be no need to modify your script, but I thought I'd let you know what those numbers mean as a matter of course... -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From pekkas at netcore.fi Wed Feb 8 16:34:56 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 8 Feb 2006 18:34:56 +0200 (EET) Subject: x86_64 support Message-ID: Hi, There was some discussion this in bugzilla under the kernel bug, so bringing it up for wider comments. FC1, FC2, and FC3 have supported both x86 and x86_64. (FC4 has added ppc to the mix as well.) Fedora Legacy has only supported x86, but there has been discussion of extending this to x86_64. So, given that we're currently already supporting 5 different versions, 1) Should we start supporting all the architectures for previous releases (FC1, FC2) where we didn't from day zero ? 2) Should we support new architectures for new releases (FC3, FC4, ..)? My personal take would be, 1) NO, 2) Hopefully not. The reasons are simple: we don't do a very good job as it is, and adding even more versions to build and potentially test at VERIFY stage would strain this even more. Especially as many of the latest bugs seem 64-bit specific: especially for 1), we'd need to go back and check every package to make sure we didn't miss any 64-bit specific update. I'd like to pose the question as follows: is there anyone out there who would want FL to support either past, present or future non-x86 arches who is willing to commit to doing serious help? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From rostetter at mail.utexas.edu Wed Feb 8 17:07:34 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 8 Feb 2006 11:07:34 -0600 Subject: x86_64 support In-Reply-To: References: Message-ID: <20060208110734.mxiu1r7pauosgc8g@mail.ph.utexas.edu> Quoting Pekka Savola : > FC1, FC2, and FC3 have supported both x86 and x86_64. (FC4 has added > ppc to the mix as well.) Fedora Legacy has only supported x86, but > there has been discussion of extending this to x86_64. My understanding is it _will_ be added, as soon as the build system supports it. > So, given that we're currently already supporting 5 different versions, > > 1) Should we start supporting all the architectures for previous > releases (FC1, FC2) where we didn't from day zero ? > 2) Should we support new architectures for new releases (FC3, FC4, > ..)? For 1) I don't care. For 2) Definately. > My personal take would be, 1) NO, 2) Hopefully not. The reasons are > simple: we don't do a very good job as it is, and adding even more > versions to build and potentially test at VERIFY stage would strain > this even more. And not supporting what is sure to be a huge user base of 64-bit users will only drain the project of volunteers even more. I have access to 1 and only one FC machine. It is FC3 and it is x64. I've been waiting until we take over FC3 x64 so I can help. If we don't take that over, then I will not help with FC releases. > Especially as many of the latest bugs seem 64-bit > specific: especially for 1), we'd need to go back and check every > package to make sure we didn't miss any 64-bit specific update. That is why I'm okay with not supporting the older FC releases in x64. But the new ones, I say we should do it. > I'd like to pose the question as follows: is there anyone out there > who would want FL to support either past, present or future non-x86 > arches who is willing to commit to doing serious help? Yes, for future releases. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From mattdm at mattdm.org Wed Feb 8 20:27:27 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 8 Feb 2006 15:27:27 -0500 Subject: rebuilding grub on FC3.... Message-ID: <20060208202727.GA27465@jadzia.bu.edu> (Hey look -- I'm not dead.) I'm trying to rebuild grub on FC3, and I've excitingly discovered that rebuilding the FC3 package, the FC4 one, or the devel package all result in a dynamically-linked binary, which doesn't work. This all seems related to: . and indeed all of the packages I'm trying to build are 0.95-3 and above. Anyone got any ideas? Thanks. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Wed Feb 8 20:34:23 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 8 Feb 2006 15:34:23 -0500 Subject: rebuilding grub on FC3.... In-Reply-To: <20060208202727.GA27465@jadzia.bu.edu> References: <20060208202727.GA27465@jadzia.bu.edu> Message-ID: <20060208203423.GA27940@jadzia.bu.edu> On Wed, Feb 08, 2006 at 03:27:27PM -0500, Matthew Miller wrote: > I'm trying to rebuild grub on FC3, and I've excitingly discovered that > rebuilding the FC3 package, the FC4 one, or the devel package all result in > a dynamically-linked binary, which doesn't work. (Um, on x86_64.) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Wed Feb 8 20:41:21 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 8 Feb 2006 15:41:21 -0500 Subject: rebuilding grub on FC3.... In-Reply-To: <20060208203423.GA27940@jadzia.bu.edu> References: <20060208202727.GA27465@jadzia.bu.edu> <20060208203423.GA27940@jadzia.bu.edu> Message-ID: <20060208204121.GA28365@jadzia.bu.edu> On Wed, Feb 08, 2006 at 03:34:23PM -0500, Matthew Miller wrote: > On Wed, Feb 08, 2006 at 03:27:27PM -0500, Matthew Miller wrote: > > I'm trying to rebuild grub on FC3, and I've excitingly discovered that > > rebuilding the FC3 package, the FC4 one, or the devel package all result in > > a dynamically-linked binary, which doesn't work. > (Um, on x86_64.) Ah. Got it. For future reference if a grub security update is needed. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From gene.heskett at verizon.net Wed Feb 8 23:13:28 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Wed, 08 Feb 2006 18:13:28 -0500 Subject: An imap server? Message-ID: <200602081813.28751.gene.heskett@verizon.net> Greetings all; What yum install 'name' should I use for name to install an imap mail server on a RH7.3 box? I'm going to try and move the spam filtering off my desktop machine. -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From mic at npgx.com.au Wed Feb 8 23:16:40 2006 From: mic at npgx.com.au (Michael Mansour) Date: Thu, 9 Feb 2006 09:16:40 +1000 Subject: An imap server? In-Reply-To: <200602081813.28751.gene.heskett@verizon.net> References: <200602081813.28751.gene.heskett@verizon.net> Message-ID: <20060208231610.M95236@npgx.com.au> > Greetings all; > > What yum install 'name' should I use for name to install an imap > mail server on a RH7.3 box? I'm going to try and move the spam > filtering off my desktop machine. Try dovecot. Michael. From nils at lemonbit.nl Wed Feb 8 23:23:39 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Thu, 9 Feb 2006 00:23:39 +0100 Subject: An imap server? In-Reply-To: <200602081813.28751.gene.heskett@verizon.net> References: <200602081813.28751.gene.heskett@verizon.net> Message-ID: Gene Heskett wrote: > What yum install 'name' should I use for name to install an imap mail > server on a RH7.3 box? I'm going to try and move the spam filtering > off my desktop machine. yum install imap Nils. From nils at lemonbit.nl Wed Feb 8 23:28:48 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Thu, 9 Feb 2006 00:28:48 +0100 Subject: An imap server? In-Reply-To: <20060208231610.M95236@npgx.com.au> References: <200602081813.28751.gene.heskett@verizon.net> <20060208231610.M95236@npgx.com.au> Message-ID: <613A563C-8A8F-42D4-A0D8-FF03F643B619@lemonbit.nl> Michael Mansour wrote: >> What yum install 'name' should I use for name to install an imap >> mail server on a RH7.3 box? I'm going to try and move the spam >> filtering off my desktop machine. > > Try dovecot. I don't see dovecot package at http://download.fedoralegacy.org/ redhat/7.3/os/i386/ so I guess it's not part of the RH7.3 distribution. However, if you're using Dag's repository you might want to try dovecot, Dag has it and it's pretty easy to setup. Or you can get the rpm directly from http://dag.wieers.com/packages/dovecot/ Nils. From gene.heskett at verizon.net Thu Feb 9 00:06:56 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Wed, 08 Feb 2006 19:06:56 -0500 Subject: An imap server? In-Reply-To: <613A563C-8A8F-42D4-A0D8-FF03F643B619@lemonbit.nl> References: <200602081813.28751.gene.heskett@verizon.net> <20060208231610.M95236@npgx.com.au> <613A563C-8A8F-42D4-A0D8-FF03F643B619@lemonbit.nl> Message-ID: <200602081906.56326.gene.heskett@verizon.net> On Wednesday 08 February 2006 18:28, Nils Breunese (Lemonbit Internet) wrote: >Michael Mansour wrote: >>> What yum install 'name' should I use for name to install an imap >>> mail server on a RH7.3 box? I'm going to try and move the spam >>> filtering off my desktop machine. >> >> Try dovecot. > >I don't see dovecot package at http://download.fedoralegacy.org/ >redhat/7.3/os/i386/ so I guess it's not part of the RH7.3 >distribution. However, if you're using Dag's repository you might >want to try dovecot, Dag has it and it's pretty easy to setup. Or you >can get the rpm directly from http://dag.wieers.com/packages/dovecot/ > >Nils. > Thanks Nils. -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From marcdeslauriers at videotron.ca Thu Feb 9 01:35:50 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 08 Feb 2006 20:35:50 -0500 Subject: Fedora Legacy Test Update Notification: httpd Message-ID: <43EA9C76.4060307@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-175406 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175406 2006-02-08 --------------------------------------------------------------------- Name : httpd Versions : rh73: apache-1.3.27-9.legacy Versions : rh9: httpd-2.0.40-21.21.legacy Versions : fc1: httpd-2.0.51-1.10.legacy Versions : fc2: httpd-2.0.51-2.9.5.legacy Versions : fc3: httpd-2.0.53-3.4.legacy Summary : The httpd Web server Description : This package contains a powerful, full-featured, efficient, and freely-available Web server based on work done by the Apache Software Foundation. It is also the most popular Web server on the Internet. --------------------------------------------------------------------- Update Information: Updated Apache httpd packages that correct three security issues are now available. The Apache HTTP Server is a popular and freely-available Web server. A memory leak in the worker MPM could allow remote attackers to cause a denial of service (memory consumption) via aborted connections, which prevents the memory for the transaction pool from being reused for other connections. The Common Vulnerabilities and Exposures project assigned the name CVE-2005-2970 to this issue. This vulnerability only affects users who are using the non-default worker MPM. A flaw in mod_imap when using the Referer directive with image maps was discovered. With certain site configurations, a remote attacker could perform a cross-site scripting attack if a victim can be forced to visit a malicious URL using certain web browsers. (CVE-2005-3352) A NULL pointer dereference flaw in mod_ssl was discovered affecting server configurations where an SSL virtual host is configured with access control and a custom 400 error document. A remote attacker could send a carefully crafted request to trigger this issue which would lead to a crash. This crash would only be a denial of service if using the non-default worker MPM. (CVE-2005-3357) Users of httpd should update to these erratum packages which contain backported patches to correct these issues. --------------------------------------------------------------------- Changelogs rh73: * Sun Jan 22 2006 Marc Deslauriers 1.3.27-9.legacy - mod_imap: add security fix for XSS issue (CVE-2005-3352) rh9: * Sun Jan 22 2006 Marc Deslauriers 2.0.40-21.21.legacy - mod_ssl: add security fix for HTTP-on-SSL-port handling (CVE-2005-3357) - mod_imap: add security fix for XSS issue (CVE-2005-3352) - worker MPM: add security fix for memory consumption DoS (CVE-2005-2970), and bug fixes for handling resource allocation failures (#171759) fc1: * Sun Jan 22 2006 Marc Deslauriers 2.0.51-1.10.legacy - mod_ssl: add security fix for HTTP-on-SSL-port handling (CVE-2005-3357) - mod_imap: add security fix for XSS issue (CVE-2005-3352) - worker MPM: add security fix for memory consumption DoS (CVE-2005-2970), and bug fixes for handling resource allocation failures (#171759) fc2: * Sun Jan 22 2006 Marc Deslauriers 2.0.51-2.9.5.legacy - mod_ssl: add security fix for HTTP-on-SSL-port handling (CVE-2005-3357) - mod_imap: add security fix for XSS issue (CVE-2005-3352) - worker MPM: add security fix for memory consumption DoS (CVE-2005-2970), and bug fixes for handling resource allocation failures (#171759) fc3: * Sun Jan 22 2006 Marc Deslauriers 2.0.53-3.4.legacy - mod_ssl: add security fix for HTTP-on-SSL-port handling (CVE-2005-3357) - mod_imap: add security fix for XSS issue (CVE-2005-3352) - worker MPM: add security fix for memory consumption DoS (CVE-2005-2970), and bug fixes for handling resource allocation failures (#171759) --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: c55d929dd5acbf4b0191a28b0ad128f1064810f8 redhat/7.3/updates-testing/i386/apache-1.3.27-9.legacy.i386.rpm aae52f7966d03dd6e81f8b8b5a090bf60fa8e601 redhat/7.3/updates-testing/i386/apache-devel-1.3.27-9.legacy.i386.rpm fafcea3e68311223b5a814a482927cd645c4356a redhat/7.3/updates-testing/i386/apache-manual-1.3.27-9.legacy.i386.rpm db23f5e77a78f78a346104038a564f0197ee9414 redhat/7.3/updates-testing/SRPMS/apache-1.3.27-9.legacy.src.rpm rh9: 8e6ca52b5fb88a43322a38966ffeb0285b0699e1 redhat/9/updates-testing/i386/httpd-2.0.40-21.21.legacy.i386.rpm be601feefd0483b24e3ce5efdfadcef6b5d7d040 redhat/9/updates-testing/i386/httpd-devel-2.0.40-21.21.legacy.i386.rpm 8816478ae2287a3d2d4c9ca91d55662efcae2b87 redhat/9/updates-testing/i386/httpd-manual-2.0.40-21.21.legacy.i386.rpm 2d565db0d6fa0756c51ca7aef8211b463c5f5348 redhat/9/updates-testing/i386/mod_ssl-2.0.40-21.21.legacy.i386.rpm e05115a5178fbf853dfe8fdc75b962c44a787316 redhat/9/updates-testing/SRPMS/httpd-2.0.40-21.21.legacy.src.rpm fc1: d34d8993fa09ebc2c017c98ac459688a913593f6 fedora/1/updates-testing/i386/httpd-2.0.51-1.10.legacy.i386.rpm 1598bdf136a0ab14195df7d9f4425ab6442ab3f7 fedora/1/updates-testing/i386/httpd-devel-2.0.51-1.10.legacy.i386.rpm e5d6b42924b9fd81869cbe07f410abd2ecaa106e fedora/1/updates-testing/i386/httpd-manual-2.0.51-1.10.legacy.i386.rpm 56c59eec43c7d87f9f59f7068f80e2774de1784a fedora/1/updates-testing/i386/mod_ssl-2.0.51-1.10.legacy.i386.rpm 4294e34c392cc90465d35dbfda88f95aae87c291 fedora/1/updates-testing/SRPMS/httpd-2.0.51-1.10.legacy.src.rpm fc2: 3572be6a040d0efe5e71186578b42bb991328254 fedora/2/updates-testing/i386/httpd-2.0.51-2.9.5.legacy.i386.rpm 3d75ef3d7720894c886c4d1a1e52f97f2b4bb345 fedora/2/updates-testing/i386/httpd-devel-2.0.51-2.9.5.legacy.i386.rpm 74c6d5286da4daf697f041d3084cab0a2fda46c6 fedora/2/updates-testing/i386/httpd-manual-2.0.51-2.9.5.legacy.i386.rpm 72050bf7341db26b0d72b8565102bb55eb9be250 fedora/2/updates-testing/i386/mod_ssl-2.0.51-2.9.5.legacy.i386.rpm 32a2bfe031fcbb40ed1db4a84bacc5ad78a7b7a4 fedora/2/updates-testing/SRPMS/httpd-2.0.51-2.9.5.legacy.src.rpm fc3: 563dd27fb0e74e13d1b8960e189f05af60926333 fedora/3/updates-testing/i386/httpd-2.0.53-3.4.legacy.i386.rpm 3673bec7d02bd1972c20cbca6d77bccf4c08f516 fedora/3/updates-testing/i386/httpd-devel-2.0.53-3.4.legacy.i386.rpm d004815e520338f6565e0f18d21847c6439c841f fedora/3/updates-testing/i386/httpd-manual-2.0.53-3.4.legacy.i386.rpm 48eac837da227883d681aa23e182ebb00174980f fedora/3/updates-testing/i386/httpd-suexec-2.0.53-3.4.legacy.i386.rpm ffdb283132cdf0e0de7026709087781a4f2eabb0 fedora/3/updates-testing/i386/mod_ssl-2.0.53-3.4.legacy.i386.rpm b6698d717f8dd6b028ee32184bcc778724695a83 fedora/3/updates-testing/SRPMS/httpd-2.0.53-3.4.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Thu Feb 9 01:36:15 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 08 Feb 2006 20:36:15 -0500 Subject: Fedora Legacy Test Update Notification: perl Message-ID: <43EA9C8F.3010707@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-176731 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176731 2006-02-08 --------------------------------------------------------------------- Name : perl Versions : rh9: perl-5.8.0-90.0.13.legacy Versions : fc1: perl-5.8.3-17.5.legacy Versions : fc2: perl-5.8.3-19.5.legacy Summary : The Perl programming language. Description : Perl is a high-level programming language commonly used for system administration utilities and Web programming. --------------------------------------------------------------------- Update Information: Updated perl packages that fix a security flaw are now available. Perl is a high-level programming language commonly used for system administration utilities and Web programming. An integer overflow bug was found in Perl's format string processor. It is possible for an attacker to cause perl to crash or execute arbitrary code if the attacker is able to process a malicious format string. This issue is only exploitable through a script which passes arbitrary untrusted strings to the format string processor. The Common Vulnerabilities and Exposures project assigned the name CVE-2005-3962 to this issue. Note that this vulnerability do not affect perl packages in Red Hat Linux 7.3 Users of perl are advised to upgrade to these packages which contain a backported patch and are not vulnerable to this issue. --------------------------------------------------------------------- Changelogs rh9: * Sat Jan 28 2006 David Eisenstein 2:5.8.0-90.0.13.legacy - Integrate fix for CVE-2005-3962 - Perl Format String Vulnerability, bugzilla Bug #176731. fc1: * Thu Jan 26 2006 David Eisenstein 3:5.8.3-17.5.legacy - Integrate fix for CVE-2005-3962 - Perl Format String Vulnerability, bugzilla Bug #176731. fc2: * Sat Jan 28 2006 David Eisenstein 3:5.8.3-19.5.legacy - Replace broken perl-5.8.3-findbin-selinux.patch with better patch by Jose Pedro Oliveira so perl will not fail "lib/FindBin" test. See Bugzilla Bug #176731 comment 2. * Sat Jan 28 2006 David Eisenstein 3:5.8.3-19.4.legacy - Integrate fix for CVE-2005-3962 - Perl Format String Vulnerability, bugzilla Bug #176731. --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh9: 4d2401a09f2cc0b126df88659bd9e259a528146d redhat/9/updates-testing/i386/perl-5.8.0-90.0.13.legacy.i386.rpm 3b5448a2a8d8241a85c4c54ad5d5deb4b9d466d4 redhat/9/updates-testing/i386/perl-CGI-2.81-90.0.13.legacy.i386.rpm 40a05fcf3a7d128e7fa79b00022d54d0542bd3af redhat/9/updates-testing/i386/perl-CPAN-1.61-90.0.13.legacy.i386.rpm 5444ce68de7e8f0b1b051a15a1658c7d497be61b redhat/9/updates-testing/i386/perl-DB_File-1.804-90.0.13.legacy.i386.rpm 76ff3cdbe78a2e7c92c1f95760906fd396f974bf redhat/9/updates-testing/i386/perl-suidperl-5.8.0-90.0.13.legacy.i386.rpm 62fbcae6dd839fd18aabcf5c9fcc6babfd844d94 redhat/9/updates-testing/SRPMS/perl-5.8.0-90.0.13.legacy.src.rpm fc1: 3267a9d83ac3cadcfa650b1625cf5c458adb5540 fedora/1/updates-testing/i386/perl-5.8.3-17.5.legacy.i386.rpm 2445d66c7ced8bccc7d875a21404216a0cd5cdb6 fedora/1/updates-testing/i386/perl-suidperl-5.8.3-17.5.legacy.i386.rpm 297a649694e03e67b13cfbac7ae8211554cea44b fedora/1/updates-testing/SRPMS/perl-5.8.3-17.5.legacy.src.rpm fc2: 772f9571df3a0eab7749bb0d162311f4cd539879 fedora/2/updates-testing/i386/perl-5.8.3-19.5.legacy.i386.rpm 83cf2b36b48760eb1f99a042214eead7a9650d38 fedora/2/updates-testing/i386/perl-suidperl-5.8.3-19.5.legacy.i386.rpm 260cf2c8b759afe09f205318e1fd78cabdeefcb0 fedora/2/updates-testing/SRPMS/perl-5.8.3-19.5.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From rdieter at math.unl.edu Thu Feb 9 14:36:49 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 09 Feb 2006 08:36:49 -0600 Subject: An imap server? In-Reply-To: <200602081813.28751.gene.heskett@verizon.net> References: <200602081813.28751.gene.heskett@verizon.net> Message-ID: Gene Heskett wrote: > What yum install 'name' should I use for name to install an imap mail > server on a RH7.3 box? I'm going to try and move the spam filtering > off my desktop machine. yum install imap should do the trick (of installing UW's imap that came with rh73). -- Rex From jung at one.ekof.bg.ac.yu Thu Feb 9 23:58:05 2006 From: jung at one.ekof.bg.ac.yu (Igor =?iso-8859-2?Q?Nestorovi=E6?=) Date: Fri, 10 Feb 2006 00:58:05 +0100 Subject: GDM Problem Message-ID: <1139529485.7469.38.camel@lara> Hello all, I have posted this problem on the Shrike list but it looks like that list is being checked scarcely, so I would like to repeat the problem I have here. Recently I have come up with rather annoying problem with GDM: it won't start. At the moment when GDM starts, the NVIDIA driver loads successfully (its splash screen shows) and then I get blank (black) screen with a mouse cursor "X". Here's the output from /var/log/gdm: Fatal server error: Server is already active for display 0 If this server is no longer running, remove /tmp/.X0-lock and start again. Here's the output from "ps -ef | grep dm": ps -ef | grep dm root 4779 1 0 19:52 ? 00:00:00 /usr/bin/gdm-binary -nodaemon root 4859 1 0 19:52 ? 00:00:03 /usr/X11R6/bin/X :0 -auth /var/gdm/:0.Xauth -nolisten tcp vt7 root 4864 4779 0 19:52 ? 00:00:00 /usr/bin/gdm-binary -nodaemon root 4867 4864 0 19:52 ? 00:00:00 /usr/libexec/gdmopen -l /bin/sh -c /usr/bin/dialog --yesno '???????? ?? ??? ????? ????????? ???? ??????????? ?? ???????? :0. ??? ?? ?? ??????? ??????? ?????? ???????? ???? ???????????? ??, ??? ????????? ?? ?? (stuff in my native language, the console question I mentioned earlier; translation: 'It looks like that X has been already up on screen :0. Should I try the other screen number? If no, should I try running on the same screen again?) root 6245 5279 0 20:07 pts/1 00:00:00 grep dm What seems to be the problem? I haven't been able to find a solution on the Internet, but confirmed that the same problem occured definitely many times earlier. In fact, Red Hat issued an errata update to GDM on its supported product line that adressed this issue, among several others. When I boot in init 3 and consequently order "startx" GNOME loads without problems. Also KDM is working fine, so I guess that XFree86.config and NVIDIA display driver are OK. Note that gdm fails also when I run "gdm" manually while in runlevel 3. The system is Red Hat 9 (Shrike). Thank you. -- Being schizophrenic is better than living alone. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: ??? ?? ??? ?????? ?? ?????????? ???????? URL: From jkeating at j2solutions.net Fri Feb 10 00:39:08 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 09 Feb 2006 16:39:08 -0800 Subject: crazy thought about how to ease QA testing Message-ID: <1139531948.3490.3.camel@ender> So I'm kicking around this idea to help w/ QA testing. What if Fedora Legacy provided very base images of the releases we support for use with vmplayer? Vmplayer is free, and from the base image a QA tester could update to the package we need QA on, use the package in various ways, and report how it worked out. No need to have a full system of that release, no bad effects to your running system, just a nice test environment to run a few smoke tests on it. Thoughts? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jimpop at yahoo.com Fri Feb 10 01:49:50 2006 From: jimpop at yahoo.com (Jim Popovitch) Date: Thu, 09 Feb 2006 20:49:50 -0500 Subject: crazy thought about how to ease QA testing In-Reply-To: <1139531948.3490.3.camel@ender> References: <1139531948.3490.3.camel@ender> Message-ID: <43EBF13E.3060600@yahoo.com> Jesse Keating wrote: > So I'm kicking around this idea to help w/ QA testing. What if Fedora > Legacy provided very base images of the releases we support for use with > vmplayer? Vmplayer is free, and from the base image a QA tester could > update to the package we need QA on, use the package in various ways, > and report how it worked out. No need to have a full system of that > release, no bad effects to your running system, just a nice test > environment to run a few smoke tests on it. > > Thoughts? That is the exact way that I Q&A 7.3 stuff. I have VM images that are near mirrors of production systems. I d/l and test 7.3 updates on the VMs before pushing them out to production. It doesn't take much to produce a VM to distribute to others for testing purposes. HOWEVER the IP addressing might present some setup issues for novices, and bandwidth necessary to download the images would be quite high. Further Thoughts? -Jim P. From i.wells at ntlworld.com Fri Feb 10 07:13:25 2006 From: i.wells at ntlworld.com (Ian Wells) Date: Fri, 10 Feb 2006 07:13:25 -0000 Subject: crazy thought about how to ease QA testing References: <1139531948.3490.3.camel@ender> <43EBF13E.3060600@yahoo.com> Message-ID: <005801c62e11$7c540280$1500a8c0@eddie> >> So I'm kicking around this idea to help w/ QA testing. What if Fedora >> Legacy provided very base images of the releases we support for use with >> vmplayer? > That is the exact way that I Q&A 7.3 stuff. I have VM images that are > near mirrors of production systems. I d/l and test 7.3 updates on the VMs > before pushing them out to production. It doesn't take much to produce a > VM to distribute to others for testing purposes. HOWEVER the IP > addressing might present some setup issues for novices, and bandwidth > necessary to download the images would be quite high. I think that this would be a very good idea - I already use this to QA other updates. Ian From pekkas at netcore.fi Fri Feb 10 15:54:32 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 10 Feb 2006 17:54:32 +0200 (EET) Subject: crazy thought about how to ease QA testing In-Reply-To: <1139531948.3490.3.camel@ender> References: <1139531948.3490.3.camel@ender> Message-ID: On Thu, 9 Feb 2006, Jesse Keating wrote: > So I'm kicking around this idea to help w/ QA testing. What if Fedora > Legacy provided very base images of the releases we support for use with > vmplayer? Vmplayer is free, and from the base image a QA tester could > update to the package we need QA on, use the package in various ways, > and report how it worked out. No need to have a full system of that > release, no bad effects to your running system, just a nice test > environment to run a few smoke tests on it. This could reduce the amount of folks saying "but I don't even have [distro] in question!" but I fear it would morph into "so, why exactly should I bother installing a vmplay of [distro]?" For the already hardcore-QA'ers (very few in number), this could help, but I think the root problem is that there isn't enough help even for the FL distro versions that the people are actually running. So, instead of adding more hoops ("please, install a virtual image of all the other distros and do verify testing etc. there"), most focus should be put on making participation easier. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From jkeating at j2solutions.net Fri Feb 10 17:19:27 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 10 Feb 2006 09:19:27 -0800 Subject: crazy thought about how to ease QA testing In-Reply-To: References: <1139531948.3490.3.camel@ender> Message-ID: <1139591967.2892.11.camel@ender> On Fri, 2006-02-10 at 17:54 +0200, Pekka Savola wrote: > So, instead of adding more hoops ("please, install a virtual image of > all the other distros and do verify testing etc. there"), most focus > should be put on making participation easier. I am trying to make it easier. I'm trying to make it so that people don't have to use their production systems as package fodder for our QA process. I'm trying to make it so that those that really care about one release and do the work for one release can easily do the work for another release w/out having to support yet another system. Just run a program anywhere that is convenient. I am really opposed to any kind of automated testing that boils down to 'it installed here, guess it is good to go'. I want human interaction on the packages, so I'm trying to make that human interaction easier. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mike.mccarty at sbcglobal.net Fri Feb 10 17:39:45 2006 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Fri, 10 Feb 2006 11:39:45 -0600 Subject: crazy thought about how to ease QA testing In-Reply-To: <1139591967.2892.11.camel@ender> References: <1139531948.3490.3.camel@ender> <1139591967.2892.11.camel@ender> Message-ID: <43ECCFE1.7090702@sbcglobal.net> Jesse Keating wrote: > On Fri, 2006-02-10 at 17:54 +0200, Pekka Savola wrote: > >>So, instead of adding more hoops ("please, install a virtual image of >>all the other distros and do verify testing etc. there"), most focus >>should be put on making participation easier. > > > I am trying to make it easier. I'm trying to make it so that people > don't have to use their production systems as package fodder for our QA That's the primary reason I haven't volunteered for testing for FC2. I have an FC2 machine which I don't want to clobber. Isn't that the *reason* Legacy exists? We don't want to clobber our machines. > process. I'm trying to make it so that those that really care about one > release and do the work for one release can easily do the work for > another release w/out having to support yet another system. Just run a > program anywhere that is convenient. > > I am really opposed to any kind of automated testing that boils down to > 'it installed here, guess it is good to go'. I want human interaction > on the packages, so I'm trying to make that human interaction easier. Engineer: Look, it booted, and the "In Service" light turned green! Manager: Ship it! Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From jimpop at yahoo.com Fri Feb 10 17:42:39 2006 From: jimpop at yahoo.com (Jim Popovitch) Date: Fri, 10 Feb 2006 12:42:39 -0500 Subject: crazy thought about how to ease QA testing In-Reply-To: <1139591967.2892.11.camel@ender> References: <1139531948.3490.3.camel@ender> <1139591967.2892.11.camel@ender> Message-ID: <43ECD08F.4080308@yahoo.com> Jesse Keating wrote: > On Fri, 2006-02-10 at 17:54 +0200, Pekka Savola wrote: >> So, instead of adding more hoops ("please, install a virtual image of >> all the other distros and do verify testing etc. there"), most focus >> should be put on making participation easier. > > I am trying to make it easier. I'm trying to make it so that people > don't have to use their production systems as package fodder for our QA > process. I'm trying to make it so that those that really care about one > release and do the work for one release can easily do the work for > another release w/out having to support yet another system. Just run a > program anywhere that is convenient. > > I am really opposed to any kind of automated testing that boils down to > 'it installed here, guess it is good to go'. I want human interaction > on the packages, so I'm trying to make that human interaction easier. > I have to agree with Jesse, there is no way automated testing will work. There are just too many differing issues from patch to patch. Jesse, Is there a way FL can beg/borrow/steal a somewhat beefy central host to run VMWare Server. You could then control the server and VMWare install, yet you could provision and make available virtual testing systems that we could use to Q&A. Sort of like SF's compiler farm, although virtual. Testing X apps might prove a pain via an exported display (over SSH of course), but in those cases we could use vnc. Thoughts? -Jim P. From rostetter at mail.utexas.edu Fri Feb 10 19:02:29 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 10 Feb 2006 13:02:29 -0600 Subject: crazy thought about how to ease QA testing In-Reply-To: <1139591967.2892.11.camel@ender> References: <1139531948.3490.3.camel@ender> <1139591967.2892.11.camel@ender> Message-ID: <20060210130229.00bdge3cdhmsccok@mail.ph.utexas.edu> Quoting Jesse Keating : > On Fri, 2006-02-10 at 17:54 +0200, Pekka Savola wrote: >> So, instead of adding more hoops ("please, install a virtual image of >> all the other distros and do verify testing etc. there"), most focus >> should be put on making participation easier. > > I am trying to make it easier. I'm trying to make it so that people > don't have to use their production systems as package fodder for our QA > process. I'm trying to make it so that those that really care about one > release and do the work for one release can easily do the work for > another release w/out having to support yet another system. Just run a > program anywhere that is convenient. What would be great is if you could put something in the wiki about how to go about this. Some pointers to VM software that can be used and where to get them from. Some pointers on how to setup the VM systems, how to use them, etc. This would be useful docs for those who have never used a VM setup before. > I am really opposed to any kind of automated testing that boils down to > 'it installed here, guess it is good to go'. I want human interaction > on the packages, so I'm trying to make that human interaction easier. Yes, I agree that we need to have the software actually "used" and not just installed. But, I'm not against some forms of automation in the process. In fact, I used a standard template for my reports, which helps a lot. Providing some scripts to help automate steps is just the next logical step/progression from the template... -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From jkeating at j2solutions.net Fri Feb 10 19:08:41 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 10 Feb 2006 11:08:41 -0800 Subject: crazy thought about how to ease QA testing In-Reply-To: <20060210130229.00bdge3cdhmsccok@mail.ph.utexas.edu> References: <1139531948.3490.3.camel@ender> <1139591967.2892.11.camel@ender> <20060210130229.00bdge3cdhmsccok@mail.ph.utexas.edu> Message-ID: <1139598522.2892.48.camel@ender> On Fri, 2006-02-10 at 13:02 -0600, Eric Rostetter wrote: > > What would be great is if you could put something in the wiki about how > to go about this. Some pointers to VM software that can be used and > where to get them from. Some pointers on how to setup the VM systems, > how to use them, etc. This would be useful docs for those who have never > used a VM setup before. Absolutely. I'm trying to get some feedback on if this would be valuable, and if it is I'll be sure we fully document it. > > I am really opposed to any kind of automated testing that boils down to > > 'it installed here, guess it is good to go'. I want human interaction > > on the packages, so I'm trying to make that human interaction easier. > > Yes, I agree that we need to have the software actually "used" and not > just installed. But, I'm not against some forms of automation in the > process. In fact, I used a standard template for my reports, which helps > a lot. Providing some scripts to help automate steps is just the next > logical step/progression from the template... Yes, I can see some value in templates and such. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pekkas at netcore.fi Fri Feb 10 19:22:40 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 10 Feb 2006 21:22:40 +0200 (EET) Subject: crazy thought about how to ease QA testing In-Reply-To: <43ECCFE1.7090702@sbcglobal.net> References: <1139531948.3490.3.camel@ender> <1139591967.2892.11.camel@ender> <43ECCFE1.7090702@sbcglobal.net> Message-ID: On Fri, 10 Feb 2006, Mike McCarty wrote: > Jesse Keating wrote: >> On Fri, 2006-02-10 at 17:54 +0200, Pekka Savola wrote: >> >>> So, instead of adding more hoops ("please, install a virtual image of all >>> the other distros and do verify testing etc. there"), most focus should be >>> put on making participation easier. >> >> >> I am trying to make it easier. I'm trying to make it so that people >> don't have to use their production systems as package fodder for our QA > > That's the primary reason I haven't volunteered for testing for FC2. > I have an FC2 machine which I don't want to clobber. Isn't that > the *reason* Legacy exists? We don't want to clobber our machines. I'd suspect most folks should have dozens if not hundreds of systems running, and are willing to experiment with a couple of them (or have a couple of experimental boxes set aside) in order to get the tested updates shipped to the rest of the systems once the updates have been approved. Jim Popovitch wrote: > I have to agree with Jesse, there is no way automated testing will > work. There are just too many differing issues from patch to patch. Jim, you're probably missing the fact that VERIFY QA doesn't include the steps "test if the patch worked; test if the vulnerability is fixed". While some folks do perform more rigorous testing, it's not required, and for a good reason. Which one is better, not shipping any updates at all (or after months and months of delays), or shipping "looks good" updates quickly and fixing them (if issues come up) even faster? Aiming for perfection doesn't cut it. Contrary to common beliefs, FL doesn't have the resources for thorough testing that some vendors have the luxury of. That's why we employ those vendors' fixes directly :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From agibson at ptm.com Fri Feb 10 20:30:48 2006 From: agibson at ptm.com (Adam Gibson) Date: Fri, 10 Feb 2006 15:30:48 -0500 Subject: crazy thought about how to ease QA testing In-Reply-To: <1139531948.3490.3.camel@ender> References: <1139531948.3490.3.camel@ender> Message-ID: <43ECF7F8.2060104@ptm.com> Jesse Keating wrote: > So I'm kicking around this idea to help w/ QA testing. What if Fedora > Legacy provided very base images of the releases we support for use with > vmplayer? Vmplayer is free, and from the base image a QA tester could > update to the package we need QA on, use the package in various ways, > and report how it worked out. No need to have a full system of that > release, no bad effects to your running system, just a nice test > environment to run a few smoke tests on it. I would be cautious about recommending people use vmware for QAing Fedora Legacy packages. For some applications that would work but sometimes having different hardware can cause bugs to show up where under a vm system where all systems look the same hardware wise it wouldn't. Diversity in hardware configurations is a good thing for QAing packages. From nils at lemonbit.nl Fri Feb 10 20:39:05 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Fri, 10 Feb 2006 21:39:05 +0100 Subject: crazy thought about how to ease QA testing In-Reply-To: References: <1139531948.3490.3.camel@ender> <1139591967.2892.11.camel@ender> <43ECCFE1.7090702@sbcglobal.net> Message-ID: Pekka Savola wrote: >> That's the primary reason I haven't volunteered for testing for FC2. >> I have an FC2 machine which I don't want to clobber. Isn't that >> the *reason* Legacy exists? We don't want to clobber our machines. > > I'd suspect most folks should have dozens if not hundreds of > systems running, and are willing to experiment with a couple of > them (or have a couple of experimental boxes set aside) in order to > get the tested updates shipped to the rest of the systems once the > updates have been approved. Well, I don't. I have FC4 on my workstation and plan on upgrading it to FC5 soon after it's released. However I have couple of servers running FC2 and FC3, though no 'spare machines' for testing. If I could QA legacy packages on my workstation using some sort of VM solution (which wouldn't take a rocket scientist to setup) I'd be happy to help. Nils. From jimpop at yahoo.com Fri Feb 10 20:44:03 2006 From: jimpop at yahoo.com (Jim Popovitch) Date: Fri, 10 Feb 2006 15:44:03 -0500 Subject: crazy thought about how to ease QA testing In-Reply-To: References: <1139531948.3490.3.camel@ender> <1139591967.2892.11.camel@ender> <43ECCFE1.7090702@sbcglobal.net> Message-ID: <43ECFB13.6080403@yahoo.com> Pekka Savola wrote: > Jim Popovitch wrote: >> I have to agree with Jesse, there is no way automated testing will >> work. There are just too many differing issues from patch to patch. > > Jim, you're probably missing the fact that VERIFY QA doesn't include the > steps "test if the patch worked; test if the vulnerability is fixed". > While some folks do perform more rigorous testing, it's not required, > and for a good reason. Pekka, ;-) You are probably missing the fact that I rigorously test the patches that affect the platform and rpms that I use (which may be less than what others use). > Which one is better, not shipping any updates at all (or after months > and months of delays), or shipping "looks good" updates quickly and > fixing them (if issues come up) even faster? I wholeheartedly agree with your "release in 2 weeks, even if not tested" stance, as this *does* get the fix into the hands of people in a timely fashion. I also think that the critical fixes (ssh/kernel/httpd/etc) get plenty of attention and testing before release. X11, Mozilla, Fonts, etc., can all fail after upgrade and everyone still be safe, IMHO. > Aiming for perfection doesn't cut it. Exactly! Microsoft taught us that. ;-) > Contrary to common beliefs, FL > doesn't have the resources for thorough testing that some vendors have > the luxury of. That's why we employ those vendors' fixes directly :-) > From Axel.Thimm at ATrpms.net Fri Feb 10 21:23:52 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 10 Feb 2006 22:23:52 +0100 Subject: crazy thought about how to ease QA testing In-Reply-To: <1139531948.3490.3.camel@ender> References: <1139531948.3490.3.camel@ender> Message-ID: <20060210212352.GD15243@neu.nirvana> On Thu, Feb 09, 2006 at 04:39:08PM -0800, Jesse Keating wrote: > So I'm kicking around this idea to help w/ QA testing. What if Fedora > Legacy provided very base images of the releases we support for use with > vmplayer? Vmplayer is free, and from the base image a QA tester could > update to the package we need QA on, use the package in various ways, > and report how it worked out. No need to have a full system of that > release, no bad effects to your running system, just a nice test > environment to run a few smoke tests on it. > > Thoughts? Technically this is a very good idea, but there may be clashes between "Fedora's goals" as a strict open source solution. It could be food for discussions similar to "kernel uses propriatary version control system". I'm not against using closed source stuff, I'm shipping closed source but otherwise distributable nvidia drivers and Intel/HP/3ware stuff at ATrpms myself, but there will be talk about this, and justifying this decision internally and externally may consume more energy than this step would profit. Maybe an unofficial HOWTO on how to setup a vmware host is the best? No official endorsement of non open source parts, and testers still have a receipe on how to do their QA on virtual machines. -- 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 jkeating at j2solutions.net Fri Feb 10 22:10:35 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 10 Feb 2006 14:10:35 -0800 Subject: crazy thought about how to ease QA testing In-Reply-To: <43ECF7F8.2060104@ptm.com> References: <1139531948.3490.3.camel@ender> <43ECF7F8.2060104@ptm.com> Message-ID: <1139609435.2892.52.camel@ender> On Fri, 2006-02-10 at 15:30 -0500, Adam Gibson wrote: > > I would be cautious about recommending people use vmware for QAing > Fedora Legacy packages. For some applications that would work but > sometimes having different hardware can cause bugs to show up where > under a vm system where all systems look the same hardware wise it > wouldn't. Diversity in hardware configurations is a good thing for > QAing packages. I agree too. However some testing on like hardware is much better than no testing on disparate hardware. Those that have full blown systems to QA with, I urge them to continue. This is to help those that don't have the spare systems to play with. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rostetter at mail.utexas.edu Fri Feb 10 22:43:33 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 10 Feb 2006 16:43:33 -0600 Subject: crazy thought about how to ease QA testing In-Reply-To: <20060210212352.GD15243@neu.nirvana> References: <1139531948.3490.3.camel@ender> <20060210212352.GD15243@neu.nirvana> Message-ID: <20060210164333.j2k0o26gpxo8w4w8@mail.ph.utexas.edu> Quoting Axel Thimm : > On Thu, Feb 09, 2006 at 04:39:08PM -0800, Jesse Keating wrote: >> So I'm kicking around this idea to help w/ QA testing. What if Fedora >> Legacy provided very base images of the releases we support for use with >> vmplayer? Vmplayer is free, and from the base image a QA tester could >> update to the package we need QA on, use the package in various ways, >> and report how it worked out. No need to have a full system of that >> release, no bad effects to your running system, just a nice test >> environment to run a few smoke tests on it. >> >> Thoughts? > > Technically this is a very good idea, but there may be clashes between > "Fedora's goals" as a strict open source solution. It could be food > for discussions similar to "kernel uses propriatary version control > system". I don't think so, as we would not be either distributing or requiring any non-open solution. We're just making it easier for people who are using a VM system, open or not, to do QA. There are open VM projects also, so we could always try that route, if they check out. > Maybe an unofficial HOWTO on how to setup a vmware host is the best? Yes. The only thing we need to distribute is an OS to run in it, not the actual VM software. Instructions on using it with various VM products would be most useful. > No official endorsement of non open source parts, and testers still > have a receipe on how to do their QA on virtual machines. Yes, sounds good. My understanding of Jesse's e-mail was we were providing just an image, not a "virtual machine image". If I'm wrong, then I would understand your concern. I guess maybe Jesse can clarify what he meant by "image". > -- > Axel.Thimm at ATrpms.net -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From jkeating at j2solutions.net Fri Feb 10 22:59:54 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 10 Feb 2006 14:59:54 -0800 Subject: crazy thought about how to ease QA testing In-Reply-To: <20060210164333.j2k0o26gpxo8w4w8@mail.ph.utexas.edu> References: <1139531948.3490.3.camel@ender> <20060210212352.GD15243@neu.nirvana> <20060210164333.j2k0o26gpxo8w4w8@mail.ph.utexas.edu> Message-ID: <1139612394.2892.63.camel@ender> On Fri, 2006-02-10 at 16:43 -0600, Eric Rostetter wrote: > I don't think so, as we would not be either distributing or requiring > any non-open solution. We're just making it easier for people who > are using a VM system, open or not, to do QA. Well, the image would be vmware (vmplayer) specific. But since that is free to the public we aren't breaking any laws or asking people to. > There are open VM projects also, so we could always try that route, > if they check out. Unfortunately most the open ones like Xen or qemu require some heavy changes to the client OS which just isn't going to happen for RHL or early FC. FC5 and later can use anaconda to install into a Xen session, so when we pick up those Xen can easily be used to test stuff, just not yet. > > Maybe an unofficial HOWTO on how to setup a vmware host is the best? > > Yes. The only thing we need to distribute is an OS to run in it, not > the actual VM software. Instructions on using it with various VM > products would be most useful. > > > No official endorsement of non open source parts, and testers still > > have a receipe on how to do their QA on virtual machines. > > Yes, sounds good. > > My understanding of Jesse's e-mail was we were providing just an image, not > a "virtual machine image". If I'm wrong, then I would understand your > concern. I guess maybe Jesse can clarify what he meant by "image". In this case, the image would be the file that vmplayer software can use. I don't think the image file would be useful to any other software. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From smooge at gmail.com Sat Feb 11 00:28:33 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Fri, 10 Feb 2006 17:28:33 -0700 Subject: crazy thought about how to ease QA testing In-Reply-To: <1139612394.2892.63.camel@ender> References: <1139531948.3490.3.camel@ender> <20060210212352.GD15243@neu.nirvana> <20060210164333.j2k0o26gpxo8w4w8@mail.ph.utexas.edu> <1139612394.2892.63.camel@ender> Message-ID: <80d7e4090602101628y402b50eaif203dc019db125da@mail.gmail.com> On 2/10/06, Jesse Keating wrote: > On Fri, 2006-02-10 at 16:43 -0600, Eric Rostetter wrote: > > I don't think so, as we would not be either distributing or requiring > > any non-open solution. We're just making it easier for people who > > are using a VM system, open or not, to do QA. > > Well, the image would be vmware (vmplayer) specific. But since that is > free to the public we aren't breaking any laws or asking people to. I think the issue is Free(Libre) and free (Beer). The usual arguments apply. -- Stephen J Smoogen. CSIRT/Linux System Administrator From jkeating at j2solutions.net Sat Feb 11 00:35:14 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 10 Feb 2006 16:35:14 -0800 Subject: crazy thought about how to ease QA testing In-Reply-To: <80d7e4090602101628y402b50eaif203dc019db125da@mail.gmail.com> References: <1139531948.3490.3.camel@ender> <20060210212352.GD15243@neu.nirvana> <20060210164333.j2k0o26gpxo8w4w8@mail.ph.utexas.edu> <1139612394.2892.63.camel@ender> <80d7e4090602101628y402b50eaif203dc019db125da@mail.gmail.com> Message-ID: <1139618115.2892.70.camel@ender> On Fri, 2006-02-10 at 17:28 -0700, Stephen J. Smoogen wrote: > > Well, the image would be vmware (vmplayer) specific. But since that is > > free to the public we aren't breaking any laws or asking people to. > > I think the issue is Free(Libre) and free (Beer). The usual arguments apply. > Agreed. I'm not crazy enough to think I'm going to catch some flack for pushing this forward. However it is one of those necessity things. I just want to gage end user response before I don the flame suite and start talking to the Foundation. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwan at digitalhermit.com Sat Feb 11 01:22:42 2006 From: kwan at digitalhermit.com (Kwan Lowe) Date: Fri, 10 Feb 2006 20:22:42 -0500 (EST) Subject: Self Introduction Message-ID: <51796.192.168.8.28.1139620962.squirrel@digitalhermit.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 1. Name: Kwan Lowe 2. Location: Pembroke Pines, FL USA 3. Profession: Unix Engineer 4. Company: Royal Caribbean Cruises, Digital Hermit Solutions 5. Goals: QA for FC1 6. Qualifications: I've not worked on any open projects of note, though I have done so professionally at other software companies. My strengths are in systems administration, scripting and documentation. I currently maintain the TLDP Kernel Rebuild Guide and am familiar with the RPM build process. 7. GPG KEYID and fingerprint: pub 1024D/2822B8B4 2006-02-11 Kwan Lowe (Digital Hermit) Key fingerprint = 258D 59B0 CC14 9E34 D7E3 068D C6AF 3949 2822 B8B4 sub 1024g/B078811B 2006-02-11 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFD7TrOxq85SSgiuLQRAiQuAKChIoHnJ+RMdpns/OehmBdrS4nEqQCff7kO 51mrvz2pAR1ib6c5jUi9UoY= =kEym -----END PGP SIGNATURE----- -- * The Digital Hermit http://www.digitalhermit.com * Unix and Linux Solutions kwan at digitalhermit.com From xiaodong_luo78 at sina.com Thu Feb 9 14:40:44 2006 From: xiaodong_luo78 at sina.com (=?GB2312?B?wt7P/ras?=) Date: Thu, 9 Feb 2006 22:40:44 +0800 Subject: Is there any update for bind of RH9? Message-ID: <20060209142436.77DB41089FE@smtp.sina.com.cn> Hello everyone! Is there any update for bind-9.2.1-16.i386.rpm of RH9? After I install this rpm package, I type "service named start".It works well.But when I type "service named stop",it doesn't stop.The process of named is still alived. Can I use yum to update the package ,or is there any way to solve this question? Thanks for your answer. ???????? ???????? ????????xiaodong_luo78 at sina.com ??????????2006-02-09 From lists at benjamindsmith.com Sat Feb 11 02:39:13 2006 From: lists at benjamindsmith.com (Benjamin Smith) Date: Fri, 10 Feb 2006 18:39:13 -0800 Subject: crazy thought about how to ease QA testing In-Reply-To: References: <1139531948.3490.3.camel@ender> <43ECCFE1.7090702@sbcglobal.net> Message-ID: <200602101839.14206.lists@benjamindsmith.com> On Friday 10 February 2006 11:22, Pekka Savola wrote: > Jim, you're probably missing the fact that VERIFY QA doesn't include > the steps "test if the patch worked; test if the vulnerability is > fixed". While some folks do perform more rigorous testing, it's not > required, and for a good reason. > > Which one is better, not shipping any updates at all (or after months > and months of delays), or shipping "looks good" updates quickly and > fixing them (if issues come up) even faster? > > Aiming for perfection doesn't cut it. Contrary to common beliefs, FL > doesn't have the resources for thorough testing that some vendors have > the luxury of. That's why we employ those vendors' fixes directly :-) It may come as no surprise (given my past threads on creating tools to make it easier to report testing results, I'm with Pekka on this one. Updates are getting delayed because nobody's bothering to test them. It's a hassle. We all have day jobs. Yatta yatta. We need to make it as easy as possible. If you want more testing on critical packages, I'd suggest giving a testing package a certain number of points needed before it's ready for release. Important packages (eg: kernel) might need more testing than lesser important ones. (EG: Mozilla) Let's say that we give different levels of validation, 1 or 2 points for "installed ok", 3-4 points for "ran several key commands in the package and it worked out, 10 points for "tested the vuln fixed and it worked out". A single negative report ("-1, it didn't work out") would kill the package for release. If a package gathers enough points for release, then it's released. Packages that are critical (EG: Kernel) would either get installed in a large number of machines without any negative reports, (meaning, it's probably OK) or get extensively tested on a smaller number of hosts by tough, dedicated admins. Either way, automating this reporting process would: 1) Make it easier to do testing, and 2) Provide more extensive testing of a kernel than Mozilla. Jesse, what do you think of this idea? > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > -- "The best way to predict the future is to invent it." - XEROX PARC slogan, circa 1978 From jkeating at j2solutions.net Sat Feb 11 02:48:57 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 10 Feb 2006 18:48:57 -0800 Subject: crazy thought about how to ease QA testing In-Reply-To: <200602101839.14206.lists@benjamindsmith.com> References: <1139531948.3490.3.camel@ender> <43ECCFE1.7090702@sbcglobal.net> <200602101839.14206.lists@benjamindsmith.com> Message-ID: <1139626137.31644.3.camel@ender> On Fri, 2006-02-10 at 18:39 -0800, Benjamin Smith wrote: > > Either way, automating this reporting process would: > 1) Make it easier to do testing, and > 2) Provide more extensive testing of a kernel than Mozilla. > > Jesse, what do you think of this idea? This makes it even more complicated. points? how many are enough? What makes one package more critical than another? How ambiguous could this be? The issue here is that we need to lower the bar for folks to test on other platforms than what they are using. Continue to get quality human testing on more packages on more releases. If we can't get a human to look at a package, then we shouldn't be releasing it. If we can't get enough humans looking at enough packages for a given release, we need to drop the release. We dropped 7.2 and 8.0 for these reasons. FC1 is next on my chopping block for when we pick up FC4 (and chopping FC2 at the same time). -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rostetter at mail.utexas.edu Sat Feb 11 02:59:08 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 10 Feb 2006 20:59:08 -0600 Subject: crazy thought about how to ease QA testing In-Reply-To: <1139612394.2892.63.camel@ender> References: <1139531948.3490.3.camel@ender> <20060210212352.GD15243@neu.nirvana> <20060210164333.j2k0o26gpxo8w4w8@mail.ph.utexas.edu> <1139612394.2892.63.camel@ender> Message-ID: <20060210205908.1cdra1c9m3ggss0c@mail.ph.utexas.edu> Quoting Jesse Keating : > On Fri, 2006-02-10 at 16:43 -0600, Eric Rostetter wrote: >> I don't think so, as we would not be either distributing or requiring >> any non-open solution. We're just making it easier for people who >> are using a VM system, open or not, to do QA. > > Well, the image would be vmware (vmplayer) specific. But since that is > free to the public we aren't breaking any laws or asking people to. The first thing the advisories all say is to make sure you've installed all other updates before installing the latest update(s). Since I doubt we would keep the VM image up-to-date, we'd have to assume the user will do so... As such, is there really a big advantage to providing a base image? Also, if this is a "minimum" system image, then many updates won't install due to dependencies, and again would it really be worth it? I'd rather see a full install myself, that can be kept updated, for the QA. > In this case, the image would be the file that vmplayer software can > use. I don't think the image file would be useful to any other > software. As I've never used vmplayer, and hence never set it up, how much work/effort does this really save over doing it manually using _good_ instructions? I guess that is the part I'm missing... -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From rostetter at mail.utexas.edu Sat Feb 11 03:15:51 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 10 Feb 2006 21:15:51 -0600 Subject: Self Introduction In-Reply-To: <51796.192.168.8.28.1139620962.squirrel@digitalhermit.com> References: <51796.192.168.8.28.1139620962.squirrel@digitalhermit.com> Message-ID: <20060210211551.3f4gez8wyjccco4g@mail.ph.utexas.edu> Quoting Kwan Lowe : > 1. Name: Kwan Lowe Welcome! > 5. Goals: QA for FC1 Cool, we need that! > 6. Qualifications: > I've not worked on any open projects of note, though I have done so > professionally at other software companies. My strengths are in > systems administration, scripting and documentation. I currently > maintain the TLDP Kernel Rebuild Guide and am familiar with > the RPM build process. Could use help with documentation if you'd like to help... Just let me (or the list) know. Thanks for the introduction! -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From rostetter at mail.utexas.edu Sat Feb 11 03:26:46 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 10 Feb 2006 21:26:46 -0600 Subject: Is there any update for bind of RH9? In-Reply-To: <20060209142436.77DB41089FE@smtp.sina.com.cn> References: <20060209142436.77DB41089FE@smtp.sina.com.cn> Message-ID: <20060210212646.flzk25fnxlc8kckw@mail.ph.utexas.edu> Quoting ??? : > Hello everyone! > > Is there any update for bind-9.2.1-16.i386.rpm of RH9? No. > After I install this rpm package, I type "service named start".It > works well.But when I type "service named stop",it doesn't stop.The > process of named is still alived. Have you updated the kernel? See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=89548 > Can I use yum to update the package ,or is there any way to solve > this question? It probably isn't a bind bug, but a kernel bug, or other bug. > > Thanks for your answer. > ???????? > > > ???????? > ????????xiaodong_luo78 at sina.com > ??????????2006-02-09 -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From donjr at maner.org Sat Feb 11 03:52:07 2006 From: donjr at maner.org (Donald Maner) Date: Fri, 10 Feb 2006 21:52:07 -0600 Subject: Self Introduction #2: Donald Maner Message-ID: Hello, everyone. This is my second introduction. I lost my previous key, and the job has been preventing me from participating after my first initial attempt. I'd like to start again, espically since I have access to a nice beefy VMware ESX server. 1. Name: Donald E. Maner, Jr. 2. Location: McKinney, Texas, USA 3. Profession: Systems Admin 4. Company: Personal work, not company sponsored 5. Goals: QA, QA, QA. I plan to do all the QA that I can for the supported versions. VMWare comes in handy. 6. Qualifications: RedHat Certified Engineer. That's about it, this is my first real participation in any community project. 7. pub 1024D/9CE7DA52 2006-02-11 Donald Maner Key fingerprint = 9DAC 6B6C DAB8 D3CD 6FE7 91B0 A713 0F28 9CE7 DA52 sub 1024g/21881B61 2006-02-11 [expires: 2007-02-11] From rostetter at mail.utexas.edu Sat Feb 11 04:50:36 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 10 Feb 2006 22:50:36 -0600 Subject: Self Introduction #2: Donald Maner In-Reply-To: References: Message-ID: <20060210225036.cr0b5ckkc1c8cw40@mail.ph.utexas.edu> Quoting Donald Maner : > Hello, everyone. This is my second introduction. I lost my previous > key, and the job has been preventing me from participating after my > first initial attempt. I'd like to start again, espically since I have > access to a nice beefy VMware ESX server. Welcome back! We'd appecriate any QA you can do to help out. > 2. Location: McKinney, Texas, USA If you're ever in the Austin area feel free to look me up ;) -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From pekkas at netcore.fi Sat Feb 11 05:32:09 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 11 Feb 2006 07:32:09 +0200 (EET) Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <1139626137.31644.3.camel@ender> References: <1139531948.3490.3.camel@ender> <43ECCFE1.7090702@sbcglobal.net> <200602101839.14206.lists@benjamindsmith.com> <1139626137.31644.3.camel@ender> Message-ID: On Fri, 10 Feb 2006, Jesse Keating wrote: > This makes it even more complicated. points? how many are enough? > What makes one package more critical than another? How ambiguous could > this be? I agree that this would complicate the process further. I have proposed something simpler, and still do: 1) every package, even without any VERIFY QA votes at all, will be released automatically in X weeks (suggest: X=2). exception: at package PUBLISH time, the packager and/or publisher, if they think the changes are major enough (e.g., non-QAed patches etc.), they can specify that the package should not be automatically released. 2) negative reports block automatic publishing. 3) positive reports can speed up automatic publishing (for example: 2 VERIFY votes --> released within 1 week, all verify votes: released immediately after the last verify) There is no need (IMHO) to grade packages to more or less critical ones. Every QA tester and eventual package user uses his or her own value judgment. If (s)he fears that the (potentially untested) automatic update would break the system, (s)he would test it before two weeks are over. Publishing positive reports can be made simpler but that probably isn't on the critical path here. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From jkeating at j2solutions.net Sat Feb 11 06:00:07 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 10 Feb 2006 22:00:07 -0800 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: References: <1139531948.3490.3.camel@ender> <43ECCFE1.7090702@sbcglobal.net> <200602101839.14206.lists@benjamindsmith.com> <1139626137.31644.3.camel@ender> Message-ID: <1139637608.31644.5.camel@ender> On Sat, 2006-02-11 at 07:32 +0200, Pekka Savola wrote: > > I agree that this would complicate the process further. > > I have proposed something simpler, and still do: > > 1) every package, even without any VERIFY QA votes at all, will be > released automatically in X weeks (suggest: X=2). > > exception: at package PUBLISH time, the packager and/or publisher, > if they think the changes are major enough (e.g., non-QAed patches > etc.), they can specify that the package should not be > automatically released. > > 2) negative reports block automatic publishing. > > 3) positive reports can speed up automatic publishing (for example: 2 > VERIFY votes --> released within 1 week, all verify votes: > released immediately after the last verify) > > There is no need (IMHO) to grade packages to more or less critical > ones. Every QA tester and eventual package user uses his or her own > value judgment. If (s)he fears that the (potentially untested) > automatic update would break the system, (s)he would test it before > two weeks are over. > > Publishing positive reports can be made simpler but that probably > isn't on the critical path here. Reluctantly I can agree to this. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at j2solutions.net Sat Feb 11 06:03:44 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 10 Feb 2006 22:03:44 -0800 Subject: crazy thought about how to ease QA testing In-Reply-To: <20060210205908.1cdra1c9m3ggss0c@mail.ph.utexas.edu> References: <1139531948.3490.3.camel@ender> <20060210212352.GD15243@neu.nirvana> <20060210164333.j2k0o26gpxo8w4w8@mail.ph.utexas.edu> <1139612394.2892.63.camel@ender> <20060210205908.1cdra1c9m3ggss0c@mail.ph.utexas.edu> Message-ID: <1139637824.31644.10.camel@ender> On Fri, 2006-02-10 at 20:59 -0600, Eric Rostetter wrote: > The first thing the advisories all say is to make sure you've installed > all other updates before installing the latest update(s). Since I doubt > we would keep the VM image up-to-date, we'd have to assume the user will > do so... As such, is there really a big advantage to providing a base > image? Also, if this is a "minimum" system image, then many updates > won't install due to dependencies, and again would it really be worth > it? Creating the base install in the first place is somewhat time consuming. Turning it on, issuing yum update, and then running a given package, that's not so difficult. The packages people would be testing would be in updates-testing repository so deps would be autoresolved. > I'd rather see a full install myself, that can be kept updated, for the > QA. That's something we probably can't provide, image would be way too big, and maint to keep the image updated would be too much. > > In this case, the image would be the file that vmplayer software can > > use. I don't think the image file would be useful to any other > > software. > > As I've never used vmplayer, and hence never set it up, how much > work/effort does this really save over doing it manually using > _good_ instructions? I guess that is the part I'm missing... It provides you a virtual machine in which to test. Not a full piece of hardware or a life server. It is a throw away system. People can 'roll back' to the base image we provide as a known good stable controlled starting point. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From lists at benjamindsmith.com Sat Feb 11 08:21:40 2006 From: lists at benjamindsmith.com (Benjamin Smith) Date: Sat, 11 Feb 2006 00:21:40 -0800 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: References: <1139531948.3490.3.camel@ender> <1139626137.31644.3.camel@ender> Message-ID: <200602110021.40574.lists@benjamindsmith.com> On Friday 10 February 2006 21:32, Pekka Savola wrote: > On Fri, 10 Feb 2006, Jesse Keating wrote: > > This makes it even more complicated. points? how many are enough? > > What makes one package more critical than another? How ambiguous could > > this be? > > I agree that this would complicate the process further. > > I have proposed something simpler, and still do: > > 1) every package, even without any VERIFY QA votes at all, will be > released automatically in X weeks (suggest: X=2). > > exception: at package PUBLISH time, the packager and/or publisher, > if they think the changes are major enough (e.g., non-QAed patches > etc.), they can specify that the package should not be > automatically released. > > 2) negative reports block automatic publishing. > > 3) positive reports can speed up automatic publishing (for example: 2 > VERIFY votes --> released within 1 week, all verify votes: > released immediately after the last verify) Pekka, I've proposed (1, 2) before... That's why I've moved my last remaining FC1 systems to testing - I've just not had problems with the updates, and I'd rather run a secure but occasionally unstable system than an insecure but "stable" one. Oh, and I've had ZERO problems with stability... -Ben -- "The best way to predict the future is to invent it." - XEROX PARC slogan, circa 1978 From Axel.Thimm at ATrpms.net Sat Feb 11 10:30:57 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 11 Feb 2006 11:30:57 +0100 Subject: Pruning old vendor update packages? In-Reply-To: <20060204165738.GG15286@neu.nirvana> References: <20051023150617.GE15406@neu.nirvana> <1098559128.28454.66.camel@yoda.loki.me> <20051023203747.GH15406@neu.nirvana> <20060204165738.GG15286@neu.nirvana> Message-ID: <20060211103057.GB32023@neu.nirvana> Ping! My mirror just hit the ceiling. Why isn't something happening? It is just adding the --delete option to rsync, or to use the list I sent a week ago. I reported this over and over again, it's very frustrating. I now have to add includes/excludes to the rsync to my mirror, as such I'm no 100% mirror anymore. On Sat, Feb 04, 2006 at 05:57:38PM +0100, Axel Thimm wrote: > My mirror is hitting the ceiling in the FL mount, and I still see 2 > 1/2 GB of such slack space. Would it help if I mail a list of the > packages to be deleted? > > Just to make it clear: I'm referring to old updates that were > obsoleted during RH's maintenance, e.g. which do not exist on > redhat.com anymore, because RH ships a newer one in its updates > folder. Last time I suggested this someone though that I was referring > to vendor packages that had been superceeded by FL, that's not the > case! > > Thanks! > > On Sun, Oct 23, 2005 at 10:37:47PM +0200, Axel Thimm wrote: > > On Sat, Oct 23, 2004 at 12:18:48PM -0700, Jesse Keating wrote: > > > On Sun, 2005-10-23 at 17:06 +0200, Axel Thimm wrote: > > > > fedoralegacy.org does not remove old update packages. These make > 3GB > > > > for Fedora releases. > > > > > > > > Could that be fixed? Mirrors would be grateful, and the use of such > > > > before-EOL-obsoleted packages is very small. > > > > > > Yes, I'm working w/ Red Hat on this one. Currently the Yum version on > > > the master server is not new enough to use the yum-utils package. > > > > Thanks! Why do you need yum-utils? Doesn't rsync --delete do the job? -- 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 jimpop at yahoo.com Sat Feb 11 12:59:54 2006 From: jimpop at yahoo.com (Jim Popovitch) Date: Sat, 11 Feb 2006 07:59:54 -0500 Subject: Pruning old vendor update packages? In-Reply-To: <20060211103057.GB32023@neu.nirvana> References: <20051023150617.GE15406@neu.nirvana> <1098559128.28454.66.camel@yoda.loki.me> <20051023203747.GH15406@neu.nirvana> <20060204165738.GG15286@neu.nirvana> <20060211103057.GB32023@neu.nirvana> Message-ID: <43EDDFCA.600@yahoo.com> Axel Thimm wrote: > Ping! > > My mirror just hit the ceiling. Why isn't something happening? It is > just adding the --delete option to rsync, or to use the list I sent a > week ago. I reported this over and over again, it's very frustrating. How large is the partition holding all the files? What rsync command are you using to sync your mirror? -Jim P. > > I now have to add includes/excludes to the rsync to my mirror, as such > I'm no 100% mirror anymore. > > On Sat, Feb 04, 2006 at 05:57:38PM +0100, Axel Thimm wrote: >> My mirror is hitting the ceiling in the FL mount, and I still see 2 >> 1/2 GB of such slack space. Would it help if I mail a list of the >> packages to be deleted? >> >> Just to make it clear: I'm referring to old updates that were >> obsoleted during RH's maintenance, e.g. which do not exist on >> redhat.com anymore, because RH ships a newer one in its updates >> folder. Last time I suggested this someone though that I was referring >> to vendor packages that had been superceeded by FL, that's not the >> case! >> >> Thanks! >> >> On Sun, Oct 23, 2005 at 10:37:47PM +0200, Axel Thimm wrote: >>> On Sat, Oct 23, 2004 at 12:18:48PM -0700, Jesse Keating wrote: >>>> On Sun, 2005-10-23 at 17:06 +0200, Axel Thimm wrote: >>>>> fedoralegacy.org does not remove old update packages. These make > 3GB >>>>> for Fedora releases. >>>>> >>>>> Could that be fixed? Mirrors would be grateful, and the use of such >>>>> before-EOL-obsoleted packages is very small. >>>> Yes, I'm working w/ Red Hat on this one. Currently the Yum version on >>>> the master server is not new enough to use the yum-utils package. >>> Thanks! Why do you need yum-utils? Doesn't rsync --delete do the job? >>> >>> ------------------------------------------------------------------------ >>> >>> -- >>> fedora-legacy-list mailing list >>> fedora-legacy-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-legacy-list From marcdeslauriers at videotron.ca Sat Feb 11 14:58:28 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sat, 11 Feb 2006 09:58:28 -0500 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <1139637608.31644.5.camel@ender> References: <1139531948.3490.3.camel@ender> <43ECCFE1.7090702@sbcglobal.net> <200602101839.14206.lists@benjamindsmith.com> <1139626137.31644.3.camel@ender> <1139637608.31644.5.camel@ender> Message-ID: <1139669908.20848.11.camel@mdlinux> On Fri, 2006-02-10 at 22:00 -0800, Jesse Keating wrote: > On Sat, 2006-02-11 at 07:32 +0200, Pekka Savola wrote: > > > > I agree that this would complicate the process further. > > > > I have proposed something simpler, and still do: > > > > 1) every package, even without any VERIFY QA votes at all, will be > > released automatically in X weeks (suggest: X=2). > > > > exception: at package PUBLISH time, the packager and/or publisher, > > if they think the changes are major enough (e.g., non-QAed patches > > etc.), they can specify that the package should not be > > automatically released. > > > > 2) negative reports block automatic publishing. > > > > 3) positive reports can speed up automatic publishing (for example: 2 > > VERIFY votes --> released within 1 week, all verify votes: > > released immediately after the last verify) > > > > There is no need (IMHO) to grade packages to more or less critical > > ones. Every QA tester and eventual package user uses his or her own > > value judgment. If (s)he fears that the (potentially untested) > > automatic update would break the system, (s)he would test it before > > two weeks are over. > > > > Publishing positive reports can be made simpler but that probably > > isn't on the critical path here. I agree to this. Marc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sheltren at cs.ucsb.edu Sat Feb 11 15:13:16 2006 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Sat, 11 Feb 2006 11:13:16 -0400 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: References: <1139531948.3490.3.camel@ender> <43ECCFE1.7090702@sbcglobal.net> <200602101839.14206.lists@benjamindsmith.com> <1139626137.31644.3.camel@ender> Message-ID: On Feb 11, 2006, at 1:32 AM, Pekka Savola wrote: > > I agree that this would complicate the process further. > > I have proposed something simpler, and still do: > > 1) every package, even without any VERIFY QA votes at all, will be > released automatically in X weeks (suggest: X=2). > > exception: at package PUBLISH time, the packager and/or publisher, > if they think the changes are major enough (e.g., non-QAed patches > etc.), they can specify that the package should not be > automatically released. > > 2) negative reports block automatic publishing. > > 3) positive reports can speed up automatic publishing (for example: 2 > VERIFY votes --> released within 1 week, all verify votes: > released immediately after the last verify) > > There is no need (IMHO) to grade packages to more or less critical > ones. Every QA tester and eventual package user uses his or her > own value judgment. If (s)he fears that the (potentially untested) > automatic update would break the system, (s)he would test it before > two weeks are over. > > Publishing positive reports can be made simpler but that probably > isn't on the critical path here. > I think this is a good idea, and I'd like to add something to it: What I'd like to see is to have something like this (Pekka's idea above) happen for regular package contributors (people that have submitted multiple packages to FL). People that haven't submitted many packages should require one of the trusted packagers/builders to do a "publish" QA before pushing the package to testing. Since the current state of things is that it's only a small group of people doing things, this won't really affect anyone at the moment- but it's just a way to ease new packagers in while being sure that they are submitting "good" packages. Fedora Extras does something similar: Once a packager gets "approved" to package something, they are able to push updates to that package without any formal QA at all. Of course, all changes to the package are sent out to an email list which is monitored by all (well, most of) the packagers, so there is some passive QA going on. All this would be easier to setup once FL is using a CVS setup to track package changes, but in the meantime I vote for something along the lines of what Pekka suggested. -Jeff From Axel.Thimm at ATrpms.net Sat Feb 11 15:48:38 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 11 Feb 2006 16:48:38 +0100 Subject: Pruning old vendor update packages? In-Reply-To: <43EDDFCA.600@yahoo.com> References: <20051023150617.GE15406@neu.nirvana> <1098559128.28454.66.camel@yoda.loki.me> <20051023203747.GH15406@neu.nirvana> <20060204165738.GG15286@neu.nirvana> <20060211103057.GB32023@neu.nirvana> <43EDDFCA.600@yahoo.com> Message-ID: <20060211154838.GA3743@neu.nirvana> On Sat, Feb 11, 2006 at 07:59:54AM -0500, Jim Popovitch wrote: > Axel Thimm wrote: > >Ping! > > > >My mirror just hit the ceiling. Why isn't something happening? It is > >just adding the --delete option to rsync, or to use the list I sent a > >week ago. I reported this over and over again, it's very frustrating. > > How large is the partition holding all the files? What rsync command > are you using to sync your mirror? What difference does it make what rsync command *I* am using? The --delete option I suggested to use is for syncing the master of downloads.fedoralagacy.org against downloads.fedora.redhat.org to get rid of the obsoleted 2.5GB, this hasn't anything to do with the rsync process master to mirrors (although these should have --delete anyway, but that's off-topic). Anyway, I'm now excluding these 2.5GB from downloading while praying that my rsync scripts are still catching fedora legacy content. > -Jim P. > > > > >I now have to add includes/excludes to the rsync to my mirror, as such > >I'm no 100% mirror anymore. > > > >On Sat, Feb 04, 2006 at 05:57:38PM +0100, Axel Thimm wrote: > >>My mirror is hitting the ceiling in the FL mount, and I still see 2 > >>1/2 GB of such slack space. Would it help if I mail a list of the > >>packages to be deleted? > >> > >>Just to make it clear: I'm referring to old updates that were > >>obsoleted during RH's maintenance, e.g. which do not exist on > >>redhat.com anymore, because RH ships a newer one in its updates > >>folder. Last time I suggested this someone though that I was referring > >>to vendor packages that had been superceeded by FL, that's not the > >>case! > >> > >>Thanks! > >> > >>On Sun, Oct 23, 2005 at 10:37:47PM +0200, Axel Thimm wrote: > >>>On Sat, Oct 23, 2004 at 12:18:48PM -0700, Jesse Keating wrote: > >>>>On Sun, 2005-10-23 at 17:06 +0200, Axel Thimm wrote: > >>>>>fedoralegacy.org does not remove old update packages. These make > 3GB > >>>>>for Fedora releases. > >>>>> > >>>>>Could that be fixed? Mirrors would be grateful, and the use of such > >>>>>before-EOL-obsoleted packages is very small. > >>>>Yes, I'm working w/ Red Hat on this one. Currently the Yum version on > >>>>the master server is not new enough to use the yum-utils package. > >>>Thanks! Why do you need yum-utils? Doesn't rsync --delete do the job? > >>> > >>> > -- 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 jkeating at j2solutions.net Sat Feb 11 16:30:25 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 11 Feb 2006 08:30:25 -0800 Subject: Pruning old vendor update packages? In-Reply-To: <20060211103057.GB32023@neu.nirvana> References: <20051023150617.GE15406@neu.nirvana> <1098559128.28454.66.camel@yoda.loki.me> <20051023203747.GH15406@neu.nirvana> <20060204165738.GG15286@neu.nirvana> <20060211103057.GB32023@neu.nirvana> Message-ID: <1139675426.31644.24.camel@ender> On Sat, 2006-02-11 at 11:30 +0100, Axel Thimm wrote: > My mirror just hit the ceiling. Why isn't something happening? It is > just adding the --delete option to rsync, or to use the list I sent a > week ago. I reported this over and over again, it's very frustrating. > > I now have to add includes/excludes to the rsync to my mirror, as such > I'm no 100% mirror anymore. > I've been working near 24/7 at Red Hat this past week trying to accomplish some full rebuilds for Test3. I haven't had but a bare moment to concentrate on Legacy issues, and that time is stolen away by trying to evaluate and test using plague/mock instead of our existing build system. This item is on my list to do, just not as high priority as some other things. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jimpop at yahoo.com Sat Feb 11 17:24:49 2006 From: jimpop at yahoo.com (Jim Popovitch) Date: Sat, 11 Feb 2006 12:24:49 -0500 Subject: Pruning old vendor update packages? In-Reply-To: <20060211154838.GA3743@neu.nirvana> References: <20051023150617.GE15406@neu.nirvana> <1098559128.28454.66.camel@yoda.loki.me> <20051023203747.GH15406@neu.nirvana> <20060204165738.GG15286@neu.nirvana> <20060211103057.GB32023@neu.nirvana> <43EDDFCA.600@yahoo.com> <20060211154838.GA3743@neu.nirvana> Message-ID: <43EE1DE1.2000500@yahoo.com> Axel Thimm wrote: > On Sat, Feb 11, 2006 at 07:59:54AM -0500, Jim Popovitch wrote: >> Axel Thimm wrote: >>> Ping! >>> >>> My mirror just hit the ceiling. Why isn't something happening? It is >>> just adding the --delete option to rsync, or to use the list I sent a >>> week ago. I reported this over and over again, it's very frustrating. >> How large is the partition holding all the files? What rsync command >> are you using to sync your mirror? > > What difference does it make what rsync command *I* am using? well, because you are the one complaining about this. ;-) Sorry for the question, I misunderstood the problem as being *yours* not someone else's. I am all for keeping the mirrors clean and tidy. -Jim P. > The --delete option I suggested to use is for syncing the master of > downloads.fedoralagacy.org against downloads.fedora.redhat.org to get > rid of the obsoleted 2.5GB, this hasn't anything to do with the rsync > process master to mirrors (although these should have --delete anyway, > but that's off-topic). > > Anyway, I'm now excluding these 2.5GB from downloading while praying > that my rsync scripts are still catching fedora legacy content. From marcdeslauriers at videotron.ca Sat Feb 11 16:42:46 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sat, 11 Feb 2006 11:42:46 -0500 Subject: [UPDATED] Fedora Legacy Test Update Notification: httpd Message-ID: <43EE1406.5040206@videotron.ca> This notification was updated to include x86_64 packages for Fedora Core 3. --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-175406 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175406 2006-02-11 --------------------------------------------------------------------- Name : httpd Versions : rh73: apache-1.3.27-9.legacy Versions : rh9: httpd-2.0.40-21.21.legacy Versions : fc1: httpd-2.0.51-1.10.legacy Versions : fc2: httpd-2.0.51-2.9.5.legacy Versions : fc3: httpd-2.0.53-3.4.legacy Summary : The httpd Web server Description : This package contains a powerful, full-featured, efficient, and freely-available Web server based on work done by the Apache Software Foundation. It is also the most popular Web server on the Internet. --------------------------------------------------------------------- Update Information: Updated Apache httpd packages that correct three security issues are now available. The Apache HTTP Server is a popular and freely-available Web server. A memory leak in the worker MPM could allow remote attackers to cause a denial of service (memory consumption) via aborted connections, which prevents the memory for the transaction pool from being reused for other connections. The Common Vulnerabilities and Exposures project assigned the name CVE-2005-2970 to this issue. This vulnerability only affects users who are using the non-default worker MPM. A flaw in mod_imap when using the Referer directive with image maps was discovered. With certain site configurations, a remote attacker could perform a cross-site scripting attack if a victim can be forced to visit a malicious URL using certain web browsers. (CVE-2005-3352) A NULL pointer dereference flaw in mod_ssl was discovered affecting server configurations where an SSL virtual host is configured with access control and a custom 400 error document. A remote attacker could send a carefully crafted request to trigger this issue which would lead to a crash. This crash would only be a denial of service if using the non-default worker MPM. (CVE-2005-3357) Users of httpd should update to these erratum packages which contain backported patches to correct these issues. --------------------------------------------------------------------- Changelogs rh73: * Sun Jan 22 2006 Marc Deslauriers 1.3.27-9.legacy - mod_imap: add security fix for XSS issue (CVE-2005-3352) rh9: * Sun Jan 22 2006 Marc Deslauriers 2.0.40-21.21.legacy - mod_ssl: add security fix for HTTP-on-SSL-port handling (CVE-2005-3357) - mod_imap: add security fix for XSS issue (CVE-2005-3352) - worker MPM: add security fix for memory consumption DoS (CVE-2005-2970), and bug fixes for handling resource allocation failures (#171759) fc1: * Sun Jan 22 2006 Marc Deslauriers 2.0.51-1.10.legacy - mod_ssl: add security fix for HTTP-on-SSL-port handling (CVE-2005-3357) - mod_imap: add security fix for XSS issue (CVE-2005-3352) - worker MPM: add security fix for memory consumption DoS (CVE-2005-2970), and bug fixes for handling resource allocation failures (#171759) fc2: * Sun Jan 22 2006 Marc Deslauriers 2.0.51-2.9.5.legacy - mod_ssl: add security fix for HTTP-on-SSL-port handling (CVE-2005-3357) - mod_imap: add security fix for XSS issue (CVE-2005-3352) - worker MPM: add security fix for memory consumption DoS (CVE-2005-2970), and bug fixes for handling resource allocation failures (#171759) fc3: * Sun Jan 22 2006 Marc Deslauriers 2.0.53-3.4.legacy - mod_ssl: add security fix for HTTP-on-SSL-port handling (CVE-2005-3357) - mod_imap: add security fix for XSS issue (CVE-2005-3352) - worker MPM: add security fix for memory consumption DoS (CVE-2005-2970), and bug fixes for handling resource allocation failures (#171759) --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: c55d929dd5acbf4b0191a28b0ad128f1064810f8 redhat/7.3/updates-testing/i386/apache-1.3.27-9.legacy.i386.rpm aae52f7966d03dd6e81f8b8b5a090bf60fa8e601 redhat/7.3/updates-testing/i386/apache-devel-1.3.27-9.legacy.i386.rpm fafcea3e68311223b5a814a482927cd645c4356a redhat/7.3/updates-testing/i386/apache-manual-1.3.27-9.legacy.i386.rpm db23f5e77a78f78a346104038a564f0197ee9414 redhat/7.3/updates-testing/SRPMS/apache-1.3.27-9.legacy.src.rpm rh9: 8e6ca52b5fb88a43322a38966ffeb0285b0699e1 redhat/9/updates-testing/i386/httpd-2.0.40-21.21.legacy.i386.rpm be601feefd0483b24e3ce5efdfadcef6b5d7d040 redhat/9/updates-testing/i386/httpd-devel-2.0.40-21.21.legacy.i386.rpm 8816478ae2287a3d2d4c9ca91d55662efcae2b87 redhat/9/updates-testing/i386/httpd-manual-2.0.40-21.21.legacy.i386.rpm 2d565db0d6fa0756c51ca7aef8211b463c5f5348 redhat/9/updates-testing/i386/mod_ssl-2.0.40-21.21.legacy.i386.rpm e05115a5178fbf853dfe8fdc75b962c44a787316 redhat/9/updates-testing/SRPMS/httpd-2.0.40-21.21.legacy.src.rpm fc1: d34d8993fa09ebc2c017c98ac459688a913593f6 fedora/1/updates-testing/i386/httpd-2.0.51-1.10.legacy.i386.rpm 1598bdf136a0ab14195df7d9f4425ab6442ab3f7 fedora/1/updates-testing/i386/httpd-devel-2.0.51-1.10.legacy.i386.rpm e5d6b42924b9fd81869cbe07f410abd2ecaa106e fedora/1/updates-testing/i386/httpd-manual-2.0.51-1.10.legacy.i386.rpm 56c59eec43c7d87f9f59f7068f80e2774de1784a fedora/1/updates-testing/i386/mod_ssl-2.0.51-1.10.legacy.i386.rpm 4294e34c392cc90465d35dbfda88f95aae87c291 fedora/1/updates-testing/SRPMS/httpd-2.0.51-1.10.legacy.src.rpm fc2: 3572be6a040d0efe5e71186578b42bb991328254 fedora/2/updates-testing/i386/httpd-2.0.51-2.9.5.legacy.i386.rpm 3d75ef3d7720894c886c4d1a1e52f97f2b4bb345 fedora/2/updates-testing/i386/httpd-devel-2.0.51-2.9.5.legacy.i386.rpm 74c6d5286da4daf697f041d3084cab0a2fda46c6 fedora/2/updates-testing/i386/httpd-manual-2.0.51-2.9.5.legacy.i386.rpm 72050bf7341db26b0d72b8565102bb55eb9be250 fedora/2/updates-testing/i386/mod_ssl-2.0.51-2.9.5.legacy.i386.rpm 32a2bfe031fcbb40ed1db4a84bacc5ad78a7b7a4 fedora/2/updates-testing/SRPMS/httpd-2.0.51-2.9.5.legacy.src.rpm fc3: 563dd27fb0e74e13d1b8960e189f05af60926333 fedora/3/updates-testing/i386/httpd-2.0.53-3.4.legacy.i386.rpm 3673bec7d02bd1972c20cbca6d77bccf4c08f516 fedora/3/updates-testing/i386/httpd-devel-2.0.53-3.4.legacy.i386.rpm d004815e520338f6565e0f18d21847c6439c841f fedora/3/updates-testing/i386/httpd-manual-2.0.53-3.4.legacy.i386.rpm 48eac837da227883d681aa23e182ebb00174980f fedora/3/updates-testing/i386/httpd-suexec-2.0.53-3.4.legacy.i386.rpm ffdb283132cdf0e0de7026709087781a4f2eabb0 fedora/3/updates-testing/i386/mod_ssl-2.0.53-3.4.legacy.i386.rpm dcf460eadeb704d54a807058d63e69c8a62b49b5 fedora/3/updates-testing/x86_64/httpd-2.0.53-3.4.legacy.x86_64.rpm eaa6dd54a8b8ad5165f8643ef4e34eef83f587b6 fedora/3/updates-testing/x86_64/httpd-devel-2.0.53-3.4.legacy.x86_64.rpm 088d7acc09d35b63a9a5278575d2797f5202d811 fedora/3/updates-testing/x86_64/httpd-manual-2.0.53-3.4.legacy.x86_64.rpm 332a9afb589537e33d895685bd145230834e77d1 fedora/3/updates-testing/x86_64/httpd-suexec-2.0.53-3.4.legacy.x86_64.rpm 85c1f146a3f8e9af3ad44b5467cfebfb18eeaee5 fedora/3/updates-testing/x86_64/mod_ssl-2.0.53-3.4.legacy.x86_64.rpm b6698d717f8dd6b028ee32184bcc778724695a83 fedora/3/updates-testing/SRPMS/httpd-2.0.53-3.4.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Sat Feb 11 16:43:15 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sat, 11 Feb 2006 11:43:15 -0500 Subject: Fedora Legacy Test Update Notification: nfs-utils Message-ID: <43EE1423.10600@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-138098 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138098 2006-02-11 --------------------------------------------------------------------- Name : nfs-utils Versions : rh7.3: nfs-utils-0.3.3-6.73.2.legacy Versions : rh9: nfs-utils-1.0.1-3.9.2.legacy Versions : fc1: nfs-utils-1.0.6-1.2.legacy Versions : fc2: nfs-utils-1.0.6-22.2.legacy Summary : NFS utilities and supporting daemons for the kernel NFS server. Description : The nfs-utils package provides a daemon for the kernel NFS server and related tools, providing a much higher level of performance than the traditional Linux NFS server used by most users. This package also contains the showmount program. Showmount queries the mount daemon on a remote host for information about the NFS (Network File System) server on the remote host. --------------------------------------------------------------------- Update Information: An updated nfs-utils package that fixes security issues is now available. The nfs-utils package provides a daemon for the kernel NFS server and related tools, providing a much higher level of performance than the traditional Linux NFS server used by most users. Arjan van de Ven discovered a buffer overflow in rquotad. On 64-bit architectures, an improper integer conversion can lead to a buffer overflow. An attacker with access to an NFS share could send a specially crafted request which could lead to the execution of arbitrary code. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0946 to this issue. In addition, the Fedora Core 2 update fixes the following issue: SGI reported that the statd daemon did not properly handle the SIGPIPE signal. A misconfigured or malicious peer could cause statd to crash, leading to a denial of service. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-1014 to this issue. All users of nfs-utils should upgrade to this updated package, which resolves these issues. --------------------------------------------------------------------- Changelogs rh73: * Mon Nov 14 2005 Jeff Sheltren 0.3.3-6.73.2.legacy - Patch for CVE-2004-0946, rquotad buffer overflow (#138098) rh9: * Mon Nov 14 2005 Jeff Sheltren 1.0.1-3.9.2.legacy - Patch for CVE-2004-0946, rquotad buffer overflow (#138098) fc1: * Mon Nov 14 2005 Jeff Sheltren 1.0.6-1.2.legacy - Patch for CVE-2004-0946, rquotad buffer overflow (#138098) fc2: * Wed Nov 16 2005 Jeff Sheltren 1.0.6-22.2.legacy - Add patch for CVE-2004-1014, sigpipe DOS (#138098, #152871) * Mon Nov 14 2005 Jeff Sheltren 1.0.6-22.1.legacy - Patch for CVE-2004-0946, rquotad buffer overflow (#138098) --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh7.3: fc563f70e9f2b5eeafb51b9444469689185ef504 redhat/7.3/updates-testing/i386/nfs-utils-0.3.3-6.73.2.legacy.i386.rpm 79dd718df766c23fc8ab4880a0e1557ca990c181 redhat/7.3/updates-testing/SRPMS/nfs-utils-0.3.3-6.73.2.legacy.src.rpm rh9: 45c4f3a310d3090271f0d0798cae1e3148ab8299 redhat/9/updates-testing/i386/nfs-utils-1.0.1-3.9.2.legacy.i386.rpm bf009c4fe075b7105316084c6ca577f15c5bdb52 redhat/9/updates-testing/SRPMS/nfs-utils-1.0.1-3.9.2.legacy.src.rpm fc1: 1c96ae93420683ad79b675b205ecb5d6ddb61ef4 fedora/1/updates-testing/i386/nfs-utils-1.0.6-1.2.legacy.i386.rpm 6d4ee9e13e8b3bf1278d59b48ccb0c48f7645f7f fedora/1/updates-testing/SRPMS/nfs-utils-1.0.6-1.2.legacy.src.rpm fc2: 2063735e17273d7967c8fa1f3649ab86921c910e fedora/2/updates-testing/i386/nfs-utils-1.0.6-22.2.legacy.i386.rpm dc3207c089204dd1c47653dc4918fe45b81a8654 fedora/2/updates-testing/SRPMS/nfs-utils-1.0.6-22.2.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Sat Feb 11 16:43:41 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sat, 11 Feb 2006 11:43:41 -0500 Subject: Fedora Legacy Test Update Notification: openssh Message-ID: <43EE143D.3030102@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-168935 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168935 2006-02-10 --------------------------------------------------------------------- Name : openssh Versions : rh73: openssh-3.1p1-14.3.legacy Versions : rh9: openssh-3.5p1-11.4.legacy Versions : fc1: openssh-3.6.1p2-19.4.legacy Versions : fc2: openssh-3.6.1p2-34.4.legacy Versions : fc3: openssh-3.9p1-8.0.4.legacy Summary : The OpenSSH implementation of SSH protocol. Description : OpenSSH is OpenBSD's SSH (Secure SHell) protocol implementation. SSH replaces rlogin and rsh, to provide secure encrypted communications between two untrusted hosts over an insecure network. X11 connections and arbitrary TCP/IP ports can also be forwarded over the secure channel. Public key authentication may be used for "passwordless" access to servers. --------------------------------------------------------------------- Update Information: Updated openssh packages that fix security issues are now available. OpenSSH is OpenBSD's SSH (Secure SHell) protocol implementation. SSH replaces rlogin and rsh, and provides secure encrypted communications between two untrusted hosts over an insecure network. X11 connections and arbitrary TCP/IP ports can also be forwarded over a secure channel. Public key authentication can be used for "passwordless" access to servers. A bug was found in the way the OpenSSH server handled the MaxStartups and LoginGraceTime configuration variables. A malicious user could connect to the SSH daemon in such a way that it would prevent additional logins from occuring until the malicious connections are closed. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2004-2069 to this issue. The scp command was found to expose filenames twice to shell expansion. A malicious user could execute arbitrary commands by using specially crafted filenames containing shell metacharacters or spaces. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2006-0225 to this issue. Users of openssh should upgrade to these updated packages, which contain backported patches to resolve these issues. --------------------------------------------------------------------- Changelogs rh73: * Mon Jan 23 2006 Marc Deslauriers 3.1p1-14.3.legacy - use fork+exec instead of system in scp - CVE-2006-0225 rh9: * Mon Jan 23 2006 Marc Deslauriers 3.5p1-11.4.legacy - use fork+exec instead of system in scp - CVE-2006-0225 * Sun Jan 22 2006 Marc Deslauriers 3.5p1-11.3.legacy - CAN-2004-2069 - prevent DoS on openssh server fc1: * Mon Jan 23 2006 Marc Deslauriers 3.6.1p2-19.4.legacy - use fork+exec instead of system in scp - CVE-2006-0225 * Sun Jan 22 2006 Marc Deslauriers 3.6.1p1-19.3.legacy - CAN-2004-2069 - prevent DoS on openssh server fc2: * Mon Jan 23 2006 Marc Deslauriers 3.6.1p2-34.4.legacy - use fork+exec instead of system in scp - CVE-2006-0225 * Sun Jan 22 2006 Marc Deslauriers 3.6.1p2-34.3.legacy - CAN-2004-2069 - prevent DoS on openssh server fc3: * Mon Jan 23 2006 Marc Deslauriers 3.9p1-8.0.4.legacy - use fork+exec instead of system in scp - CVE-2006-0225 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 5c732eac2396d1dbc767c6706b936177b04e3ba9 redhat/7.3/updates-testing/i386/openssh-3.1p1-14.3.legacy.i386.rpm ac522209cbabd3638e8ca2b08bdf5453c1d9a8d4 redhat/7.3/updates-testing/i386/openssh-askpass-3.1p1-14.3.legacy.i386.rpm a79e45b1fd78f517a2dfb846e1814aeff35ab86d redhat/7.3/updates-testing/i386/openssh-askpass-gnome-3.1p1-14.3.legacy.i386.rpm daa5d5518e33835ef47f41f3bb379d9659e2bc3f redhat/7.3/updates-testing/i386/openssh-clients-3.1p1-14.3.legacy.i386.rpm 28d3e3a66e6c786db875c5ea8d629b6abcc7fe5b redhat/7.3/updates-testing/i386/openssh-server-3.1p1-14.3.legacy.i386.rpm d838db35baa90040dec9df7459af4682f8976b7a redhat/7.3/updates-testing/SRPMS/openssh-3.1p1-14.3.legacy.src.rpm rh9: 2e4da4da715512dccb420fc67f3bb24dae2d9a40 redhat/9/updates-testing/i386/openssh-3.5p1-11.4.legacy.i386.rpm af36bd2aa23d16986072cf15c6906add540f8b8a redhat/9/updates-testing/i386/openssh-askpass-3.5p1-11.4.legacy.i386.rpm 0cc2cf34bde4b876944c8f19c1cd58d9f4503757 redhat/9/updates-testing/i386/openssh-askpass-gnome-3.5p1-11.4.legacy.i386.rpm f0e967606a821ec50f6d0af708935a9f04b52d11 redhat/9/updates-testing/i386/openssh-clients-3.5p1-11.4.legacy.i386.rpm d49d40f814c95319dff11a49f8bb66dcdd3f808c redhat/9/updates-testing/i386/openssh-server-3.5p1-11.4.legacy.i386.rpm 38544ce3e39dbebcb15ce213f4aff9bf3edb93a7 redhat/9/updates-testing/SRPMS/openssh-3.5p1-11.4.legacy.src.rpm fc1: c962909e215becff41ab14353a0b1ef3f5a499fd fedora/1/updates-testing/i386/openssh-3.6.1p2-19.4.legacy.i386.rpm 61ca655031b498ba8c66a97f0792c4f9dbd0f795 fedora/1/updates-testing/i386/openssh-askpass-3.6.1p2-19.4.legacy.i386.rpm 0201fe8254733f85cde19e17911015c38ae6f8fa fedora/1/updates-testing/i386/openssh-askpass-gnome-3.6.1p2-19.4.legacy.i386.rpm 3818241e59db35fe61773f7e59d9d83fafd4b16a fedora/1/updates-testing/i386/openssh-clients-3.6.1p2-19.4.legacy.i386.rpm 202bec4605eaf6054433a170a6432a3d449862cb fedora/1/updates-testing/i386/openssh-server-3.6.1p2-19.4.legacy.i386.rpm e5b385dbba09ec63225c2eb25e22827d0e6fd789 fedora/1/updates-testing/SRPMS/openssh-3.6.1p2-19.4.legacy.src.rpm fc2: ca85182633a97ce1bb8c3bcb683d44242881703f fedora/2/updates-testing/i386/openssh-3.6.1p2-34.4.legacy.i386.rpm f49c8368fe790df101b671a368f0ff47fdc0fad3 fedora/2/updates-testing/i386/openssh-askpass-3.6.1p2-34.4.legacy.i386.rpm 281fe61d517ebff0a297cd4c6342c398debcd33f fedora/2/updates-testing/i386/openssh-askpass-gnome-3.6.1p2-34.4.legacy.i386.rpm d25c9ca4c55732cc3368587cfd6b4b7629c52ee8 fedora/2/updates-testing/i386/openssh-clients-3.6.1p2-34.4.legacy.i386.rpm ec570330a25c600803dd2f88ff140726a66d3c7e fedora/2/updates-testing/i386/openssh-server-3.6.1p2-34.4.legacy.i386.rpm 4bf28b7a7d7a9fad922b6a1e96a0433320cab26e fedora/2/updates-testing/SRPMS/openssh-3.6.1p2-34.4.legacy.src.rpm fc3: 75001fc461867ff3b5f608423de99b5c0d9705e6 fedora/3/updates-testing/i386/openssh-3.9p1-8.0.4.legacy.i386.rpm e4a4bfc7866e2ace0c9b0a0a3b4598e9594fd6ae fedora/3/updates-testing/i386/openssh-askpass-3.9p1-8.0.4.legacy.i386.rpm 4df1fe9ad8bfcdee35dcddbc9fb124e513718275 fedora/3/updates-testing/i386/openssh-askpass-gnome-3.9p1-8.0.4.legacy.i386.rpm f53b372fcab1724ac8a073aebc9b04718439c894 fedora/3/updates-testing/i386/openssh-clients-3.9p1-8.0.4.legacy.i386.rpm 8b800276ec20d03452cf1e39883315baa9c7a7df fedora/3/updates-testing/i386/openssh-server-3.9p1-8.0.4.legacy.i386.rpm 61a70c9f0cf6c152fb7f48c5857b5e002dc0527a fedora/3/updates-testing/x86_64/openssh-3.9p1-8.0.4.legacy.x86_64.rpm b8e38615db4f431c1e87204a0ecaefbabde2479b fedora/3/updates-testing/x86_64/openssh-askpass-3.9p1-8.0.4.legacy.x86_64.rpm 5cd606345fb8b3ba1f7c1d6f005d18c50d0886bd fedora/3/updates-testing/x86_64/openssh-askpass-gnome-3.9p1-8.0.4.legacy.x86_64.rpm db5f2a76871dc0e6987702a492ad84252a5211c4 fedora/3/updates-testing/x86_64/openssh-clients-3.9p1-8.0.4.legacy.x86_64.rpm 18f578efebdc634ee6ab363064f9ac8d81fa5cf0 fedora/3/updates-testing/x86_64/openssh-server-3.9p1-8.0.4.legacy.x86_64.rpm 8dc6ca866a0a5d0e2c01f4b898bbaa798399fa40 fedora/3/updates-testing/SRPMS/openssh-3.9p1-8.0.4.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From dick at dickmorrell.com Sat Feb 11 17:54:37 2006 From: dick at dickmorrell.com (Richard Morrell) Date: Sat, 11 Feb 2006 17:54:37 +0000 Subject: Self Introduction #3: Richard Morrell In-Reply-To: References: Message-ID: <43EE24DD.8040908@dickmorrell.com> As other people are doing this I thought I'd climb from the trench where I lurk reading the lists since day one and put my hand gingerly up. Name: Richard Morrell Location: UK Profession: VP of Security for some rather large Internet brands that will remain nameless Company: Four of Europes largest ISPs Goals: I test and smash to pieces Fedora packages during release and testing for use on my own networks and projects Qualifications: 10 yr Linux veteran, former Linuxcare and VA Linux stalwart (Sourceforge, Slashdot, clustering and HA, Security development blah blah). Founder and co-author SmoothWall Linux project and company of same name, currently working last two years on mail anti abuse technologies and Linux thin client development on embedded boxes (based entirely on Fedora). Sponsor of several OpenSource projects (Phlak, LocalAreaSecurity, M0n0wall). I'll retire to my slit trench and continue coding in quiet. -- This message has been scanned for viruses & dangerous content by MailScanner, and is believed to be clean. www.mailscanner.info / postmaster at morrellnet.com From marcdeslauriers at videotron.ca Sat Feb 11 17:54:22 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sat, 11 Feb 2006 12:54:22 -0500 Subject: Fedora Legacy Test Update Notification: mozilla Message-ID: <43EE24CE.9060708@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-180036-1 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180036 2006-02-11 --------------------------------------------------------------------- Name : mozilla Versions : rh7.3: mozilla-1.7.12-0.73.3.legacy Versions : rh9: mozilla-1.7.12-0.90.2.legacy Versions : fc1: mozilla-1.7.12-1.1.2.legacy Versions : fc2: mozilla-1.7.12-1.2.3.legacy Versions : fc3: mozilla-1.7.12-1.3.3.legacy Summary : A Web browser. Description : Mozilla is an open-source Web browser, designed for standards compliance, performance, and portability. --------------------------------------------------------------------- Update Information: Updated mozilla packages that fix several security bugs are now available. Mozilla is an open source Web browser, advanced email and newsgroup client, IRC chat client, and HTML editor. Igor Bukanov discovered a bug in the way Mozilla's Javascript interpreter dereferences objects. If a user visits a malicious web page, Mozilla could crash or execute arbitrary code as the user running Mozilla. The Common Vulnerabilities and Exposures project assigned the name CVE-2006-0292 to this issue. moz_bug_r_a4 discovered a bug in Mozilla's XULDocument.persist() function. A malicious web page could inject arbitrary RDF data into a user's localstore.rdf file, which can cause Mozilla to execute arbitrary javascript when a user runs Mozilla. (CVE-2006-0296) A denial of service bug was found in the way Mozilla saves history information. If a user visits a web page with a very long title, it is possible Mozilla will crash or take a very long time the next time it is run. (CVE-2005-4134) Users of Mozilla are advised to upgrade to these updated packages, which contain backported patches to correct these issues. --------------------------------------------------------------------- Changelogs rh7.3: * Sun Feb 05 2006 Marc Deslauriers 37:1.7.12-0.73.3.legacy - Fix CVE-2005-4134, CVE-2006-0292, CVE-2006-0296 rh9: * Mon Feb 06 2006 Marc Deslauriers 37:1.7.12-0.90.2.legacy - Fix CVE-2005-4134, CVE-2006-0292, CVE-2006-0296 fc1: * Sun Feb 05 2006 Marc Deslauriers 37:1.7.12-1.1.2.legacy - Fix CVE-2005-4134, CVE-2006-0292, CVE-2006-0296 fc2: * Fri Feb 10 2006 Marc Deslauriers 37:1.7.12-1.2.3.legacy - Added mozilla-nspr to BuildPrereq * Sun Feb 05 2006 Marc Deslauriers 37:1.7.12-1.2.2.legacy - Fix CVE-2005-4134, CVE-2006-0292, CVE-2006-0296 fc3: * Fri Feb 10 2006 Marc Deslauriers 37:1.7.12-1.3.3.legacy - Added mozilla-nspr, gnome-vfs2-devel, desktop-file-utils, and krb5-devel to BuildPrereq * Sun Feb 05 2006 Marc Deslauriers 37:1.7.12-1.3.2.legacy - Fix CVE-2005-4134, CVE-2006-0292, CVE-2006-0296 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh7.3: baf937574b92b01271c70169e5e6465eb7736c81 redhat/7.3/updates-testing/i386/mozilla-1.7.12-0.73.3.legacy.i386.rpm 4e401f2064201c290aa00527d148141904532d8a redhat/7.3/updates-testing/i386/mozilla-chat-1.7.12-0.73.3.legacy.i386.rpm d97acf0463781ac5600754b02b5a902125df5fd4 redhat/7.3/updates-testing/i386/mozilla-devel-1.7.12-0.73.3.legacy.i386.rpm 251eb4a2d0e0f8cf63b7b7975c9819a7e58fd5b3 redhat/7.3/updates-testing/i386/mozilla-dom-inspector-1.7.12-0.73.3.legacy.i386.rpm 584062b1c063fb8c2375693b49e48b8ae7530a00 redhat/7.3/updates-testing/i386/mozilla-js-debugger-1.7.12-0.73.3.legacy.i386.rpm aa3594680a3224f6b8b7abb9a6b9585fa6f519c1 redhat/7.3/updates-testing/i386/mozilla-mail-1.7.12-0.73.3.legacy.i386.rpm 1676c32cd8143b9ff939b45269b2423b50d062f1 redhat/7.3/updates-testing/i386/mozilla-nspr-1.7.12-0.73.3.legacy.i386.rpm 9d9d350082b38b94d45e458e02f3345b0a4e3ed0 redhat/7.3/updates-testing/i386/mozilla-nspr-devel-1.7.12-0.73.3.legacy.i386.rpm 33753a720edea798966550963426db05a409a6c4 redhat/7.3/updates-testing/i386/mozilla-nss-1.7.12-0.73.3.legacy.i386.rpm b17dec4e9eab3acca07dc0345d01fa522c3f43d8 redhat/7.3/updates-testing/i386/mozilla-nss-devel-1.7.12-0.73.3.legacy.i386.rpm 169c96bd3eae5e8f4220ed87291ceb176bf1f6b2 redhat/7.3/updates-testing/SRPMS/mozilla-1.7.12-0.73.3.legacy.src.rpm rh9: ffa6d9ff83d69b2aa32fb92a660775cbb92f2b53 redhat/9/updates-testing/i386/mozilla-1.7.12-0.90.2.legacy.i386.rpm d4bc650d1652ae30bb4df3037bcd1f9f77781774 redhat/9/updates-testing/i386/mozilla-chat-1.7.12-0.90.2.legacy.i386.rpm 0148688359ca6168c0c77160c8891315ac319147 redhat/9/updates-testing/i386/mozilla-devel-1.7.12-0.90.2.legacy.i386.rpm 2be970089280e3b23401402e5ea5019cc57b95ba redhat/9/updates-testing/i386/mozilla-dom-inspector-1.7.12-0.90.2.legacy.i386.rpm 653ceef20cbbd2d415ab8453b5c6d6e81193b6b3 redhat/9/updates-testing/i386/mozilla-js-debugger-1.7.12-0.90.2.legacy.i386.rpm 1c576446d6eef094adf576310d6fa773ee52259b redhat/9/updates-testing/i386/mozilla-mail-1.7.12-0.90.2.legacy.i386.rpm a2bf3a3f3cbf90a1d0f73bc3ecba5b3d48a8e151 redhat/9/updates-testing/i386/mozilla-nspr-1.7.12-0.90.2.legacy.i386.rpm 8eb53c3254fdbfcb78c229672a28c22d4ef0e4c7 redhat/9/updates-testing/i386/mozilla-nspr-devel-1.7.12-0.90.2.legacy.i386.rpm 4ca88669c7390d9181673af47c954512d6dd7eef redhat/9/updates-testing/i386/mozilla-nss-1.7.12-0.90.2.legacy.i386.rpm ccc8207ee4ee6dac6b23715884c011dd023acfb0 redhat/9/updates-testing/i386/mozilla-nss-devel-1.7.12-0.90.2.legacy.i386.rpm 9f0c42c95eee533f46cb69e9ca24983d598b7c19 redhat/9/updates-testing/SRPMS/mozilla-1.7.12-0.90.2.legacy.src.rpm fc1: ccc9f1f2f0a31d46cc69af0a7b3fc8279347c855 fedora/1/updates-testing/i386/mozilla-1.7.12-1.1.2.legacy.i386.rpm 22fb3e89d2484c03774aa28756082ad7fd68c9a9 fedora/1/updates-testing/i386/mozilla-chat-1.7.12-1.1.2.legacy.i386.rpm 971284c2c887c7de98cae3fc5fc48c542ff6934f fedora/1/updates-testing/i386/mozilla-devel-1.7.12-1.1.2.legacy.i386.rpm e7c1727896f18603d38ad40a6f209d19d3049f0a fedora/1/updates-testing/i386/mozilla-dom-inspector-1.7.12-1.1.2.legacy.i386.rpm 938aa693e2a7a499a33c6605cfa3a74e8673df27 fedora/1/updates-testing/i386/mozilla-js-debugger-1.7.12-1.1.2.legacy.i386.rpm d6a2a1f6974ab09ec1d02af7592e782c27f578e6 fedora/1/updates-testing/i386/mozilla-mail-1.7.12-1.1.2.legacy.i386.rpm 67cb0d096878aed78036e5ea0970f1147bf74d44 fedora/1/updates-testing/i386/mozilla-nspr-1.7.12-1.1.2.legacy.i386.rpm cd48424e01cfe88b1f438c932a673b97f2101704 fedora/1/updates-testing/i386/mozilla-nspr-devel-1.7.12-1.1.2.legacy.i386.rpm dd89685756cbe81a3928075f14310f58ce409af3 fedora/1/updates-testing/i386/mozilla-nss-1.7.12-1.1.2.legacy.i386.rpm e193799b982e920ebb932fcc06c49a5228f704f6 fedora/1/updates-testing/i386/mozilla-nss-devel-1.7.12-1.1.2.legacy.i386.rpm a07447de816fe5b143dd3f6a3476d3334e01576c fedora/1/updates-testing/SRPMS/mozilla-1.7.12-1.1.2.legacy.src.rpm fc2: f22f8ad6584a2e8ff16f52858181f145a27ad88e fedora/2/updates-testing/i386/mozilla-1.7.12-1.2.3.legacy.i386.rpm 9c1600eb0de0484a292b4b556b6e13d579cba87a fedora/2/updates-testing/i386/mozilla-chat-1.7.12-1.2.3.legacy.i386.rpm 86859e409dc365f5bec29d0a93b175ac0bcba1b7 fedora/2/updates-testing/i386/mozilla-devel-1.7.12-1.2.3.legacy.i386.rpm 2d9fccb410dc48ec08d16a34924db7be85b5270e fedora/2/updates-testing/i386/mozilla-dom-inspector-1.7.12-1.2.3.legacy.i386.rpm 089f2798d5a48d3dbff41b750c0fa263d3c084b2 fedora/2/updates-testing/i386/mozilla-js-debugger-1.7.12-1.2.3.legacy.i386.rpm 7f7cfb22bab08e5cafb4179ab400fb20f9f0e92d fedora/2/updates-testing/i386/mozilla-mail-1.7.12-1.2.3.legacy.i386.rpm 122072963825101d273120c4efc5e0b414d8363c fedora/2/updates-testing/i386/mozilla-nspr-1.7.12-1.2.3.legacy.i386.rpm 377d51c94a02e610a0085a3805a51d97896c56ed fedora/2/updates-testing/i386/mozilla-nspr-devel-1.7.12-1.2.3.legacy.i386.rpm 255a282fed707f6730d559e5e182e15db1a2c647 fedora/2/updates-testing/i386/mozilla-nss-1.7.12-1.2.3.legacy.i386.rpm 63f3f43a95d43c8d03a63a7d9914544d020e36af fedora/2/updates-testing/i386/mozilla-nss-devel-1.7.12-1.2.3.legacy.i386.rpm 3763ccd5bb56555376b15e3b6719addea3d72e94 fedora/2/updates-testing/SRPMS/mozilla-1.7.12-1.2.3.legacy.src.rpm fc3: 1dc7f066ff6b1edc46037b874c88871b92e689bd fedora/3/updates-testing/i386/mozilla-1.7.12-1.3.3.legacy.i386.rpm d42189ed08ecb23f10fa811233191da00a6d2b86 fedora/3/updates-testing/i386/mozilla-chat-1.7.12-1.3.3.legacy.i386.rpm 178fde65f593bfb2c97feef7a9368acd6a85e0a1 fedora/3/updates-testing/i386/mozilla-devel-1.7.12-1.3.3.legacy.i386.rpm 934df1335c0409c5d200d3afcf0c5d1bb619d7a0 fedora/3/updates-testing/i386/mozilla-dom-inspector-1.7.12-1.3.3.legacy.i386.rpm 44a98a9a93f06916e80028e436f3cb5a7e757403 fedora/3/updates-testing/i386/mozilla-js-debugger-1.7.12-1.3.3.legacy.i386.rpm d70a4a67cae1c047ddd515ff466cc3964dc21639 fedora/3/updates-testing/i386/mozilla-mail-1.7.12-1.3.3.legacy.i386.rpm 628cb7537726199cf5ecd459e7cbf2bb27acdca5 fedora/3/updates-testing/i386/mozilla-nspr-1.7.12-1.3.3.legacy.i386.rpm 6c4a6afd3c1b3538a1ab0f691af18b75ae910f0a fedora/3/updates-testing/i386/mozilla-nspr-devel-1.7.12-1.3.3.legacy.i386.rpm 6df7e4d99d0b5b0634eaf71816aff3a76308850c fedora/3/updates-testing/i386/mozilla-nss-1.7.12-1.3.3.legacy.i386.rpm 86a0ea171fa09f02a13307cfd742aa4d7669dbf3 fedora/3/updates-testing/i386/mozilla-nss-devel-1.7.12-1.3.3.legacy.i386.rpm cc1ee55af3e20e520347b8d54604c49a3a687a68 fedora/3/updates-testing/x86_64/mozilla-1.7.12-1.3.3.legacy.x86_64.rpm 2365e1dd78f64bfb6888e8a7c5ad16ce10a222f9 fedora/3/updates-testing/x86_64/mozilla-chat-1.7.12-1.3.3.legacy.x86_64.rpm 1dc8b590ba623365a07c33c8a98c5d6eb7057486 fedora/3/updates-testing/x86_64/mozilla-devel-1.7.12-1.3.3.legacy.x86_64.rpm abdf5d08629556a3335ad70eb565b65dbec226b3 fedora/3/updates-testing/x86_64/mozilla-dom-inspector-1.7.12-1.3.3.legacy.x86_64.rpm 3489b08fbbe7dab2e913c6c79c24296bc0ac0078 fedora/3/updates-testing/x86_64/mozilla-js-debugger-1.7.12-1.3.3.legacy.x86_64.rpm b544c2a6807963113eb2234ff3d846eb2c435661 fedora/3/updates-testing/x86_64/mozilla-mail-1.7.12-1.3.3.legacy.x86_64.rpm 628cb7537726199cf5ecd459e7cbf2bb27acdca5 fedora/3/updates-testing/x86_64/mozilla-nspr-1.7.12-1.3.3.legacy.i386.rpm 6cf873ef9085f915b38f2bc70f16adfcfa155bfd fedora/3/updates-testing/x86_64/mozilla-nspr-1.7.12-1.3.3.legacy.x86_64.rpm 5eb2b843489853ea7d395502c492383557d1d7ce fedora/3/updates-testing/x86_64/mozilla-nspr-devel-1.7.12-1.3.3.legacy.x86_64.rpm 6df7e4d99d0b5b0634eaf71816aff3a76308850c fedora/3/updates-testing/x86_64/mozilla-nss-1.7.12-1.3.3.legacy.i386.rpm f7c34c932da9b4f65f134123ee8b86af16c7667d fedora/3/updates-testing/x86_64/mozilla-nss-1.7.12-1.3.3.legacy.x86_64.rpm 5889b94be3ad690867bf59697b6d4704757d1402 fedora/3/updates-testing/x86_64/mozilla-nss-devel-1.7.12-1.3.3.legacy.x86_64.rpm c4051d635668658df5f1ce4df69becc721fb752a fedora/3/updates-testing/SRPMS/mozilla-1.7.12-1.3.3.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Sat Feb 11 17:55:01 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sat, 11 Feb 2006 12:55:01 -0500 Subject: Fedora Legacy Test Update Notification: firefox Message-ID: <43EE24F5.10805@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-180036-2 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180036 2006-02-11 --------------------------------------------------------------------- Name : firefox Versions : fc3: firefox-1.0.7-1.3.fc3.legacy Summary : Mozilla Firefox Web browser. Description : Mozilla Firefox is an open-source web browser, designed for standards compliance, performance and portability. --------------------------------------------------------------------- Update Information: An updated firefox package that fixes several security bugs is now available. Mozilla Firefox is an open-source web browser, designed for standards compliance, performance and portability. Igor Bukanov discovered a bug in the way Firefox's Javascript interpreter derefernces objects. If a user visits a malicious web page, Firefox could crash or execute arbitrary code as the user running Firefox. The Common Vulnerabilities and Exposures project assigned the name CVE-2006-0292 to this issue. moz_bug_r_a4 discovered a bug in Firefox's XULDocument.persist() function. A malicious web page could inject arbitrary RDF data into a user's localstore.rdf file, which can cause Firefox to execute arbitrary javascript when a user runs Firefox. (CVE-2006-0296) A denial of service bug was found in the way Firefox saves history information. If a user visits a web page with a very long title, it is possible Firefox will crash or take a very long time the next time it is run. (CVE-2005-4134) Users of Firefox are advised to upgrade to this updated package, which contains backported patches to correct these issues. --------------------------------------------------------------------- Changelogs fc3: * Sat Feb 11 2006 Marc Deslauriers 0:1.0.7-1.3.fc3.legacy - Added libbonobo-devel, GConf2-devel, libgnome-devel, popt to BuildRequires * Sun Feb 05 2006 Marc Deslauriers 0:1.0.7-1.2.fc3.legacy - Fix CVE-2005-4134, CVE-2006-0292, CVE-2006-0296 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) fc3: 3b05d93992aba7369a418d53344250aa275330ac fedora/3/updates-testing/i386/firefox-1.0.7-1.3.fc3.legacy.i386.rpm 850534b4cfa591372d8245808e46378c5923e086 fedora/3/updates-testing/x86_64/firefox-1.0.7-1.3.fc3.legacy.x86_64.rpm a167dc9061c484aa26f89703dc0228883409235e fedora/3/updates-testing/SRPMS/firefox-1.0.7-1.3.fc3.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From xiaodong_luo78 at sina.com Sat Feb 11 22:20:39 2006 From: xiaodong_luo78 at sina.com (=?gb2312?B?wt7P/ras?=) Date: Sun, 12 Feb 2006 06:20:39 +0800 Subject: Is there any update for bind of RH9? Message-ID: <20060211220420.DAE963B5A35@smtp.sina.com.cn> I have installed a new kernel.And command "rndc stop " works well now. thanks for your advice. >Quoting : > >> Hello everyone! >> >> Is there any update for bind-9.2.1-16.i386.rpm of RH9? > >No. > >> After I install this rpm package, I type "service named start".It >> works well.But when I type "service named stop",it doesn't stop.The >> process of named is still alived. > >Have you updated the kernel? See > >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=89548 > >> Can I use yum to update the package ,or is there any way to solve >> this question? > >It probably isn't a bind bug, but a kernel bug, or other bug. > >> >> Thanks for your answer. >> ???????? >> >> >> ???????? >> ????????xiaodong_luo78 at sina.com >> ??????????2006-02-09 > >-- >Eric Rostetter >The Department of Physics >The University of Texas at Austin > >Go Longhorns! > >-- >fedora-legacy-list mailing list >fedora-legacy-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-legacy-list = = = = = = = = = = = = = = = = = = = = ??????? ??????????? ????????xiaodong_luo78 at sina.com ??????????2006-02-12 From gene.heskett at verizon.net Sun Feb 12 02:53:21 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Sat, 11 Feb 2006 21:53:21 -0500 Subject: fetchmail problem? Message-ID: <200602112153.21314.gene.heskett@verizon.net> Greetings all; I am trying to use fetchmail, which for sucking mail is working great, dumping it right into the kmail suck dir in /var/spool/mail/$USER. However, adjust and restart till I'm blue in the face, I cannot make it use an alternate mda, such as procmail. It seemingly ignores the default mda /usr/bin/procmail -d gene line at the top of ~/.fetchmailrc, and if an attempt is made to pass it in via the set syntax instead, thats an outright error and fetchmail dies, silently. Similarly that same syntax but with either a -m or a --mda on the command line also results in an error abort, reporting the --mda as a syntax error even if it is used as a -m like this: su gene -c "fetchmail -d 90 --fetchmailrc /home/gene/.fetchmailrc -m /usr/bin/procmail". I think I'm doing it right, and according to the manpages. Do I need a newer fetchmail than can be readily installed on an FC2 system? The currently installed fetchmail is: fetchmail-6.2.5.5-1.fc3 System is however, an FC2 (mostly) system. -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From pekkas at netcore.fi Sun Feb 12 13:55:50 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Sun, 12 Feb 2006 15:55:50 +0200 (EET) Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: References: <1139531948.3490.3.camel@ender> <43ECCFE1.7090702@sbcglobal.net> <200602101839.14206.lists@benjamindsmith.com> <1139626137.31644.3.camel@ender> Message-ID: On Sat, 11 Feb 2006, Jeff Sheltren wrote: > What I'd like to see is to have something like this (Pekka's idea above) > happen for regular package contributors (people that have submitted multiple > packages to FL). People that haven't submitted many packages should require > one of the trusted packagers/builders to do a "publish" QA before pushing the > package to testing. Since the current state of things is that it's only a > small group of people doing things, this won't really affect anyone at the > moment- but it's just a way to ease new packagers in while being sure that > they are submitting "good" packages. Yes, "automatic publish without VERIFY QA" depends a lot that the package proposals, PUBLISH QA (for every distro), and building and pushing to updates-testing (by FL core people) is done properly. Given that this currently (unfortunately) happens almost solely by a very small set of people (say, about 5), as you say, this isn't a problem now. Even if new people came up to join the PUBLISH crowd, I'm confident that they'd blend in because there's pretty good guidance in Wiki on how to do good package proposals, publish, etc. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From gene.heskett at verizon.net Sun Feb 12 19:00:19 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Sun, 12 Feb 2006 14:00:19 -0500 Subject: procmail & dovecot Q. Message-ID: <200602121400.19599.gene.heskett@verizon.net> Greetings; I have fetchmail delivering the incoming mail to procmail and procmailrc contains code to both save a raw clone, keep a log, and filter via spamc. While its delivering non-spam mail ok, its not keeping a log, or a rawmbox clone, and although I don't see procmailrc as containing it, spam is apparently being sent to /dev/null, so I've no way to check for FP's. I'd like to get dovecot involved so I could read mail from any of my machines eventually too, Whats the best mailing list to get on where help with this might be obtained? -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From tmz at pobox.com Sun Feb 12 19:59:19 2006 From: tmz at pobox.com (Todd Zullinger) Date: Sun, 12 Feb 2006 14:59:19 -0500 Subject: procmail & dovecot Q. In-Reply-To: <200602121400.19599.gene.heskett@verizon.net> References: <200602121400.19599.gene.heskett@verizon.net> Message-ID: <20060212195919.GF3026@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gene Heskett wrote: > I have fetchmail delivering the incoming mail to procmail and procmailrc > contains code to both save a raw clone, keep a log, and filter via > spamc. [...] > Whats the best mailing list to get on where help with this might be > obtained? Check the procmail lists. There's a link to archives and info on subscribing here: http://www.procmail.org/era/lists.html - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== Chaos, panic, and disorder - my job is done here. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iG0EARECAC0FAkPvk5YmGGh0dHA6Ly93d3cucG9ib3guY29tL350bXovcGdwL3Rt ei5hc2MACgkQuv+09NZUB1q4XQCfefRzbsS9tQgKmZQwFWqmx/EjRU0An34ifRGs MeNQVN6EByWBc7eLxcdT =4gaH -----END PGP SIGNATURE----- From pekkas at netcore.fi Sun Feb 12 20:17:29 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Sun, 12 Feb 2006 22:17:29 +0200 (EET) Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <1139669908.20848.11.camel@mdlinux> References: <1139531948.3490.3.camel@ender> <43ECCFE1.7090702@sbcglobal.net> <200602101839.14206.lists@benjamindsmith.com> <1139626137.31644.3.camel@ender> <1139637608.31644.5.camel@ender> <1139669908.20848.11.camel@mdlinux> Message-ID: Hi, It seems there's rather strong agreement for this. Unless I hear major objections in two days, I'll start the two-week clock (from today) for all the pending packages. After that I'll also update the Wiki entry for QaVerify unless someone else has done it. On Sat, 11 Feb 2006, Marc Deslauriers wrote: >>> I have proposed something simpler, and still do: >>> >>> 1) every package, even without any VERIFY QA votes at all, will be >>> released automatically in X weeks (suggest: X=2). >>> >>> exception: at package PUBLISH time, the packager and/or publisher, >>> if they think the changes are major enough (e.g., non-QAed patches >>> etc.), they can specify that the package should not be >>> automatically released. >>> >>> 2) negative reports block automatic publishing. >>> >>> 3) positive reports can speed up automatic publishing (for example: 2 >>> VERIFY votes --> released within 1 week, all verify votes: >>> released immediately after the last verify) >>> >>> There is no need (IMHO) to grade packages to more or less critical >>> ones. Every QA tester and eventual package user uses his or her own >>> value judgment. If (s)he fears that the (potentially untested) >>> automatic update would break the system, (s)he would test it before >>> two weeks are over. >>> >>> Publishing positive reports can be made simpler but that probably >>> isn't on the critical path here. > > I agree to this. > > Marc > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From stuart at serverpeak.com Sun Feb 12 21:05:11 2006 From: stuart at serverpeak.com (Stuart Low) Date: Mon, 13 Feb 2006 07:05:11 +1000 Subject: procmail & dovecot Q. In-Reply-To: <200602121400.19599.gene.heskett@verizon.net> References: <200602121400.19599.gene.heskett@verizon.net> Message-ID: <1139778312.11338.86.camel@laptop.seekbrain.com> Hi there, > Whats the best mailing list to get on where help with this might be > obtained? This is not entirely what you're looking for, however, I've put out a guide to setup getmail + Dovecot. I believe getmail & Dovecot support SpamAsssassin out of the box too. http://seekbrain.com/2006/02/12/home-network-setup-part-5/ Stuart From gene.heskett at verizon.net Sun Feb 12 23:27:12 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Sun, 12 Feb 2006 18:27:12 -0500 Subject: procmail & dovecot Q. In-Reply-To: <20060212195919.GF3026@psilocybe.teonanacatl.org> References: <200602121400.19599.gene.heskett@verizon.net> <20060212195919.GF3026@psilocybe.teonanacatl.org> Message-ID: <200602121827.12402.gene.heskett@verizon.net> On Sunday 12 February 2006 14:59, Todd Zullinger wrote: >http://www.procmail.org/era/lists.html Msg sent, thanks. -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From marcdeslauriers at videotron.ca Mon Feb 13 00:45:32 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sun, 12 Feb 2006 19:45:32 -0500 Subject: Fedora Legacy Test Update Notification: postgresql Message-ID: <43EFD6AC.1020808@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-157366 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157366 2006-02-12 --------------------------------------------------------------------- Name : postgresql Versions : rh9: postgresql-7.3.10-0.90.1.legacy Versions : fc1: postgresql-7.3.10-1.1.legacy Versions : fc2: postgresql-7.4.8-1.FC2.1.legacy Summary : PostgreSQL client programs and libraries. Description : PostgreSQL is an advanced Object-Relational database management system (DBMS) that supports almost all SQL constructs, including transactions, subselects, and user-defined types and functions. The postgresql package includes the client programs and libraries that you need to access a PostgreSQL DBMS server. --------------------------------------------------------------------- Update Information: Updated postgresql packages that fix several security vulnerabilities and risks of data loss are now available. PostgreSQL is an advanced Object-Relational database management system (DBMS) that supports almost all SQL constructs (including transactions, subselects and user-defined types and functions). The PostgreSQL community discovered two distinct errors in initial system catalog entries that could allow authorized database users to crash the database and possibly escalate their privileges. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CVE-2005-1409 and CVE-2005-1410 to these issues. Although installing this update will protect new (freshly initdb'd) database installations from these errors, administrators MUST TAKE MANUAL ACTION to repair the errors in pre-existing databases. The appropriate procedures are explained at http://www.postgresql.org/docs/8.0/static/release-7-4-8.html for Fedora Core 2 users, or http://www.postgresql.org/docs/8.0/static/release-7-3-10.html for Fedora Core 1 and Red Hat Linux 9 users. This update also includes fixes for several other errors, including two race conditions that could result in apparent data inconsistency or actual data loss. All users of PostgreSQL are advised to upgrade to these updated packages and to apply the recommended manual corrections to existing databases. --------------------------------------------------------------------- Changelogs rh9: * Sat Feb 11 2006 Marc Deslauriers 7.3.10-0.90.1.legacy - Update to PostgreSQL 7.3.10 (fixes CVE-2005-1409 and CVE-2005-1410) fc1: * Sat Feb 11 2006 Marc Deslauriers 7.3.10-1.1.legacy - Rebuilt as Fedora Legacy security update for Fedore Core 1 - Added missing libtermcap-devel, perl-SGMLSpm, openjade, docbook-utils and docbook-style-dsssl to BuildRequires fc2: * Sat Feb 11 2006 Marc Deslauriers 7.4.8-1.FC2.1.legacy - Rebuild as a Fedora Legacy update for Fedora Core 2 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh9: 88bf97be3530effdf1c7c3a779bfe7f80e7ea6be redhat/9/updates-testing/i386/postgresql-7.3.10-0.90.1.legacy.i386.rpm 6130777335db38d64a44d52106353cd76154ca23 redhat/9/updates-testing/i386/postgresql-contrib-7.3.10-0.90.1.legacy.i386.rpm 4bce5f9e6e80edb944a7aa24839f34c609c44c99 redhat/9/updates-testing/i386/postgresql-devel-7.3.10-0.90.1.legacy.i386.rpm f6d7a63730df0a33b4f7582077472bf8cecc0f4e redhat/9/updates-testing/i386/postgresql-docs-7.3.10-0.90.1.legacy.i386.rpm 3f76bb95ef0ce2da9b6a58993cdf7a1000e33019 redhat/9/updates-testing/i386/postgresql-jdbc-7.3.10-0.90.1.legacy.i386.rpm a7a9187c41f2820ca9c2d2364f63859d33d21044 redhat/9/updates-testing/i386/postgresql-libs-7.3.10-0.90.1.legacy.i386.rpm 0d0e4d4e566583111f30f4c06f255daeaf9bbd49 redhat/9/updates-testing/i386/postgresql-pl-7.3.10-0.90.1.legacy.i386.rpm def9d9581141c219e013a875146c75b65af67e91 redhat/9/updates-testing/i386/postgresql-python-7.3.10-0.90.1.legacy.i386.rpm 43590dabe9601ddbefbc6d9086c9b7dfb363acaa redhat/9/updates-testing/i386/postgresql-server-7.3.10-0.90.1.legacy.i386.rpm e4769b82d862178d6d395f52ebcbd56a75e36e71 redhat/9/updates-testing/i386/postgresql-tcl-7.3.10-0.90.1.legacy.i386.rpm fbd07e5eaad5e4ee5bd1b30e02001a043331daff redhat/9/updates-testing/i386/postgresql-test-7.3.10-0.90.1.legacy.i386.rpm 57fc00132f9d66263729566666fd1eba3d7a9d2f redhat/9/updates-testing/SRPMS/postgresql-7.3.10-0.90.1.legacy.src.rpm fc1: de59e42459e24cd8846fbd6d765bc892d621a0dc fedora/1/updates-testing/i386/postgresql-7.3.10-1.1.legacy.i386.rpm 88abba3e24f01c6189be15b6481d77b135b6191c fedora/1/updates-testing/i386/postgresql-contrib-7.3.10-1.1.legacy.i386.rpm 39a6163dffc299ba088f8f71c0393fca08648ae9 fedora/1/updates-testing/i386/postgresql-devel-7.3.10-1.1.legacy.i386.rpm 0ac78a44e03f5b31113b7b110d35472aded5ecbd fedora/1/updates-testing/i386/postgresql-docs-7.3.10-1.1.legacy.i386.rpm e8a17936599c1c2aa7a26056ee3449e43a460d07 fedora/1/updates-testing/i386/postgresql-jdbc-7.3.10-1.1.legacy.i386.rpm 421fc09afacbeb0e6773a8c2c1dd2ebb45406fd9 fedora/1/updates-testing/i386/postgresql-libs-7.3.10-1.1.legacy.i386.rpm f79b142305ab70af54594478e248830edfdb8247 fedora/1/updates-testing/i386/postgresql-pl-7.3.10-1.1.legacy.i386.rpm ab86d2fbf57b470934131cb78916117fdf177a4d fedora/1/updates-testing/i386/postgresql-python-7.3.10-1.1.legacy.i386.rpm 71c2abb0a89a19fa88eaa3a22048062ea4d938f3 fedora/1/updates-testing/i386/postgresql-server-7.3.10-1.1.legacy.i386.rpm 92e2b78d179c4aa378875b6ab42c488cad6b44c7 fedora/1/updates-testing/i386/postgresql-tcl-7.3.10-1.1.legacy.i386.rpm 44a3837dd2f7ae68790637be50fe1f29b8d86814 fedora/1/updates-testing/i386/postgresql-test-7.3.10-1.1.legacy.i386.rpm de79d4182b566ec3c4a623cd26c51af2e8938ffb fedora/1/updates-testing/SRPMS/postgresql-7.3.10-1.1.legacy.src.rpm fc2: 0046d088278b0c08740222a41ca511d0c0fa3d99 fedora/2/updates-testing/i386/postgresql-7.4.8-1.FC2.1.legacy.i386.rpm 184dd4304908b60a216f3be9f0756fde449c729e fedora/2/updates-testing/i386/postgresql-contrib-7.4.8-1.FC2.1.legacy.i386.rpm 8ae68e66295eddb1936c31fe15cf95662db4b345 fedora/2/updates-testing/i386/postgresql-devel-7.4.8-1.FC2.1.legacy.i386.rpm 7e547b6ee8c0e1b06bc803aa45086971158ced10 fedora/2/updates-testing/i386/postgresql-docs-7.4.8-1.FC2.1.legacy.i386.rpm 646cba1375fa3548aff2a791035f5eacb7927869 fedora/2/updates-testing/i386/postgresql-jdbc-7.4.8-1.FC2.1.legacy.i386.rpm 642feb043c19a5584f60ef45713bf8249c689216 fedora/2/updates-testing/i386/postgresql-libs-7.4.8-1.FC2.1.legacy.i386.rpm 6955df9f381e1683d1d79aa779f5f295e74e2b68 fedora/2/updates-testing/i386/postgresql-pl-7.4.8-1.FC2.1.legacy.i386.rpm 99b1ee5e4c26370d39e52437c10bb9cdcbc5d273 fedora/2/updates-testing/i386/postgresql-python-7.4.8-1.FC2.1.legacy.i386.rpm 167fb15d6f300bd4aaf8a0b080dfa42136ee9f1c fedora/2/updates-testing/i386/postgresql-server-7.4.8-1.FC2.1.legacy.i386.rpm 62f4e5798b3179a49cbe8c515343a0db4687834b fedora/2/updates-testing/i386/postgresql-tcl-7.4.8-1.FC2.1.legacy.i386.rpm 1c8feebe8cf8d2ef07cb004b10cd4cf69e654989 fedora/2/updates-testing/i386/postgresql-test-7.4.8-1.FC2.1.legacy.i386.rpm c2b44a61fdbf644cecccb3edcf78a80dbda9cfa4 fedora/2/updates-testing/SRPMS/postgresql-7.4.8-1.FC2.1.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Mon Feb 13 00:45:52 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sun, 12 Feb 2006 19:45:52 -0500 Subject: Fedora Legacy Test Update Notification: gnutls Message-ID: <43EFD6C0.2000401@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-181014 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181014 2006-02-12 --------------------------------------------------------------------- Name : gnutls Versions : fc3: Summary : A TLS implementation. Description : The GNU TLS Library provides support for cryptographic algorithms and protocols such as TLS. GNU TLS includes Libtasn1, a library developed for ASN.1 structures management that includes DER encoding and decoding. --------------------------------------------------------------------- Update Information: Updated gnutls packages that fix a security issue are now available. The GNU TLS Library provides support for cryptographic algorithms and protocols such as TLS. GNU TLS includes Libtasn1, a library developed for ASN.1 structures management that includes DER encoding and decoding. Several flaws were found in the way libtasn1 decodes DER. An attacker could create a carefully crafted invalid X.509 certificate in such a way that could trigger this flaw if parsed by an application that uses GNU TLS. This could lead to a denial of service (application crash). It is not certain if this issue could be escalated to allow arbitrary code execution. The Common Vulnerabilities and Exposures project assigned the name CVE-2006-0645 to this issue. Users are advised to upgrade to these updated packages, which contain a backported patch from the GNU TLS maintainers to correct this issue. --------------------------------------------------------------------- Changelogs fc3: * Sun Feb 12 2006 Marc Deslauriers 1.0.20-3.1.3.legacy - Added missing zlib-devel to BuildPrereq * Sat Feb 11 2006 Marc Deslauriers 1.0.20-3.1.2.legacy - Added patch for GnuTLS x509 DER DoS - CVE-2006-0645 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) fc3: 87b93af583ea3abaa48337b0a8c71cba97a45410 fedora/3/updates-testing/i386/gnutls-1.0.20-3.1.3.legacy.i386.rpm dca7e6e11093d7b8528d82cc9c3f5f1b1c78ea23 fedora/3/updates-testing/i386/gnutls-devel-1.0.20-3.1.3.legacy.i386.rpm 87b93af583ea3abaa48337b0a8c71cba97a45410 fedora/3/updates-testing/x86_64/gnutls-1.0.20-3.1.3.legacy.i386.rpm 742be40634dc2a32b245f78caf610d0a6b45cb75 fedora/3/updates-testing/x86_64/gnutls-1.0.20-3.1.3.legacy.x86_64.rpm 762630c8973f02bcc934adc8f5a946383f8479cc fedora/3/updates-testing/x86_64/gnutls-devel-1.0.20-3.1.3.legacy.x86_64.rpm cce2a463b57be400362624f09dc49a4fdde09305 fedora/3/updates-testing/SRPMS/gnutls-1.0.20-3.1.3.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From deisenst at gtw.net Mon Feb 13 11:48:02 2006 From: deisenst at gtw.net (David Eisenstein) Date: Mon, 13 Feb 2006 05:48:02 -0600 (CST) Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: Message-ID: On Sun, 12 Feb 2006, Pekka Savola wrote: > Hi, > > It seems there's rather strong agreement for this. > > Unless I hear major objections in two days, I'll start the two-week > clock (from today) for all the pending packages. > > After that I'll also update the Wiki entry for QaVerify unless someone > else has done it. > On Sat, 11 Feb 2006, Marc Deslauriers wrote: > >>> I have proposed something simpler, and still do: > >>> > >>> 1) every package, even without any VERIFY QA votes at all, will be > >>> released automatically in X weeks (suggest: X=2). > >>> > >>> exception: at package PUBLISH time, the packager and/or publisher, > >>> if they think the changes are major enough (e.g., non-QAed patches > >>> etc.), they can specify that the package should not be > >>> automatically released. > >>> > >>> 2) negative reports block automatic publishing. > >>> > >>> 3) positive reports can speed up automatic publishing (for example: 2 > >>> VERIFY votes --> released within 1 week, all verify votes: > >>> released immediately after the last verify) > >>> > >>> <> > > > > I agree to this. > > > > Marc Let's give this a try. I hear very few complaints about the packages that Fedora Legacy Project produces. It is good to have the option of letting the package builder say, "Hey, someone who knows this thing I built, please try it out!" It's impossible for the folks on our build team to be intimately familiar with all the packages we build; there are too many of them and too few builders so far. In many cases, packages just work, because we are depending on the excellent work of others (either upstream or Red Hat engineers' work) in creating patches that work and that don't introduce other problems, as Pekka has noted elsewhere. Doing things this way may have the unfortunate effect of pretty much doing away with QA Testing, though. If a package is going to be released two weeks from when it is pushed to updates-testing, regardless of whether or not it has been tested, people may end up saying, "Why bother?" We can always revisit this decision if users start having problems with the packages that Fedora Legacy releases. -David From mike.mccarty at sbcglobal.net Mon Feb 13 17:16:56 2006 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Mon, 13 Feb 2006 11:16:56 -0600 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: References: Message-ID: <43F0BF08.1030704@sbcglobal.net> David Eisenstein wrote: [snip] > Doing things this way may have the unfortunate effect of pretty much doing > away with QA Testing, though. If a package is going to be released two > weeks from when it is pushed to updates-testing, regardless of whether or > not it has been tested, people may end up saying, "Why bother?" I'l make that stronger... I'd rather run with a known security vulnerability than an untested package. With a known security hole, I know some steps I can take externally to my box, and know what my vulnerability is. With an untested package, I know neither. > We can always revisit this decision if users start having problems with > the packages that Fedora Legacy releases. If "two weeks, and it gets released whether it's tested or not" is implemented, then Fedora Legacy gets removed from my yum configuration file, and I start considering installing Debian or CentOS or Scientific Linux. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From mike.mccarty at sbcglobal.net Mon Feb 13 17:18:22 2006 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Mon, 13 Feb 2006 11:18:22 -0600 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <200602110021.40574.lists@benjamindsmith.com> References: <1139531948.3490.3.camel@ender> <1139626137.31644.3.camel@ender> <200602110021.40574.lists@benjamindsmith.com> Message-ID: <43F0BF5E.8080007@sbcglobal.net> Benjamin Smith wrote: > On Friday 10 February 2006 21:32, Pekka Savola wrote: > >>On Fri, 10 Feb 2006, Jesse Keating wrote: >> >>>This makes it even more complicated. points? how many are enough? >>>What makes one package more critical than another? How ambiguous could >>>this be? >> >>I agree that this would complicate the process further. >> >>I have proposed something simpler, and still do: >> >>1) every package, even without any VERIFY QA votes at all, will be >> released automatically in X weeks (suggest: X=2). >> >> exception: at package PUBLISH time, the packager and/or publisher, >> if they think the changes are major enough (e.g., non-QAed patches >> etc.), they can specify that the package should not be >> automatically released. >> >>2) negative reports block automatic publishing. >> >>3) positive reports can speed up automatic publishing (for example: 2 >> VERIFY votes --> released within 1 week, all verify votes: >> released immediately after the last verify) > > > Pekka, > > I've proposed (1, 2) before... That's why I've moved my last remaining FC1 > systems to testing - I've just not had problems with the updates, and I'd > rather run a secure but occasionally unstable system than an insecure but > "stable" one. Then why are we having this discussion? I thought that the issue was that "testing" wasn't being actually tested. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From jimpop at yahoo.com Mon Feb 13 17:45:06 2006 From: jimpop at yahoo.com (Jim Popovitch) Date: Mon, 13 Feb 2006 12:45:06 -0500 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <43F0BF08.1030704@sbcglobal.net> References: <43F0BF08.1030704@sbcglobal.net> Message-ID: <43F0C5A2.9050403@yahoo.com> Mike McCarty wrote: > > I'd rather run with a known security vulnerability than an untested > package. With a known security hole, I know some steps I can take > externally to my box, and know what my vulnerability is. With an > untested package, I know neither. Mike, I would generally agree with that above statement, however most (99 percent?) of the FL fixes involved code that was written and tested elsewhere. All FL does is re-apply the same fix to the FL codebase. I for one am willing to accept a tested fix that is applied to a parallel codebase over running a known vulnerability. It's not an exact science but it also isn't running blind. -Jim P. From rostetter at mail.utexas.edu Mon Feb 13 18:34:24 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 13 Feb 2006 12:34:24 -0600 Subject: procmail & dovecot Q. In-Reply-To: <200602121400.19599.gene.heskett@verizon.net> References: <200602121400.19599.gene.heskett@verizon.net> Message-ID: <20060213123424.7rnkzptqp8v4g0s8@mail.ph.utexas.edu> Quoting Gene Heskett : > Whats the best mailing list to get on where help with this might be > obtained? For all things dovecot, use the dovecot mailing list. See http://www.dovecot.org/mailinglists.html For procmail, I don't really know which lists might be best, but I'd start at http://www.procmail.org/era/lists.html In any case, these are separate issues which would go to separate lists, and probably have little or nothing to do with Red Hat or Fedora Legacy. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From gene.heskett at verizon.net Mon Feb 13 21:21:49 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Mon, 13 Feb 2006 16:21:49 -0500 Subject: procmail & dovecot Q. In-Reply-To: <20060213123424.7rnkzptqp8v4g0s8@mail.ph.utexas.edu> References: <200602121400.19599.gene.heskett@verizon.net> <20060213123424.7rnkzptqp8v4g0s8@mail.ph.utexas.edu> Message-ID: <200602131621.50098.gene.heskett@verizon.net> On Monday 13 February 2006 13:34, Eric Rostetter wrote: >Quoting Gene Heskett : >> Whats the best mailing list to get on where help with this might be >> obtained? > >For all things dovecot, use the dovecot mailing list. See >http://www.dovecot.org/mailinglists.html Unforch, the above server is a black hole for subscribe requests. No response to my subscribe requests (2) has been rx'd in 4 days now. >For procmail, I don't really know which lists might be best, but >I'd start at http://www.procmail.org/era/lists.html I have this one sorted I believe. > >In any case, these are separate issues which would go to separate > lists, and probably have little or nothing to do with Red Hat or > Fedora Legacy. Which is why I didn't make a lot of noise here asking detailed questions. -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From cave.dnb at tiscali.fr Mon Feb 13 21:47:19 2006 From: cave.dnb at tiscali.fr (Nigel Henry) Date: Mon, 13 Feb 2006 22:47:19 +0100 Subject: procmail & dovecot Q. In-Reply-To: <200602131621.50098.gene.heskett@verizon.net> References: <200602121400.19599.gene.heskett@verizon.net> <20060213123424.7rnkzptqp8v4g0s8@mail.ph.utexas.edu> <200602131621.50098.gene.heskett@verizon.net> Message-ID: <200602132247.19564.cave.dnb@tiscali.fr> On Monday 13 February 2006 22:21, Gene Heskett wrote: > On Monday 13 February 2006 13:34, Eric Rostetter wrote: > >Quoting Gene Heskett : > >> Whats the best mailing list to get on where help with this might be > >> obtained? > > > >For all things dovecot, use the dovecot mailing list. See > >http://www.dovecot.org/mailinglists.html > > Unforch, the above server is a black hole for subscribe requests. No > response to my subscribe requests (2) has been rx'd in 4 days now. Hi Gene, Probably a bit unethical, but I've just tried subscribing to the Dovecot list, and have got on straight away, received the confirmation e-mail, then the welcome to e-mail. Try it again perhaps? Nigel. > > >For procmail, I don't really know which lists might be best, but > >I'd start at http://www.procmail.org/era/lists.html > > I have this one sorted I believe. > > >In any case, these are separate issues which would go to separate > > lists, and probably have little or nothing to do with Red Hat or > > Fedora Legacy. > > Which is why I didn't make a lot of noise here asking detailed > questions. From ben at schoolpathways.com Tue Feb 14 05:15:38 2006 From: ben at schoolpathways.com (Benjamin Smith) Date: Mon, 13 Feb 2006 21:15:38 -0800 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> Message-ID: <200602132115.38856.ben@schoolpathways.com> On Sunday 12 February 2006 12:17, Pekka Savola wrote: > Hi, > > It seems there's rather strong agreement for this. Yep. (From me) > Unless I hear major objections in two days, I'll start the two-week > clock (from today) for all the pending packages. Cool! > After that I'll also update the Wiki entry for QaVerify unless someone > else has done it. > > On Sat, 11 Feb 2006, Marc Deslauriers wrote: > >>> I have proposed something simpler, and still do: > >>> > >>> 1) every package, even without any VERIFY QA votes at all, will be > >>> released automatically in X weeks (suggest: X=2). > >>> > >>> exception: at package PUBLISH time, the packager and/or publisher, > >>> if they think the changes are major enough (e.g., non-QAed patches > >>> etc.), they can specify that the package should not be > >>> automatically released. > >>> > >>> 2) negative reports block automatic publishing. > >>> > >>> 3) positive reports can speed up automatic publishing (for example: 2 > >>> VERIFY votes --> released within 1 week, all verify votes: > >>> released immediately after the last verify) > >>> > >>> There is no need (IMHO) to grade packages to more or less critical > >>> ones. Every QA tester and eventual package user uses his or her own > >>> value judgment. If (s)he fears that the (potentially untested) > >>> automatic update would break the system, (s)he would test it before > >>> two weeks are over. > >>> > >>> Publishing positive reports can be made simpler but that probably > >>> isn't on the critical path here. > > > > I agree to this. > > > > Marc > > > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > -- "I kept looking around for somebody to solve the problem. Then I realized I am somebody" -Anonymous From ben at schoolpathways.com Tue Feb 14 05:19:20 2006 From: ben at schoolpathways.com (Benjamin Smith) Date: Mon, 13 Feb 2006 21:19:20 -0800 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: References: Message-ID: <200602132119.20869.ben@schoolpathways.com> On Monday 13 February 2006 03:48, David Eisenstein wrote: > Doing things this way may have the unfortunate effect of pretty much doing > away with QA Testing, though. ?If a package is going to be released two > weeks from when it is pushed to updates-testing, regardless of whether or > not it has been tested, people may end up saying, "Why bother?" I'd guess the opposite: those who actually WANT to test the packages will have a fire lit under their backside to do the testing in a timeframe that's relevant. I'd rather err on the side of security. -Ben -- "I kept looking around for somebody to solve the problem. Then I realized I am somebody" -Anonymous From mike.mccarty at sbcglobal.net Tue Feb 14 08:31:14 2006 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Tue, 14 Feb 2006 02:31:14 -0600 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <200602132115.38856.ben@schoolpathways.com> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> Message-ID: <43F19552.3010808@sbcglobal.net> Benjamin Smith wrote: With apologies to Benjamin Smith for replying "through" his response. > On Sunday 12 February 2006 12:17, Pekka Savola wrote: > >>Hi, >> >>It seems there's rather strong agreement for this. > > > Yep. (From me) > > >>Unless I hear major objections in two days, I'll start the two-week >>clock (from today) for all the pending packages. Ok then, it seems to me that there is no longer any distinction between the released repository, and the test repository. So, please send out an e-mail three days before the first "timed release" so I can pull a last tested version before removing the legacy repository from my yum configuration. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From pekkas at netcore.fi Tue Feb 14 14:09:08 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 14 Feb 2006 16:09:08 +0200 (EET) Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <43F19552.3010808@sbcglobal.net> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> Message-ID: On Tue, 14 Feb 2006, Mike McCarty wrote: > Ok then, it seems to me that there is no longer any distinction > between the released repository, and the test repository. > So, please send out an e-mail three days before the first > "timed release" so I can pull a last tested version before > removing the legacy repository from my yum configuration. I can send such an email, but I'll have to charge 100 USD for the trouble. Credit cards accepted. Perhaps you forgot that Fedora Legacy is a community project? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From rostetter at mail.utexas.edu Tue Feb 14 14:49:12 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 14 Feb 2006 08:49:12 -0600 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <200602132119.20869.ben@schoolpathways.com> References: <200602132119.20869.ben@schoolpathways.com> Message-ID: <20060214084912.rs8qy685zmhw8k00@mail.ph.utexas.edu> Quoting Benjamin Smith : > I'd rather err on the side of security. > > -Ben Then you would insist on a real QA test suite, one that also tested the security of the test. You would be against pushing untested updates. I think you would rather err on the side of timelyness rather than security... What we're proposing basically is a system in which someone can purposefully place a trojan horse or backdoor on all Fedora Legacy systems without any one checking for it ahead of time. You call that security? Putting all your eggs in your trust in one person rather than multiple people? That isn't security... I'm staying out of the argument for or against this proposal, as my fews should be well known from the last dozen times this has come up, and I'm tired of fighting for this. I can always just upgrade my machines to Centos should Fedora Legacy lose its security. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From jkeating at j2solutions.net Tue Feb 14 15:07:01 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 14 Feb 2006 07:07:01 -0800 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <43F19552.3010808@sbcglobal.net> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> Message-ID: <1139929622.2466.25.camel@ender> On Tue, 2006-02-14 at 02:31 -0600, Mike McCarty wrote: > Ok then, it seems to me that there is no longer any distinction > between the released repository, and the test repository. > So, please send out an e-mail three days before the first > "timed release" so I can pull a last tested version before > removing the legacy repository from my yum configuration. I appreciate your concern mike, however if we have people testing during the timeout period, then there would be no untested packages. If I see too many packages go w/out testing on a given platform, I'm going to drop that platform as not having enough community interest. This is a very self service project. You get out of it what you put into it. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at j2solutions.net Tue Feb 14 15:08:57 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 14 Feb 2006 07:08:57 -0800 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <20060214084912.rs8qy685zmhw8k00@mail.ph.utexas.edu> References: <200602132119.20869.ben@schoolpathways.com> <20060214084912.rs8qy685zmhw8k00@mail.ph.utexas.edu> Message-ID: <1139929737.2466.28.camel@ender> On Tue, 2006-02-14 at 08:49 -0600, Eric Rostetter wrote: > > What we're proposing basically is a system in which someone can purposefully > place a trojan horse or backdoor on all Fedora Legacy systems without any > one checking for it ahead of time. You call that security? Putting all your > eggs in your trust in one person rather than multiple people? That isn't > security... > If I'm not mistaken, the timeout period starts when there is a package for updates testing. We can't get to the updates testing package phase w/out somebody doing the first level QA which includes making sure the patch uses is a known good patch from at least some other vendor. So the plot to root all Legacy systems is going to have to start further up the food chain. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From gene.heskett at verizon.net Tue Feb 14 16:39:39 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Tue, 14 Feb 2006 11:39:39 -0500 Subject: services query Message-ID: <200602141139.39225.gene.heskett@verizon.net> Greetings; What have I stopped from working if I've shut xprint and canna off? xprint in particular outputs quite a few failed messages about fonts and what not at bootup time, so I don't think it was working all that well anyway, but I can print from anything that wants to before I stopped it just now. Logged stuff like: ============ rc: Starting xprint: succeeded Feb 13 00:35:57 coyote Xprt_33: lpstat: Unable to connect to server: Connection refused Feb 13 00:35:57 coyote Xprt_33: No matching visual for __GLcontextMode with visual class = 0 (32775), nplanes = 8 Feb 13 00:35:57 coyote Xprt_33: Could not init font path element /usr/share/fonts, removing from list! Feb 13 00:35:58 coyote Xprt_33: Could not init font path element /usr/share/fonts/msfonts, removing from list! Feb 13 00:35:58 coyote Xprt_33: Could not init font path element /usr/X11R6/lib/X11/fonts, removing from list! Feb 13 00:35:58 coyote Xprt_33: Could not init font path element /usr/X11R6/lib/X11/fonts/latin2, removing from lis t! Feb 13 00:35:58 coyote Xprt_33: Could not init font path element /usr/X11R6/lib/X11/fonts/local, removing from list ! Feb 13 00:35:58 coyote Xprt_33: Could not init font path element /usr/X11R6/lib/X11/fonts/OTF, removing from list! Feb 13 00:35:58 coyote Xprt_33: Could not init font path element /usr/X11R6/lib/X11/fonts/util, removing from list! ============ The canna server I was recently told isn't output, but for chinese input, so its of no use to me in that event. -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From jkosin at beta.intcomgrp.com Tue Feb 14 17:32:24 2006 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Tue, 14 Feb 2006 12:32:24 -0500 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <1139929737.2466.28.camel@ender> References: <200602132119.20869.ben@schoolpathways.com> <20060214084912.rs8qy685zmhw8k00@mail.ph.utexas.edu> <1139929737.2466.28.camel@ender> Message-ID: <43F21428.7090607@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: > > If I'm not mistaken, the timeout period starts when there is a package > for updates testing. We can't get to the updates testing package phase > w/out somebody doing the first level QA which includes making sure the > patch uses is a known good patch from at least some other vendor. So > the plot to root all Legacy systems is going to have to start further up > the food chain. > OK, Maybe we (Fedora Legacy) need to define the process of getting a package from bug report (or SA) to QA released state, and stop arguing who is at fault or how to bypass QA. If everyone knows the process and follows it we all can benefit... Maybe, its time I started witting something! A document on the whole process for everyone to review and agree upon... unless something like this already exists... which I've never seen. Thanks, James Kosin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD8hQokNLDmnu1kSkRAu1nAJwJq9OK49o7lHySze7/YdD946z/vQCfaGg8 zAIWK7orCaOp/IYyu63R0Jg= =b0lD -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From sundaram at fedoraproject.org Tue Feb 14 17:35:14 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 14 Feb 2006 23:05:14 +0530 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <43F21428.7090607@beta.intcomgrp.com> References: <200602132119.20869.ben@schoolpathways.com> <20060214084912.rs8qy685zmhw8k00@mail.ph.utexas.edu> <1139929737.2466.28.camel@ender> <43F21428.7090607@beta.intcomgrp.com> Message-ID: <43F214D2.7040006@fedoraproject.org> Hi >Maybe we (Fedora Legacy) need to define the process of getting a package >from bug report (or SA) to QA released state, and stop arguing who is at >fault or how to bypass QA. If everyone knows the process and follows it >we all can benefit... > >Maybe, its time I started witting something! A document on the whole >process for everyone to review and agree upon... unless something like >this already exists... which I've never seen. > http://fedoraproject.org/wiki/Legacy/QATesting. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From jkosin at beta.intcomgrp.com Tue Feb 14 17:59:56 2006 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Tue, 14 Feb 2006 12:59:56 -0500 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <43F214D2.7040006@fedoraproject.org> References: <200602132119.20869.ben@schoolpathways.com> <20060214084912.rs8qy685zmhw8k00@mail.ph.utexas.edu> <1139929737.2466.28.camel@ender> <43F21428.7090607@beta.intcomgrp.com> <43F214D2.7040006@fedoraproject.org> Message-ID: <43F21A9C.8070004@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rahul Sundaram wrote: > Hi > > http://fedoraproject.org/wiki/Legacy/QATesting. > OK, It is a little buried in the clutter. I've seen this page many times, but never really dig-ed into it. I'm printing this stuff out for further review. Thanks, James Kosin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD8hqckNLDmnu1kSkRAjp2AJ9kviT73/Gq68jPuvUmpc/+j+fYIACcDAy0 1XV+rtijKjZtdjoHfrsiA5E= =ulPh -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From officeparis at yahoo.co.jp Tue Feb 14 18:02:28 2006 From: officeparis at yahoo.co.jp (Kazuo Ishii) Date: Wed, 15 Feb 2006 03:02:28 +0900 (JST) Subject: (no subject) Message-ID: <20060214180228.98382.qmail@web2810.mail.bbt.yahoo.co.jp> -------------------------------------- GANBARE! NIPPON! Yahoo! JAPAN JOC OFFICIAL INTERNET PORTAL SITE PARTNER http://pr.mail.yahoo.co.jp/ganbare-nippon/ From sundaram at fedoraproject.org Tue Feb 14 18:14:33 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 14 Feb 2006 23:44:33 +0530 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <43F21A9C.8070004@beta.intcomgrp.com> References: <200602132119.20869.ben@schoolpathways.com> <20060214084912.rs8qy685zmhw8k00@mail.ph.utexas.edu> <1139929737.2466.28.camel@ender> <43F21428.7090607@beta.intcomgrp.com> <43F214D2.7040006@fedoraproject.org> <43F21A9C.8070004@beta.intcomgrp.com> Message-ID: <43F21E09.9080709@fedoraproject.org> James Kosin wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Rahul Sundaram wrote: > > >>Hi >> >>http://fedoraproject.org/wiki/Legacy/QATesting. >> >> >> >OK, > >It is a little buried in the clutter. I've seen this page many times, >but never really dig-ed into it. > > It is referred from http://fedoraproject.org/wiki/Legacy which has a link from the frontpage. How is that buried in clutter?. What can we do to improve that?\ -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From mike.mccarty at sbcglobal.net Tue Feb 14 18:48:48 2006 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Tue, 14 Feb 2006 12:48:48 -0600 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> Message-ID: <43F22610.2050307@sbcglobal.net> Pekka Savola wrote: > On Tue, 14 Feb 2006, Mike McCarty wrote: > >> Ok then, it seems to me that there is no longer any distinction >> between the released repository, and the test repository. >> So, please send out an e-mail three days before the first >> "timed release" so I can pull a last tested version before >> removing the legacy repository from my yum configuration. > > > I can send such an email, but I'll have to charge 100 USD for the > trouble. Credit cards accepted. Don't be ridiculous. I meant that, three days before the new policy actually takes effect, send a message to the mail echo. > Perhaps you forgot that Fedora Legacy is a community project? Never mind, I just removed Fedora Legacy from my yum configuration file. It's no longer an issue for me. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From mike.mccarty at sbcglobal.net Tue Feb 14 18:57:37 2006 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Tue, 14 Feb 2006 12:57:37 -0600 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <1139929622.2466.25.camel@ender> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> Message-ID: <43F22821.4080606@sbcglobal.net> Jesse Keating wrote: > On Tue, 2006-02-14 at 02:31 -0600, Mike McCarty wrote: > >>Ok then, it seems to me that there is no longer any distinction >>between the released repository, and the test repository. >>So, please send out an e-mail three days before the first >>"timed release" so I can pull a last tested version before >>removing the legacy repository from my yum configuration. > > > I appreciate your concern mike, however if we have people testing during > the timeout period, then there would be no untested packages. If I see I'm afraid I don't understand what you mean. Perhaps I misunderstood what the proposal is. My understanding is that there are new versions of software which supposedly repair security defects in something called "testing". And that until they are tested by some volunteers, they remain there. I understand that the proposal is to institute a time limit such that if software resides in "testing" without any further testing actually being done, then it automatically enters "released" after a set time period. > too many packages go w/out testing on a given platform, I'm going to > drop that platform as not having enough community interest. This is a If this is the case, then what is the proposal? > very self service project. You get out of it what you put into it. More accurately, I get out of it what I pull from the repositories. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From sundaram at fedoraproject.org Tue Feb 14 19:11:41 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 15 Feb 2006 00:41:41 +0530 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <43F22821.4080606@sbcglobal.net> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> Message-ID: <43F22B6D.3040503@fedoraproject.org> Mike McCarty wrote: > Jesse Keating wrote: > >> On Tue, 2006-02-14 at 02:31 -0600, Mike McCarty wrote: >> >>> Ok then, it seems to me that there is no longer any distinction >>> between the released repository, and the test repository. >>> So, please send out an e-mail three days before the first >>> "timed release" so I can pull a last tested version before >>> removing the legacy repository from my yum configuration. >> >> >> >> I appreciate your concern mike, however if we have people testing during >> the timeout period, then there would be no untested packages. If I see > > > I'm afraid I don't understand what you mean. If people are interested in testing and providing feedback they would be able to do that within the specified time limit. If a sufficient amount of people are not interested in providing feedback either the platform can be dropped out of the legacy maintenance or the update can be pushed into the main legacy repository after QA work done by the packager. That is the proposal. The way you can help is either by doing the QA work or suggesting alternative proposals that would help in preventing important security and bug fixes lagging in updates testing for a infinite amount of time awaiting feedback. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From jkosin at beta.intcomgrp.com Tue Feb 14 19:30:03 2006 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Tue, 14 Feb 2006 14:30:03 -0500 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <43F21E09.9080709@fedoraproject.org> References: <200602132119.20869.ben@schoolpathways.com> <20060214084912.rs8qy685zmhw8k00@mail.ph.utexas.edu> <1139929737.2466.28.camel@ender> <43F21428.7090607@beta.intcomgrp.com> <43F214D2.7040006@fedoraproject.org> <43F21A9C.8070004@beta.intcomgrp.com> <43F21E09.9080709@fedoraproject.org> Message-ID: <43F22FBB.6010403@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rahul Sundaram wrote: > It is referred from http://fedoraproject.org/wiki/Legacy which has a > link from the frontpage. How is that buried in clutter?. What can we do > to improve that?\ > Don't get personal, I'm talking semantics here about not outlining them as steps. ex: The first one is named 'QASubmit'... OK maybe a limitation of wiki here and not someone's exact wording... but, maybe a description saying Package Resubmitting Procedures could be better. Something pointing to the fact the page is a procedural form instead of a simple description. Even something like follow these steps or procedures.... James Kosin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD8i+7kNLDmnu1kSkRAu6zAJ4874rS9Xfly2zdxapfWJecy7ObuQCffu8j 7Kz9ON76BJye21LktA4fJtk= =qJij -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From sundaram at fedoraproject.org Tue Feb 14 19:36:27 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 15 Feb 2006 01:06:27 +0530 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <43F22FBB.6010403@beta.intcomgrp.com> References: <200602132119.20869.ben@schoolpathways.com> <20060214084912.rs8qy685zmhw8k00@mail.ph.utexas.edu> <1139929737.2466.28.camel@ender> <43F21428.7090607@beta.intcomgrp.com> <43F214D2.7040006@fedoraproject.org> <43F21A9C.8070004@beta.intcomgrp.com> <43F21E09.9080709@fedoraproject.org> <43F22FBB.6010403@beta.intcomgrp.com> Message-ID: <43F2313B.20404@fedoraproject.org> James Kosin wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Rahul Sundaram wrote: > > >>It is referred from http://fedoraproject.org/wiki/Legacy which has a >>link from the frontpage. How is that buried in clutter?. What can we do >>to improve that?\ >> >> >> >Don't get personal, I'm talking semantics here about not outlining them >as steps. > > I am not getting personal. I am asking for suggestions to help improve the accessibility of the content since you believe it is cluttered now. >ex: The first one is named 'QASubmit'... OK maybe a limitation of wiki >here and not someone's exact wording... but, maybe a description saying >Package Resubmitting Procedures could be better. Something pointing to >the fact the page is a procedural form instead of a simple description. > > There is no limitation in the wiki on page lengths but we dont want very long wiki page names that makes it harder to remember. The explanations or headings within the pages can be as descriptive as you want them to be. >Even something like follow these steps or procedures.... > > Do you want to try and help make it better?. Register your name in the wiki and let me know so that I can add you to the edit group. http://fedoraproject.org/wiki/WikiEditing. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From rostetter at mail.utexas.edu Tue Feb 14 18:54:59 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 14 Feb 2006 12:54:59 -0600 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <43F21428.7090607@beta.intcomgrp.com> References: <200602132119.20869.ben@schoolpathways.com> <20060214084912.rs8qy685zmhw8k00@mail.ph.utexas.edu> <1139929737.2466.28.camel@ender> <43F21428.7090607@beta.intcomgrp.com> Message-ID: <20060214125459.ewyk4kntq54cc080@mail.ph.utexas.edu> Quoting James Kosin : > Jesse Keating wrote: >> >> If I'm not mistaken, the timeout period starts when there is a package >> for updates testing. There has been talk the last couple days of doing away with QA to get it to the updates-testing. This is what I was referencing, not the current setup. >> We can't get to the updates testing package phase >> w/out somebody doing the first level QA which includes making sure the >> patch uses is a known good patch from at least some other vendor. So I don't think this is true in theory; the patch need not come from some other vendor, or even upstream, in theory, though it perhaps always has in practice. Plus, the upstream patch is often modified, so there is always the chance for foul-play. >> the plot to root all Legacy systems is going to have to start further up >> the food chain. I don't think so. And in any case, I was refering to the suggestion on this list that we don't do QA to move to updates-testing, which would by-pass this whole issue you try to bring up. > Maybe, its time I started witting something! A document on the whole > process for everyone to review and agree upon... unless something like > this already exists... which I've never seen. It's been done and re-done so many times it makes my head spin. > Thanks, > James Kosin -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From drees76 at gmail.com Tue Feb 14 20:23:23 2006 From: drees76 at gmail.com (David Rees) Date: Tue, 14 Feb 2006 12:23:23 -0800 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <43F22821.4080606@sbcglobal.net> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> Message-ID: <72dbd3150602141223j7fb8e3e1ya7020cb5fb001513@mail.gmail.com> On 2/14/06, Mike McCarty wrote: > I'm afraid I don't understand what you mean. Perhaps I misunderstood > what the proposal is. My understanding is that there are new > versions of software which supposedly repair security defects in > something called "testing". And that until they are tested by some > volunteers, they remain there. I understand that the proposal is > to institute a time limit such that if software resides in "testing" > without any further testing actually being done, then it automatically > enters "released" after a set time period. That is correct. However, if the necessary QA votes get published before the timeout hits, the package will be released sooner. > > very self service project. You get out of it what you put into it. > > More accurately, I get out of it what I pull from the repositories. And by not contributing any QA yourself, you can not expect to get any QA besides what the original packager put into the release. Which is good enough if we can't get enough QA votes to release it before the proposed timeout hits. If it's not good enough for you, I suggest that you QA these packages yourself. -Dave From jkeating at j2solutions.net Tue Feb 14 20:27:51 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 14 Feb 2006 12:27:51 -0800 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <20060214125459.ewyk4kntq54cc080@mail.ph.utexas.edu> References: <200602132119.20869.ben@schoolpathways.com> <20060214084912.rs8qy685zmhw8k00@mail.ph.utexas.edu> <1139929737.2466.28.camel@ender> <43F21428.7090607@beta.intcomgrp.com> <20060214125459.ewyk4kntq54cc080@mail.ph.utexas.edu> Message-ID: <1139948871.2466.40.camel@ender> On Tue, 2006-02-14 at 12:54 -0600, Eric Rostetter wrote: > > There has been talk the last couple days of doing away with QA to get it > to the updates-testing. This is what I was referencing, not the current > setup. That is something I will not agree to. However the timeout period is, it strikes a balance. If we see too many packages get released w/out QA by the time the timeout hits, then that is very good indication that we can drop that platform. > >> We can't get to the updates testing package phase > >> w/out somebody doing the first level QA which includes making sure the > >> patch uses is a known good patch from at least some other vendor. So > > I don't think this is true in theory; the patch need not come from some > other vendor, or even upstream, in theory, though it perhaps always has > in practice. Plus, the upstream patch is often modified, so there is > always the chance for foul-play. Perhaps we should make it policy that the patch come from or get approval from upstream. Make the practice a policy. This is why we still have humans looking at the step from proposed patch to updates-testing. That will not get a timeout, that has to happen. The good thing about that step is that it doesn't require a whole system to test. > >> the plot to root all Legacy systems is going to have to start further up > >> the food chain. > > I don't think so. And in any case, I was refering to the suggestion on > this list that we don't do QA to move to updates-testing, which would > by-pass this whole issue you try to bring up. Well I won't agree to anything that bypasses the patch check step. QA must still happen before we put a package into updates-testing. Another thing to think about is we are putting in more QA into our updates that Fedora upstream puts into the updates it issues into live releases. Just food for thought. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pekkas at netcore.fi Tue Feb 14 20:34:14 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 14 Feb 2006 22:34:14 +0200 (EET) Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <1139948871.2466.40.camel@ender> References: <200602132119.20869.ben@schoolpathways.com> <20060214084912.rs8qy685zmhw8k00@mail.ph.utexas.edu> <1139929737.2466.28.camel@ender> <43F21428.7090607@beta.intcomgrp.com> <20060214125459.ewyk4kntq54cc080@mail.ph.utexas.edu> <1139948871.2466.40.camel@ender> Message-ID: On Tue, 14 Feb 2006, Jesse Keating wrote: > On Tue, 2006-02-14 at 12:54 -0600, Eric Rostetter wrote: >> >> There has been talk the last couple days of doing away with QA to get it >> to the updates-testing. This is what I was referencing, not the current >> setup. > > That is something I will not agree to. However the timeout period is, > it strikes a balance. If we see too many packages get released w/out QA > by the time the timeout hits, then that is very good indication that we > can drop that platform. There has been little or no discussion or proposals regarding doing away with QA to get to updates-testing, except for a couple of misunderstandings and an idea about "trusted fedora legacy [core] members" who could create updates-testing packages on their own (but there wasn't much discussion on that). The current policy change proposal was about reducing the amount of QA for moving updates-testing packages to updates. So, I'm not sure why we're having this conversation.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From jkeating at j2solutions.net Tue Feb 14 20:44:10 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 14 Feb 2006 12:44:10 -0800 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: References: <200602132119.20869.ben@schoolpathways.com> <20060214084912.rs8qy685zmhw8k00@mail.ph.utexas.edu> <1139929737.2466.28.camel@ender> <43F21428.7090607@beta.intcomgrp.com> <20060214125459.ewyk4kntq54cc080@mail.ph.utexas.edu> <1139948871.2466.40.camel@ender> Message-ID: <1139949850.2466.42.camel@ender> On Tue, 2006-02-14 at 22:34 +0200, Pekka Savola wrote: > > The current policy change proposal was about reducing the amount of QA > for moving updates-testing packages to updates. > > So, I'm not sure why we're having this conversation.. It is just a case of misunderstanding. Generic terms regarding QA can muddy the waters between updates-testing QA (phase 2?) and package source QA (phase 1?). -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mike.mccarty at sbcglobal.net Tue Feb 14 20:44:37 2006 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Tue, 14 Feb 2006 14:44:37 -0600 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <72dbd3150602141223j7fb8e3e1ya7020cb5fb001513@mail.gmail.com> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> <72dbd3150602141223j7fb8e3e1ya7020cb5fb001513@mail.gmail.com> Message-ID: <43F24135.2020302@sbcglobal.net> David Rees wrote: > On 2/14/06, Mike McCarty wrote: > >>I'm afraid I don't understand what you mean. Perhaps I misunderstood >>what the proposal is. My understanding is that there are new [snip] > That is correct. However, if the necessary QA votes get published > before the timeout hits, the package will be released sooner. Then the Legacy Project has removed my ability not to subscribe to "testing". >>>very self service project. You get out of it what you put into it. >> >>More accurately, I get out of it what I pull from the repositories. > > > And by not contributing any QA yourself, you can not expect to get any > QA besides what the original packager put into the release. Which is > good enough if we can't get enough QA votes to release it before the > proposed timeout hits. If it's not good enough for you, I suggest that > you QA these packages yourself. Since Legacy is no longer in my yum configuration, it's no longer an issue for me, good or bad. I don't wish to subscribe to "testing". Since "testing" and "release" have been merged, I have unsubscribed from "release". If the security notices on FC2 get severe enough, I'll just move on to CentOs, Scientific Linux, or Debian. Since I'm already helping administer a Debian box, it might make sense to move to that. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From mike.mccarty at sbcglobal.net Tue Feb 14 20:46:19 2006 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Tue, 14 Feb 2006 14:46:19 -0600 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <43F22FBB.6010403@beta.intcomgrp.com> References: <200602132119.20869.ben@schoolpathways.com> <20060214084912.rs8qy685zmhw8k00@mail.ph.utexas.edu> <1139929737.2466.28.camel@ender> <43F21428.7090607@beta.intcomgrp.com> <43F214D2.7040006@fedoraproject.org> <43F21A9C.8070004@beta.intcomgrp.com> <43F21E09.9080709@fedoraproject.org> <43F22FBB.6010403@beta.intcomgrp.com> Message-ID: <43F2419B.5080606@sbcglobal.net> James Kosin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Rahul Sundaram wrote: > >>It is referred from http://fedoraproject.org/wiki/Legacy which has a >>link from the frontpage. How is that buried in clutter?. What can we do >>to improve that?\ >> > > Don't get personal, I'm talking semantics here about not outlining them > as steps. The only way for that to be person that I can see would be for it to be sarcastic, and my experience with Mr. Sundaram leads me to believe that he was not sarcastic, but asking for help to make the web page better. [snip] Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From sundaram at fedoraproject.org Tue Feb 14 20:50:59 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 15 Feb 2006 02:20:59 +0530 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <43F24135.2020302@sbcglobal.net> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> <72dbd3150602141223j7fb8e3e1ya7020cb5fb001513@mail.gmail.com> <43F24135.2020302@sbcglobal.net> Message-ID: <43F242B3.9030802@fedoraproject.org> Mike McCarty wrote: > David Rees wrote: > >> On 2/14/06, Mike McCarty wrote: >> >>> I'm afraid I don't understand what you mean. Perhaps I misunderstood >>> what the proposal is. My understanding is that there are new >> > > [snip] > >> That is correct. However, if the necessary QA votes get published >> before the timeout hits, the package will be released sooner. > > > Then the Legacy Project has removed my ability not to subscribe > to "testing". Seems to be a misunderstanding here. There are separate repositories for testing and general legacy updates. Yes? -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From mike.mccarty at sbcglobal.net Tue Feb 14 20:52:23 2006 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Tue, 14 Feb 2006 14:52:23 -0600 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <1139948871.2466.40.camel@ender> References: <200602132119.20869.ben@schoolpathways.com> <20060214084912.rs8qy685zmhw8k00@mail.ph.utexas.edu> <1139929737.2466.28.camel@ender> <43F21428.7090607@beta.intcomgrp.com> <20060214125459.ewyk4kntq54cc080@mail.ph.utexas.edu> <1139948871.2466.40.camel@ender> Message-ID: <43F24307.1020905@sbcglobal.net> Jesse Keating wrote: > On Tue, 2006-02-14 at 12:54 -0600, Eric Rostetter wrote: > [snip] >>I don't think so. And in any case, I was refering to the suggestion on >>this list that we don't do QA to move to updates-testing, which would >>by-pass this whole issue you try to bring up. > > > Well I won't agree to anything that bypasses the patch check step. QA > must still happen before we put a package into updates-testing. I haven't noticed that you/anyone were asked. There was a pseudo-question indicating that this is what would happen, unless there was strong objection. I stated that if it happened I was going to withdraw from Legacy updates to my machine, which I think is the strongest possible objection there could be. The decision seemed to be made, anyway, so I have withdrawn. I suggest that, instead of continuing to argue with people who have made up their minds, you simply withdraw, and maintain control of what gets installed on your machine. Or perhaps you are referring to something different? > Another thing to think about is we are putting in more QA into our > updates that Fedora upstream puts into the updates it issues into live > releases. Just food for thought. IMO, good reason not to use FCx for production machines. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From jkeating at j2solutions.net Tue Feb 14 20:54:18 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 14 Feb 2006 12:54:18 -0800 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <43F242B3.9030802@fedoraproject.org> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> <72dbd3150602141223j7fb8e3e1ya7020cb5fb001513@mail.gmail.com> <43F24135.2020302@sbcglobal.net> <43F242B3.9030802@fedoraproject.org> Message-ID: <1139950458.2466.45.camel@ender> On Wed, 2006-02-15 at 02:20 +0530, Rahul Sundaram wrote: > Seems to be a misunderstanding here. There are separate repositories > for > testing and general legacy updates. Yes? > He is speaking in virtual terms. Since we would introduce a timeout, he is afraid that the quality of packages coming into released will be lower than it is right now, and be considered "testing" packages. IMHO the quality of packages hitting updates-testing is pretty on par with the quality of packages hitting Fedora updates. So I'm not so sure what the problem is here. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rostetter at mail.utexas.edu Tue Feb 14 19:56:35 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 14 Feb 2006 13:56:35 -0600 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <43F22B6D.3040503@fedoraproject.org> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> <43F22B6D.3040503@fedoraproject.org> Message-ID: <20060214135635.s150ve8q8pc8sgw0@mail.ph.utexas.edu> Quoting Rahul Sundaram : > If people are interested in testing and providing feedback they would > be able to do that within the specified time limit. If a sufficient True. > amount of people are not interested in providing feedback either the > platform can be dropped out of the legacy maintenance True. > or the update can > be pushed into the main legacy repository after QA work done by the > packager. Some have proposed to remove that step also. That is a concern. > That is the proposal. The way you can help is either by > doing the QA work or suggesting alternative proposals that would help > in preventing important security and bug fixes lagging in updates > testing for a infinite amount of time awaiting feedback. We already have such a system. The original proposal that started this thread is to shorten the timeout period. That was followed by another proposal to also put the same type of timeout on the PUBLISH as on the VERIFY. Proposal one does nothing but shorten the time period for pushing an update-testing package that doesn't have enough QA postings. Proposal two does nothing but make it possible to push packages through the entire system with NO QA AT ALL being done on them. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From mike.mccarty at sbcglobal.net Tue Feb 14 20:58:02 2006 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Tue, 14 Feb 2006 14:58:02 -0600 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <43F242B3.9030802@fedoraproject.org> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> <72dbd3150602141223j7fb8e3e1ya7020cb5fb001513@mail.gmail.com> <43F24135.2020302@sbcglobal.net> <43F242B3.9030802@fedoraproject.org> Message-ID: <43F2445A.6080504@sbcglobal.net> Rahul Sundaram wrote: > Mike McCarty wrote: > >> Then the Legacy Project has removed my ability not to subscribe >> to "testing". > > > Seems to be a misunderstanding here. There are separate repositories for > testing and general legacy updates. Yes? AIUI, there will be objects put into "testing". These then will be automatically moved to "rlease" state after either some QA takes place, or some time lapses, whichever comes first. IMO, this is tantamount to merging "test" and "release" states. Always willing to be corrected if I have misunderstood the proposal. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From jkeating at j2solutions.net Tue Feb 14 21:04:22 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 14 Feb 2006 13:04:22 -0800 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <43F2445A.6080504@sbcglobal.net> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> <72dbd3150602141223j7fb8e3e1ya7020cb5fb001513@mail.gmail.com> <43F24135.2020302@sbcglobal.net> <43F242B3.9030802@fedoraproject.org> <43F2445A.6080504@sbcglobal.net> Message-ID: <1139951062.2466.51.camel@ender> On Tue, 2006-02-14 at 14:58 -0600, Mike McCarty wrote: > > AIUI, there will be objects put into "testing". These then will be > automatically moved to "rlease" state after either some QA takes > place, or some time lapses, whichever comes first. IMO, this is > tantamount to merging "test" and "release" states. > > Always willing to be corrected if I have misunderstood the > proposal. Nope, you understand it correctly. This does not mean that no QA work gets done. The sources are QAd before they can ever go to updates-testing. The updates-testing QA is a final smoke test to make sure something really stupid didn't happen in the build process. A lot of the 'stupid things' a build process can do can also be auto checked during the build and I'll be looking to enable these. Our hope is that if this proposal scares some people, it will scare them into finding ways to help out the project so that little to no packages escape updates-testing w/out some QA done on it. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mike.mccarty at sbcglobal.net Tue Feb 14 21:09:07 2006 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Tue, 14 Feb 2006 15:09:07 -0600 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <1139950458.2466.45.camel@ender> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> <72dbd3150602141223j7fb8e3e1ya7020cb5fb001513@mail.gmail.com> <43F24135.2020302@sbcglobal.net> <43F242B3.9030802@fedoraproject.org> <1139950458.2466.45.camel@ender> Message-ID: <43F246F3.5070308@sbcglobal.net> Jesse Keating wrote: > On Wed, 2006-02-15 at 02:20 +0530, Rahul Sundaram wrote: > >>Seems to be a misunderstanding here. There are separate repositories >>for >>testing and general legacy updates. Yes? >> > > > He is speaking in virtual terms. Since we would introduce a timeout, he I was speaking in logical terms, not physical terms. > is afraid that the quality of packages coming into released will be > lower than it is right now, and be considered "testing" packages. "Afraid" is a strong term, and not one I would use to describe my emotional state. > IMHO the quality of packages hitting updates-testing is pretty on par > with the quality of packages hitting Fedora updates. So I'm not so sure > what the problem is here. Your opinion, in regards to what gets put on my machine, does not carry much weight. I have been apalled at what generally passes as QA in the "Linux Community" generally, and FC specifically. Since I barely tolerate what exists now, it is difficult to contemplate someone considering even more laxity saying "I'm not so sure what the problem is here." I am astounded, amazed, and shocked. I generally don't speak my mind so openly, because people in the "Linux Community" seem to think that SEI "chaotic" processes for software development are the best thing since sliced bread, and I don't want to start a flame war. But in this particular instance, QA is the actual topic of discussion, so it's difficult to negotiate the path between stating what is obvious to anyone who has been in any industry where real QA was an important topic, and user's control over what is on their machines was likewise important, and being careful not to step on the feelings of others. Availability and reliability are not terms I even ever see used among those in the "Linux Community", let alone actually measured. And I've never seen a new version of Linux come out with a "back out" procedure associated. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From mike.mccarty at sbcglobal.net Tue Feb 14 21:11:47 2006 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Tue, 14 Feb 2006 15:11:47 -0600 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <1139951062.2466.51.camel@ender> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> <72dbd3150602141223j7fb8e3e1ya7020cb5fb001513@mail.gmail.com> <43F24135.2020302@sbcglobal.net> <43F242B3.9030802@fedoraproject.org> <43F2445A.6080504@sbcglobal.net> <1139951062.2466.51.camel@ender> Message-ID: <43F24793.8000304@sbcglobal.net> Jesse Keating wrote: > Our hope is that if this proposal scares some people, it will scare them > into finding ways to help out the project so that little to no packages > escape updates-testing w/out some QA done on it. It doesn't frighten me at all, but it does discourage me from using the repository. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From mike.mccarty at sbcglobal.net Tue Feb 14 21:14:07 2006 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Tue, 14 Feb 2006 15:14:07 -0600 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <20060214135635.s150ve8q8pc8sgw0@mail.ph.utexas.edu> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> <43F22B6D.3040503@fedoraproject.org> <20060214135635.s150ve8q8pc8sgw0@mail.ph.utexas.edu> Message-ID: <43F2481F.6070400@sbcglobal.net> Eric Rostetter wrote: [snip] > Proposal one does nothing but shorten the time period for pushing an > update-testing package that doesn't have enough QA postings. > > Proposal two does nothing but make it possible to push packages through the > entire system with NO QA AT ALL being done on them. Thank you. I couldn't have put it better myself. I probably will not be contributing further to this thread, as I've already stated my position, and I've taken action to protect my machine by removing Legacy from yum.conf Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From jkeating at j2solutions.net Tue Feb 14 21:20:58 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 14 Feb 2006 13:20:58 -0800 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <43F246F3.5070308@sbcglobal.net> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> <72dbd3150602141223j7fb8e3e1ya7020cb5fb001513@mail.gmail.com> <43F24135.2020302@sbcglobal.net> <43F242B3.9030802@fedoraproject.org> <1139950458.2466.45.camel@ender> <43F246F3.5070308@sbcglobal.net> Message-ID: <1139952058.2466.56.camel@ender> On Tue, 2006-02-14 at 15:09 -0600, Mike McCarty wrote: > I have been apalled at what generally passes as QA in the > "Linux Community" generally, and FC specifically. Since I > barely tolerate what exists now, it is difficult to contemplate > someone considering even more laxity saying "I'm not so sure > what the problem is here." I am astounded, amazed, and shocked. I don't see a problem because this is not an enterprise class operating system, we are not an enterprise class project, and you don't get enterprise class QA for free. Please look into RHEL if you want guaranteed QA. CentOS won't be enough for you as there is very little QA that happens between the rebuild of a RHEL srpm and a push to the public. Enterprise guaranteed QA comes at a price. If you're not even willing to contribute some time to the project, why in gods name would you expect anything in return? What I am appalled by is the general feeling of "I should get things my way, and it should be free" I see in the Linux user community. As I've stated before, you get out what you put in. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Tue Feb 14 21:23:56 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 15 Feb 2006 02:53:56 +0530 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <43F24793.8000304@sbcglobal.net> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> <72dbd3150602141223j7fb8e3e1ya7020cb5fb001513@mail.gmail.com> <43F24135.2020302@sbcglobal.net> <43F242B3.9030802@fedoraproject.org> <43F2445A.6080504@sbcglobal.net> <1139951062.2466.51.camel@ender> <43F24793.8000304@sbcglobal.net> Message-ID: <43F24A6C.8000609@fedoraproject.org> Mike McCarty wrote: > Jesse Keating wrote: > >> Our hope is that if this proposal scares some people, it will scare them >> into finding ways to help out the project so that little to no packages >> escape updates-testing w/out some QA done on it. > > > It doesn't frighten me at all, but it does discourage me from using > the repository. Hopefully see the need for contributors to do the actual work involved including QA and look into that instead of moving away from the project. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From rostetter at mail.utexas.edu Tue Feb 14 21:24:30 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 14 Feb 2006 15:24:30 -0600 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: References: <200602132119.20869.ben@schoolpathways.com> <20060214084912.rs8qy685zmhw8k00@mail.ph.utexas.edu> <1139929737.2466.28.camel@ender> <43F21428.7090607@beta.intcomgrp.com> <20060214125459.ewyk4kntq54cc080@mail.ph.utexas.edu> <1139948871.2466.40.camel@ender> Message-ID: <20060214152430.4wma5mo6enxcgw4w@mail.ph.utexas.edu> Quoting Pekka Savola : > There has been little or no discussion or proposals regarding doing > away with QA to get to updates-testing, except for a couple of > misunderstandings and an idea about "trusted fedora legacy [core] > members" who could create updates-testing packages on their own (but > there wasn't much discussion on that). There may have been little talk, but there was talk. And no one has said no to it until I brought it up here. > The current policy change proposal was about reducing the amount of QA > for moving updates-testing packages to updates. Actually, IIRC, it simply reduces the time to push it through... > So, I'm not sure why we're having this conversation.. Because it was proposed, and until I started the conversation, neither you, Jesse, I, or anyone else has denounced it or retracted it. Now that Jesse and I have denounced it, and you have said you are not pushing it, the conversation can probably be terminated and forgotten. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From deisenst at gtw.net Tue Feb 14 21:47:25 2006 From: deisenst at gtw.net (David Eisenstein) Date: Tue, 14 Feb 2006 15:47:25 -0600 (CST) Subject: Risk Models and QA [Re: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing]] In-Reply-To: <43F19552.3010808@sbcglobal.net> Message-ID: On Tue, 14 Feb 2006, Mike McCarty wrote: > > >>Unless I hear major objections in two days, I'll start the two-week > >>clock (from today) for all the pending packages. > > Ok then, it seems to me that there is no longer any distinction > between the released repository, and the test repository. > So, please send out an e-mail three days before the first > "timed release" so I can pull a last tested version before > removing the legacy repository from my yum configuration. Hi Mike, and all, I just want to let you know that I have reservations about this as well. You are not alone in the way you feel about this proposed and now implemented way of ... of getting stuff done here. For my systems, I end up choosing not to use yum's automated updating feature. This is the way I've done it from day one, even when Red Hat was maintaining the security updates and upgrades for FC1. Even when packages end up going through all the stages of Fedora Legacy's previous QA methods, I still apply updates with caution, and always provide a way to restore the previously installed version of a given software package in case things suddenly stop working right after applying an update. How one chooses to update one's system(s) ends up being a matter of either personal policy or, if doing updates for a company, a matter of company policy. We have what I consider to be an excellent discussion of that kind of local decisionmaking (when and how to use Automatic Updates) on our wiki, at . I highly recommend reading it. My experience with Fedora Legacy over the year-and-a-half that I've participated in it is that the Legacy project does not have hard-and-fast standards for what people do in the last stage of QA testing (that is, the "QA Verify" testing -- testing of packages for release to updates, as documented in http://fedoraproject.org/wiki/Legacy/QAVerify). My experience is, in many cases, the people who do that QA Verify testing for the Fedora Legacy Project (including myself) are simply installing the package on their test system, running it through as little as a few paces or as much as many days worth of running it in a production-like environment, and then saying, "Ok, it works for me!" In many if not most cases of QA testing, it seems to me that the people who do it do *not* specifically test the new package for the security vulnerabilities we are purporting to fix. At least part of the reason for that is that the test cases are not available to us -- they're either embargoed somewhere, or the vulnerability is rather theoretical and has never been proven to harm anyone. This is not a scientific nor rigorous way of doing QA testing. But due to the limited time and population of folks who do testing in our community, it is the probably the best we can expect. As hard as it is for a perfec- tionist like me to accept, we're not in the business of excellence here so much as we're in the business of trade-offs. With limited manpower and time and expertise, the issue to me becomes -- "Which is the least risk?" When we can get more manpower to check packages more thoroughly, our risk goes down. When we have less manpower, the risk goes up. But if we are to be a viable project, the sense of the participants of this list as I read it is that we need to have a product pushed out in a timely fashion. For some people, the Fedora Legacy Project risk model is not for them. By the same token, for some people, the Fedora *Project* risk model is not for them, either. Not unlike the Fedora Project, the use of Fedora Legacy packages comes with a different risk model than some project like CentOS or Debian. Fedora Project is closer to the "bleeding edge," and so it is not unreasonable to expect that Fedora Legacy may also be that way. We do the best we are able. Anyone who wants to do QA testing may do so. We welcome participation at whatever level you are willing and able to do, Mike, and everyone. Thank you for expressing your thoughts, Mike. I appreciate them. Warm regards, David Eisenstein From rostetter at mail.utexas.edu Tue Feb 14 21:43:54 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 14 Feb 2006 15:43:54 -0600 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <43F242B3.9030802@fedoraproject.org> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> <72dbd3150602141223j7fb8e3e1ya7020cb5fb001513@mail.gmail.com> <43F24135.2020302@sbcglobal.net> <43F242B3.9030802@fedoraproject.org> Message-ID: <20060214154354.pohlxp5pxygo48g8@mail.ph.utexas.edu> Quoting Rahul Sundaram : >> Then the Legacy Project has removed my ability not to subscribe >> to "testing". > > Seems to be a misunderstanding here. There are separate repositories > for testing and general legacy updates. Yes? Under the new proposal, the "testing" channel becomes nothing more than a speed bump to the "updates" channel... It remains, and everything must go through it, but only to the extent of sitting there for 2 weeks. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From rostetter at mail.utexas.edu Tue Feb 14 21:45:50 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 14 Feb 2006 15:45:50 -0600 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <1139950458.2466.45.camel@ender> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> <72dbd3150602141223j7fb8e3e1ya7020cb5fb001513@mail.gmail.com> <43F24135.2020302@sbcglobal.net> <43F242B3.9030802@fedoraproject.org> <1139950458.2466.45.camel@ender> Message-ID: <20060214154550.1ly4x6a5e1b4gwgw@mail.ph.utexas.edu> Quoting Jesse Keating : > On Wed, 2006-02-15 at 02:20 +0530, Rahul Sundaram wrote: >> Seems to be a misunderstanding here. There are separate repositories >> for >> testing and general legacy updates. Yes? >> > > He is speaking in virtual terms. Since we would introduce a timeout, he > is afraid that the quality of packages coming into released will be > lower than it is right now, and be considered "testing" packages. > > IMHO the quality of packages hitting updates-testing is pretty on par > with the quality of packages hitting Fedora updates. So I'm not so sure > what the problem is here. The problem is two fold: 1) You can't use Fedora standards for the RHL releases, only for the Fedora releases. 2) This is a major change to the tenents that FL was founded on. Any such change must be by consensus. We must establish if there is a consensus or not. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From rostetter at mail.utexas.edu Tue Feb 14 21:35:01 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 14 Feb 2006 15:35:01 -0600 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <1139949850.2466.42.camel@ender> References: <200602132119.20869.ben@schoolpathways.com> <20060214084912.rs8qy685zmhw8k00@mail.ph.utexas.edu> <1139929737.2466.28.camel@ender> <43F21428.7090607@beta.intcomgrp.com> <20060214125459.ewyk4kntq54cc080@mail.ph.utexas.edu> <1139948871.2466.40.camel@ender> <1139949850.2466.42.camel@ender> Message-ID: <20060214153501.2mi5mr93qv7ocg44@mail.ph.utexas.edu> Quoting Jesse Keating : > On Tue, 2006-02-14 at 22:34 +0200, Pekka Savola wrote: >> >> The current policy change proposal was about reducing the amount of QA >> for moving updates-testing packages to updates. >> >> So, I'm not sure why we're having this conversation.. > > It is just a case of misunderstanding. Generic terms regarding QA can > muddy the waters between updates-testing QA (phase 2?) and package > source QA (phase 1?). NO! A proposal was made to effectively remove any need for QA by accepting packages without any QA. There is no misunderstanding. This was proposed on the list. Until just a few minutes ago, no one said it was dead, so it was still a valid point of conversation. Now it is dead, and can RIP. But it was not a misunderstanding, it was a real proposal made to the list. > -- > Jesse Keating RHCE (geek.j2solutions.net) > Fedora Legacy Team (www.fedoralegacy.org) > GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) > -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From rostetter at mail.utexas.edu Tue Feb 14 21:40:26 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 14 Feb 2006 15:40:26 -0600 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <43F24135.2020302@sbcglobal.net> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> <72dbd3150602141223j7fb8e3e1ya7020cb5fb001513@mail.gmail.com> <43F24135.2020302@sbcglobal.net> Message-ID: <20060214154026.ei1zupc4ajysssg0@mail.ph.utexas.edu> Quoting Mike McCarty : > Then the Legacy Project has removed my ability not to subscribe > to "testing". No, the Legacy Project has _proposed_ to that, at least in your opinion. It was followed by something like "unless we get a lot of objection" so please, if you object, let it be known. > Since Legacy is no longer in my yum configuration, it's no longer > an issue for me, good or bad. Yes, we lose a few people from the community every time this issue comes up. I guess the hope is we will gain more if we release more, but I'm not sure it is true (hasn't been so far, as far as I can tell). > I don't wish to subscribe to "testing". > Since "testing" and "release" have been merged, I have unsubscribed > from "release". No, it was proposed that we merge them, but it is still under consideration, and can still be blocked. Your action is a bit premature. But then, considering some of the responses you have received in e-mail (like having to pay to be notified) I don't blame you too much. > If the security notices on FC2 get severe enough, > I'll just move on to CentOs, Scientific Linux, or Debian. Since > I'm already helping administer a Debian box, it might make sense > to move to that. Of course your choice... > Mike -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From mike.mccarty at sbcglobal.net Tue Feb 14 21:57:57 2006 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Tue, 14 Feb 2006 15:57:57 -0600 Subject: Risk Models and QA [Re: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing]] In-Reply-To: References: Message-ID: <43F25265.9090208@sbcglobal.net> David Eisenstein wrote: > Hi Mike, and all, > > I just want to let you know that I have reservations about this as well. > You are not alone in the way you feel about this proposed and now > implemented way of ... of getting stuff done here. > > For my systems, I end up choosing not to use yum's automated updating > feature. This is the way I've done it from day one, even when Red Hat was I have never allowed an automated update to any of my systems, I run yum manually. In fact, on my Win.. machines I find that packages often want to install some "latest version" of a graphics display package. I have returned software on that basis, telling the clerk and sometimes the store manager that I bought a piece of software to do X, and it wants me also to install software to do Y. On other occasions, I have "snapshotted" my machine, installed, run, and then reverted to the "snapshot". [snip] > We do the best we are able. Anyone who wants to do QA testing may do so. > We welcome participation at whatever level you are willing and able to do, > Mike, and everyone. > > Thank you for expressing your thoughts, Mike. I appreciate them. > > Warm regards, > David Eisenstein Thanks for the kind thoughts. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From jkeating at j2solutions.net Tue Feb 14 21:58:46 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 14 Feb 2006 13:58:46 -0800 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <20060214154550.1ly4x6a5e1b4gwgw@mail.ph.utexas.edu> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> <72dbd3150602141223j7fb8e3e1ya7020cb5fb001513@mail.gmail.com> <43F24135.2020302@sbcglobal.net> <43F242B3.9030802@fedoraproject.org> <1139950458.2466.45.camel@ender> <20060214154550.1ly4x6a5e1b4gwgw@mail.ph.utexas.edu> Message-ID: <1139954326.2466.61.camel@ender> On Tue, 2006-02-14 at 15:45 -0600, Eric Rostetter wrote: > > The problem is two fold: > > 1) You can't use Fedora standards for the RHL releases, only for the > Fedora releases. You are correct. However Fedora Legacy originally was just for Fedora. It was my choice and the choice of other users to extend the Legacy project to the RHL releases. To be perfectly honest, I'm not all that interested in maintaining these RHL releases, but the community seems to be for now. > 2) This is a major change to the tenents that FL was founded on. Any such > change must be by consensus. We must establish if there is a consensus or > not. Correct. We have some of that, although with some misunderstanding on many sides (; Honestly I haven't seen enough naysayers yet to discard this shortened timeout policy. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at j2solutions.net Tue Feb 14 22:02:07 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 14 Feb 2006 14:02:07 -0800 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <20060214153501.2mi5mr93qv7ocg44@mail.ph.utexas.edu> References: <200602132119.20869.ben@schoolpathways.com> <20060214084912.rs8qy685zmhw8k00@mail.ph.utexas.edu> <1139929737.2466.28.camel@ender> <43F21428.7090607@beta.intcomgrp.com> <20060214125459.ewyk4kntq54cc080@mail.ph.utexas.edu> <1139948871.2466.40.camel@ender> <1139949850.2466.42.camel@ender> <20060214153501.2mi5mr93qv7ocg44@mail.ph.utexas.edu> Message-ID: <1139954527.2466.64.camel@ender> On Tue, 2006-02-14 at 15:35 -0600, Eric Rostetter wrote: > > But it was not a misunderstanding, it was a real proposal made to the > list. Then the misunderstanding was on my part, as I was not aware a real proposal was made to this affect. The proposal about shortening the timeout I was aware of, and AFAIK someone jumped to a conclusion that we were doing away with QA and started the tail chasing we've been doing for the past day. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rostetter at mail.utexas.edu Tue Feb 14 21:49:02 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 14 Feb 2006 15:49:02 -0600 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <1139951062.2466.51.camel@ender> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> <72dbd3150602141223j7fb8e3e1ya7020cb5fb001513@mail.gmail.com> <43F24135.2020302@sbcglobal.net> <43F242B3.9030802@fedoraproject.org> <43F2445A.6080504@sbcglobal.net> <1139951062.2466.51.camel@ender> Message-ID: <20060214154902.bthmh0tfnj6s4go4@mail.ph.utexas.edu> Quoting Jesse Keating : > Our hope is that if this proposal scares some people, it will scare them > into finding ways to help out the project so that little to no packages > escape updates-testing w/out some QA done on it. My fear is that we spend more time arguing about these than we do testing. As I've said the last 3-4 times this came up; if each of us spent as much time QA testing packages as we do arguing about the QA processing on the mailing list, we wouldn't have any problem at all. I know these threads stop me from doing any QA while they are going on. > -- > Jesse Keating RHCE (geek.j2solutions.net) > Fedora Legacy Team (www.fedoralegacy.org) > GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) > -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From rostetter at mail.utexas.edu Tue Feb 14 22:12:33 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 14 Feb 2006 16:12:33 -0600 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <1139954326.2466.61.camel@ender> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> <72dbd3150602141223j7fb8e3e1ya7020cb5fb001513@mail.gmail.com> <43F24135.2020302@sbcglobal.net> <43F242B3.9030802@fedoraproject.org> <1139950458.2466.45.camel@ender> <20060214154550.1ly4x6a5e1b4gwgw@mail.ph.utexas.edu> <1139954326.2466.61.camel@ender> Message-ID: <20060214161233.dlbg3xzya3r48wo8@mail.ph.utexas.edu> Quoting Jesse Keating : > On Tue, 2006-02-14 at 15:45 -0600, Eric Rostetter wrote: >> >> The problem is two fold: >> >> 1) You can't use Fedora standards for the RHL releases, only for the >> Fedora releases. > > You are correct. However Fedora Legacy originally was just for Fedora. > It was my choice and the choice of other users to extend the Legacy > project to the RHL releases. To be perfectly honest, I'm not all that > interested in maintaining these RHL releases, but the community seems to > be for now. This is not the impression the project gives off in any way other than its name. >> 2) This is a major change to the tenents that FL was founded on. Any such >> change must be by consensus. We must establish if there is a consensus or >> not. > > Correct. We have some of that, although with some misunderstanding on > many sides (; > > Honestly I haven't seen enough naysayers yet to discard this shortened > timeout policy. Nor have I seen enough people in favor of it to counter those against it. In other words, we have very few stating anything at all. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From mike.mccarty at sbcglobal.net Tue Feb 14 22:30:24 2006 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Tue, 14 Feb 2006 16:30:24 -0600 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <1139952058.2466.56.camel@ender> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> <72dbd3150602141223j7fb8e3e1ya7020cb5fb001513@mail.gmail.com> <43F24135.2020302@sbcglobal.net> <43F242B3.9030802@fedoraproject.org> <1139950458.2466.45.camel@ender> <43F246F3.5070308@sbcglobal.net> <1139952058.2466.56.camel@ender> Message-ID: <43F25A00.1050004@sbcglobal.net> Jesse Keating wrote: > On Tue, 2006-02-14 at 15:09 -0600, Mike McCarty wrote: > >>I have been apalled at what generally passes as QA in the >>"Linux Community" generally, and FC specifically. Since I >>barely tolerate what exists now, it is difficult to contemplate >>someone considering even more laxity saying "I'm not so sure >>what the problem is here." I am astounded, amazed, and shocked. > > > I don't see a problem because this is not an enterprise class operating > system, we are not an enterprise class project, and you don't get I guess that I didn't quite make myself clear, using an undefined and perhaps ambiguous term "Linux Community". By this term I mean those who work on Linux, GNU, and all applications which generally are released by those who like the idea of Linux+GNU. Software development in this rather amorphous network of contributors has what SEI would call a "chaotic" process. > enterprise class QA for free. Please look into RHEL if you want > guaranteed QA. CentOS won't be enough for you as there is very little I am apalled at what passes for QA in every distribution I have had experience with. I said "Linux Community". This includes even things which are neither Linux, nor GNU. Major distros I have experience with: Red Hat (pre enterprise) Blue Hat LynxOs (redist) Fedora Core Debian SuSe Mandrake (now Mandrivia) Slackware I was involved in a cooperative effort with some people at Red Hat corp. to beef up the QA they do with Blue Hat, though I was never really satisfied with their procedures. I have to admit that I found Greg Rose with Blue Hat a very nice guy, and used to eat lunch with him on a semi-regular basis. But he was reluctant about implementing any real QA changes. I was disappointed when LynxOs picked up Linux and abandoned their own product, which was superior. I also have some experience with minor distros. (Well, maybe LynxOs should be put into the minor list. Or even Blue Hat. But I think that most of the others will be recognized by most people here.) > What I am appalled by is the general feeling of "I should get things my > way, and it should be free" I see in the Linux user community. As I've > stated before, you get out what you put in. I get out what I download, be it good or bad. In some cases, I got what I paid for. Red Hat, Blue Hat, LynxOs, SuSe and Mandrivia are *not* free. I haven't said one word demanding, insisting, or even requesting that things be done differently. I have stated what my actions would be if the new policy is implemented, and I have taken those actions. So I guess I'm not one of the general "Linux user community" you refer to. I wonder how profitable further discussion would be? Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From mike.mccarty at sbcglobal.net Tue Feb 14 22:41:26 2006 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Tue, 14 Feb 2006 16:41:26 -0600 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <20060214154026.ei1zupc4ajysssg0@mail.ph.utexas.edu> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> <72dbd3150602141223j7fb8e3e1ya7020cb5fb001513@mail.gmail.com> <43F24135.2020302@sbcglobal.net> <20060214154026.ei1zupc4ajysssg0@mail.ph.utexas.edu> Message-ID: <43F25C96.4010109@sbcglobal.net> Eric Rostetter wrote: > Quoting Mike McCarty : > >> Then the Legacy Project has removed my ability not to subscribe >> to "testing". > > > No, the Legacy Project has _proposed_ to that, at least in your opinion. > It was followed by something like "unless we get a lot of objection" so > please, if you object, let it be known. I did object, and then I saw that the decision was *made*. >> Since Legacy is no longer in my yum configuration, it's no longer >> an issue for me, good or bad. > > > Yes, we lose a few people from the community every time this issue comes > up. I guess the hope is we will gain more if we release more, but I'm not > sure it is true (hasn't been so far, as far as I can tell). You didn't "lose" me because the issue came up, you "lost" me because /a decision was made/. >> I don't wish to subscribe to "testing". >> Since "testing" and "release" have been merged, I have unsubscribed >> from "release". > > No, it was proposed that we merge them, but it is still under > consideration, > and can still be blocked. Your action is a bit premature. But then, > considering some of the responses you have received in e-mail (like having > to pay to be notified) I don't blame you too much. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From sundaram at fedoraproject.org Tue Feb 14 22:55:07 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 15 Feb 2006 04:25:07 +0530 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <43F25C96.4010109@sbcglobal.net> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> <72dbd3150602141223j7fb8e3e1ya7020cb5fb001513@mail.gmail.com> <43F24135.2020302@sbcglobal.net> <20060214154026.ei1zupc4ajysssg0@mail.ph.utexas.edu> <43F25C96.4010109@sbcglobal.net> Message-ID: <43F25FCB.3030301@fedoraproject.org> Mike McCarty wrote: > Eric Rostetter wrote: > >> Quoting Mike McCarty : >> >>> Then the Legacy Project has removed my ability not to subscribe >>> to "testing". >> >> >> >> No, the Legacy Project has _proposed_ to that, at least in your opinion. >> It was followed by something like "unless we get a lot of objection" so >> please, if you object, let it be known. > > > I did object, and then I saw that the decision was *made*. A decision hasnt been made. Even if one has been made it can be reverted. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From deisenst at gtw.net Tue Feb 14 22:55:15 2006 From: deisenst at gtw.net (David Eisenstein) Date: Tue, 14 Feb 2006 16:55:15 -0600 (CST) Subject: The actual proposed QA changes - getting on same page Message-ID: Here below is my understanding of what has been proposed and (correct me if I am wrong) appear to be in the process of being implemented. Fedora Legacy QA Process Overview w/Proposed Changes ---------------------------------------------------- 1. Vulnerability discerned. 2. Bugzilla ticket for package and vulnerability (with CVE #) opened. 3. Source package(s) for vulnerability proposed. 4. People do SOURCE LEVEL ("PUBLISH") QA on the packages and report in Bugzilla their findings. 5. Once all source packages have been voted for PUBLISH, new signed packages are built and both .src.rpm and (.i386|.x86_64).rpm packages are pushed to updates-testing. An announcement goes out to fedora-legacy-list announcing that packages are ready for testing and asking for participation in doing VERIFY QA. NOTE: If there are any objections in the PUBLISH QA or if any distro does not receive a PUBLISH vote, nothing further is done with that package until the issue(s) are resolved. Old Policy - VERIFY QA to RELEASE: 6. If no positive votes happen on binary packages in updates-testing, they stay in updates-testing and go no further. 7. If one positive vote happens on one distro for pkgs. in updates- testing, a 4-week timeout is set. If no further votes happen before timeout, then after 4 weeks, all packages are released to updates. 8. If two or more distro's (but less than all distros) have positive votes, the 4-week timeout is reduced to a two-week timeout at the time the 2nd distro has a "+" vote. At timeout, all packages are released to updates. 9. If all distros get "+" votes, binary packages are considered fully tested, and can be released to updates straight away. New (Proposed Policy) - VERIFY QA to RELEASE: 6. If no positive votes happen on binary packages in updates-testing, they will be released after a 2-week timeout after having placed in updates-testing. 7. If one positive vote happens on one distro for the pkgs. in updates- testing, the 2-week timeout is reduced to 1-week from the point of the first positive vote. 8. If two or more distro's (but less than all distros) have positive votes, the same timeout in step (7) of the new policy applies. 9. As in the old policy, if all distros get "+" votes, binary pack- ages are considered fully tested and can be released to updates right away. Both policies: 10. Packages released to updates from updates-testing are announced on fedora-legacy-list and fedora-legacy-announce-list. -David From marcdeslauriers at videotron.ca Tue Feb 14 22:51:20 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 14 Feb 2006 17:51:20 -0500 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <43F24135.2020302@sbcglobal.net> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> <72dbd3150602141223j7fb8e3e1ya7020cb5fb001513@mail.gmail.com> <43F24135.2020302@sbcglobal.net> Message-ID: <1139957480.25327.18.camel@mdlinux> On Tue, 2006-02-14 at 14:44 -0600, Mike McCarty wrote: > Since Legacy is no longer in my yum configuration, it's no longer > an issue for me, good or bad. I don't wish to subscribe to "testing". > Since "testing" and "release" have been merged, I have unsubscribed > from "release". If the security notices on FC2 get severe enough, > I'll just move on to CentOs, Scientific Linux, or Debian. Since > I'm already helping administer a Debian box, it might make sense > to move to that. Just out of curiosity, what are the Debian, CentOS and Scientific Linux QA procedures? Maybe Fedora Legacy could use some of them to get FL releases up to their standards. They do have documented QA procedures, right? Marc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mike.mccarty at sbcglobal.net Tue Feb 14 23:54:47 2006 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Tue, 14 Feb 2006 17:54:47 -0600 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <1139957480.25327.18.camel@mdlinux> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> <72dbd3150602141223j7fb8e3e1ya7020cb5fb001513@mail.gmail.com> <43F24135.2020302@sbcglobal.net> <1139957480.25327.18.camel@mdlinux> Message-ID: <43F26DC7.5040107@sbcglobal.net> Marc Deslauriers wrote: > On Tue, 2006-02-14 at 14:44 -0600, Mike McCarty wrote: > >>Since Legacy is no longer in my yum configuration, it's no longer >>an issue for me, good or bad. I don't wish to subscribe to "testing". >>Since "testing" and "release" have been merged, I have unsubscribed >>from "release". If the security notices on FC2 get severe enough, >>I'll just move on to CentOs, Scientific Linux, or Debian. Since >>I'm already helping administer a Debian box, it might make sense >>to move to that. > > > Just out of curiosity, what are the Debian, CentOS and Scientific Linux > QA procedures? Maybe Fedora Legacy could use some of them to get FL > releases up to their standards. They do have documented QA procedures, > right? CentOs does, I know. I've also read that for Scientific Linux. Scientific Linux makes sure that they rebuild the same binary as RHEL. It isn't what I like, but it's better than "no one has actually used it for two weeks, so I guess we'd better put it on your machine." Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From sundaram at fedoraproject.org Wed Feb 15 00:14:46 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 15 Feb 2006 05:44:46 +0530 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <1139957480.25327.18.camel@mdlinux> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> <72dbd3150602141223j7fb8e3e1ya7020cb5fb001513@mail.gmail.com> <43F24135.2020302@sbcglobal.net> <1139957480.25327.18.camel@mdlinux> Message-ID: <43F27276.4010306@fedoraproject.org> Marc Deslauriers wrote: >On Tue, 2006-02-14 at 14:44 -0600, Mike McCarty wrote: > > >>Since Legacy is no longer in my yum configuration, it's no longer >>an issue for me, good or bad. I don't wish to subscribe to "testing". >>Since "testing" and "release" have been merged, I have unsubscribed >>from "release". If the security notices on FC2 get severe enough, >>I'll just move on to CentOs, Scientific Linux, or Debian. Since >>I'm already helping administer a Debian box, it might make sense >>to move to that. >> >> > >Just out of curiosity, what are the Debian, CentOS and Scientific Linux >QA procedures? Maybe Fedora Legacy could use some of them to get FL >releases up to their standards. They do have documented QA procedures, >right? > > You think?. I am not so sure they are well documented at all and Debian says on http://qa.debian.org/ "We know that, at the moment, there is no real quality assurance for Debian, in a conventional meaning of that term". Feel free to look for better QA processes than Fedora legacy within the community distributions and suggest ideas. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From sundaram at fedoraproject.org Wed Feb 15 00:16:18 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 15 Feb 2006 05:46:18 +0530 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <43F26DC7.5040107@sbcglobal.net> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> <72dbd3150602141223j7fb8e3e1ya7020cb5fb001513@mail.gmail.com> <43F24135.2020302@sbcglobal.net> <1139957480.25327.18.camel@mdlinux> <43F26DC7.5040107@sbcglobal.net> Message-ID: <43F272D2.1030300@fedoraproject.org> Hi > > CentOs does, I know. I've also read that for Scientific Linux. > Scientific Linux makes sure that they rebuild the same binary > as RHEL. It isn't what I like, but it's better > than "no one has actually used it for two weeks, so I guess > we'd better put it on your machine." I would like to see what the formal policies within these projects are for doing QA is. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From mike.mccarty at sbcglobal.net Wed Feb 15 00:30:51 2006 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Tue, 14 Feb 2006 18:30:51 -0600 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <43F27276.4010306@fedoraproject.org> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> <72dbd3150602141223j7fb8e3e1ya7020cb5fb001513@mail.gmail.com> <43F24135.2020302@sbcglobal.net> <1139957480.25327.18.camel@mdlinux> <43F27276.4010306@fedoraproject.org> Message-ID: <43F2763B.5080503@sbcglobal.net> Rahul Sundaram wrote: > Marc Deslauriers wrote: > >> On Tue, 2006-02-14 at 14:44 -0600, Mike McCarty wrote: >> >> >>> Since Legacy is no longer in my yum configuration, it's no longer >>> an issue for me, good or bad. I don't wish to subscribe to "testing". >>> Since "testing" and "release" have been merged, I have unsubscribed >>> from "release". If the security notices on FC2 get severe enough, >>> I'll just move on to CentOs, Scientific Linux, or Debian. Since >>> I'm already helping administer a Debian box, it might make sense >>> to move to that. >>> >> >> >> Just out of curiosity, what are the Debian, CentOS and Scientific Linux >> QA procedures? Maybe Fedora Legacy could use some of them to get FL >> releases up to their standards. They do have documented QA procedures, >> right? >> >> > You think?. I am not so sure they are well documented at all and Debian > says on http://qa.debian.org/ "We know that, at the moment, there is no > real quality assurance for Debian, in a conventional meaning of that > term". Feel free to look for better QA processes than Fedora legacy > within the community distributions and suggest ideas. > Yes, my indictment earlier was for *all* distributions of Linux. But Legacy has gone further than I can follow along, that's all. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From sundaram at fedoraproject.org Wed Feb 15 00:43:02 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 15 Feb 2006 06:13:02 +0530 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <43F2763B.5080503@sbcglobal.net> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> <72dbd3150602141223j7fb8e3e1ya7020cb5fb001513@mail.gmail.com> <43F24135.2020302@sbcglobal.net> <1139957480.25327.18.camel@mdlinux> <43F27276.4010306@fedoraproject.org> <43F2763B.5080503@sbcglobal.net> Message-ID: <43F27916.6050503@fedoraproject.org> Hi > > Yes, my indictment earlier was for *all* distributions of Linux. > But Legacy has gone further than I can follow along, that's all. We are merely discussing a proposal so legacy process hasnt gone further at all. You also state that other distributions QA process is better. How do we know?. If they are better are you willing to get involved in QA with the legacy project to help it be better?. Thats what we need. More contributors working on it. Other discussions is just fluff. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From mike.mccarty at sbcglobal.net Wed Feb 15 01:08:36 2006 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Tue, 14 Feb 2006 19:08:36 -0600 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <43F27916.6050503@fedoraproject.org> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> <72dbd3150602141223j7fb8e3e1ya7020cb5fb001513@mail.gmail.com> <43F24135.2020302@sbcglobal.net> <1139957480.25327.18.camel@mdlinux> <43F27276.4010306@fedoraproject.org> <43F2763B.5080503@sbcglobal.net> <43F27916.6050503@fedoraproject.org> Message-ID: <43F27F14.9000707@sbcglobal.net> Rahul Sundaram wrote: > Hi > >> >> Yes, my indictment earlier was for *all* distributions of Linux. >> But Legacy has gone further than I can follow along, that's all. > > > We are merely discussing a proposal so legacy process hasnt gone further That is not my understanding. > at all. You also state that other distributions QA process is better. Other distros do have better QA, as Red Hat itself says about FCx. RHEL has, per Red Hat, better QA than FC. > How do we know?. If they are better are you willing to get involved in Well, I guess that Red Hat could be mistaken or misleading about its own products and projects, but I doubt that. > QA with the legacy project to help it be better?. Thats what we need. > More contributors working on it. Other discussions is just fluff. No, I am not. I sent out an e-mail some weeks ago suggesting that if there were an easy way for me to test without endangering the stability of my system, then I'd be willing to do some QA testing. The silence in response to that message was completely deafening. It got not even one reply. I saw recently some things about using VmWare perhaps allowing one to do testing in a protected environment, but no one really seems interested in following up on that. So, while there is no backout procedure for the testing packages, I am unwilling to do any testing. And, before I get more unwelcome messages about "You get out what you put in." If someone offers something up free, without expectation of recompense, and I accept it, giving back no recompense, then I do not feel that I have done anything criminal, unethical, immoral, lazy, ungrateful, or even unfriendly. So those of you who are tempted to respond along these lines, save your collective breath. However, I don't like those who look gift horses in the mouth any more than any of you do. So I'm not one to complain about FC. I use it. I don't have to like it or where it comes from, but I don't complain about it unless I pay for it. When I installed Red Hat 6.something and paid for it, I *did* complain, and left Linux and especially Red Hat for quite some time due to what I perceived to be the inadequate response of Red Hat at that time ("buy the next version"). I installed FC2 because a company I got a contract with *asked* me to. That contract has now expired, so I have no mooring to FCx other than inertia in changing what is already set up and "working". I also don't want to make it my hobby, any more than I want to make Windows my hobby. But I'm not complaining about Fcx, or Legacy for FC2 in particular. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From rostetter at mail.utexas.edu Wed Feb 15 02:57:22 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 14 Feb 2006 20:57:22 -0600 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <43F27F14.9000707@sbcglobal.net> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> <72dbd3150602141223j7fb8e3e1ya7020cb5fb001513@mail.gmail.com> <43F24135.2020302@sbcglobal.net> <1139957480.25327.18.camel@mdlinux> <43F27276.4010306@fedoraproject.org> <43F2763B.5080503@sbcglobal.net> <43F27916.6050503@fedoraproject.org> <43F27F14.9000707@sbcglobal.net> Message-ID: <20060214205722.u0n8142bq97o0wg4@mail.ph.utexas.edu> Quoting Mike McCarty : > I sent out an e-mail some weeks ago suggesting that if > there were an easy way for me to test without endangering the stability > of my system, then I'd be willing to do some QA testing. The silence > in response to that message was completely deafening. That simply isn't true. If you were concerned about progress, you should have asked for an update. Jesse said he was taking the idea of a vmplayer image up the chain for approval. It was discussed a fair amount here. Several people asked about just creating good docs for using VM systems for QA. I started trying to code some stuff up to better automate the QA process to make it easier for people to get involved, and I still plan to work on them once this thread dies down. > It got not > even one reply. I saw recently some things about using VmWare perhaps > allowing one to do testing in a protected environment, but no one > really seems interested in following up on that. That simply isn't true. This is being followed up, and it was due in part to your postings. > So, while there is no backout procedure for the testing packages, > I am unwilling to do any testing. That is BS. You haven't even tried. > And, before I get more unwelcome messages about "You get out what you > put in." You get what the community puts in, where "community" means all those involved in any way in FL. You are part of the community, but you are free to leave the community if you want. > If someone offers something up free, without expectation of recompense, > and I accept it, giving back no recompense, then I do not feel > that I have done anything criminal, unethical, immoral, lazy, > ungrateful, or even unfriendly. So those of you who are tempted > to respond along these lines, save your collective breath. You have not done anything criminal, unethical, immoral, ungrateful, or unfriendly in using the packages FL produces. Lazy, well, matter of opinion. Ungrateful, only if you complain about the project while unwilling to help to improve it. The idea behind a community project is you can't complain loudly (but you can ask questions, and make suggestions) unless you are willing to help out. We're giving the stuff away for free, and in return we ask that those not helping don't complain. However, we should always accept helpful suggestions, comments, tips, hints, support, even constructive critisism. Just not complaints by people unwilling to help out. The other idea is you have to wait until we get around to what you want. You can't post a suggestion and expect we will all spend 12 hours a day working on it. It might take months to get it done. You have to be patient, or willing to help. You can't refuse to participate and refuse to wait for the results. > But I'm not complaining about Fcx, or Legacy for FC2 in particular. Okay. > Mike -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From deisenst at gtw.net Wed Feb 15 07:36:20 2006 From: deisenst at gtw.net (David Eisenstein) Date: Wed, 15 Feb 2006 01:36:20 -0600 (CST) Subject: New GPG key Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi folks, Here is a new PGP key I will be using to sometimes sign testing packages, in addition to my regular key: $ gpg --fingerprint 0x7910794F pub 1024D/7910794F 2006-02-15 David Eisenstein (Legacy package signature key) Key fingerprint = C417 B860 0B85 7EDC 2E0C F68C 1B2A D689 7910 794F sub 1024g/AA7E31F3 2006-02-15 You can download the public key for 7910794F from: , or retrieve it from pgpkeys.mit.edu. Thanks. -David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFD8tn8xou1V/j9XZwRAkUbAKDVjnUv0aKbnQzVsSbnrIyXx3rbYgCfSm1G iokQfDSA1B+8Fv8BqKq35QU= =Mp8z -----END PGP SIGNATURE----- From sundaram at fedoraproject.org Wed Feb 15 10:37:01 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 15 Feb 2006 16:07:01 +0530 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <43F27F14.9000707@sbcglobal.net> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> <72dbd3150602141223j7fb8e3e1ya7020cb5fb001513@mail.gmail.com> <43F24135.2020302@sbcglobal.net> <1139957480.25327.18.camel@mdlinux> <43F27276.4010306@fedoraproject.org> <43F2763B.5080503@sbcglobal.net> <43F27916.6050503@fedoraproject.org> <43F27F14.9000707@sbcglobal.net> Message-ID: <43F3044D.3080302@fedoraproject.org> Mike McCarty wrote: > Rahul Sundaram wrote: > >> Hi >> >>> >>> Yes, my indictment earlier was for *all* distributions of Linux. >>> But Legacy has gone further than I can follow along, that's all. >> >> >> >> We are merely discussing a proposal so legacy process hasnt gone further > > > That is not my understanding. > >> at all. You also state that other distributions QA process is better. > > > Other distros do have better QA, as Red Hat itself says about FCx. > RHEL has, per Red Hat, better QA than FC. Comparing a commercial product to a community project is unfair. Lets hear about QA processes documented in other community projects. > >> How do we know?. If they are better are you willing to get involved in > > > Well, I guess that Red Hat could be mistaken or misleading about > its own products and projects, but I doubt that. See above. > >> QA with the legacy project to help it be better?. Thats what we >> need. More contributors working on it. Other discussions is just fluff. > > > No, I am not. > > I sent out an e-mail some weeks ago suggesting that if > there were an easy way for me to test without endangering the stability > of my system, then I'd be willing to do some QA testing. The silence > in response to that message was completely deafening. It got not > even one reply. I saw recently some things about using VmWare perhaps > allowing one to do testing in a protected environment, but no one > really seems interested in following up on that. > > So, while there is no backout procedure for the testing packages, > I am unwilling to do any testing. See the other mails regarding this. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From mike.mccarty at sbcglobal.net Wed Feb 15 12:04:51 2006 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Wed, 15 Feb 2006 06:04:51 -0600 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <43F3044D.3080302@fedoraproject.org> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> <72dbd3150602141223j7fb8e3e1ya7020cb5fb001513@mail.gmail.com> <43F24135.2020302@sbcglobal.net> <1139957480.25327.18.camel@mdlinux> <43F27276.4010306@fedoraproject.org> <43F2763B.5080503@sbcglobal.net> <43F27916.6050503@fedoraproject.org> <43F27F14.9000707@sbcglobal.net> <43F3044D.3080302@fedoraproject.org> Message-ID: <43F318E3.5070500@sbcglobal.net> Rahul Sundaram wrote: > Mike McCarty wrote: > >> Rahul Sundaram wrote: >> >>> Hi >>> >>>> >>>> Yes, my indictment earlier was for *all* distributions of Linux. >>>> But Legacy has gone further than I can follow along, that's all. >>> >>> >>> >>> >>> We are merely discussing a proposal so legacy process hasnt gone further >> >> >> >> That is not my understanding. >> >>> at all. You also state that other distributions QA process is better. >> >> >> >> Other distros do have better QA, as Red Hat itself says about FCx. >> RHEL has, per Red Hat, better QA than FC. > > > Comparing a commercial product to a community project is unfair. Lets > hear about QA processes documented in other community projects. Eh? My comment, as I asserted again, was about all Linux distros. None of them has adequate QA. But I know of nobody who has proposed to move software automatically from a test state to a release state merely based on time elapsed except for FC and FCL. [snip] > See the other mails regarding this. Certainly did. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From sundaram at fedoraproject.org Wed Feb 15 12:19:57 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 15 Feb 2006 17:49:57 +0530 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <43F318E3.5070500@sbcglobal.net> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> <72dbd3150602141223j7fb8e3e1ya7020cb5fb001513@mail.gmail.com> <43F24135.2020302@sbcglobal.net> <1139957480.25327.18.camel@mdlinux> <43F27276.4010306@fedoraproject.org> <43F2763B.5080503@sbcglobal.net> <43F27916.6050503@fedoraproject.org> <43F27F14.9000707@sbcglobal.net> <43F3044D.3080302@fedoraproject.org> <43F318E3.5070500@sbcglobal.net> Message-ID: <43F31C6D.1080207@fedoraproject.org> Hi >>> >>> Other distros do have better QA, as Red Hat itself says about FCx. >>> RHEL has, per Red Hat, better QA than FC. >> >> >> >> Comparing a commercial product to a community project is unfair. Lets >> hear about QA processes documented in other community projects. > > > Eh? My comment, as I asserted again, was about all Linux distros. > None of them has adequate QA This is not a discussion about personal opinions on QA policies within all distributions including commercial ones. Only about whether Fedora legacy can improve itself to match a better policy within the community distributions. > . But I know of nobody who has proposed > to move software automatically from a test state to a release state > merely based on time elapsed except for FC and FCL. Feel free to point to Fedora legacy a better documented policy within the community distributions or better yet contribute towards improving it. The time spend in discussions on the list could be directed towards actual work. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From mike.mccarty at sbcglobal.net Wed Feb 15 13:16:31 2006 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Wed, 15 Feb 2006 07:16:31 -0600 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <43F31C6D.1080207@fedoraproject.org> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> <72dbd3150602141223j7fb8e3e1ya7020cb5fb001513@mail.gmail.com> <43F24135.2020302@sbcglobal.net> <1139957480.25327.18.camel@mdlinux> <43F27276.4010306@fedoraproject.org> <43F2763B.5080503@sbcglobal.net> <43F27916.6050503@fedoraproject.org> <43F27F14.9000707@sbcglobal.net> <43F3044D.3080302@fedoraproject.org> <43F318E3.5070500@sbcglobal.net> <43F31C6D.1080207@fedoraproject.org> Message-ID: <43F329AF.8000704@sbcglobal.net> Rahul Sundaram wrote: > This is not a discussion about personal opinions on QA policies within I haven't presumed to dictate the content of your messages, or state what your intended topic was. Please grant me the same privilege. Or are you acting as a moderator? Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From sundaram at fedoraproject.org Wed Feb 15 13:40:28 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 15 Feb 2006 19:10:28 +0530 Subject: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing] In-Reply-To: <43F329AF.8000704@sbcglobal.net> References: <1139531948.3490.3.camel@ender> <1139669908.20848.11.camel@mdlinux> <200602132115.38856.ben@schoolpathways.com> <43F19552.3010808@sbcglobal.net> <1139929622.2466.25.camel@ender> <43F22821.4080606@sbcglobal.net> <72dbd3150602141223j7fb8e3e1ya7020cb5fb001513@mail.gmail.com> <43F24135.2020302@sbcglobal.net> <1139957480.25327.18.camel@mdlinux> <43F27276.4010306@fedoraproject.org> <43F2763B.5080503@sbcglobal.net> <43F27916.6050503@fedoraproject.org> <43F27F14.9000707@sbcglobal.net> <43F3044D.3080302@fedoraproject.org> <43F318E3.5070500@sbcglobal.net> <43F31C6D.1080207@fedoraproject.org> <43F329AF.8000704@sbcglobal.net> Message-ID: <43F32F4C.3060709@fedoraproject.org> Mike McCarty wrote: > Rahul Sundaram wrote: > >> This is not a discussion about personal opinions on QA policies within > > > I haven't presumed to dictate the content of your messages, or state > what your intended topic was. Please grant me the same privilege. > > Or are you acting as a moderator? No but stick to topic. Thats common courtesy. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From ben at schoolpathways.com Thu Feb 16 02:46:04 2006 From: ben at schoolpathways.com (Benjamin Smith) Date: Wed, 15 Feb 2006 18:46:04 -0800 Subject: The actual proposed QA changes - getting on same page In-Reply-To: References: Message-ID: <200602151846.04888.ben@schoolpathways.com> I like this proposed change. -Ben On Tuesday 14 February 2006 14:55, David Eisenstein wrote: > Here below is my understanding of what has been proposed and (correct me > if I am wrong) appear to be in the process of being implemented. > > Fedora Legacy QA Process Overview w/Proposed Changes > ---------------------------------------------------- > > 1. Vulnerability discerned. > 2. Bugzilla ticket for package and vulnerability (with CVE #) opened. > 3. Source package(s) for vulnerability proposed. > 4. People do SOURCE LEVEL ("PUBLISH") QA on the packages and report > in Bugzilla their findings. > 5. Once all source packages have been voted for PUBLISH, new > signed packages are built and both .src.rpm and (.i386|.x86_64).rpm > packages are pushed to updates-testing. An announcement goes out > to fedora-legacy-list announcing that packages are ready for testing > and asking for participation in doing VERIFY QA. > NOTE: If there are any objections in the PUBLISH QA or if any > distro does not receive a PUBLISH vote, nothing further is done > with that package until the issue(s) are resolved. > > Old Policy - VERIFY QA to RELEASE: > 6. If no positive votes happen on binary packages in updates-testing, > they stay in updates-testing and go no further. > 7. If one positive vote happens on one distro for pkgs. in updates- > testing, a 4-week timeout is set. If no further votes happen > before timeout, then after 4 weeks, all packages are released to > updates. > 8. If two or more distro's (but less than all distros) have positive > votes, the 4-week timeout is reduced to a two-week timeout at the > time the 2nd distro has a "+" vote. At timeout, all packages are > released to updates. > 9. If all distros get "+" votes, binary packages are considered fully > tested, and can be released to updates straight away. > > New (Proposed Policy) - VERIFY QA to RELEASE: > 6. If no positive votes happen on binary packages in updates-testing, > they will be released after a 2-week timeout after having placed > in updates-testing. > 7. If one positive vote happens on one distro for the pkgs. in updates- > testing, the 2-week timeout is reduced to 1-week from the point > of the first positive vote. > 8. If two or more distro's (but less than all distros) have positive > votes, the same timeout in step (7) of the new policy applies. > 9. As in the old policy, if all distros get "+" votes, binary pack- > ages are considered fully tested and can be released to updates > right away. > > Both policies: > 10. Packages released to updates from updates-testing are announced > on fedora-legacy-list and fedora-legacy-announce-list. > > > -David > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > -- "I kept looking around for somebody to solve the problem. Then I realized I am somebody" -Anonymous From rostetter at mail.utexas.edu Thu Feb 16 03:09:10 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 15 Feb 2006 21:09:10 -0600 Subject: The actual proposed QA changes - getting on same page In-Reply-To: References: Message-ID: <20060215210910.6n5i09blxjcgoo84@mail.ph.utexas.edu> Quoting David Eisenstein : > Here below is my understanding of what has been proposed and (correct me > if I am wrong) appear to be in the process of being implemented. The list appears to be perfect, and is very useful to understanding the proposal and all the related issues. Thanks for preparing and posting it. It would have been useful to have this type of thing earlier. Having said that, for the record, I'm against the changes... That's all I'm going to say. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From donjr at maner.org Thu Feb 16 17:18:27 2006 From: donjr at maner.org (Donald Maner) Date: Thu, 16 Feb 2006 11:18:27 -0600 Subject: VMware with 2.6 kernels Message-ID: With the discussion of using VMware to help with the QA process, I felt I should speak up and add my experience over the past week getting a fc2 and fc3 vm going. The biggest problem I came across was that I had to recompile the fc2 and fc3 kernels to reduce the HZ setting in include/asm-i386/params.h from 1000 to 100. At 1000, the VMs were too slow to do any real work. The vmware discussion forums were great in pointing out that was the problem with the slowness. I'm running my VMs on ESX Server 2.5.2, so I don't know if the latest Server beta or VMWare workstation 5.5 are any better. But someone does put out pre-made VMWare images to help with QA, those images probably need a 100 HZ kernel in them. Thanks, Donald -------------- next part -------------- An HTML attachment was scrubbed... URL: From gene.heskett at verizon.net Fri Feb 17 01:31:57 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Thu, 16 Feb 2006 20:31:57 -0500 Subject: firefox-chatzilla for fc2?? Message-ID: <200602162031.57730.gene.heskett@verizon.net> The subject line is the question. I have it for moz, but I'm wondering if there is a chatzilla plugin for firefox-1.5*? -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From jedgecombe at carolina.rr.com Fri Feb 17 02:01:14 2006 From: jedgecombe at carolina.rr.com (Jason Edgecombe) Date: Thu, 16 Feb 2006 21:01:14 -0500 Subject: VMware with 2.6 kernels In-Reply-To: References: Message-ID: <43F52E6A.2060708@carolina.rr.com> Donald Maner wrote: > With the discussion of using VMware to help with the QA process, I > felt I should speak up and add my experience over the past week > getting a fc2 and fc3 vm going. > > The biggest problem I came across was that I had to recompile the fc2 > and fc3 kernels to reduce the HZ setting in include/asm-i386/params.h > from 1000 to 100. At 1000, the VMs were too slow to do any real > work. The vmware discussion forums were great in pointing out that > was the problem with the slowness. I'm running my VMs on ESX Server > 2.5.2, so I don't know if the latest Server beta or VMWare workstation > 5.5 are any better. But someone does put out pre-made VMWare images > to help with QA, those images probably need a 100 HZ kernel in them. > Hi there, 1. I can confirm this experience. 2. fc4 changes the HZ setting back to 100 3. Vmware 5 is supposed to fix the problem. Jason From res00vl8 at alltel.net Fri Feb 17 18:15:08 2006 From: res00vl8 at alltel.net (taharka) Date: Fri, 17 Feb 2006 13:15:08 -0500 Subject: firefox-chatzilla for fc2?? In-Reply-To: <200602162031.57730.gene.heskett@verizon.net> References: <200602162031.57730.gene.heskett@verizon.net> Message-ID: <43F612AC.2080506@alltel.net> Gene Heskett wrote: >The subject line is the question. I have it for moz, but I'm wondering >if there is a chatzilla plugin for firefox-1.5*? > > > Can't speak for a plugin but, a firefox chatzilla extension exists at; https://addons.mozilla.org/extensions/moreinfo.php?application=firefox&numpg=10&id=16 taharka Lexington, Kentucky U.S.A. From gene.heskett at verizon.net Fri Feb 17 18:35:16 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Fri, 17 Feb 2006 13:35:16 -0500 Subject: firefox-chatzilla for fc2?? In-Reply-To: <43F612AC.2080506@alltel.net> References: <200602162031.57730.gene.heskett@verizon.net> <43F612AC.2080506@alltel.net> Message-ID: <200602171335.16198.gene.heskett@verizon.net> On Friday 17 February 2006 13:15, taharka wrote: >Gene Heskett wrote: >>The subject line is the question. I have it for moz, but I'm >> wondering if there is a chatzilla plugin for firefox-1.5*? > >Can't speak for a plugin but, a firefox chatzilla extension exists at; >https://addons.mozilla.org/extensions/moreinfo.php?application=firefox >&numpg=10&id=16 Thank you very much. But I wonder why this isn't visible on the mozilla-firefox pages. >taharka > >Lexington, Kentucky U.S.A. > >-- >fedora-legacy-list mailing list >fedora-legacy-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-legacy-list -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From gene.heskett at verizon.net Fri Feb 17 19:09:02 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Fri, 17 Feb 2006 14:09:02 -0500 Subject: firefox-chatzilla for fc2?? In-Reply-To: <43F612AC.2080506@alltel.net> References: <200602162031.57730.gene.heskett@verizon.net> <43F612AC.2080506@alltel.net> Message-ID: <200602171409.03279.gene.heskett@verizon.net> On Friday 17 February 2006 13:15, taharka wrote: >Gene Heskett wrote: >>The subject line is the question. I have it for moz, but I'm >> wondering if there is a chatzilla plugin for firefox-1.5*? > >Can't speak for a plugin but, a firefox chatzilla extension exists at; >https://addons.mozilla.org/extensions/moreinfo.php?application=firefox >&numpg=10&id=16 > Unforch, this installs to the mozilla install, which already had a chatzilla installed. When I attempt to access this saved as a local file, firefox tells me the installation is disabled, and that I should click on edit to fix this. I have several times, and there is nothing there that looks as if its has extension installations disabled. Also in firefox, going directly to the link above, the display is slightly different and there in no response to the install now button because it isn't a button in firefox. I can right click and download it however. And its that download, which when I attempt to load the local copy I've dl'd, presents me with the above message in the form of a temporary toolbar containing that text and an edit button that brings up the prefs editor, this toolbar being shown in one line at the top of the display space. So whats the proper procedure? There appears to be enough diffs in the directory structures the two program use to make it diffcult to guess where to put the files contained in the chatzilla.xpi. Or is there indeed not a chatzilla plugin for firefox-1.5*? >taharka > >Lexington, Kentucky U.S.A. > >-- >fedora-legacy-list mailing list >fedora-legacy-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-legacy-list -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From gene.heskett at verizon.net Fri Feb 17 21:22:45 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Fri, 17 Feb 2006 16:22:45 -0500 Subject: firefox-chatzilla for fc2?? update In-Reply-To: <200602171409.03279.gene.heskett@verizon.net> References: <200602162031.57730.gene.heskett@verizon.net> <43F612AC.2080506@alltel.net> <200602171409.03279.gene.heskett@verizon.net> Message-ID: <200602171622.45519.gene.heskett@verizon.net> On Friday 17 February 2006 14:09, Gene Heskett wrote: >On Friday 17 February 2006 13:15, taharka wrote: >>Gene Heskett wrote: >>>The subject line is the question. I have it for moz, but I'm >>> wondering if there is a chatzilla plugin for firefox-1.5*? >> >>Can't speak for a plugin but, a firefox chatzilla extension exists >> at; >> https://addons.mozilla.org/extensions/moreinfo.php?application=firef >>ox &numpg=10&id=16 > >Unforch, this installs to the mozilla install, which already had a >chatzilla installed. > >When I attempt to access this saved as a local file, firefox tells me >the installation is disabled, and that I should click on edit to fix >this. I have several times, and there is nothing there that looks as >if its has extension installations disabled. Also in firefox, going >directly to the link above, the display is slightly different and > there in no response to the install now button because it isn't a > button in firefox. I can right click and download it however. And > its that download, which when I attempt to load the local copy I've > dl'd, presents me with the above message in the form of a temporary > toolbar containing that text and an edit button that brings up the > prefs editor, this toolbar being shown in one line at the top of the > display space. > >So whats the proper procedure? There appears to be enough diffs in > the directory structures the two program use to make it diffcult to > guess where to put the files contained in the chatzilla.xpi. > >Or is there indeed not a chatzilla plugin for firefox-1.5*? What it turns out to have been was an option set false in the about:config screen. After that it installed just fine. This really should have been available in the prefs menu, but isn't. >>taharka >> >>Lexington, Kentucky U.S.A. >> >>-- >>fedora-legacy-list mailing list >>fedora-legacy-list at redhat.com >>https://www.redhat.com/mailman/listinfo/fedora-legacy-list -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From marcdeslauriers at videotron.ca Fri Feb 17 21:27:35 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Fri, 17 Feb 2006 16:27:35 -0500 Subject: Fedora Legacy Test Update Notification: sudo Message-ID: <43F63FC7.8000903@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-162750 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162750 2006-02-17 --------------------------------------------------------------------- Name : sudo Versions : rh7.3: sudo-1.6.5p2-2.3.legacy Versions : rh9: sudo-1.6.6-3.3.legacy Versions : fc1: sudo-1.6.7p5-2.3.legacy Versions : fc2: sudo-1.6.7p5-26.2.legacy Summary : Allows restricted root access for specified users. Description : Sudo (superuser do) allows a system administrator to give certain users (or groups of users) the ability to run some (or all) commands as root while logging all commands and arguments. Sudo operates on a per-command basis. It is not a replacement for the shell. Features include: the ability to restrict what commands a user may run on a per-host basis, copious logging of each command (providing a clear audit trail of who did what), a configurable timeout of the sudo command, and the ability to use the same configuration file (sudoers) on many different machines. --------------------------------------------------------------------- Update Information: An updated sudo package is available that fixes a race condition in sudo's pathname validation. The sudo (superuser do) utility allows system administrators to give certain users the ability to run commands as root with logging. A race condition bug was found in the way sudo handles pathnames. It is possible that a local user with limited sudo access could create a race condition that would allow the execution of arbitrary commands as the root user. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-1993 to this issue. Users of sudo should update to this updated package, which contains a backported patch and is not vulnerable to this issue. --------------------------------------------------------------------- Changelogs rh73: * Mon Feb 13 2006 Marc Deslauriers 1.6.5p2-2.3.legacy - Fix CVE-2005-1993 sudo trusted user arbitrary command execution rh9: * Mon Feb 13 2006 Marc Deslauriers 1.6.6-3.3.legacy - Fix CVE-2005-1993 sudo trusted user arbitrary command execution fc1: * Wed Feb 15 2006 Marc Deslauriers 1.6.7p5-2.3.legacy - Fix CVE-2005-1993 sudo trusted user arbitrary command execution fc2: * Thu Feb 16 2006 Marc Deslauriers 1.6.7p5-26.2.legacy - Added missing libselinux-devel to BuildRequires * Wed Feb 15 2006 Marc Deslauriers 1.6.7p5-26.1.legacy - Fix CVE-2005-1993 sudo trusted user arbitrary command execution --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh7.3: 5eed8171a2be78f8a03de987b86220b1c8ecb9d4 redhat/7.3/updates-testing/i386/sudo-1.6.5p2-2.3.legacy.i386.rpm f1fdc4b82456cf66f89764ec7f9c0909a0603805 redhat/7.3/updates-testing/SRPMS/sudo-1.6.5p2-2.3.legacy.src.rpm rh9: 7a84e2d96bba56142ca8c6dec2603577e31b2072 redhat/9/updates-testing/i386/sudo-1.6.6-3.3.legacy.i386.rpm 4aca97be1c9e5f61efa1165955eb219fce3af70e redhat/9/updates-testing/SRPMS/sudo-1.6.6-3.3.legacy.src.rpm fc1: 4e7b55e41c355e51b4cdd3a820a6d5c94df43fdc fedora/1/updates-testing/i386/sudo-1.6.7p5-2.3.legacy.i386.rpm 6843f6ee7792e8c63f1034107a4a4e464a613798 fedora/1/updates-testing/SRPMS/sudo-1.6.7p5-2.3.legacy.src.rpm fc2: 954a6e7098b7e86e7bc1f1532a72f8a3dab32380 fedora/2/updates-testing/i386/sudo-1.6.7p5-26.2.legacy.i386.rpm 82c884d6bcff123dd510ffdb8a0d81ce63606364 fedora/2/updates-testing/SRPMS/sudo-1.6.7p5-26.2.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Fri Feb 17 21:28:11 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Fri, 17 Feb 2006 16:28:11 -0500 Subject: Fedora Legacy Test Update Notification: XFree86 Message-ID: <43F63FEB.5000203@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-168264-1 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168264 2006-02-17 --------------------------------------------------------------------- Name : XFree86 Versions : rh73: XFree86-4.2.1-16.73.31.legacy Versions : rh9: XFree86-4.3.0-2.90.61.legacy Versions : fc1: XFree86-4.3.0-60.legacy Summary : The basic fonts, programs and docs for an X workstation. Description : XFree86 is an open source implementation of the X Window System. It provides the basic low level functionality which full fledged graphical user interfaces (GUIs) such as GNOME and KDE are designed upon. --------------------------------------------------------------------- Update Information: Updated XFree86 packages that fix security issues are now available. XFree86 is an open source implementation of the X Window System. It provides the basic low-level functionality that full-fledged graphical user interfaces (GUIs) such as GNOME and KDE are designed upon. An integer overflow flaw was found in libXpm, which is used by some applications for loading of XPM images. An attacker could create a malicious XPM file that would execute arbitrary code if opened by a victim using an application linked to the vulnerable library. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0605 to this issue. Several integer overflow bugs were found in the way XFree86 parses pixmap images. It is possible for a user to gain elevated privileges by loading a specially crafted pixmap image. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-2495 to this issue. Users of XFree86 should upgrade to these updated packages, which contain backported patches and are not vulnerable to these issues. --------------------------------------------------------------------- Changelogs rh73: * Sun Feb 12 2006 Marc Deslauriers 4.2.1-16.73.31.legacy - Add XFree86-4.1.0-xpm-security-fix-CAN-2005-0605.patch. - Add XFree86-4.3.0-security-CAN-2005-2495.patch to fix various integer overflows. rh9: * Sun Feb 12 2006 Marc Deslauriers 4.3.0-2.x.61.legacy - Add XFree86-4.1.0-xpm-security-fix-CAN-2005-0605.patch. - Add XFree86-4.3.0-security-CAN-2005-2495.patch to fix various integer overflows. fc1: * Sun Feb 12 2006 Marc Deslauriers 4.3.0-60.legacy - Add XFree86-4.1.0-xpm-security-fix-CAN-2005-0605.patch. - Add XFree86-4.3.0-security-CAN-2005-2495.patch to fix various integer overflows. --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 0cbc1cb6499a8684d19f24cf111b4fea65ba92ae redhat/7.3/updates-testing/i386/XFree86-100dpi-fonts-4.2.1-16.73.31.legacy.i386.rpm 8c2025d75448c2f03b9bd2493cdc42f84741ba14 redhat/7.3/updates-testing/i386/XFree86-4.2.1-16.73.31.legacy.i386.rpm 45d182c851d2d98fcf551ee5f4229ba76f7fe1ae redhat/7.3/updates-testing/i386/XFree86-75dpi-fonts-4.2.1-16.73.31.legacy.i386.rpm 57d848f52c35787175eb7556350cf6202a3acc9e redhat/7.3/updates-testing/i386/XFree86-base-fonts-4.2.1-16.73.31.legacy.i386.rpm 6b7e1499d32cea54eda46c7a23586edff860b01f redhat/7.3/updates-testing/i386/XFree86-cyrillic-fonts-4.2.1-16.73.31.legacy.i386.rpm 5ae4db073a051453c1ea05328ba611820c54ac6e redhat/7.3/updates-testing/i386/XFree86-devel-4.2.1-16.73.31.legacy.i386.rpm 8f5ddf6f2ffc17a706368dbdcd9f6880cf163eca redhat/7.3/updates-testing/i386/XFree86-doc-4.2.1-16.73.31.legacy.i386.rpm e80034e10d2babcab44f449040556f1c62b9c65b redhat/7.3/updates-testing/i386/XFree86-font-utils-4.2.1-16.73.31.legacy.i386.rpm 67b6b5d8b00a4f53ad300bc07d5c35c6c023280f redhat/7.3/updates-testing/i386/XFree86-ISO8859-15-100dpi-fonts-4.2.1-16.73.31.legacy.i386.rpm c25c85a92e2fb2e80fb9ee2c19b0cb017e92b065 redhat/7.3/updates-testing/i386/XFree86-ISO8859-15-75dpi-fonts-4.2.1-16.73.31.legacy.i386.rpm a54081ce435b2ed6695231f895e8cce95972027f redhat/7.3/updates-testing/i386/XFree86-ISO8859-2-100dpi-fonts-4.2.1-16.73.31.legacy.i386.rpm ceb5c88c82123d553c09ed2dceb7395abf893dfc redhat/7.3/updates-testing/i386/XFree86-ISO8859-2-75dpi-fonts-4.2.1-16.73.31.legacy.i386.rpm 9d8a2d217d1161cd8e37187ab82826592fced64b redhat/7.3/updates-testing/i386/XFree86-ISO8859-9-100dpi-fonts-4.2.1-16.73.31.legacy.i386.rpm 7b7684a8bca628231f42d04aa545624052ebd59b redhat/7.3/updates-testing/i386/XFree86-ISO8859-9-75dpi-fonts-4.2.1-16.73.31.legacy.i386.rpm dc04b533163d6a61471e2ce404bbce11e8a026de redhat/7.3/updates-testing/i386/XFree86-libs-4.2.1-16.73.31.legacy.i386.rpm 58388c03cb94a1b74c4e65246a21b364e3e9bec0 redhat/7.3/updates-testing/i386/XFree86-tools-4.2.1-16.73.31.legacy.i386.rpm 23d5801937faf0b0033db434d4713719bf13992f redhat/7.3/updates-testing/i386/XFree86-truetype-fonts-4.2.1-16.73.31.legacy.i386.rpm ea0187127b7e4177c7d1653fe65c86d1b95f2dd9 redhat/7.3/updates-testing/i386/XFree86-twm-4.2.1-16.73.31.legacy.i386.rpm 05d935b6e8e5b2dcc443556a3f15522aaa054278 redhat/7.3/updates-testing/i386/XFree86-xdm-4.2.1-16.73.31.legacy.i386.rpm 7ec5886f06e93eac890fd5c47ed96b811b218b17 redhat/7.3/updates-testing/i386/XFree86-xf86cfg-4.2.1-16.73.31.legacy.i386.rpm cd5d813aa22857cea4ea75179befad39e643559d redhat/7.3/updates-testing/i386/XFree86-xfs-4.2.1-16.73.31.legacy.i386.rpm 53f7b20ad43180b4b860974a867030c484656b23 redhat/7.3/updates-testing/i386/XFree86-Xnest-4.2.1-16.73.31.legacy.i386.rpm e0629ed131499721c4384630364fa34a4338614f redhat/7.3/updates-testing/i386/XFree86-Xvfb-4.2.1-16.73.31.legacy.i386.rpm f28c45eafb4b035d7fa814ed8b23c1270aea4d0b redhat/7.3/updates-testing/SRPMS/XFree86-4.2.1-16.73.31.legacy.src.rpm rh9: fb1a1f39a9372aa0147c508eb5d4db52d581a1cc redhat/9/updates-testing/i386/XFree86-100dpi-fonts-4.3.0-2.90.61.legacy.i386.rpm 562913cdf6f7237b852062d1c6fd8f1a03482f9f redhat/9/updates-testing/i386/XFree86-4.3.0-2.90.61.legacy.i386.rpm a0a44151d9c0c7b73e2b266b3c81f4e5cd2ba712 redhat/9/updates-testing/i386/XFree86-75dpi-fonts-4.3.0-2.90.61.legacy.i386.rpm 0b6ae5bf6ea0938feadc805890c1b46b5de98870 redhat/9/updates-testing/i386/XFree86-base-fonts-4.3.0-2.90.61.legacy.i386.rpm 6e06fe3b0262230d005020b9176a0601f8fe17fd redhat/9/updates-testing/i386/XFree86-cyrillic-fonts-4.3.0-2.90.61.legacy.i386.rpm 75ec411aeaa191642774ff3d6b2da778849fff86 redhat/9/updates-testing/i386/XFree86-devel-4.3.0-2.90.61.legacy.i386.rpm 9ca5fb3e139559593e1d3b243c03fd660ebf1bde redhat/9/updates-testing/i386/XFree86-doc-4.3.0-2.90.61.legacy.i386.rpm 77f4f6d9d41c8ae72ca152fa8c5d856dd0d14acb redhat/9/updates-testing/i386/XFree86-font-utils-4.3.0-2.90.61.legacy.i386.rpm 8a3282947adcb55f210534fa7930a2caf35ee31b redhat/9/updates-testing/i386/XFree86-ISO8859-14-100dpi-fonts-4.3.0-2.90.61.legacy.i386.rpm 00e356bf12d218e3cf4cfd16cbdbb3bb6c1f4ff6 redhat/9/updates-testing/i386/XFree86-ISO8859-14-75dpi-fonts-4.3.0-2.90.61.legacy.i386.rpm ffa1bfa1925f88314a916835609d2567593fee7d redhat/9/updates-testing/i386/XFree86-ISO8859-15-100dpi-fonts-4.3.0-2.90.61.legacy.i386.rpm 73ccf11e207edc656b4bb7dfce08ed804290ef4b redhat/9/updates-testing/i386/XFree86-ISO8859-15-75dpi-fonts-4.3.0-2.90.61.legacy.i386.rpm 38b67c16ea8b8191edb4b3df890d017b4c498397 redhat/9/updates-testing/i386/XFree86-ISO8859-2-100dpi-fonts-4.3.0-2.90.61.legacy.i386.rpm ec33602ea178f0c9b3133f5224c7230f373a19ff redhat/9/updates-testing/i386/XFree86-ISO8859-2-75dpi-fonts-4.3.0-2.90.61.legacy.i386.rpm b47fb63d7c9dfbe83846a8c016a4e62725d8fad4 redhat/9/updates-testing/i386/XFree86-ISO8859-9-100dpi-fonts-4.3.0-2.90.61.legacy.i386.rpm b9c0e2552ccd4ce1f2cdd3494d38d956cd0e8c52 redhat/9/updates-testing/i386/XFree86-ISO8859-9-75dpi-fonts-4.3.0-2.90.61.legacy.i386.rpm f34539d0acccb62d0c39eda5d8e2f69677594505 redhat/9/updates-testing/i386/XFree86-libs-4.3.0-2.90.61.legacy.i386.rpm 44c71e911bcbc53bf2692bdb4fa39d05b69777ec redhat/9/updates-testing/i386/XFree86-libs-data-4.3.0-2.90.61.legacy.i386.rpm b65547fc07ae1c1880cbfb2905dbc61a3e97f7d3 redhat/9/updates-testing/i386/XFree86-Mesa-libGL-4.3.0-2.90.61.legacy.i386.rpm 537c5f4aacb6eedd2c508ab2968f013396e52a76 redhat/9/updates-testing/i386/XFree86-Mesa-libGLU-4.3.0-2.90.61.legacy.i386.rpm 2b4c1d714eec3c66cb5b01539ee8d179b49ffcc1 redhat/9/updates-testing/i386/XFree86-sdk-4.3.0-2.90.61.legacy.i386.rpm 97b8aa8cf0cfcb6af5e594819d98486b32f9c965 redhat/9/updates-testing/i386/XFree86-syriac-fonts-4.3.0-2.90.61.legacy.i386.rpm 7898a7ae919e67e4cfe63fd3121d815710240bf0 redhat/9/updates-testing/i386/XFree86-tools-4.3.0-2.90.61.legacy.i386.rpm d8b6e93b6c4fa6c0563bf9bc4f82b1e4828c9b30 redhat/9/updates-testing/i386/XFree86-truetype-fonts-4.3.0-2.90.61.legacy.i386.rpm 3fdf5b8877cef9d337ae13deff0c72fdea156291 redhat/9/updates-testing/i386/XFree86-twm-4.3.0-2.90.61.legacy.i386.rpm 612a4e120fcd790c5e8a3481e0cadd76fddb1cc7 redhat/9/updates-testing/i386/XFree86-xauth-4.3.0-2.90.61.legacy.i386.rpm 6ceb66f35332408b2a19474533285b3d0fc17c9d redhat/9/updates-testing/i386/XFree86-xdm-4.3.0-2.90.61.legacy.i386.rpm 174dcc7e757da7175b270ff34f8ce9c4efd9563e redhat/9/updates-testing/i386/XFree86-xfs-4.3.0-2.90.61.legacy.i386.rpm 22b32e9c6460e4a52704f43d78675f0cdcce8291 redhat/9/updates-testing/i386/XFree86-Xnest-4.3.0-2.90.61.legacy.i386.rpm ec25c9cb7a1bff4eccd503fedd3b49862d9c2405 redhat/9/updates-testing/i386/XFree86-Xvfb-4.3.0-2.90.61.legacy.i386.rpm 84bbfb5f2fa13f20d465a0a552041526cb26bc3b redhat/9/updates-testing/SRPMS/XFree86-4.3.0-2.90.61.legacy.src.rpm fc1: 2a09c30f05a126480d06220affc808bed0ccd831 fedora/1/updates-testing/i386/XFree86-100dpi-fonts-4.3.0-60.legacy.i386.rpm d168ebb164d69f9fa0edd668a27e50a4e43ea2dd fedora/1/updates-testing/i386/XFree86-4.3.0-60.legacy.i386.rpm e6ab23ec2e99a2d6dcbfed6a073402d88e796563 fedora/1/updates-testing/i386/XFree86-75dpi-fonts-4.3.0-60.legacy.i386.rpm 5573af42869b10f104a52ac6fa5221e4c125cd46 fedora/1/updates-testing/i386/XFree86-base-fonts-4.3.0-60.legacy.i386.rpm 0ae445a93ae5b573b2afb72441a712ac858c002e fedora/1/updates-testing/i386/XFree86-cyrillic-fonts-4.3.0-60.legacy.i386.rpm c453822bd9aa5cdd6d7497bf7e629928a0424ebb fedora/1/updates-testing/i386/XFree86-devel-4.3.0-60.legacy.i386.rpm b8768066b3f60ae86ab32559748c33590ae58b61 fedora/1/updates-testing/i386/XFree86-doc-4.3.0-60.legacy.i386.rpm 142309e5f990556c9789bbe8e5b29e7b99ce9131 fedora/1/updates-testing/i386/XFree86-font-utils-4.3.0-60.legacy.i386.rpm 02f4ffe56217dac4c263317c754be2221f11c2b1 fedora/1/updates-testing/i386/XFree86-ISO8859-14-100dpi-fonts-4.3.0-60.legacy.i386.rpm f5a98a73fcdc0ff03e2b24ed9b8e147c85e55487 fedora/1/updates-testing/i386/XFree86-ISO8859-14-75dpi-fonts-4.3.0-60.legacy.i386.rpm 7d833db16f028ff40d6ee67e04c03e7bb351a0fd fedora/1/updates-testing/i386/XFree86-ISO8859-15-100dpi-fonts-4.3.0-60.legacy.i386.rpm 318f747bcdbd0be642d3fe1d52382772dec56634 fedora/1/updates-testing/i386/XFree86-ISO8859-15-75dpi-fonts-4.3.0-60.legacy.i386.rpm 38395a9806da0e234d74b7c1e6e3dbed5d525726 fedora/1/updates-testing/i386/XFree86-ISO8859-2-100dpi-fonts-4.3.0-60.legacy.i386.rpm 507cc1c515c2fe3f901704153819bcc62c133b46 fedora/1/updates-testing/i386/XFree86-ISO8859-2-75dpi-fonts-4.3.0-60.legacy.i386.rpm e5a19310f393f5fde53a72a7fa3d522e227bc7e7 fedora/1/updates-testing/i386/XFree86-ISO8859-9-100dpi-fonts-4.3.0-60.legacy.i386.rpm f65b8b8da1484ce2dd20737cc0279865ab5fdbd8 fedora/1/updates-testing/i386/XFree86-ISO8859-9-75dpi-fonts-4.3.0-60.legacy.i386.rpm 1bbdad4b6bd3117c6495d7c3bdef3da6bcb9ab0b fedora/1/updates-testing/i386/XFree86-libs-4.3.0-60.legacy.i386.rpm 8a55ec0a7a0564c3cd3f4263b6cc8e4ed151ba8e fedora/1/updates-testing/i386/XFree86-libs-data-4.3.0-60.legacy.i386.rpm c9eb4e6054d2159b1ff28a5ce52b640a4e9b0359 fedora/1/updates-testing/i386/XFree86-Mesa-libGL-4.3.0-60.legacy.i386.rpm 5e9c2f7390b7200e573a77bd9051ec36eb67621f fedora/1/updates-testing/i386/XFree86-Mesa-libGLU-4.3.0-60.legacy.i386.rpm 9cde04ebb5610324b158a9ae2b5f0d04d56ed7cb fedora/1/updates-testing/i386/XFree86-sdk-4.3.0-60.legacy.i386.rpm 339d8521270468753b9db696306acd64cb8bbab1 fedora/1/updates-testing/i386/XFree86-syriac-fonts-4.3.0-60.legacy.i386.rpm c011244e0b99ce7d3929c3ad6958f409de1f6139 fedora/1/updates-testing/i386/XFree86-tools-4.3.0-60.legacy.i386.rpm 36ba1b374ee3fae3b65712e2cd2a6b1e131524a5 fedora/1/updates-testing/i386/XFree86-truetype-fonts-4.3.0-60.legacy.i386.rpm 36f807093616e0615f4a70dc46ebd91b256ce8d2 fedora/1/updates-testing/i386/XFree86-twm-4.3.0-60.legacy.i386.rpm 5f82fea2f05c74f2433ebc6bc2e4db188ad9e7d2 fedora/1/updates-testing/i386/XFree86-xauth-4.3.0-60.legacy.i386.rpm 2b5768e46ce851b22564cc3b824d0987d027b8d1 fedora/1/updates-testing/i386/XFree86-xdm-4.3.0-60.legacy.i386.rpm c11d8de359322a543e8876163581bc38fa06b954 fedora/1/updates-testing/i386/XFree86-xfs-4.3.0-60.legacy.i386.rpm a3b20af14a192aa110f0fe247d7c6d0478cebd98 fedora/1/updates-testing/i386/XFree86-Xnest-4.3.0-60.legacy.i386.rpm ba4f2c18b58be48594a48eafc97564d31aec0286 fedora/1/updates-testing/i386/XFree86-Xvfb-4.3.0-60.legacy.i386.rpm d1fe795457c17ae1348c63e859414623d8fd5c02 fedora/1/updates-testing/SRPMS/XFree86-4.3.0-60.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Fri Feb 17 21:28:52 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Fri, 17 Feb 2006 16:28:52 -0500 Subject: Fedora Legacy Test Update Notification: xorg-x11 Message-ID: <43F64014.3090106@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-168264-2 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168264 2006-02-17 --------------------------------------------------------------------- Name : xorg-x11 Versions : fc2: xorg-x11-6.7.0-14.1.legacy Summary : The basic fonts, programs and docs for an X workstation. Description : X.org X11 is an open source implementation of the X Window System. It provides the basic low level functionality which full fledged graphical user interfaces (GUIs) such as GNOME and KDE are designed upon. --------------------------------------------------------------------- Update Information: Updated X.org packages that fix a security issue are now available. X.org is an open source implementation of the X Window System. It provides the basic low-level functionality that full-fledged graphical user interfaces (GUIs) such as GNOME and KDE are designed upon. Several integer overflow bugs were found in the way X.org parses pixmap images. It is possible for a user to gain elevated privileges by loading a specially crafted pixmap image. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-2495 to this issue. Users of X.org should upgrade to these updated packages, which contain a backported patch and are not vulnerable to this issue. --------------------------------------------------------------------- Changelogs fc2: * Sun Feb 12 2006 Marc Deslauriers 6.7.0-14.1.legacy - Add XFree86-4.3.0-security-CAN-2005-2495.patch to fix various integer overflows. --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) fc2: fb2e8bbd5c2f1132d19ee20bd773be9d3179db9d fedora/2/updates-testing/i386/xorg-x11-100dpi-fonts-6.7.0-14.1.legacy.i386.rpm 02ff368c88f7907764b2da5e385f2e079f3849cd fedora/2/updates-testing/i386/xorg-x11-6.7.0-14.1.legacy.i386.rpm c81dda89910ea896c7070eab733df161dba54a39 fedora/2/updates-testing/i386/xorg-x11-75dpi-fonts-6.7.0-14.1.legacy.i386.rpm 501f87e1196be0a33d95f0d52ead826677a34f22 fedora/2/updates-testing/i386/xorg-x11-base-fonts-6.7.0-14.1.legacy.i386.rpm 1e0c6b43d3965b5e7d2d049bbc790d9a8c73a7d0 fedora/2/updates-testing/i386/xorg-x11-cyrillic-fonts-6.7.0-14.1.legacy.i386.rpm 82eb2326f5b8494f96761e6092e34056e700a809 fedora/2/updates-testing/i386/xorg-x11-devel-6.7.0-14.1.legacy.i386.rpm c0d1461ddb2c070cdabddf6b3ebccc34ec66d3ef fedora/2/updates-testing/i386/xorg-x11-doc-6.7.0-14.1.legacy.i386.rpm 3f6382954c75e22ab177abbe1707140feea0170d fedora/2/updates-testing/i386/xorg-x11-font-utils-6.7.0-14.1.legacy.i386.rpm 6f0c373860e9d64c5efea95e77d3e6d5872dacc0 fedora/2/updates-testing/i386/xorg-x11-ISO8859-14-100dpi-fonts-6.7.0-14.1.legacy.i386.rpm c861aa4032a4f169929f225d46e798f5e0f18890 fedora/2/updates-testing/i386/xorg-x11-ISO8859-14-75dpi-fonts-6.7.0-14.1.legacy.i386.rpm 83eb270f4395c14edd17cc55a1d78965e5f602e8 fedora/2/updates-testing/i386/xorg-x11-ISO8859-15-100dpi-fonts-6.7.0-14.1.legacy.i386.rpm a99b042654bd86640eea6e7e1b76bda402d49b85 fedora/2/updates-testing/i386/xorg-x11-ISO8859-15-75dpi-fonts-6.7.0-14.1.legacy.i386.rpm 52b7c9ff7e29265605c4bb1d08a735b279287fc5 fedora/2/updates-testing/i386/xorg-x11-ISO8859-2-100dpi-fonts-6.7.0-14.1.legacy.i386.rpm 4e3900230a90728563f1173c8af82af2272dec03 fedora/2/updates-testing/i386/xorg-x11-ISO8859-2-75dpi-fonts-6.7.0-14.1.legacy.i386.rpm 5091477dffb64324caae7d3d558882ab73e26609 fedora/2/updates-testing/i386/xorg-x11-ISO8859-9-100dpi-fonts-6.7.0-14.1.legacy.i386.rpm 9ef03f7f4355a5e1d3f19f71d597e541cad3e831 fedora/2/updates-testing/i386/xorg-x11-ISO8859-9-75dpi-fonts-6.7.0-14.1.legacy.i386.rpm f1ea8740e9802ad98b194284e8afb3eee8e1106d fedora/2/updates-testing/i386/xorg-x11-libs-6.7.0-14.1.legacy.i386.rpm 222037711ead385d31fac145142c10c9c93f8c51 fedora/2/updates-testing/i386/xorg-x11-libs-data-6.7.0-14.1.legacy.i386.rpm c21a7c11d52eaabe8bae5145e270c5301fcf8c17 fedora/2/updates-testing/i386/xorg-x11-Mesa-libGL-6.7.0-14.1.legacy.i386.rpm 3314b29f2bc32e4ccd837b7973fc07847d073df0 fedora/2/updates-testing/i386/xorg-x11-Mesa-libGLU-6.7.0-14.1.legacy.i386.rpm 3eac8219f4e3753644511090657ddc513a75c0c8 fedora/2/updates-testing/i386/xorg-x11-sdk-6.7.0-14.1.legacy.i386.rpm f99d01e683755302d4ed5ea8a03f09b4828b7ea0 fedora/2/updates-testing/i386/xorg-x11-syriac-fonts-6.7.0-14.1.legacy.i386.rpm d265d17e698e8d2e3a40c9b8519fe70cd01a1ca2 fedora/2/updates-testing/i386/xorg-x11-tools-6.7.0-14.1.legacy.i386.rpm ff8ff747514e3b9bf7945aac37ed19ab00293fbd fedora/2/updates-testing/i386/xorg-x11-truetype-fonts-6.7.0-14.1.legacy.i386.rpm e6141cfe3188c556c6e8ba54eba44d5e8645f09b fedora/2/updates-testing/i386/xorg-x11-twm-6.7.0-14.1.legacy.i386.rpm 05fc596a5a8956e8fcbd1ac788bbba855e87fbba fedora/2/updates-testing/i386/xorg-x11-xauth-6.7.0-14.1.legacy.i386.rpm 70b47f7e0e944ef7402437135a044209cba064ae fedora/2/updates-testing/i386/xorg-x11-xdm-6.7.0-14.1.legacy.i386.rpm f6b74e278a54a2477bbda52155daad7787721a81 fedora/2/updates-testing/i386/xorg-x11-xfs-6.7.0-14.1.legacy.i386.rpm c362a7d289c0c8d56ad63f0364e879819185871f fedora/2/updates-testing/i386/xorg-x11-Xnest-6.7.0-14.1.legacy.i386.rpm fd3251aec6f906005c34d5a6e3324e38a0dcc510 fedora/2/updates-testing/i386/xorg-x11-Xvfb-6.7.0-14.1.legacy.i386.rpm af4f7aea4c1b550d1a0389c0f3213bc6c74d87e6 fedora/2/updates-testing/SRPMS/xorg-x11-6.7.0-14.1.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From res00vl8 at alltel.net Fri Feb 17 22:40:22 2006 From: res00vl8 at alltel.net (taharka) Date: Fri, 17 Feb 2006 17:40:22 -0500 Subject: firefox-chatzilla for fc2?? update In-Reply-To: <200602171622.45519.gene.heskett@verizon.net> References: <200602162031.57730.gene.heskett@verizon.net> <43F612AC.2080506@alltel.net> <200602171409.03279.gene.heskett@verizon.net> <200602171622.45519.gene.heskett@verizon.net> Message-ID: <43F650D6.9080003@alltel.net> Gene Heskett wrote: >On Friday 17 February 2006 14:09, Gene Heskett wrote: > > >>On Friday 17 February 2006 13:15, taharka wrote: >> >> >>>Gene Heskett wrote: >>> >>> >>>>The subject line is the question. I have it for moz, but I'm >>>>wondering if there is a chatzilla plugin for firefox-1.5*? >>>> >>>> >>>Can't speak for a plugin but, a firefox chatzilla extension exists >>>at; >>>https://addons.mozilla.org/extensions/moreinfo.php?application=firef >>>ox &numpg=10&id=16 >>> >>> >>Unforch, this installs to the mozilla install, which already had a >>chatzilla installed. >> >>When I attempt to access this saved as a local file, firefox tells me >>the installation is disabled, and that I should click on edit to fix >>this. I have several times, and there is nothing there that looks as >>if its has extension installations disabled. Also in firefox, going >>directly to the link above, the display is slightly different and >>there in no response to the install now button because it isn't a >>button in firefox. I can right click and download it however. And >>its that download, which when I attempt to load the local copy I've >>dl'd, presents me with the above message in the form of a temporary >>toolbar containing that text and an edit button that brings up the >>prefs editor, this toolbar being shown in one line at the top of the >>display space. >> >>So whats the proper procedure? There appears to be enough diffs in >>the directory structures the two program use to make it diffcult to >>guess where to put the files contained in the chatzilla.xpi. >> >>Or is there indeed not a chatzilla plugin for firefox-1.5*? >> >> > >What it turns out to have been was an option set false in the >about:config screen. After that it installed just fine. This really >should have been available in the prefs menu, but isn't. > > I've never used the extension myself but, do know of it's existence. Did you by chance read the FAQ/developer's comments? Think I may have seen something regarding that issue there. Personally, I shy away from IRC stuff. That extension has a mailing list & you can always contact the authors also. taharka Lexington, Kentucky U.S.A. From gene.heskett at verizon.net Sat Feb 18 02:41:45 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Fri, 17 Feb 2006 21:41:45 -0500 Subject: firefox-chatzilla for fc2?? update In-Reply-To: <43F650D6.9080003@alltel.net> References: <200602162031.57730.gene.heskett@verizon.net> <200602171622.45519.gene.heskett@verizon.net> <43F650D6.9080003@alltel.net> Message-ID: <200602172141.45695.gene.heskett@verizon.net> On Friday 17 February 2006 17:40, taharka wrote: >Gene Heskett wrote: [...] >>What it turns out to have been was an option set false in the >>about:config screen. After that it installed just fine. This really >>should have been available in the prefs menu, but isn't. > >I've never used the extension myself but, do know of it's existence. > Did you by chance read the FAQ/developer's comments? Think I may have > seen something regarding that issue there. Personally, I shy away > from IRC stuff. That extension has a mailing list & you can always > contact the authors also. Well, the developers for emc get together at odd hours to talk about problems as the new release of emc2 approaches, and often I can get fixes for an itch of mine in real time, fix the code, recompile and test while the main part of the crew is watching. I am not what one would call an irc addict by any means, and haven't been on irc in >5 years till now. But its a tool, and it does come in handy, and on that group at least, no script kiddies welcome which suits me just fine. At 71, I have little or no use for the script kiddies that think harrassing a group or bragging about the girls they had last nite is fun. Truth be said, they are probably doing that sort of thing because they didn't get any recently... They should have been taught some manners by the "good enough to run a computer" age, but thats seems to have gone out of style I guess. Sigh... >taharka > >Lexington, Kentucky U.S.A. > >-- >fedora-legacy-list mailing list >fedora-legacy-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-legacy-list -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From fedora-legacy at neufeind.net Sat Feb 18 11:56:09 2006 From: fedora-legacy at neufeind.net (Stefan Neufeind) Date: Sat, 18 Feb 2006 12:56:09 +0100 Subject: Status of legacy-repo for FC3 Message-ID: <43F70B59.5030706@neufeind.net> Hi, please excuse this question - I'm new to the list. But from what I found on the archives I couldn't make up a clear view of the legacy-repo-status for FC3. I see there are a few packages in testing, though they stand there for quite a while already. No advisories have been filed for FC3, no official updates have been released. So is the legacy-repo for FC3 really "active" already? I'm especially worried about the missing ImageMagick-upgrade - but for sure other upgrades might be interest as well. Kind regards, Stefan From tseaver at palladion.com Wed Feb 15 14:45:18 2006 From: tseaver at palladion.com (Tres Seaver) Date: Wed, 15 Feb 2006 09:45:18 -0500 Subject: Comments on first verification QA Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I finally got my stuff together to add verifies to a couple of packages (openssh, httpd) in 'updates-testing' last night. Here are some thoughts on the matter: - I have only the one FC box, and it is my production mailserver, as well as serving as DNS / webserver for a number of low-volume domains with reasonable availability constraints. - I rent the box from an ISP, which makes it much scarier to update the "core" packages than if I had it physically available. - I was only confident enough to update the box because I first did a dry-run of the updates against a recently-built "mockup" image I built using VMWare's new "VMWare Server" product (freely available from their site). - I didn't feel comfortable issuing a VERIFY solely on the basis of installing the packages in the VMWare replica, mostly because of the interations with the parts of the system (virtual domains, etc.) which I haven't been able or willing to replicate; nonetheless, having the replica available to do initial testing (particularly for openssh) enabled me to proceed with confidence. I am therefore very much inclined to back the idea that Legacy offer "minimal" images as starting points for would-be QA volunteers, along with directions on how to set up either VMWare's Server or Player products to use them. We might need to give people clues about using the "snapshot" facilities provided by the tools to ease the process, as well. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver at palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD8z5++gerLs4ltQ4RAlsdAJwPKGILp4+opJ5Xp9LY24LAFZuLJwCgqusF f1tgVNtjlSjIu5sFsHpku38= =NW+d -----END PGP SIGNATURE----- From marcdeslauriers at videotron.ca Sat Feb 18 19:19:33 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sat, 18 Feb 2006 14:19:33 -0500 Subject: [FLSA-2006:152809] Updated squid package fixes security issues Message-ID: <43F77345.6050001@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated squid package fixes security issues Advisory ID: FLSA:152809 Issue date: 2006-02-18 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2004-0541 CVE-2004-0832 CVE-2004-0918 CVE-2005-0094 CVE-2005-0095 CVE-2005-0096 CVE-2005-0097 CVE-2005-0173 CVE-2005-0174 CVE-2005-0175 CVE-2005-0194 CVE-2005-0211 CVE-2005-0241 CVE-2005-0446 CVE-2005-0626 CVE-2005-0718 CVE-2005-1345 CVE-1999-0710 CVE-2005-1519 CVE-2004-2479 CVE-2005-2794 CVE-2005-2796 CVE-2005-2917 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: An updated Squid package that fixes several security issues is now available. Squid is a full-featured Web proxy cache. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 3. Problem description: A buffer overflow was found within the NTLM authentication helper routine. If Squid is configured to use the NTLM authentication helper, a remote attacker could potentially execute arbitrary code by sending a lengthy password. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2004-0541 to this issue. An out of bounds memory read bug was found within the NTLM authentication helper routine. If Squid is configured to use the NTLM authentication helper, a remote attacker could send a carefully crafted NTLM authentication packet and cause Squid to crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2004-0832 to this issue. iDEFENSE reported a flaw in the squid SNMP module. This flaw could allow an attacker who has the ability to send arbitrary packets to the SNMP port to restart the server, causing it to drop all open connections. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2004-0918 to this issue. A buffer overflow flaw was found in the Gopher relay parser. This bug could allow a remote Gopher server to crash the Squid proxy that reads data from it. Although Gopher servers are now quite rare, a malicious web page (for example) could redirect or contain a frame pointing to an attacker's malicious gopher server. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0094 to this issue. An integer overflow flaw was found in the WCCP message parser. It is possible to crash the Squid server if an attacker is able to send a malformed WCCP message with a spoofed source address matching Squid's "home router". The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0095 to this issue. A memory leak was found in the NTLM fakeauth_auth helper. It is possible that an attacker could place the Squid server under high load, causing the NTML fakeauth_auth helper to consume a large amount of memory, resulting in a denial of service. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0096 to this issue. A NULL pointer de-reference bug was found in the NTLM fakeauth_auth helper. It is possible for an attacker to send a malformed NTLM type 3 message, causing the Squid server to crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0097 to this issue. A username validation bug was found in squid_ldap_auth. It is possible for a username to be padded with spaces, which could allow a user to bypass explicit access control rules or confuse accounting. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0173 to this issue. The way Squid handles HTTP responses was found to need strengthening. It is possible that a malicious web server could send a series of HTTP responses in such a way that the Squid cache could be poisoned, presenting users with incorrect webpages. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CVE-2005-0174 and CVE-2005-0175 to these issues. When processing the configuration file, Squid parses empty Access Control Lists (ACLs) and proxy_auth ACLs without defined auth schemes in a way that effectively removes arguments, which could allow remote attackers to bypass intended ACLs. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0194 to this issue. A buffer overflow bug was found in the WCCP message parser. It is possible that an attacker could send a malformed WCCP message which could crash the Squid server or execute arbitrary code. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0211 to this issue. A bug was found in the way Squid handled oversized HTTP response headers. It is possible that a malicious web server could send a specially crafted HTTP header which could cause the Squid cache to be poisoned, presenting users with incorrect webpages. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0241 to this issue. A bug was found in the way Squid handles FQDN lookups. It was possible to crash the Squid server by sending a carefully crafted DNS response to an FQDN lookup. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0446 to this issue. A race condition bug was found in the way Squid handles the now obsolete Set-Cookie header. It is possible that Squid can leak Set-Cookie header information to other clients connecting to Squid. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0626 to this issue. A bug was found in the way Squid handles PUT and POST requests. It is possible for an authorised remote user to cause a failed PUT or POST request which can cause Squid to crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0718 to this issue. A bug was found in the way Squid processes errors in the access control list. It is possible that an error in the access control list could give users more access than intended. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-1345 to this issue. A bug was found in the way Squid handles access to the cachemgr.cgi script. It is possible for an authorised remote user to bypass access control lists with this flaw. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-1999-0710 to this issue. A bug was found in the way Squid handles DNS replies. If the port Squid uses for DNS requests is not protected by a firewall it is possible for a remote attacker to spoof DNS replies, possibly redirecting a user to spoofed or malicious content. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-1519 to this issue. A bug was found in the way Squid displays error messages. A remote attacker could submit a request containing an invalid hostname which would result in Squid displaying a previously used error message. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2004-2479 to this issue. Two denial of service bugs were found in the way Squid handles malformed requests. A remote attacker could submit a specially crafted request to Squid that would cause the server to crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CVE-2005-2794 and CVE-2005-2796 to these issues. A bug was found in the way Squid handles certain request sequences while performing NTLM authentication. It is possible for an attacker to cause Squid to crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-2917 to this issue. Users of Squid should upgrade to this updated package, which contains backported patches, and is not vulnerable to 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/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152809 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/squid-2.4.STABLE7-0.73.3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/squid-2.4.STABLE7-0.73.3.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/squid-2.5.STABLE1-9.10.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/squid-2.5.STABLE1-9.10.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/squid-2.5.STABLE3-2.fc1.6.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/squid-2.5.STABLE3-2.fc1.6.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/squid-2.5.STABLE9-1.FC2.4.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/squid-2.5.STABLE9-1.FC2.4.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 5db383926b0358e7b1a74cd0c84d3c253fae82a6 redhat/7.3/updates/i386/squid-2.4.STABLE7-0.73.3.legacy.i386.rpm 8d2b75252ee52b9fe943d4478960e30508bae4ea redhat/7.3/updates/SRPMS/squid-2.4.STABLE7-0.73.3.legacy.src.rpm d90f37a598d6789876d85fc41297fb6d6957711d redhat/9/updates/i386/squid-2.5.STABLE1-9.10.legacy.i386.rpm c6f5927ebca3000a5d9cb2d52912e9ea989ee8eb redhat/9/updates/SRPMS/squid-2.5.STABLE1-9.10.legacy.src.rpm 4e1d0e1546e50f3f694617ce641b31230b3989ad fedora/1/updates/i386/squid-2.5.STABLE3-2.fc1.6.legacy.i386.rpm 03e318f01302e6305d368349ea778ac9f104839d fedora/1/updates/SRPMS/squid-2.5.STABLE3-2.fc1.6.legacy.src.rpm 9eb87b9c886d2c72d6ecefa3f70e016d65de9574 fedora/2/updates/i386/squid-2.5.STABLE9-1.FC2.4.legacy.i386.rpm 6aab32f2cb1e01196722d2ee6e980dc3915d788b fedora/2/updates/SRPMS/squid-2.5.STABLE9-1.FC2.4.legacy.src.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=CVE-2004-0541 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0832 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0918 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0094 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0095 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0096 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0097 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0173 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0174 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0175 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0194 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0211 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0241 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0446 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0626 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0718 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1345 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-0710 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1519 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-2479 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2794 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2796 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2917 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Sat Feb 18 19:20:20 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sat, 18 Feb 2006 14:20:20 -0500 Subject: [FLSA-2006:168935] Updated openssh packages fix security issues Message-ID: <43F77374.2090306@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated openssh packages fix security issues Advisory ID: FLSA:168935 Issue date: 2006-02-18 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2004-2069 CVE-2006-0225 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated openssh packages that fix security issues are now available. OpenSSH is OpenBSD's SSH (Secure SHell) protocol implementation. SSH replaces rlogin and rsh, and provides secure encrypted communications between two untrusted hosts over an insecure network. X11 connections and arbitrary TCP/IP ports can also be forwarded over a secure channel. Public key authentication can be used for "passwordless" access to servers. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 Fedora Core 3 - i386, x86_64 3. Problem description: A bug was found in the way the OpenSSH server handled the MaxStartups and LoginGraceTime configuration variables. A malicious user could connect to the SSH daemon in such a way that it would prevent additional logins from occuring until the malicious connections are closed. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2004-2069 to this issue. The scp command was found to expose filenames twice to shell expansion. A malicious user could execute arbitrary commands by using specially crafted filenames containing shell metacharacters or spaces. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2006-0225 to this issue. Users of openssh should upgrade to these updated packages, which contain backported patches to resolve 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/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168935 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/openssh-3.1p1-14.3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/openssh-3.1p1-14.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/openssh-askpass-3.1p1-14.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/openssh-askpass-gnome-3.1p1-14.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/openssh-clients-3.1p1-14.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/openssh-server-3.1p1-14.3.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/openssh-3.5p1-11.4.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/openssh-3.5p1-11.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/openssh-askpass-3.5p1-11.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/openssh-askpass-gnome-3.5p1-11.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/openssh-clients-3.5p1-11.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/openssh-server-3.5p1-11.4.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/openssh-3.6.1p2-19.4.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/openssh-3.6.1p2-19.4.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/openssh-askpass-3.6.1p2-19.4.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/openssh-askpass-gnome-3.6.1p2-19.4.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/openssh-clients-3.6.1p2-19.4.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/openssh-server-3.6.1p2-19.4.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/openssh-3.6.1p2-34.4.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/openssh-3.6.1p2-34.4.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/openssh-askpass-3.6.1p2-34.4.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/openssh-askpass-gnome-3.6.1p2-34.4.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/openssh-clients-3.6.1p2-34.4.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/openssh-server-3.6.1p2-34.4.legacy.i386.rpm Fedora Core 3: SRPM: http://download.fedoralegacy.org/fedora/3/updates/SRPMS/openssh-3.9p1-8.0.4.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/3/updates/i386/openssh-3.9p1-8.0.4.legacy.i386.rpm http://download.fedoralegacy.org/fedora/3/updates/i386/openssh-askpass-3.9p1-8.0.4.legacy.i386.rpm http://download.fedoralegacy.org/fedora/3/updates/i386/openssh-askpass-gnome-3.9p1-8.0.4.legacy.i386.rpm http://download.fedoralegacy.org/fedora/3/updates/i386/openssh-clients-3.9p1-8.0.4.legacy.i386.rpm http://download.fedoralegacy.org/fedora/3/updates/i386/openssh-server-3.9p1-8.0.4.legacy.i386.rpm x86_64: http://download.fedoralegacy.org/fedora/3/updates/x86_64/openssh-3.9p1-8.0.4.legacy.x86_64.rpm http://download.fedoralegacy.org/fedora/3/updates/x86_64/openssh-askpass-3.9p1-8.0.4.legacy.x86_64.rpm http://download.fedoralegacy.org/fedora/3/updates/x86_64/openssh-askpass-gnome-3.9p1-8.0.4.legacy.x86_64.rpm http://download.fedoralegacy.org/fedora/3/updates/x86_64/openssh-clients-3.9p1-8.0.4.legacy.x86_64.rpm http://download.fedoralegacy.org/fedora/3/updates/x86_64/openssh-server-3.9p1-8.0.4.legacy.x86_64.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 5c732eac2396d1dbc767c6706b936177b04e3ba9 redhat/7.3/updates/i386/openssh-3.1p1-14.3.legacy.i386.rpm ac522209cbabd3638e8ca2b08bdf5453c1d9a8d4 redhat/7.3/updates/i386/openssh-askpass-3.1p1-14.3.legacy.i386.rpm a79e45b1fd78f517a2dfb846e1814aeff35ab86d redhat/7.3/updates/i386/openssh-askpass-gnome-3.1p1-14.3.legacy.i386.rpm daa5d5518e33835ef47f41f3bb379d9659e2bc3f redhat/7.3/updates/i386/openssh-clients-3.1p1-14.3.legacy.i386.rpm 28d3e3a66e6c786db875c5ea8d629b6abcc7fe5b redhat/7.3/updates/i386/openssh-server-3.1p1-14.3.legacy.i386.rpm d838db35baa90040dec9df7459af4682f8976b7a redhat/7.3/updates/SRPMS/openssh-3.1p1-14.3.legacy.src.rpm 2e4da4da715512dccb420fc67f3bb24dae2d9a40 redhat/9/updates/i386/openssh-3.5p1-11.4.legacy.i386.rpm af36bd2aa23d16986072cf15c6906add540f8b8a redhat/9/updates/i386/openssh-askpass-3.5p1-11.4.legacy.i386.rpm 0cc2cf34bde4b876944c8f19c1cd58d9f4503757 redhat/9/updates/i386/openssh-askpass-gnome-3.5p1-11.4.legacy.i386.rpm f0e967606a821ec50f6d0af708935a9f04b52d11 redhat/9/updates/i386/openssh-clients-3.5p1-11.4.legacy.i386.rpm d49d40f814c95319dff11a49f8bb66dcdd3f808c redhat/9/updates/i386/openssh-server-3.5p1-11.4.legacy.i386.rpm 38544ce3e39dbebcb15ce213f4aff9bf3edb93a7 redhat/9/updates/SRPMS/openssh-3.5p1-11.4.legacy.src.rpm c962909e215becff41ab14353a0b1ef3f5a499fd fedora/1/updates/i386/openssh-3.6.1p2-19.4.legacy.i386.rpm 61ca655031b498ba8c66a97f0792c4f9dbd0f795 fedora/1/updates/i386/openssh-askpass-3.6.1p2-19.4.legacy.i386.rpm 0201fe8254733f85cde19e17911015c38ae6f8fa fedora/1/updates/i386/openssh-askpass-gnome-3.6.1p2-19.4.legacy.i386.rpm 3818241e59db35fe61773f7e59d9d83fafd4b16a fedora/1/updates/i386/openssh-clients-3.6.1p2-19.4.legacy.i386.rpm 202bec4605eaf6054433a170a6432a3d449862cb fedora/1/updates/i386/openssh-server-3.6.1p2-19.4.legacy.i386.rpm e5b385dbba09ec63225c2eb25e22827d0e6fd789 fedora/1/updates/SRPMS/openssh-3.6.1p2-19.4.legacy.src.rpm ca85182633a97ce1bb8c3bcb683d44242881703f fedora/2/updates/i386/openssh-3.6.1p2-34.4.legacy.i386.rpm f49c8368fe790df101b671a368f0ff47fdc0fad3 fedora/2/updates/i386/openssh-askpass-3.6.1p2-34.4.legacy.i386.rpm 281fe61d517ebff0a297cd4c6342c398debcd33f fedora/2/updates/i386/openssh-askpass-gnome-3.6.1p2-34.4.legacy.i386.rpm d25c9ca4c55732cc3368587cfd6b4b7629c52ee8 fedora/2/updates/i386/openssh-clients-3.6.1p2-34.4.legacy.i386.rpm ec570330a25c600803dd2f88ff140726a66d3c7e fedora/2/updates/i386/openssh-server-3.6.1p2-34.4.legacy.i386.rpm 4bf28b7a7d7a9fad922b6a1e96a0433320cab26e fedora/2/updates/SRPMS/openssh-3.6.1p2-34.4.legacy.src.rpm 75001fc461867ff3b5f608423de99b5c0d9705e6 fedora/3/updates/i386/openssh-3.9p1-8.0.4.legacy.i386.rpm e4a4bfc7866e2ace0c9b0a0a3b4598e9594fd6ae fedora/3/updates/i386/openssh-askpass-3.9p1-8.0.4.legacy.i386.rpm 4df1fe9ad8bfcdee35dcddbc9fb124e513718275 fedora/3/updates/i386/openssh-askpass-gnome-3.9p1-8.0.4.legacy.i386.rpm f53b372fcab1724ac8a073aebc9b04718439c894 fedora/3/updates/i386/openssh-clients-3.9p1-8.0.4.legacy.i386.rpm 8b800276ec20d03452cf1e39883315baa9c7a7df fedora/3/updates/i386/openssh-server-3.9p1-8.0.4.legacy.i386.rpm 61a70c9f0cf6c152fb7f48c5857b5e002dc0527a fedora/3/updates/x86_64/openssh-3.9p1-8.0.4.legacy.x86_64.rpm b8e38615db4f431c1e87204a0ecaefbabde2479b fedora/3/updates/x86_64/openssh-askpass-3.9p1-8.0.4.legacy.x86_64.rpm 5cd606345fb8b3ba1f7c1d6f005d18c50d0886bd fedora/3/updates/x86_64/openssh-askpass-gnome-3.9p1-8.0.4.legacy.x86_64.rpm db5f2a76871dc0e6987702a492ad84252a5211c4 fedora/3/updates/x86_64/openssh-clients-3.9p1-8.0.4.legacy.x86_64.rpm 18f578efebdc634ee6ab363064f9ac8d81fa5cf0 fedora/3/updates/x86_64/openssh-server-3.9p1-8.0.4.legacy.x86_64.rpm 8dc6ca866a0a5d0e2c01f4b898bbaa798399fa40 fedora/3/updates/SRPMS/openssh-3.9p1-8.0.4.legacy.src.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=CVE-2004-2069 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0225 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Sat Feb 18 19:21:00 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sat, 18 Feb 2006 14:21:00 -0500 Subject: [FLSA-2006:175406] Updated Apache httpd packages fix security issues Message-ID: <43F7739C.6060207@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated Apache httpd packages fix security issues Advisory ID: FLSA:175406 Issue date: 2006-02-18 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2005-2970 CVE-2005-3352 CVE-2005-3357 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated Apache httpd packages that correct three security issues are now available. The Apache HTTP Server is a popular and freely-available Web server. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 Fedora Core 3 - i386, x86_64 3. Problem description: A memory leak in the worker MPM could allow remote attackers to cause a denial of service (memory consumption) via aborted connections, which prevents the memory for the transaction pool from being reused for other connections. The Common Vulnerabilities and Exposures project assigned the name CVE-2005-2970 to this issue. This vulnerability only affects users who are using the non-default worker MPM. A flaw in mod_imap when using the Referer directive with image maps was discovered. With certain site configurations, a remote attacker could perform a cross-site scripting attack if a victim can be forced to visit a malicious URL using certain web browsers. (CVE-2005-3352) A NULL pointer dereference flaw in mod_ssl was discovered affecting server configurations where an SSL virtual host is configured with access control and a custom 400 error document. A remote attacker could send a carefully crafted request to trigger this issue which would lead to a crash. This crash would only be a denial of service if using the non-default worker MPM. (CVE-2005-3357) Users of httpd should update to these erratum packages which contain backported patches to 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/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175406 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/apache-1.3.27-9.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/apache-1.3.27-9.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/apache-devel-1.3.27-9.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/apache-manual-1.3.27-9.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/httpd-2.0.40-21.21.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/httpd-2.0.40-21.21.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/httpd-devel-2.0.40-21.21.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/httpd-manual-2.0.40-21.21.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mod_ssl-2.0.40-21.21.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/httpd-2.0.51-1.10.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/httpd-2.0.51-1.10.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/httpd-devel-2.0.51-1.10.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/httpd-manual-2.0.51-1.10.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/mod_ssl-2.0.51-1.10.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/httpd-2.0.51-2.9.5.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/httpd-2.0.51-2.9.5.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/httpd-devel-2.0.51-2.9.5.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/httpd-manual-2.0.51-2.9.5.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/mod_ssl-2.0.51-2.9.5.legacy.i386.rpm Fedora Core 3: SRPM: http://download.fedoralegacy.org/fedora/3/updates/SRPMS/httpd-2.0.53-3.4.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/3/updates/i386/httpd-2.0.53-3.4.legacy.i386.rpm http://download.fedoralegacy.org/fedora/3/updates/i386/httpd-devel-2.0.53-3.4.legacy.i386.rpm http://download.fedoralegacy.org/fedora/3/updates/i386/httpd-manual-2.0.53-3.4.legacy.i386.rpm http://download.fedoralegacy.org/fedora/3/updates/i386/httpd-suexec-2.0.53-3.4.legacy.i386.rpm http://download.fedoralegacy.org/fedora/3/updates/i386/mod_ssl-2.0.53-3.4.legacy.i386.rpm x86_64: http://download.fedoralegacy.org/fedora/3/updates/x86_64/httpd-2.0.53-3.4.legacy.x86_64.rpm http://download.fedoralegacy.org/fedora/3/updates/x86_64/httpd-devel-2.0.53-3.4.legacy.x86_64.rpm http://download.fedoralegacy.org/fedora/3/updates/x86_64/httpd-manual-2.0.53-3.4.legacy.x86_64.rpm http://download.fedoralegacy.org/fedora/3/updates/x86_64/httpd-suexec-2.0.53-3.4.legacy.x86_64.rpm http://download.fedoralegacy.org/fedora/3/updates/x86_64/mod_ssl-2.0.53-3.4.legacy.x86_64.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- c55d929dd5acbf4b0191a28b0ad128f1064810f8 redhat/7.3/updates/i386/apache-1.3.27-9.legacy.i386.rpm aae52f7966d03dd6e81f8b8b5a090bf60fa8e601 redhat/7.3/updates/i386/apache-devel-1.3.27-9.legacy.i386.rpm fafcea3e68311223b5a814a482927cd645c4356a redhat/7.3/updates/i386/apache-manual-1.3.27-9.legacy.i386.rpm db23f5e77a78f78a346104038a564f0197ee9414 redhat/7.3/updates/SRPMS/apache-1.3.27-9.legacy.src.rpm 8e6ca52b5fb88a43322a38966ffeb0285b0699e1 redhat/9/updates/i386/httpd-2.0.40-21.21.legacy.i386.rpm be601feefd0483b24e3ce5efdfadcef6b5d7d040 redhat/9/updates/i386/httpd-devel-2.0.40-21.21.legacy.i386.rpm 8816478ae2287a3d2d4c9ca91d55662efcae2b87 redhat/9/updates/i386/httpd-manual-2.0.40-21.21.legacy.i386.rpm 2d565db0d6fa0756c51ca7aef8211b463c5f5348 redhat/9/updates/i386/mod_ssl-2.0.40-21.21.legacy.i386.rpm e05115a5178fbf853dfe8fdc75b962c44a787316 redhat/9/updates/SRPMS/httpd-2.0.40-21.21.legacy.src.rpm d34d8993fa09ebc2c017c98ac459688a913593f6 fedora/1/updates/i386/httpd-2.0.51-1.10.legacy.i386.rpm 1598bdf136a0ab14195df7d9f4425ab6442ab3f7 fedora/1/updates/i386/httpd-devel-2.0.51-1.10.legacy.i386.rpm e5d6b42924b9fd81869cbe07f410abd2ecaa106e fedora/1/updates/i386/httpd-manual-2.0.51-1.10.legacy.i386.rpm 56c59eec43c7d87f9f59f7068f80e2774de1784a fedora/1/updates/i386/mod_ssl-2.0.51-1.10.legacy.i386.rpm 4294e34c392cc90465d35dbfda88f95aae87c291 fedora/1/updates/SRPMS/httpd-2.0.51-1.10.legacy.src.rpm 3572be6a040d0efe5e71186578b42bb991328254 fedora/2/updates/i386/httpd-2.0.51-2.9.5.legacy.i386.rpm 3d75ef3d7720894c886c4d1a1e52f97f2b4bb345 fedora/2/updates/i386/httpd-devel-2.0.51-2.9.5.legacy.i386.rpm 74c6d5286da4daf697f041d3084cab0a2fda46c6 fedora/2/updates/i386/httpd-manual-2.0.51-2.9.5.legacy.i386.rpm 72050bf7341db26b0d72b8565102bb55eb9be250 fedora/2/updates/i386/mod_ssl-2.0.51-2.9.5.legacy.i386.rpm 32a2bfe031fcbb40ed1db4a84bacc5ad78a7b7a4 fedora/2/updates/SRPMS/httpd-2.0.51-2.9.5.legacy.src.rpm 563dd27fb0e74e13d1b8960e189f05af60926333 fedora/3/updates/i386/httpd-2.0.53-3.4.legacy.i386.rpm 3673bec7d02bd1972c20cbca6d77bccf4c08f516 fedora/3/updates/i386/httpd-devel-2.0.53-3.4.legacy.i386.rpm d004815e520338f6565e0f18d21847c6439c841f fedora/3/updates/i386/httpd-manual-2.0.53-3.4.legacy.i386.rpm 48eac837da227883d681aa23e182ebb00174980f fedora/3/updates/i386/httpd-suexec-2.0.53-3.4.legacy.i386.rpm ffdb283132cdf0e0de7026709087781a4f2eabb0 fedora/3/updates/i386/mod_ssl-2.0.53-3.4.legacy.i386.rpm dcf460eadeb704d54a807058d63e69c8a62b49b5 fedora/3/updates/x86_64/httpd-2.0.53-3.4.legacy.x86_64.rpm eaa6dd54a8b8ad5165f8643ef4e34eef83f587b6 fedora/3/updates/x86_64/httpd-devel-2.0.53-3.4.legacy.x86_64.rpm 088d7acc09d35b63a9a5278575d2797f5202d811 fedora/3/updates/x86_64/httpd-manual-2.0.53-3.4.legacy.x86_64.rpm 332a9afb589537e33d895685bd145230834e77d1 fedora/3/updates/x86_64/httpd-suexec-2.0.53-3.4.legacy.x86_64.rpm 85c1f146a3f8e9af3ad44b5467cfebfb18eeaee5 fedora/3/updates/x86_64/mod_ssl-2.0.53-3.4.legacy.x86_64.rpm b6698d717f8dd6b028ee32184bcc778724695a83 fedora/3/updates/SRPMS/httpd-2.0.53-3.4.legacy.src.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=CVE-2005-2970 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3352 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3357 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From fedora-legacy at neufeind.net Sat Feb 18 19:38:37 2006 From: fedora-legacy at neufeind.net (Stefan Neufeind) Date: Sat, 18 Feb 2006 20:38:37 +0100 Subject: Security-release httpd for FC3 Message-ID: <43F777BD.8090508@neufeind.net> Hi, the current releases are not yet available at the links mentioned in the announcement. Is that right? At least not e.g. for httpd for FC3 which I tried: http://download.fedoralegacy.org/fedora/3/updates/i386/httpd-2.0.53-3.4.legacy.i386.rpm Kind regards, Stefan From marcdeslauriers at videotron.ca Sat Feb 18 20:38:07 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sat, 18 Feb 2006 15:38:07 -0500 Subject: Security-release httpd for FC3 In-Reply-To: <43F777BD.8090508@neufeind.net> References: <43F777BD.8090508@neufeind.net> Message-ID: <1140295088.7128.8.camel@mdlinux> On Sat, 2006-02-18 at 20:38 +0100, Stefan Neufeind wrote: > the current releases are not yet available at the links mentioned in the > announcement. Is that right? At least not e.g. for httpd for FC3 which I > tried: > > http://download.fedoralegacy.org/fedora/3/updates/i386/httpd-2.0.53-3.4.legacy.i386.rpm It takes a while for the mirrors to sync. It should be there now. Marc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From fedora-legacy at neufeind.net Sat Feb 18 22:02:13 2006 From: fedora-legacy at neufeind.net (Stefan Neufeind) Date: Sat, 18 Feb 2006 23:02:13 +0100 Subject: Security-release httpd for FC3 In-Reply-To: <1140295088.7128.8.camel@mdlinux> References: <43F777BD.8090508@neufeind.net> <1140295088.7128.8.camel@mdlinux> Message-ID: <43F79965.1080708@neufeind.net> Marc Deslauriers wrote: > On Sat, 2006-02-18 at 20:38 +0100, Stefan Neufeind wrote: >> the current releases are not yet available at the links mentioned in the >> announcement. Is that right? At least not e.g. for httpd for FC3 which I >> tried: >> >> http://download.fedoralegacy.org/fedora/3/updates/i386/httpd-2.0.53-3.4.legacy.i386.rpm > > It takes a while for the mirrors to sync. It should be there now. Sorry for the noise :-) From nils at lemonbit.nl Sun Feb 19 21:21:16 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Sun, 19 Feb 2006 22:21:16 +0100 Subject: VMware en Fedora Message-ID: Hi all, Check out http://clunixchit.blogspot.com/2006/02/launching-fedora- based-livecd-with.html and the linked article there. Maybe interesting stuff for the QA/VMware department? Nils Breunese. From rostetter at mail.utexas.edu Mon Feb 20 21:58:01 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 20 Feb 2006 15:58:01 -0600 Subject: Comments on first verification QA In-Reply-To: References: Message-ID: <20060220155801.xyiohlht8gpw84co@mail.ph.utexas.edu> Quoting Tres Seaver : > I am therefore very much inclined to back the idea that Legacy offer > "minimal" images as starting points for would-be QA volunteers, along > with directions on how to set up either VMWare's Server or Player > products to use them. We might need to give people clues about using > the "snapshot" facilities provided by the tools to ease the process, as > well. Yes, I agree. I would love to see this done. I would then be able to use VM to test things also, which would be great. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From donjr at maner.org Mon Feb 20 22:08:07 2006 From: donjr at maner.org (Donald Maner) Date: Mon, 20 Feb 2006 16:08:07 -0600 Subject: Comments on first verification QA Message-ID: <9CD490EAC0F62A40A780878421D4A7305209@amun.home.maner.org> I gotta say, that I tried to use the currently available Server beta, and I wasn't impressed. My VMs would lock up on boot. I just went back to using GSX server (after I screwed up my ESX server and decided to export the VMs to use in GSX). > -----Original Message----- > From: fedora-legacy-list-bounces at redhat.com > [mailto:fedora-legacy-list-bounces at redhat.com] On Behalf Of > Eric Rostetter > Sent: Monday, February 20, 2006 3:58 PM > To: fedora-legacy-list at redhat.com > Subject: Re: Comments on first verification QA > > Quoting Tres Seaver : > > > I am therefore very much inclined to back the idea that > Legacy offer > > "minimal" images as starting points for would-be QA > volunteers, along > > with directions on how to set up either VMWare's Server or Player > > products to use them. We might need to give people clues > about using > > the "snapshot" facilities provided by the tools to ease the > process, > > as well. > > Yes, I agree. I would love to see this done. I would then > be able to use VM to test things also, which would be great. From marcdeslauriers at videotron.ca Tue Feb 21 00:57:04 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 20 Feb 2006 19:57:04 -0500 Subject: Fedora Legacy Test Update Notification: kernel (rh73 and rh9) Message-ID: <43FA6560.902@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-157459-1 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157459 2006-02-20 --------------------------------------------------------------------- Name : kernel Versions : rh7.3: kernel-2.4.20-45.7.legacy Versions : rh9: kernel-2.4.20-45.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 the 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: Updated kernel packages that fix several security issues are now available. The Linux kernel handles the basic functions of the operating system. These new kernel packages contain fixes for the security issues described below: - a flaw in network IGMP processing that a allowed a remote user on the local network to cause a denial of service (disabling of multicast reports) if the system is running multicast applications (CVE-2002-2185) - a recent Internet Draft by Fernando Gont recommended that ICMP Source Quench messages be ignored by hosts. A patch to ignore these messages is included. (CVE-2004-0791) - flaws in the coda module that allowed denial-of-service attacks (crashes) or local privilege escalations (CVE-2005-0124) - a flaw between execve() syscall handling and core dumping of ELF-format executables allowed local unprivileged users to cause a denial of service (system crash) or possibly gain privileges (CVE-2005-1263) - a flaw in gzip/zlib handling internal to the kernel that may allow a local user to cause a denial of service (crash) (CVE-2005-2458) - a flaw in sendmsg() syscall handling on 64-bit systems that allowed a local user to cause a denial of service or potentially gain privileges (CAN-2005-2490) - a flaw in exec() handling on some 64-bit architectures that allowed a local user to cause a denial of service (crash) (CVE-2005-2708) - a flaw in procfs handling during unloading of modules that allowed a local user to cause a denial of service or potentially gain privileges (CVE-2005-2709) - a flaw in IPv6 network UDP port hash table lookups that allowed a local user to cause a denial of service (hang) (CVE-2005-2973) - a network buffer info leak using the orinoco driver that allowed a remote user to possibly view uninitialized data (CVE-2005-3180) - a flaw in the packet radio ROSE protocol that allowed a user to trigger out-of-bounds errors. (CVE-2005-3273) - a flaw in IPv4 network TCP and UDP netfilter handling that allowed a local user to cause a denial of service (crash) (CVE-2005-3275) - a minor info leak with the get_thread_area() syscall that allowed a local user to view uninitialized kernel stack data (CVE-2005-3276) - a flaw in the IPv6 flowlabel code that allowed a local user to cause a denial of service (crash) (CVE-2005-3806) - a flaw in file lease time-out handling that allowed a local user to cause a denial of service (log file overflow) (CVE-2005-3857) All users are advised to upgrade their kernels to the packages associated with their machine architectures and configurations as listed in this erratum. --------------------------------------------------------------------- Changelogs rh73: * Sat Feb 04 2006 Marc Deslauriers 2.4.20-45.9.legacy - Removed CVE-2005-3044 patch (it was 64-bit only) - Fixed CVE-2005-2709 patch - Added patch for CVE-2002-2185 (potential IGMP DoS) * Fri Feb 03 2006 Marc Deslauriers 2.4.20-44.9.legacy - Added patches for: CVE-2004-0791 (source quench DoS) CVE-2005-0124 (coda fs flaw) CVE-2005-1263 (ELF core dump privilege elevation) CVE-2005-2458 (gzip/zlib flaws) CVE-2005-2490 (compat layer sendmsg() races) CVE-2005-2708 (user code panics kernel in exec.c) CVE-2005-2709 (sysctl races) CVE-2005-2973 (ipv6 infinite loop) CVE-2005-3044 (lost fput and sockfd_put could lead to DoS) CVE-2005-3180 (orinoco driver information leakage) CVE-2005-3273 (ROSE ndigis verification) CVE-2005-3275 (NAT DoS) CVE-2005-3276 (sys_get_thread_area minor info leak) CVE-2005-3806 (ipv6 flowlabel DOS) CVE-2005-3857 (lease printk DoS) rh9: * Sat Feb 04 2006 Marc Deslauriers 2.4.20-45.9.legacy - Removed CVE-2005-3044 patch (it was 64-bit only) - Fixed CVE-2005-2709 patch - Added patch for CVE-2002-2185 (potential IGMP DoS) * Fri Feb 03 2006 Marc Deslauriers 2.4.20-44.9.legacy - Added patches for: CVE-2004-0791 (source quench DoS) CVE-2005-0124 (coda fs flaw) CVE-2005-1263 (ELF core dump privilege elevation) CVE-2005-2458 (gzip/zlib flaws) CVE-2005-2490 (compat layer sendmsg() races) CVE-2005-2708 (user code panics kernel in exec.c) CVE-2005-2709 (sysctl races) CVE-2005-2973 (ipv6 infinite loop) CVE-2005-3044 (lost fput and sockfd_put could lead to DoS) CVE-2005-3180 (orinoco driver information leakage) CVE-2005-3273 (ROSE ndigis verification) CVE-2005-3275 (NAT DoS) CVE-2005-3276 (sys_get_thread_area minor info leak) CVE-2005-3806 (ipv6 flowlabel DOS) CVE-2005-3857 (lease printk DoS) --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh7.3: 95b69624330b0f8e68f49abf74ecc23c570ae4b5 redhat/7.3/updates-testing/i386/kernel-2.4.20-45.7.legacy.athlon.rpm 3d3077374f86a53920a3a0c69cbbb06e831f24d3 redhat/7.3/updates-testing/i386/kernel-2.4.20-45.7.legacy.i386.rpm 778142537201606c53c3d019236c2760429dbe3d redhat/7.3/updates-testing/i386/kernel-2.4.20-45.7.legacy.i586.rpm 488df87ec8914c665f2509688a06dbb7dc5cf476 redhat/7.3/updates-testing/i386/kernel-2.4.20-45.7.legacy.i686.rpm 35a542d7ed5e2dff70e6ebeb15dc63db3a5a22ed redhat/7.3/updates-testing/i386/kernel-bigmem-2.4.20-45.7.legacy.i686.rpm 102da0ff1569535bbc7d9aca3e2a561023acb57e redhat/7.3/updates-testing/i386/kernel-BOOT-2.4.20-45.7.legacy.i386.rpm 8e212adf8bfc35be7dc76ddc5a953f284afb6999 redhat/7.3/updates-testing/i386/kernel-doc-2.4.20-45.7.legacy.i386.rpm b7028d0d870b89f6458bb84327cb027c3d9ec5d1 redhat/7.3/updates-testing/i386/kernel-smp-2.4.20-45.7.legacy.athlon.rpm 2943f4978adeb9f53c50188662408a23634e302b redhat/7.3/updates-testing/i386/kernel-smp-2.4.20-45.7.legacy.i586.rpm 4035b35ddeac849f735c8ad5cde1a7bb3fef5e21 redhat/7.3/updates-testing/i386/kernel-smp-2.4.20-45.7.legacy.i686.rpm d242481b1d858a51630249cce33c21e228c46e07 redhat/7.3/updates-testing/i386/kernel-source-2.4.20-45.7.legacy.i386.rpm 89fbef5527f3eca6d425fa9ea19279d5f68bd5e2 redhat/7.3/updates-testing/SRPMS/kernel-2.4.20-45.7.legacy.src.rpm rh9: 79715461d8828d7234ec6b869bc4194c2a79b361 redhat/9/updates-testing/i386/kernel-2.4.20-45.9.legacy.athlon.rpm 7f9842acd1795a36cb453e25e407ca2025341f36 redhat/9/updates-testing/i386/kernel-2.4.20-45.9.legacy.i386.rpm aa842cd1fe707a70c931ff48ba50298262f2497b redhat/9/updates-testing/i386/kernel-2.4.20-45.9.legacy.i586.rpm 7ec2ea043778048f1406ece0c7f6b991e02966ac redhat/9/updates-testing/i386/kernel-2.4.20-45.9.legacy.i686.rpm 09d566d1a703b793c42b87155b0d4814dfd40469 redhat/9/updates-testing/i386/kernel-bigmem-2.4.20-45.9.legacy.i686.rpm 45802423788003573d97706975ccc9636d89c82b redhat/9/updates-testing/i386/kernel-BOOT-2.4.20-45.9.legacy.i386.rpm 9c1d236b876886cfd3327aa2f348e7e5530442fa redhat/9/updates-testing/i386/kernel-doc-2.4.20-45.9.legacy.i386.rpm 97ce9e99cb88f211a5a9346705fad362b418816b redhat/9/updates-testing/i386/kernel-smp-2.4.20-45.9.legacy.athlon.rpm 3232e1932a793feee9d625aea2bbde38abff40dc redhat/9/updates-testing/i386/kernel-smp-2.4.20-45.9.legacy.i586.rpm fc363685f585932dbb1ebb90c093a411e6195598 redhat/9/updates-testing/i386/kernel-smp-2.4.20-45.9.legacy.i686.rpm 81fa656b518909155cd84e2cfeebda3eb1050af5 redhat/9/updates-testing/i386/kernel-source-2.4.20-45.9.legacy.i386.rpm c267b0ccf2e7f62362b2e0413eeb9f315d04dd77 redhat/9/updates-testing/SRPMS/kernel-2.4.20-45.9.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Tue Feb 21 00:57:30 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 20 Feb 2006 19:57:30 -0500 Subject: Fedora Legacy Test Update Notification: kernel (fc1) Message-ID: <43FA657A.5070401@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-157459-2 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157459 2006-02-20 --------------------------------------------------------------------- Name : kernel Versions : fc1: kernel-2.4.22-1.2199.7.legacy.nptl Summary : The Linux kernel (the core of the Linux operating system). Description : The kernel package contains the Linux kernel (vmlinuz), the core of the 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: Updated kernel packages that fix several security issues are now available. The Linux kernel handles the basic functions of the operating system. These new kernel packages contain fixes for the security issues described below: - a flaw in network IGMP processing that a allowed a remote user on the local network to cause a denial of service (disabling of multicast reports) if the system is running multicast applications (CVE-2002-2185) - a recent Internet Draft by Fernando Gont recommended that ICMP Source Quench messages be ignored by hosts. A patch to ignore these messages is included. (CVE-2004-0791) - flaws in ptrace() syscall handling on AMD64 and Intel EM64T systems that allowed a local user to cause a denial of service (crash) (CAN-2005-0756, CAN-2005-1762, CAN-2005-2553) - a flaw between execve() syscall handling and core dumping of ELF-format executables allowed local unprivileged users to cause a denial of service (system crash) or possibly gain privileges (CVE-2005-1263) - a flaw in gzip/zlib handling internal to the kernel that may allow a local user to cause a denial of service (crash) (CVE-2005-2458) - a flaw in sendmsg() syscall handling on 64-bit systems that allowed a local user to cause a denial of service or potentially gain privileges (CAN-2005-2490) - a flaw in exec() handling on some 64-bit architectures that allowed a local user to cause a denial of service (crash) (CVE-2005-2708) - a flaw in procfs handling during unloading of modules that allowed a local user to cause a denial of service or potentially gain privileges (CVE-2005-2709) - a flaw in IPv6 network UDP port hash table lookups that allowed a local user to cause a denial of service (hang) (CVE-2005-2973) - a flaw in 32-bit-compat handling of the TIOCGDEV ioctl that allowed a local user to cause a denial of service (crash) (CVE-2005-3044) - a network buffer info leak using the orinoco driver that allowed a remote user to possibly view uninitialized data (CVE-2005-3180) - a flaw in IPv4 network TCP and UDP netfilter handling that allowed a local user to cause a denial of service (crash) (CVE-2005-3275) - a minor info leak with the get_thread_area() syscall that allowed a local user to view uninitialized kernel stack data (CVE-2005-3276) - a flaw in the IPv6 flowlabel code that allowed a local user to cause a denial of service (crash) (CVE-2005-3806) - a flaw in file lease time-out handling that allowed a local user to cause a denial of service (log file overflow) (CVE-2005-3857) All users are advised to upgrade their kernels to the packages associated with their machine architectures and configurations as listed in this erratum. --------------------------------------------------------------------- Changelogs fc1: * Fri Feb 17 2006 Marc Deslauriers 2.4.22-1.2199.7.legacy.nptl - Added patch for CVE-2002-2185 (potential IGMP DoS) * Thu Feb 02 2006 Marc Deslauriers 2.4.22-1.2199.6.legacy.nptl - Added patches for: CVE-2004-0791 (source quench DoS) CVE-2005-0756 (ptrace-check-segment x86_64 crash) CVE-2005-1263 (ELF core dump privilege elevation) CVE-2005-1762 (ptrace can induce double-fault on x86_64) CVE-2005-2458 (gzip/zlib flaws) CVE-2005-2490 (compat layer sendmsg() races) CVE-2005-2553 (32-bit ptrace find_target() oops) CVE-2005-2708 (user code panics kernel in exec.c) CVE-2005-2709 (sysctl races) CVE-2005-2973 (ipv6 infinite loop) CVE-2005-3044 (lost fput and sockfd_put could lead to DoS) CVE-2005-3180 (orinoco driver information leakage) CVE-2005-3275 (NAT DoS) CVE-2005-3276 (sys_get_thread_area minor info leak) CVE-2005-3806 (ipv6 flowlabel DOS) CVE-2005-3857 (lease printk DoS) --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) fc1: 3e6b7ebfdf1b6c5f075aef36299ce8746f292d40 fedora/1/updates-testing/i386/kernel-2.4.22-1.2199.7.legacy.nptl.athlon.rpm 839072496f51940e258f5611b9cc58007a4d7364 fedora/1/updates-testing/i386/kernel-2.4.22-1.2199.7.legacy.nptl.i586.rpm 79d928006411ff6bffda331d2f2a4c1023b5f26f fedora/1/updates-testing/i386/kernel-2.4.22-1.2199.7.legacy.nptl.i686.rpm 84b43c2dff417f86a6dcd0266a55b79bddaa99da fedora/1/updates-testing/i386/kernel-BOOT-2.4.22-1.2199.7.legacy.nptl.i386.rpm 7cc2ce4d1db0f84bc1f8fcec0d988b2d09f322e4 fedora/1/updates-testing/i386/kernel-doc-2.4.22-1.2199.7.legacy.nptl.i386.rpm 178695c22baa53fc78eb3ee5ec60300a75fda9c1 fedora/1/updates-testing/i386/kernel-smp-2.4.22-1.2199.7.legacy.nptl.athlon.rpm 723c08fc887abab70032e3c0dabf2d3331502e67 fedora/1/updates-testing/i386/kernel-smp-2.4.22-1.2199.7.legacy.nptl.i586.rpm 9374c084a20f5610911bfb63e4a607ba1cbd05a2 fedora/1/updates-testing/i386/kernel-smp-2.4.22-1.2199.7.legacy.nptl.i686.rpm 27c171fe901031ac3a7b89cc3e6b38df4b662cdb fedora/1/updates-testing/i386/kernel-source-2.4.22-1.2199.7.legacy.nptl.i386.rpm b65085b0eacca6ec4288b00aefeb58a29aae5f83 fedora/1/updates-testing/SRPMS/kernel-2.4.22-1.2199.7.legacy.nptl.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Tue Feb 21 00:57:54 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 20 Feb 2006 19:57:54 -0500 Subject: Fedora Legacy Test Update Notification: kernel (fc2) Message-ID: <43FA6592.9010502@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-157459-3 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157459 2006-02-20 --------------------------------------------------------------------- Name : kernel Versions : fc2: kernel-2.6.10-2.3.legacy_FC2 Summary : The Linux kernel (the core of the Linux operating system). Description : The kernel package contains the Linux kernel (vmlinuz), the core of the 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: Updated kernel packages that fix several security issues are now available. The Linux kernel handles the basic functions of the operating system. These new kernel packages contain fixes for the security issues described below: - a flaw in network IGMP processing that a allowed a remote user on the local network to cause a denial of service (disabling of multicast reports) if the system is running multicast applications (CVE-2002-2185) - flaws in ptrace() syscall handling on 64-bit systems that allowed a local user to cause a denial of service (crash) (CVE-2005-0756, CVE-2005-1761, CVE-2005-1762, CVE-2005-1763) - a flaw when setting the line discipline on a serial tty that allowed a local user to inject mouse movements or keystrokes when another user is logged in. (CVE-2005-0839) - an integer overflow flaw when writing to a sysfs file that allowed a local user to overwrite kernel memory, causing a denial of service (system crash) or arbitrary code execution. (CVE-2005-0867) - a flaw in the futex functions that allowed a local user to cause a denial of service (system crash). (CVE-2005-0937) - a flaw in the tmpfs file system that allowed a local user to cause a denial of service (system crash). (CVE-2005-0977) - a flaw in the fib_seq_start function that allowed a local user to cause a denial of service (system crash) via /proc/net/route. (CVE-2005-1041) - a flaw between execve() syscall handling and core dumping of ELF-format executables allowed local unprivileged users to cause a denial of service (system crash) or possibly gain privileges (CVE-2005-1263) - a flaw in the servicing of a raw device ioctl that allowed a local user who has access to raw devices to write to kernel memory and cause a denial of service or potentially gain privileges (CVE-2005-1264) - a flaw that prevented the topdown allocator from allocating mmap areas all the way down to address zero (CVE-2005-1265) - a flaw in the key_user_lookup function in security/keys/key.c that allowed a user to cause a denial of service (crash) (CVE-2005-1368) - a flaw in the it87 and via686a drivers in I2C that allowed a locl user to cause a denial of service (crash) (CVE-2005-1369) - flaws dealing with keyrings that could cause a local denial of service (CVE-2005-2098, CVE-2005-2099) - flaws in IPSEC network handling that allowed a local user to cause a denial of service or potentially gain privileges (CVE-2005-2456, CVE-2005-2555) - a flaw in gzip/zlib handling internal to the kernel that may allow a local user to cause a denial of service (crash) (CVE-2005-2458) - a flaw in sendmsg() syscall handling on 64-bit systems that allowed a local user to cause a denial of service or potentially gain privileges (CVE-2005-2490) - a flaw in sendmsg() syscall handling that allowed a local user to cause a denial of service by altering hardware state (CVE-2005-2492) - a flaw in procfs handling during unloading of modules that allowed a local user to cause a denial of service or potentially gain privileges (CVE-2005-2709) - a flaw in the SCSI procfs interface that allowed a local user to cause a denial of service (crash) (CVE-2005-2800) - a xattr sharing bug in the ext2 and ext3 file systems that could cause default ACLs to disappear (CVE-2005-2801) - a flaw in the ipt_recent module on 64-bit architectures which could allow a remote denial of service (CVE-2005-2872) - a flaw in IPv6 network UDP port hash table lookups that allowed a local user to cause a denial of service (hang) (CVE-2005-2973) - a flaw in 32-bit-compat handling of the TIOCGDEV ioctl that allowed a local user to cause a denial of service (crash) (CVE-2005-3044) - a flaw in the set_mempolicy system call that allowed a local user to cause a denial of service (system panic). (CVE-2005-3053) - a race condition when threads share memory mapping that allowed local users to cause a denial of service (deadlock) (CVE-2005-3106) - a flaw when trying to mount a non-hfsplus filesystem using hfsplus that allowed local users to cause a denial of service (crash) (CVE-2005-3109) - a race condition in the ebtables netfilter module that may allow remote attackers to cause a denial of service (crash) on a SMP system that is operating under a heavy load (CVE-2005-3110) - a network buffer info leak using the orinoco driver that allowed a remote user to possibly view uninitialized data (CVE-2005-3180) - a memory leak was found in the audit system that allowed an unprivileged local user to cause a denial of service. (CVE-2005-3181) - a race condition in ip_vs_conn_flush that allowed a local user to cause a denial of service (CVE-2005-3274) - a flaw in IPv4 network TCP and UDP netfilter handling that allowed a local user to cause a denial of service (crash) (CVE-2005-3275) - a minor info leak with the get_thread_area() syscall that allowed a local user to view uninitialized kernel stack data (CVE-2005-3276) - a flaw in mq_open system call that allowed a local user to cause a denial of service (crash) (CVE-2005-3356) - a flaw in set_mempolicy that allowed a local user on some 64-bit architectures to cause a denial of service (crash) (CVE-2005-3358) - a flaw in the auto-reap of child processes that allowed a local user to cause a denial of service (crash) (CVE-2005-3784) - a flaw in the POSIX timer cleanup handling that allowed a local user to cause a denial of service (crash) (CVE-2005-3805) - a flaw in the IPv6 flowlabel code that allowed a local user to cause a denial of service (crash) (CVE-2005-3806) - a memory leak in the VFS file lease handling that allowed a local user to cause a denial of service (CVE-2005-3807) - a flaw in network ICMP processing that allowed a local user to cause a denial of service (memory exhaustion) (CVE-2005-3848) - a flaw in file lease time-out handling that allowed a local user to cause a denial of service (log file overflow) (CVE-2005-3857) - a flaw in network IPv6 xfrm handling that allowed a local user to cause a denial of service (memory exhaustion) (CVE-2005-3858) - a flaw in procfs handling that allowed a local user to read kernel memory (CVE-2005-4605) - a memory disclosure flaw in dm-crypt that allowed a local user to obtain sensitive information about a cryptographic key (CVE-2006-0095) All users are advised to upgrade their kernels to the packages associated with their machine architectures and configurations as listed in this erratum. --------------------------------------------------------------------- Changelogs fc2: * Fri Feb 10 2006 Marc Deslauriers 2.6.10-2.3.legacy_FC2 - Added patches for: CVE-2002-2185 (IGMP DoS) CVE-2005-3805 (POSIX timer cleanup handling on exit locking problem) CVE-2005-3807 (memory leak with file leases) CVE-2006-0095 (dm-crypt key leak) * Fri Feb 03 2006 Marc Deslauriers 2.6.10-2.2.legacy_FC2 - Added patches for: CVE-2005-2800 (/proc/scsi/scsi DoS) CVE-2005-2801 (ext2/3 xattr sharing bug) CVE-2005-2872 (ipt_recent integer handling) CVE-2005-2973 (ipv6 infinite loop) CVE-2005-3053 (sys_set_mempolicy() bounds check) CVE-2005-3106 (exec_mmap race DoS) CVE-2005-3109 (HFS oops) CVE-2005-3110 (race in ebtables) CVE-2005-3180 (etherleak in orinoco) CVE-2005-3181 (names_cache memory leak) CVE-2005-3275 (NAT DoS) CVE-2005-3276 (sys_get_thread_area has minor info leak) CVE-2005-3848 (dst_entry leak DoS) CVE-2005-3858 (ip6_input_finish DoS) * Sat Jan 28 2006 Marc Deslauriers 2.6.10-2.1.legacy_FC2 - Added patches for: CVE-2005-0756 (ptrace-check-segment x86_64 crash) CVE-2005-0839 (Only root should be able to set the N_MOUSE line discipline) CVE-2005-0867 (signedness issue in sysfs) CVE-2005-0937 (futex mmap_sem deadlock) CVE-2005-0977 (tmpfs truncate bug) CVE-2005-1041 (crash while reading /proc/net/route) CVE-2005-1263 (ELF core dump privilege elevation) CVE-2005-1264 (data corruptor/local root in raw driver) CVE-2005-1265 (Prevent NULL mmap in topdown model) CVE-2005-1368 (key lookup race DoS) CVE-2005-1369 (i2c alarms sysfs DoS) CVE-2005-1761 (ia64 ptrace vulnerability) CVE-2005-1762 (ptrace can induce double-fault on x86_64) CVE-2005-1763 (x86_64-ptrace-overflow crash) CVE-2005-2098 (key management session can leave semaphore pinned) CVE-2005-2099 (Destruction of failed keyring oopses) CVE-2005-2456 (IPSEC overflow) CVE-2005-2458 (gzip/zlib flaws) CVE-2005-2490 (compat layer sendmsg() races) CVE-2005-2492 (Fix raw_sendmsg accesses) CVE-2005-2555 (IPSEC lacks restrictions) CVE-2005-2709 (sysctl races) CVE-2005-3044 (lost fput and sockfd_put could lead to DoS) CVE-2005-3274 (ip_vs_conn_flush race condition DoS) CVE-2005-3356 (double decrement of mqueue_mnt->mnt_count in sys_mq_open) CVE-2005-3358 (prevent panic caused by invalid arguments to set_mempolicy) CVE-2005-3784 (auto-reap DoS) CVE-2005-3806 (ipv6 flowlabel DOS) CVE-2005-3857 (lease printk DoS) CVE-2005-4605 (kernel memory disclosure via /proc exploit) --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) fc2: 68999cdecf0bb3c6cda09edbe2cedd57fff709ad fedora/2/updates-testing/i386/kernel-2.6.10-2.3.legacy_FC2.i586.rpm 85de0ac6c22acb127c7bfae0c8b6e8067fd60442 fedora/2/updates-testing/i386/kernel-2.6.10-2.3.legacy_FC2.i686.rpm 631a71b16611758af3db18da17205422deb41c30 fedora/2/updates-testing/i386/kernel-doc-2.6.10-2.3.legacy_FC2.noarch.rpm 6f5010188ca24a79d5fb6323a687c5cdc9611d24 fedora/2/updates-testing/i386/kernel-smp-2.6.10-2.3.legacy_FC2.i586.rpm 4beec907750088ff917855a7e5ec8a31bb752358 fedora/2/updates-testing/i386/kernel-smp-2.6.10-2.3.legacy_FC2.i686.rpm 1a33e38fa69b09fb80e6a5d334aad72e963820eb fedora/2/updates-testing/i386/kernel-sourcecode-2.6.10-2.3.legacy_FC2.noarch.rpm 85eee44769a3a0ca55221b93d9386563798961a7 fedora/2/updates-testing/SRPMS/kernel-2.6.10-2.3.legacy_FC2.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Tue Feb 21 00:58:21 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 20 Feb 2006 19:58:21 -0500 Subject: Fedora Legacy Test Update Notification: kernel (fc3) Message-ID: <43FA65AD.70809@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-157459-4 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157459 2006-02-20 --------------------------------------------------------------------- Name : kernel Versions : fc3: kernel-2.6.12-2.3.legacy_FC3 Summary : The Linux kernel (the core of the Linux operating system). Description : The kernel package contains the Linux kernel (vmlinuz), the core of the 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: Updated kernel packages that fix several security issues are now available. The Linux kernel handles the basic functions of the operating system. These new kernel packages contain fixes for the security issues described below: - a flaw in network IGMP processing that a allowed a remote user on the local network to cause a denial of service (disabling of multicast reports) if the system is running multicast applications (CVE-2002-2185) - a flaw in procfs handling during unloading of modules that allowed a local user to cause a denial of service or potentially gain privileges (CVE-2005-2709) - a flaw in 32-bit-compat handling of the TIOCGDEV ioctl that allowed a local user to cause a denial of service (crash) (CVE-2005-3044) - a race condition in ip_vs_conn_flush that allowed a local user to cause a denial of service (CVE-2005-3274) - a flaw in mq_open system call that allowed a local user to cause a denial of service (crash) (CVE-2005-3356) - a flaw in set_mempolicy that allowed a local user on some 64-bit architectures to cause a denial of service (crash) (CVE-2005-3358) - a race condition in do_coredump in signal.c that allowed a local user to cause a denial of service (crash) (CVE-2005-3527) - a flaw in the auto-reap of child processes that allowed a local user to cause a denial of service (crash) (CVE-2005-3784) - a flaw in the POSIX timer cleanup handling that allowed a local user to cause a denial of service (crash) (CVE-2005-3805) - a flaw in the IPv6 flowlabel code that allowed a local user to cause a denial of service (crash) (CVE-2005-3806) - a memory leak in the VFS file lease handling that allowed a local user to cause a denial of service (CVE-2005-3807) - a flaw in file lease time-out handling that allowed a local user to cause a denial of service (log file overflow) (CVE-2005-3857) - a flaw in procfs handling that allowed a local user to read kernel memory (CVE-2005-4605) - a memory disclosure flaw in dm-crypt that allowed a local user to obtain sensitive information about a cryptographic key (CVE-2006-0095) - a flaw while constructing an ICMP response that allowed remote users to cause a denial of service (crash) (CVE-2006-0454) All users are advised to upgrade their kernels to the packages associated with their machine architectures and configurations as listed in this erratum. --------------------------------------------------------------------- Changelogs fc3: * Sat Feb 18 2006 Marc Deslauriers 2.6.12-2.3.legacy_FC3 - Corrected upstream reference in CVE-2006-0454 patch * Tue Feb 07 2006 Marc Deslauriers 2.6.12-2.2.legacy_FC3 - Added patches for: CVE-2002-2185 (IGMP DoS) CVE-2005-3527 (do_coredump() vs SIGSTOP race) CVE-2005-3805 (POSIX timer cleanup handling on exit locking problem) CVE-2006-0095 (dm-crypt key leak) CVE-2006-0454 (ICMP route double-free) CVE-2005-3807 (memory leak with file leases) * Fri Jan 27 2006 Marc Deslauriers 2.6.12-2.1.legacy_FC3 - Added patches for: CVE-2005-2709 (sysctl races) CVE-2005-3044 (lost fput and sockfd_put could lead to DoS) CVE-2005-3274 (ip_vs_conn_flush race condition DoS) CVE-2005-3356 (double decrement of mqueue_mnt->mnt_count in sys_mq_open) CVE-2005-3358 (prevent panic caused by invalid arguments to set_mempolicy) CVE-2005-3784 (auto-reap DoS) CVE-2005-3806 (ipv6 flowlabel DOS) CVE-2005-3857 (lease printk DoS) CVE-2005-4605 (kernel memory disclosure via /proc exploit) --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) fc3: b9e37d94319ce74e98aa053d9da798437b979a5e fedora/3/updates-testing/i386/kernel-2.6.12-2.3.legacy_FC3.i586.rpm e8698e932795b5a8c9ecc97e95fab42f55d71ac9 fedora/3/updates-testing/i386/kernel-2.6.12-2.3.legacy_FC3.i686.rpm 58e7014a387ef6e17bf9f68d26eb1242a9dab3f2 fedora/3/updates-testing/i386/kernel-doc-2.6.12-2.3.legacy_FC3.noarch.rpm d09fb6f194558505d8d52fb22a60420cd35a06f1 fedora/3/updates-testing/i386/kernel-smp-2.6.12-2.3.legacy_FC3.i586.rpm 640077c447f1ac5edf5e21000c916bb750006f84 fedora/3/updates-testing/i386/kernel-smp-2.6.12-2.3.legacy_FC3.i686.rpm 3341ee0cc5e61d464a9982a5f96ec802d9121965 fedora/3/updates-testing/x86_64/kernel-2.6.12-2.3.legacy_FC3.x86_64.rpm 58e7014a387ef6e17bf9f68d26eb1242a9dab3f2 fedora/3/updates-testing/x86_64/kernel-doc-2.6.12-2.3.legacy_FC3.noarch.rpm ab4a29a3ec0bceda378319476b6ce46613805f90 fedora/3/updates-testing/x86_64/kernel-smp-2.6.12-2.3.legacy_FC3.x86_64.rpm 725204fe5e8fb35b54083be1a6757cc8be43cf9d fedora/3/updates-testing/SRPMS/kernel-2.6.12-2.3.legacy_FC3.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Tue Feb 21 00:58:41 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 20 Feb 2006 19:58:41 -0500 Subject: Fedora Legacy Test Update Notification: gpdf Message-ID: <43FA65C1.3060706@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-176751 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176751 2006-02-20 --------------------------------------------------------------------- Name : gpdf Versions : fc1: gpdf-0.110-1.5.legacy Versions : fc2: gpdf-2.8.2-4.1.1.legacy Versions : fc3: gpdf-2.8.2-7.2.1.legacy Summary : viewer for Portable Document Format (PDF) files for GNOME Description : This is GPdf, a viewer for Portable Document Format (PDF) files for GNOME. GPdf is based on the Xpdf program and uses additional GNOME libraries for better desktop integration. --------------------------------------------------------------------- Update Information: An updated gpdf package that fixes several security issues is now available. The gpdf package is a GNOME based viewer for Portable Document Format (PDF) files. A flaw was discovered in gpdf. An attacker could construct a carefully crafted PDF file that would cause gpdf to consume all available disk space in /tmp when opened. The Common Vulnerabilities and Exposures project assigned the name CVE-2005-2097 to this issue. Several flaws were discovered in gpdf. An attacker could construct a carefully crafted PDF file that could cause gpdf to crash or possibly execute arbitrary code when opened. The Common Vulnerabilities and Exposures project assigned the names CVE-2005-3191, CVE-2005-3192, CVE-2005-3193, CVE-2005-3624, CVE-2005-3625, CVE-2005-3626, CVE-2005-3627 and CVE-2005-3628 to these issues. Users of gpdf should upgrade to this updated package, which contains backported patches to resolve these issues. --------------------------------------------------------------------- Changelogs fc1: * Sat Feb 18 2006 Marc Deslauriers 0.110-1.5.legacy - Use better patch for CVE-2004-0888 (from RHEL3 xpdf) - Add patch for CVE-2005-3193 fc2: * Sat Feb 18 2006 Marc Deslauriers 2.8.2-4.1.1.legacy - Rebuilt as Fedora Legacy security update for Fedora Core 2 - Removed the desktop-file-utils dependencies * Fri Jan 06 2006 Ray Strode 2.8.2-7.4 - Apply fix for CVE-2005-3624 (also covers CVE-2005-3193) (bug 176865) * Wed Dec 14 2005 Ray Strode 2.8.2-7.3 - apply updated patch for CVE-2005-3193 (bug 175102) fc3: * Sat Feb 18 2006 Marc Deslauriers 2.8.2-7.2.1.legacy - Rebuilt as Fedora Legacy security update for Fedora Core 3 * Fri Jan 06 2006 Ray Strode 2.8.2-7.4 - Apply fix for CVE-2005-3624 (also covers CVE-2005-3193) (bug 176865) * Wed Dec 14 2005 Ray Strode 2.8.2-7.3 - apply updated patch for CVE-2005-3193 (bug 175102) --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) fc1: 646edd9bdaf07a2f74d0b9874a666f94dc4f7982 fedora/1/updates-testing/i386/gpdf-0.110-1.5.legacy.i386.rpm 23f1172453f4e6572bd5a5bebcf093fda9c9ef62 fedora/1/updates-testing/SRPMS/gpdf-0.110-1.5.legacy.src.rpm fc2: 2798a8e5ba37214b4ad3d537aa38b65c62c9e7c7 fedora/2/updates-testing/i386/gpdf-2.8.2-4.1.1.legacy.i386.rpm e6d36329145bd25d5646da0064124f4b3a3faf99 fedora/2/updates-testing/SRPMS/gpdf-2.8.2-4.1.1.legacy.src.rpm fc3: b732b32164a34ddca2471548cffdb4fa654a61cd fedora/3/updates-testing/i386/gpdf-2.8.2-7.2.1.legacy.i386.rpm 3ec3762affc6295144245af9e804692e293614be fedora/3/updates-testing/SRPMS/gpdf-2.8.2-7.2.1.legacy.src.rpm e6c957006f2bc7c17c5754df527cd8eec86d0c9a fedora/3/updates-testing/x86_64/gpdf-2.8.2-7.2.1.legacy.x86_64.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Tue Feb 21 00:59:07 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 20 Feb 2006 19:59:07 -0500 Subject: Fedora Legacy Test Update Notification: perl-DBI Message-ID: <43FA65DB.1090704@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-178989 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178989 2006-02-20 --------------------------------------------------------------------- Name : perl-DBI Versions : rh73: perl-DBI-1.21-1.1.legacy Versions : rh9: perl-DBI-1.32-5.1.legacy Versions : fc1: perl-DBI-1.37-1.1.legacy Versions : fc2: perl-DBI-1.40-4.1.legacy Summary : A database access API for Perl. Description : DBI is a database access Application Programming Interface (API) for the Perl programming language. The DBI API specification defines a set of functions, variables and conventions that provide a consistent database interface independent of the actual database being used. --------------------------------------------------------------------- Update Information: An updated perl-DBI package that fixes a temporary file flaw in DBI::ProxyServer is now available. DBI is a database access Application Programming Interface (API) for the Perl programming language. The Debian Security Audit Project discovered that the DBI library creates a temporary PID file in an insecure manner. A local user could overwrite or create files as a different user who happens to run an application which uses DBI::ProxyServer. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0077 to this issue. Users should update to this erratum package which disables the temporary PID file unless configured. --------------------------------------------------------------------- Changelogs rh73: * Sat Feb 18 2006 Marc Deslauriers 1.21-1.1.legacy - Added fix for CVE-2005-0077 rh9: * Sat Feb 18 2006 Marc Deslauriers 1.32-5.1.legacy - Added fix for CVE-2005-0077 fc1: * Sat Feb 18 2006 Marc Deslauriers 1.37-1.1.legacy - Added fix for CVE-2005-0077 fc2: * Sat Feb 18 2006 Marc Deslauriers 1.40-4.1.legacy - Added fix for CVE-2005-0077 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 847cb03e61abf1bbb965b2fa6e7c0f812e7edde1 redhat/7.3/updates-testing/i386/perl-DBI-1.21-1.1.legacy.i386.rpm 7c0c13670d8da3620d6bdc0d24f96201ff3feee8 redhat/7.3/updates-testing/SRPMS/perl-DBI-1.21-1.1.legacy.src.rpm rh9: 2e473b5822a019a10b7b9577f4de60933e75fecc redhat/9/updates-testing/i386/perl-DBI-1.32-5.1.legacy.i386.rpm 19934b803bf33b0cc93466ae43e2ac14302ac0df redhat/9/updates-testing/SRPMS/perl-DBI-1.32-5.1.legacy.src.rpm fc1: 50a02fd2d68f47d35f76bc690281253bbdf9a486 fedora/1/updates-testing/i386/perl-DBI-1.37-1.1.legacy.i386.rpm 0018ffba083fd98b88a4bcec3383005ed32d5e6a fedora/1/updates-testing/SRPMS/perl-DBI-1.37-1.1.legacy.src.rpm fc2: 69a623c7db409341705bfc125b5fd6f0c056af7b fedora/2/updates-testing/i386/perl-DBI-1.40-4.1.legacy.i386.rpm 4443111b0e9137bd1624183b9d209b2cada204dd fedora/2/updates-testing/SRPMS/perl-DBI-1.40-4.1.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From pekkas at netcore.fi Tue Feb 21 06:21:52 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 21 Feb 2006 08:21:52 +0200 (EET) Subject: Comments on first verification QA In-Reply-To: <20060220155801.xyiohlht8gpw84co@mail.ph.utexas.edu> References: <20060220155801.xyiohlht8gpw84co@mail.ph.utexas.edu> Message-ID: On Mon, 20 Feb 2006, Eric Rostetter wrote: > Quoting Tres Seaver : >> I am therefore very much inclined to back the idea that Legacy offer >> "minimal" images as starting points for would-be QA volunteers, along >> with directions on how to set up either VMWare's Server or Player >> products to use them. We might need to give people clues about using >> the "snapshot" facilities provided by the tools to ease the process, as >> well. > > Yes, I agree. I would love to see this done. I would then be able > to use VM to test things also, which would be great. I guess this won't get done, unless someone gets this done. Anyone willing to do the work? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From jkeating at j2solutions.net Tue Feb 21 06:53:05 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 20 Feb 2006 22:53:05 -0800 Subject: Comments on first verification QA In-Reply-To: References: <20060220155801.xyiohlht8gpw84co@mail.ph.utexas.edu> Message-ID: <1140504785.17286.75.camel@ender> On Tue, 2006-02-21 at 08:21 +0200, Pekka Savola wrote: > I guess this won't get done, unless someone gets this done. Anyone > willing to do the work? I'm going to inquire with VMWare to see if they will donate a license to the project so that I can create some base images. Consider this on my plate for now. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From dom at earth.li Tue Feb 21 09:40:47 2006 From: dom at earth.li (Dominic Hargreaves) Date: Tue, 21 Feb 2006 09:40:47 +0000 Subject: Comments on first verification QA In-Reply-To: <1140504785.17286.75.camel@ender> References: <20060220155801.xyiohlht8gpw84co@mail.ph.utexas.edu> <1140504785.17286.75.camel@ender> Message-ID: <20060221094047.GB11691@urchin.earth.li> On Mon, Feb 20, 2006 at 10:53:05PM -0800, Jesse Keating wrote: > On Tue, 2006-02-21 at 08:21 +0200, Pekka Savola wrote: > > I guess this won't get done, unless someone gets this done. Anyone > > willing to do the work? > > I'm going to inquire with VMWare to see if they will donate a license to > the project so that I can create some base images. Consider this on my > plate for now. I believe you can use the qemu utilities to create vmware-compatible images without having a vmware licence. I couldn't say whether this was breaking the terms of the player licence, though. Cheers, Dominic. -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email) From mattdm at mattdm.org Tue Feb 21 19:44:11 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 21 Feb 2006 14:44:11 -0500 Subject: Security-release httpd for FC3 In-Reply-To: <1140295088.7128.8.camel@mdlinux> References: <43F777BD.8090508@neufeind.net> <1140295088.7128.8.camel@mdlinux> Message-ID: <20060221194411.GA22772@jadzia.bu.edu> On Sat, Feb 18, 2006 at 03:38:07PM -0500, Marc Deslauriers wrote: > > http://download.fedoralegacy.org/fedora/3/updates/i386/httpd-2.0.53-3.4.legacy.i386.rpm > It takes a while for the mirrors to sync. It should be there now. The x86_64 packages still aren't there as far as I can see.... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at j2solutions.net Tue Feb 21 19:59:01 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 21 Feb 2006 11:59:01 -0800 Subject: Security-release httpd for FC3 In-Reply-To: <20060221194411.GA22772@jadzia.bu.edu> References: <43F777BD.8090508@neufeind.net> <1140295088.7128.8.camel@mdlinux> <20060221194411.GA22772@jadzia.bu.edu> Message-ID: <1140551942.17286.110.camel@ender> On Tue, 2006-02-21 at 14:44 -0500, Matthew Miller wrote: > On Sat, Feb 18, 2006 at 03:38:07PM -0500, Marc Deslauriers wrote: > > > http://download.fedoralegacy.org/fedora/3/updates/i386/httpd-2.0.53-3.4.legacy.i386.rpm > > It takes a while for the mirrors to sync. It should be there now. > > The x86_64 packages still aren't there as far as I can see.... Arg. Our upload script wasn't modified to handle x86_64 updates. I'm fixing that now. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From jkeating at j2solutions.net Tue Feb 21 20:19:55 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 21 Feb 2006 12:19:55 -0800 Subject: Security-release httpd for FC3 In-Reply-To: <1140551942.17286.110.camel@ender> References: <43F777BD.8090508@neufeind.net> <1140295088.7128.8.camel@mdlinux> <20060221194411.GA22772@jadzia.bu.edu> <1140551942.17286.110.camel@ender> Message-ID: <1140553195.17286.112.camel@ender> On Tue, 2006-02-21 at 11:59 -0800, Jesse Keating wrote: > Arg. Our upload script wasn't modified to handle x86_64 updates. I'm > fixing that now. And check now? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From rostetter at mail.utexas.edu Tue Feb 21 20:21:19 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 21 Feb 2006 14:21:19 -0600 Subject: FC3 yum instructions Message-ID: <20060221142119.jpl2sxuize0o8o8s@mail.ph.utexas.edu> I've added the following to the web site: http://www.fedoralegacy.org/docs/yum-fc3.php and would appreciate testing, feedback, etc. Thanks! -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From jkeating at j2solutions.net Tue Feb 21 20:36:28 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 21 Feb 2006 12:36:28 -0800 Subject: FC3 yum instructions In-Reply-To: <20060221142119.jpl2sxuize0o8o8s@mail.ph.utexas.edu> References: <20060221142119.jpl2sxuize0o8o8s@mail.ph.utexas.edu> Message-ID: <1140554189.17286.115.camel@ender> On Tue, 2006-02-21 at 14:21 -0600, Eric Rostetter wrote: > > I've added the following to the web site: > > http://www.fedoralegacy.org/docs/yum-fc3.php > > and would appreciate testing, feedback, etc. Thanks! Looks pretty good. I'm not entirely sure that you can get an FC3 installation w/out yum, but good to have that there anyway. We need to get this echoed to the wiki much like http://fedoraproject.org/wiki/Legacy/YumFC2Detailed Just make a new page named YumFC3Detailed and then link to it from the main http://fedoraproject.org/wiki/Legacy page. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From rostetter at mail.utexas.edu Tue Feb 21 20:50:02 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 21 Feb 2006 14:50:02 -0600 Subject: FC3 yum instructions In-Reply-To: <1140554189.17286.115.camel@ender> References: <20060221142119.jpl2sxuize0o8o8s@mail.ph.utexas.edu> <1140554189.17286.115.camel@ender> Message-ID: <20060221145002.g0u662hkipswos4c@mail.ph.utexas.edu> Quoting Jesse Keating : > We need to get this echoed to the wiki much like > http://fedoraproject.org/wiki/Legacy/YumFC2Detailed Why do we have it in two places? That just leads to confusions and things being out of sync. > Just make a new page named YumFC3Detailed and then link to it from the > main http://fedoraproject.org/wiki/Legacy page. Why? To me it seems we should have either one or the other, not both. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From jkeating at j2solutions.net Tue Feb 21 21:02:44 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 21 Feb 2006 13:02:44 -0800 Subject: FC3 yum instructions In-Reply-To: <20060221145002.g0u662hkipswos4c@mail.ph.utexas.edu> References: <20060221142119.jpl2sxuize0o8o8s@mail.ph.utexas.edu> <1140554189.17286.115.camel@ender> <20060221145002.g0u662hkipswos4c@mail.ph.utexas.edu> Message-ID: <1140555764.17286.118.camel@ender> On Tue, 2006-02-21 at 14:50 -0600, Eric Rostetter wrote: > > Why do we have it in two places? That just leads to confusions and > things being out of sync. > > > Just make a new page named YumFC3Detailed and then link to it from the > > main http://fedoraproject.org/wiki/Legacy page. > > Why? To me it seems we should have either one or the other, not both. Honestly because I'd like to start moving all documentation into the wiki. This is where the rest of the Fedora projects have their documentation. The need for our own webspace may go away in the future. Especially as we move toward using the same build software that Fedora Extras uses, we can use a lot of their documentation for our needs. Having all these things in the same space (the wiki) makes sense moving forward. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Tue Feb 21 21:10:12 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 22 Feb 2006 02:40:12 +0530 Subject: FC3 yum instructions In-Reply-To: <1140555764.17286.118.camel@ender> References: <20060221142119.jpl2sxuize0o8o8s@mail.ph.utexas.edu> <1140554189.17286.115.camel@ender> <20060221145002.g0u662hkipswos4c@mail.ph.utexas.edu> <1140555764.17286.118.camel@ender> Message-ID: <43FB81B4.6070808@fedoraproject.org> Jesse Keating wrote: >On Tue, 2006-02-21 at 14:50 -0600, Eric Rostetter wrote: > > >>Why do we have it in two places? That just leads to confusions and >>things being out of sync. >> >> >> >>>Just make a new page named YumFC3Detailed and then link to it from the >>>main http://fedoraproject.org/wiki/Legacy page. >>> >>> >>Why? To me it seems we should have either one or the other, not both. >> >> > >Honestly because I'd like to start moving all documentation into the >wiki. This is where the rest of the Fedora projects have their >documentation. The need for our own webspace may go away in the future. > For those who hate the wiki with a passion, we will have a CMS system soon in fedoraproject.org. Plone+Zope and a few other custom utilities and scripts. -- Rahul From rostetter at mail.utexas.edu Wed Feb 22 03:49:55 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 21 Feb 2006 21:49:55 -0600 Subject: FC3 yum instructions In-Reply-To: <1140555764.17286.118.camel@ender> References: <20060221142119.jpl2sxuize0o8o8s@mail.ph.utexas.edu> <1140554189.17286.115.camel@ender> <20060221145002.g0u662hkipswos4c@mail.ph.utexas.edu> <1140555764.17286.118.camel@ender> Message-ID: <20060221214955.rus1d0357csg8oco@mail.ph.utexas.edu> Quoting Jesse Keating : > On Tue, 2006-02-21 at 14:50 -0600, Eric Rostetter wrote: >> >> Why do we have it in two places? That just leads to confusions and >> things being out of sync. >> >> > Just make a new page named YumFC3Detailed and then link to it from the >> > main http://fedoraproject.org/wiki/Legacy page. >> >> Why? To me it seems we should have either one or the other, not both. > > Honestly because I'd like to start moving all documentation into the > wiki. Okay. I'm against this personally, but I know you want to do it. > This is where the rest of the Fedora projects have their > documentation. The need for our own webspace may go away in the future. Fedora itself does not do it this way. I'd rather we didn't either. I do recognize that the other Fedora Community Projects do, but I don't consider us to be the same level as most of them. I suppose you could compare us with the Fedora Documentation Project at best, not the Extras Project. And they do maintain web pages as well as wiki pages. In fact, they only caved and went to wiki pages due to user input for various things to be in wiki (instead of requiring knowledge of XML, etc). I don't we have the same problem, and we've had wiki since (more or less) the start unlike the Documentation Project, so... > Especially as we move toward using the same build software that Fedora > Extras uses, we can use a lot of their documentation for our needs. Yes. But why not point to their content from our web page? No need to be a wiki to share content... > Having all these things in the same space (the wiki) makes sense moving > forward. I don't see it, but I won't stop you from doing that. My point is, if we want these things in the wiki, then we shouldn't have them in the web also. We should remove them from the web, and only have them in the wiki, and not duplicate them in both. I'll let the rest of the list comment, if they want. I've already told Jesse privately how I feel about the issue. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From jkeating at j2solutions.net Wed Feb 22 06:47:28 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 21 Feb 2006 22:47:28 -0800 Subject: FC3 yum instructions In-Reply-To: <20060221214955.rus1d0357csg8oco@mail.ph.utexas.edu> References: <20060221142119.jpl2sxuize0o8o8s@mail.ph.utexas.edu> <1140554189.17286.115.camel@ender> <20060221145002.g0u662hkipswos4c@mail.ph.utexas.edu> <1140555764.17286.118.camel@ender> <20060221214955.rus1d0357csg8oco@mail.ph.utexas.edu> Message-ID: <1140590848.17286.157.camel@ender> On Tue, 2006-02-21 at 21:49 -0600, Eric Rostetter wrote: > Fedora itself does not do it this way. I'd rather we didn't either. > I do recognize that the other Fedora Community Projects do, but I don't > consider us to be the same level as most of them. We're considering doing away with the fedora.redhat.com website. 1) It ties Fedora uneccessarily to Red Hat, 2) it takes a lot of effort to change something there. With the new content management stuff going online for fedoraproject.org we may see fedora.redhat.com become just a link to this. Still being discussed AFAIK. > I suppose you could compare us with the Fedora Documentation Project > at best, not the Extras Project. And they do maintain web pages as > well as wiki pages. In fact, they only caved and went to wiki pages > due to user input for various things to be in wiki (instead of requiring > knowledge of XML, etc). I don't we have the same problem, and we've had > wiki since (more or less) the start unlike the Documentation Project, > so... I'm working on getting us to the level that Extras is. We now are a true subproject, I chair the project to the Fedora Foundation / board, same way that Extras is. We're getting closer to using Fedora CVS for our sources, and using a build system like Fedora Extras. What else keeps us from being of the same level? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From pekkas at netcore.fi Wed Feb 22 10:00:59 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 22 Feb 2006 12:00:59 +0200 (EET) Subject: FC3 yum instructions In-Reply-To: <1140590848.17286.157.camel@ender> References: <20060221142119.jpl2sxuize0o8o8s@mail.ph.utexas.edu> <1140554189.17286.115.camel@ender> <20060221145002.g0u662hkipswos4c@mail.ph.utexas.edu> <1140555764.17286.118.camel@ender> <20060221214955.rus1d0357csg8oco@mail.ph.utexas.edu> <1140590848.17286.157.camel@ender> Message-ID: On Tue, 21 Feb 2006, Jesse Keating wrote: >> at best, not the Extras Project. And they do maintain web pages as >> well as wiki pages. In fact, they only caved and went to wiki pages >> due to user input for various things to be in wiki (instead of requiring >> knowledge of XML, etc). I don't we have the same problem, and we've had >> wiki since (more or less) the start unlike the Documentation Project, >> so... > > I'm working on getting us to the level that Extras is. We now are a > true subproject, I chair the project to the Fedora Foundation / board, > same way that Extras is. We're getting closer to using Fedora CVS for > our sources, and using a build system like Fedora Extras. What else > keeps us from being of the same level? I'm all for getting FL closer to common Fedora infrastructure, especially as the focus on Fedora Core support is increasing. Hence, Fedora CVS, buildsystem, etc. is the direction we should go. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From Klaus.Steinberger at physik.uni-muenchen.de Wed Feb 22 12:07:39 2006 From: Klaus.Steinberger at physik.uni-muenchen.de (Klaus Steinberger) Date: Wed, 22 Feb 2006 13:07:39 +0100 Subject: x86_64 Packages missing Message-ID: <200602221307.39850.Klaus.Steinberger@physik.uni-muenchen.de> Hello, in the last Advisories (e.g. [FLSA-2006:175406]) also x86_64 Packages were mentioned, but they are missing from the updates Repository, they are just in updates-testing. Were they missed or is that intentional? the x86_64 Support is essential for me. Sincerly, Klaus Steinberger -- Klaus Steinberger Maier-Leibnitz Labor Phone: (+49 89)289 14287 Am Coulombwall 6, D-85748 Garching, Germany FAX: (+49 89)289 14280 EMail: Klaus.Steinberger at Physik.Uni-Muenchen.DE URL: http://www.physik.uni-muenchen.de/~k2/ In a world without Walls and Fences, who needs Windows and Gates From marcdeslauriers at videotron.ca Wed Feb 22 13:12:33 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 22 Feb 2006 08:12:33 -0500 Subject: x86_64 Packages missing In-Reply-To: <200602221307.39850.Klaus.Steinberger@physik.uni-muenchen.de> References: <200602221307.39850.Klaus.Steinberger@physik.uni-muenchen.de> Message-ID: <1140613953.29279.14.camel@mdlinux> On Wed, 2006-02-22 at 13:07 +0100, Klaus Steinberger wrote: > Hello, > > in the last Advisories (e.g. [FLSA-2006:175406]) also x86_64 Packages were > mentioned, but they are missing from the updates Repository, they are just in > updates-testing. > > Were they missed or is that intentional? the x86_64 Support is essential for > me. Sorry about that. I forgot to move the x86_64 packages from updates-testing to updates. The mirrors are being synced now, they should appear shortly. Marc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From henryhartley at westat.com Wed Feb 22 14:57:42 2006 From: henryhartley at westat.com (Henry Hartley) Date: Wed, 22 Feb 2006 09:57:42 -0500 Subject: Fedora Legacy Test Update Notification: kernel (fc3) Message-ID: <403593359CA56C4CAE1F8F4F00DCFE7D0320D771@MAILBE2.westat.com> On Mon, Feb 20, 2006 7:58 PM Marc Deslauriers said: >> >> Name : kernel >> Versions : fc3: kernel-2.6.12-2.3.legacy_FC3 >> Summary : The Linux kernel (the core of the Linux operating system). Please pardon my ignorance. Uname says I'm running 2.6.12-1.1372_FC3, which seems quite a bit older than this announced kernel. Yum appears to have have installed four newer kernels but I haven't rebooted in over six months so they aren't being used. In any case, I thought I should update to this one and reboot. But when I run yum update kernel it tells me I have nothing to update. My yum repo files seem to be correct, as I've gotten openssh, httpd, and mod_ssl updates recently. Am I missing something? -- Henry From nils at lemonbit.nl Wed Feb 22 15:16:55 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Wed, 22 Feb 2006 16:16:55 +0100 Subject: Fedora Legacy Test Update Notification: kernel (fc3) In-Reply-To: <403593359CA56C4CAE1F8F4F00DCFE7D0320D771@MAILBE2.westat.com> References: <403593359CA56C4CAE1F8F4F00DCFE7D0320D771@MAILBE2.westat.com> Message-ID: <08E066BF-3FD0-47AE-B99F-C93DD86FF98C@lemonbit.nl> Henry Hartley wrote: > On Mon, Feb 20, 2006 7:58 PM Marc Deslauriers said: >>> >>> Name : kernel >>> Versions : fc3: kernel-2.6.12-2.3.legacy_FC3 >>> Summary : The Linux kernel (the core of the Linux operating > system). > > Please pardon my ignorance. > > Uname says I'm running 2.6.12-1.1372_FC3, which seems quite a bit > older > than this announced kernel. Yum appears to have have installed four > newer kernels but I haven't rebooted in over six months so they aren't > being used. In any case, I thought I should update to this one and > reboot. But when I run yum update kernel it tells me I have > nothing to > update. > > My yum repo files seem to be correct, as I've gotten openssh, > httpd, and > mod_ssl updates recently. > > Am I missing something? The kernel update just hit updates-testing, but hasn't been released yet into the updates channel. I think you may have yum configured to only use the updates channel, not updates-testing? Nils From henryhartley at westat.com Wed Feb 22 16:15:48 2006 From: henryhartley at westat.com (Henry Hartley) Date: Wed, 22 Feb 2006 11:15:48 -0500 Subject: Fedora Legacy Test Update Notification: kernel (fc3) Message-ID: <403593359CA56C4CAE1F8F4F00DCFE7D0320D772@MAILBE2.westat.com> On Wed, Feb 22, 2006 10:17 AM Nils Breunese said: >> >> Henry Hartley wrote: >> > Uname says I'm running 2.6.12-1.1372_FC3, which seems quite a bit >> > older than this announced kernel. Yum appears to have have >> > installed four newer kernels but I haven't rebooted in over six >> > months so they aren't being used. In any case, I thought I >> > should update to this one and reboot. But when I run yum update >> > kernel it tells me I have nothing to update. >> > >> > My yum repo files seem to be correct, as I've gotten openssh, >> > httpd, and mod_ssl updates recently. >> >> The kernel update just hit updates-testing, but hasn't been >> released yet into the updates channel. I think you may have yum >> configured to only use the updates channel, not updates-testing? Yes, that seems to be the problem. I have base, updates, and utils but not testing. Is it recommended that I have testing or am I safer with what I have? -- Henry From rostetter at mail.utexas.edu Wed Feb 22 16:21:00 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 22 Feb 2006 10:21:00 -0600 Subject: FC3 yum instructions In-Reply-To: <1140590848.17286.157.camel@ender> References: <20060221142119.jpl2sxuize0o8o8s@mail.ph.utexas.edu> <1140554189.17286.115.camel@ender> <20060221145002.g0u662hkipswos4c@mail.ph.utexas.edu> <1140555764.17286.118.camel@ender> <20060221214955.rus1d0357csg8oco@mail.ph.utexas.edu> <1140590848.17286.157.camel@ender> Message-ID: <20060222102100.ucqeeyc1ctko44ck@mail.ph.utexas.edu> Quoting Jesse Keating : > On Tue, 2006-02-21 at 21:49 -0600, Eric Rostetter wrote: >> Fedora itself does not do it this way. I'd rather we didn't either. >> I do recognize that the other Fedora Community Projects do, but I don't >> consider us to be the same level as most of them. > > We're considering doing away with the fedora.redhat.com website. 1) It > ties Fedora uneccessarily to Red Hat, 2) it takes a lot of effort to > change something there. This has not that much to do with web vs wiki. It is really just a management or hosting issue. You can change the DNS and #1 goes away. You can change how things are updated and #2 goes away. Neither in anyway means one should use wiki over traditional web. > With the new content management stuff going > online for fedoraproject.org we may see fedora.redhat.com become just a > link to this. Still being discussed AFAIK. If the goal is to move all projects fully to the fedoralegacy.org wiki, then fine. But no one has told me yet that such a goal exists. > I'm working on getting us to the level that Extras is. I'm not really familiar with Extras, so that doesn't help me much. My impression from others talking about it is that they are not at a very high level, but that impression could be totally incorrect as it is based on second hand reports only. > We now are a > true subproject, I chair the project to the Fedora Foundation / board, > same way that Extras is. We're getting closer to using Fedora CVS for > our sources, and using a build system like Fedora Extras. What else > keeps us from being of the same level? That all sounds good. But that really isn't what I meant when I was talking about levels. Personally I don't find the wiki to inspire professionalism or confidence in the projects, and if you are expecting to draw users to _use_ your packages you want to project professionalism and give a sense of confidence. Now, maybe if you want to draw people into _contribute_ a wiki might help by making it a bit easier for (mostly minor) contributions. But it also makes it harder to maintain the integrity of the site. There are trade offs both ways... I guess the question is what is the goal here. Is it: 1) To consolidate all the projects in one place? 2) To make it easier to use/contribute/maintain? 3) To attract new people to the project? 4) To change for the sake of change? 5) Some other reason or reasons? -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From fedora-legacy at neufeind.net Wed Feb 22 16:24:47 2006 From: fedora-legacy at neufeind.net (Stefan Neufeind) Date: Wed, 22 Feb 2006 17:24:47 +0100 Subject: Fedora Legacy Test Update Notification: kernel (fc3) In-Reply-To: <403593359CA56C4CAE1F8F4F00DCFE7D0320D772@MAILBE2.westat.com> References: <403593359CA56C4CAE1F8F4F00DCFE7D0320D772@MAILBE2.westat.com> Message-ID: <43FC904F.6060506@neufeind.net> Henry Hartley wrote: > On Wed, Feb 22, 2006 10:17 AM Nils Breunese said: >>> Henry Hartley wrote: >>>> Uname says I'm running 2.6.12-1.1372_FC3, which seems quite a bit >>>> older than this announced kernel. Yum appears to have have >>>> installed four newer kernels but I haven't rebooted in over six >>>> months so they aren't being used. In any case, I thought I >>>> should update to this one and reboot. But when I run yum update >>>> kernel it tells me I have nothing to update. >>>> >>>> My yum repo files seem to be correct, as I've gotten openssh, >>>> httpd, and mod_ssl updates recently. >>> The kernel update just hit updates-testing, but hasn't been >>> released yet into the updates channel. I think you may have yum >>> configured to only use the updates channel, not updates-testing? > > Yes, that seems to be the problem. I have base, updates, and utils but > not testing. Is it recommended that I have testing or am I safer with > what I have? Sure you are "saver" off with not using testing. However, if you have the chance, using testing and reporting back any potential problems that might occur is highly appreciated. So to say, if you don't have the machine in a critical production environment, you might possible consider trying the testing-updates. Also confirmations ("works") for testing-updates are recommended. However, note that reporting "works" can only be true for software you actually use ... not just "installs fine" :-) Regards, Stefan From nils at lemonbit.nl Wed Feb 22 16:26:48 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Wed, 22 Feb 2006 17:26:48 +0100 Subject: Fedora Legacy Test Update Notification: kernel (fc3) In-Reply-To: <403593359CA56C4CAE1F8F4F00DCFE7D0320D772@MAILBE2.westat.com> References: <403593359CA56C4CAE1F8F4F00DCFE7D0320D772@MAILBE2.westat.com> Message-ID: Henry Hartley wrote: > On Wed, Feb 22, 2006 10:17 AM Nils Breunese said: >>> >>> Henry Hartley wrote: >>>> Uname says I'm running 2.6.12-1.1372_FC3, which seems quite a bit >>>> older than this announced kernel. Yum appears to have have >>>> installed four newer kernels but I haven't rebooted in over six >>>> months so they aren't being used. In any case, I thought I >>>> should update to this one and reboot. But when I run yum update >>>> kernel it tells me I have nothing to update. >>>> >>>> My yum repo files seem to be correct, as I've gotten openssh, >>>> httpd, and mod_ssl updates recently. >>> >>> The kernel update just hit updates-testing, but hasn't been >>> released yet into the updates channel. I think you may have yum >>> configured to only use the updates channel, not updates-testing? > > Yes, that seems to be the problem. I have base, updates, and utils > but > not testing. Is it recommended that I have testing or am I safer with > what I have? I don't think there is a problem reallu. If you're prepared to do QA on a test machine (see http://www.fedoraproject.org/wiki/Legacy/ QATesting) you will need to enable the testing repository. Enabling the updates-testing channel on a production system is not recommended. Nils Breunese. From rostetter at mail.utexas.edu Wed Feb 22 16:50:16 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 22 Feb 2006 10:50:16 -0600 Subject: FC3 yum instructions In-Reply-To: References: <20060221142119.jpl2sxuize0o8o8s@mail.ph.utexas.edu> <1140554189.17286.115.camel@ender> <20060221145002.g0u662hkipswos4c@mail.ph.utexas.edu> <1140555764.17286.118.camel@ender> <20060221214955.rus1d0357csg8oco@mail.ph.utexas.edu> <1140590848.17286.157.camel@ender> Message-ID: <20060222105016.ja1cw9c7tvcwo0c4@mail.ph.utexas.edu> Quoting Pekka Savola : > I'm all for getting FL closer to common Fedora infrastructure, > especially as the focus on Fedora Core support is increasing. Hence, > Fedora CVS, buildsystem, etc. is the direction we should go. But what about web vs. wiki? Should we move to Fedora wiki, or stay as a more traditional web site, or some of each? Fedora Extras is at one end, Fedora Documentation Project is in the middle, we were at one end but are moving towards the other, etc. Where should the FL web be moving; towards wiki or towards web or towards a split between them? > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From michal at harddata.com Wed Feb 22 16:57:29 2006 From: michal at harddata.com (Michal Jaegermann) Date: Wed, 22 Feb 2006 09:57:29 -0700 Subject: Fedora Legacy Test Update Notification: gpdf In-Reply-To: <43FA65C1.3060706@videotron.ca> References: <43FA65C1.3060706@videotron.ca> Message-ID: <20060222165729.GA19837@mail.harddata.com> On Mon, Feb 20, 2006 at 07:58:41PM -0500, Marc Deslauriers wrote: > --------------------------------------------------------------------- > Fedora Legacy Test Update Notification > FEDORALEGACY-2006-176751 .... > fedora/3/updates-testing/i386/gpdf-2.8.2-7.2.1.legacy.i386.rpm At least this package is unsigned so yum, in a default configuration from legacy-yumconf-3-4.fc3 plus enabled 'legacy-testing', will not install that. sha1sum agrees with what was posted, though. Michal From jkeating at j2solutions.net Wed Feb 22 18:24:05 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 22 Feb 2006 10:24:05 -0800 Subject: FC3 yum instructions In-Reply-To: <20060222102100.ucqeeyc1ctko44ck@mail.ph.utexas.edu> References: <20060221142119.jpl2sxuize0o8o8s@mail.ph.utexas.edu> <1140554189.17286.115.camel@ender> <20060221145002.g0u662hkipswos4c@mail.ph.utexas.edu> <1140555764.17286.118.camel@ender> <20060221214955.rus1d0357csg8oco@mail.ph.utexas.edu> <1140590848.17286.157.camel@ender> <20060222102100.ucqeeyc1ctko44ck@mail.ph.utexas.edu> Message-ID: <1140632646.4578.13.camel@ender> On Wed, 2006-02-22 at 10:21 -0600, Eric Rostetter wrote: > > 1) To consolidate all the projects in one place? Yes, > 2) To make it easier to use/contribute/maintain? Yes. > 3) To attract new people to the project? Yes, like current Extras folks or others looking for ways to help out on Fedora through the fedoraproject pages. > 4) To change for the sake of change? No. > 5) Some other reason or reasons? To further make our selves seem as a project of the same level as the Extras or Documentation project, by existing in the same spaces that they do. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From rostetter at mail.utexas.edu Wed Feb 22 18:52:48 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 22 Feb 2006 12:52:48 -0600 Subject: FC3 yum instructions In-Reply-To: <1140632646.4578.13.camel@ender> References: <20060221142119.jpl2sxuize0o8o8s@mail.ph.utexas.edu> <1140554189.17286.115.camel@ender> <20060221145002.g0u662hkipswos4c@mail.ph.utexas.edu> <1140555764.17286.118.camel@ender> <20060221214955.rus1d0357csg8oco@mail.ph.utexas.edu> <1140590848.17286.157.camel@ender> <20060222102100.ucqeeyc1ctko44ck@mail.ph.utexas.edu> <1140632646.4578.13.camel@ender> Message-ID: <20060222125248.pzecjgur76w4c48k@mail.ph.utexas.edu> Quoting Jesse Keating : > On Wed, 2006-02-22 at 10:21 -0600, Eric Rostetter wrote: >> >> 1) To consolidate all the projects in one place? > > Yes, Okay, then I guess we should scrape the web site asap and just use the wiki instead for everything. >> 5) Some other reason or reasons? > > To further make our selves seem as a project of the same level as the > Extras or Documentation project, by existing in the same spaces that > they do. I personally think we are lowering ourselves to their level, but so be it. Not my call. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From skvidal at linux.duke.edu Wed Feb 22 18:58:29 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 22 Feb 2006 13:58:29 -0500 Subject: FC3 yum instructions In-Reply-To: <20060222125248.pzecjgur76w4c48k@mail.ph.utexas.edu> References: <20060221142119.jpl2sxuize0o8o8s@mail.ph.utexas.edu> <1140554189.17286.115.camel@ender> <20060221145002.g0u662hkipswos4c@mail.ph.utexas.edu> <1140555764.17286.118.camel@ender> <20060221214955.rus1d0357csg8oco@mail.ph.utexas.edu> <1140590848.17286.157.camel@ender> <20060222102100.ucqeeyc1ctko44ck@mail.ph.utexas.edu> <1140632646.4578.13.camel@ender> <20060222125248.pzecjgur76w4c48k@mail.ph.utexas.edu> Message-ID: <1140634709.3959.35.camel@cutter> > >> 5) Some other reason or reasons? > > > > To further make our selves seem as a project of the same level as the > > Extras or Documentation project, by existing in the same spaces that > > they do. > > I personally think we are lowering ourselves to their level, but so be it. > Not my call. 'lowering ourselves' You might need a reality check if you think that legacy is 'lowering itself' to the level of extras. -sv From jkeating at j2solutions.net Wed Feb 22 19:00:52 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 22 Feb 2006 11:00:52 -0800 Subject: FC3 yum instructions In-Reply-To: <1140634709.3959.35.camel@cutter> References: <20060221142119.jpl2sxuize0o8o8s@mail.ph.utexas.edu> <1140554189.17286.115.camel@ender> <20060221145002.g0u662hkipswos4c@mail.ph.utexas.edu> <1140555764.17286.118.camel@ender> <20060221214955.rus1d0357csg8oco@mail.ph.utexas.edu> <1140590848.17286.157.camel@ender> <20060222102100.ucqeeyc1ctko44ck@mail.ph.utexas.edu> <1140632646.4578.13.camel@ender> <20060222125248.pzecjgur76w4c48k@mail.ph.utexas.edu> <1140634709.3959.35.camel@cutter> Message-ID: <1140634852.4578.30.camel@ender> On Wed, 2006-02-22 at 13:58 -0500, seth vidal wrote: > > > > I personally think we are lowering ourselves to their level, but so be it. > > Not my call. > > 'lowering ourselves' > > You might need a reality check if you think that legacy is 'lowering > itself' to the level of extras. > I agree. Extras has far surpassed us in quantity, quality, participation by the community, integration within Fedora itself, community exposure, etc, etc, etc.... We are very much trying to play catchup. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From rostetter at mail.utexas.edu Wed Feb 22 19:20:39 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 22 Feb 2006 13:20:39 -0600 Subject: FC3 yum instructions In-Reply-To: <1140634709.3959.35.camel@cutter> References: <20060221142119.jpl2sxuize0o8o8s@mail.ph.utexas.edu> <1140554189.17286.115.camel@ender> <20060221145002.g0u662hkipswos4c@mail.ph.utexas.edu> <1140555764.17286.118.camel@ender> <20060221214955.rus1d0357csg8oco@mail.ph.utexas.edu> <1140590848.17286.157.camel@ender> <20060222102100.ucqeeyc1ctko44ck@mail.ph.utexas.edu> <1140632646.4578.13.camel@ender> <20060222125248.pzecjgur76w4c48k@mail.ph.utexas.edu> <1140634709.3959.35.camel@cutter> Message-ID: <20060222132039.6qaxgalawdmkg8so@mail.ph.utexas.edu> Quoting seth vidal : >> >> 5) Some other reason or reasons? >> > >> > To further make our selves seem as a project of the same level as the >> > Extras or Documentation project, by existing in the same spaces that >> > they do. >> >> I personally think we are lowering ourselves to their level, but so be it. >> Not my call. > > 'lowering ourselves' > > You might need a reality check if you think that legacy is 'lowering > itself' to the level of extras. > > -sv Only in the sense of web site presence and presentation, not in the sense of community involvement, output/productivity, or many other areas where it clearly outshines FL. But then, our web presence has never been good anyway, since no one will participate in the process. I proposed an updated overview years ago, and have received basically no feedback of any sort, and no go-ahead to implement it, and any attempt to get it approved has failed. So if this "community" can't even be bothered to look at and approve or reject a document that is supposed to describe its existance and purpose, I guess it isn't much of a project. Maybe the nay-sayers are right. Maybe the project is crap, and we're all just wasting our time on it. Certainly is the least satisfying project I've ever been involved with. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From rostetter at mail.utexas.edu Wed Feb 22 19:22:03 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 22 Feb 2006 13:22:03 -0600 Subject: FC3 yum instructions In-Reply-To: <1140634852.4578.30.camel@ender> References: <20060221142119.jpl2sxuize0o8o8s@mail.ph.utexas.edu> <1140554189.17286.115.camel@ender> <20060221145002.g0u662hkipswos4c@mail.ph.utexas.edu> <1140555764.17286.118.camel@ender> <20060221214955.rus1d0357csg8oco@mail.ph.utexas.edu> <1140590848.17286.157.camel@ender> <20060222102100.ucqeeyc1ctko44ck@mail.ph.utexas.edu> <1140632646.4578.13.camel@ender> <20060222125248.pzecjgur76w4c48k@mail.ph.utexas.edu> <1140634709.3959.35.camel@cutter> <1140634852.4578.30.camel@ender> Message-ID: <20060222132203.47uc3lzzfxckc0oc@mail.ph.utexas.edu> Quoting Jesse Keating : > I agree. Extras has far surpassed us in quantity, quality, > participation by the community, integration within Fedora itself, > community exposure, etc, etc, etc.... We are very much trying to play > catchup. Yes, but I was talking only in web presence... -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From jkeating at j2solutions.net Wed Feb 22 19:27:45 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 22 Feb 2006 11:27:45 -0800 Subject: FC3 yum instructions In-Reply-To: <20060222132039.6qaxgalawdmkg8so@mail.ph.utexas.edu> References: <20060221142119.jpl2sxuize0o8o8s@mail.ph.utexas.edu> <1140554189.17286.115.camel@ender> <20060221145002.g0u662hkipswos4c@mail.ph.utexas.edu> <1140555764.17286.118.camel@ender> <20060221214955.rus1d0357csg8oco@mail.ph.utexas.edu> <1140590848.17286.157.camel@ender> <20060222102100.ucqeeyc1ctko44ck@mail.ph.utexas.edu> <1140632646.4578.13.camel@ender> <20060222125248.pzecjgur76w4c48k@mail.ph.utexas.edu> <1140634709.3959.35.camel@cutter> <20060222132039.6qaxgalawdmkg8so@mail.ph.utexas.edu> Message-ID: <1140636466.4578.34.camel@ender> On Wed, 2006-02-22 at 13:20 -0600, Eric Rostetter wrote: > > But then, our web presence has never been good anyway, since no one will > participate in the process. I proposed an updated overview years ago, and > have received basically no feedback of any sort, and no go-ahead to implement > it, and any attempt to get it approved has failed. Probably because webwork isn't fun, and nobody feels like they have the 'authority' to approve or disapprove updates. I'm sorry I have missed your requests, I'm not the best at keeping track of these things. Moving to the wiki allows for changes to happen more rapidly, and if they appear to be bad changes, we can roll them back fairly easily. Yes you can do this now with our website, but there is one you, and it is non trivial to add more people to the current web system to be able to do updates and such. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From rostetter at mail.utexas.edu Wed Feb 22 19:39:45 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 22 Feb 2006 13:39:45 -0600 Subject: FC3 yum instructions In-Reply-To: <1140636466.4578.34.camel@ender> References: <20060221142119.jpl2sxuize0o8o8s@mail.ph.utexas.edu> <1140554189.17286.115.camel@ender> <20060221145002.g0u662hkipswos4c@mail.ph.utexas.edu> <1140555764.17286.118.camel@ender> <20060221214955.rus1d0357csg8oco@mail.ph.utexas.edu> <1140590848.17286.157.camel@ender> <20060222102100.ucqeeyc1ctko44ck@mail.ph.utexas.edu> <1140632646.4578.13.camel@ender> <20060222125248.pzecjgur76w4c48k@mail.ph.utexas.edu> <1140634709.3959.35.camel@cutter> <20060222132039.6qaxgalawdmkg8so@mail.ph.utexas.edu> <1140636466.4578.34.camel@ender> Message-ID: <20060222133945.8zz05vra95sk8o0w@mail.ph.utexas.edu> Quoting Jesse Keating : > On Wed, 2006-02-22 at 13:20 -0600, Eric Rostetter wrote: >> >> But then, our web presence has never been good anyway, since no one will >> participate in the process. I proposed an updated overview years ago, and >> have received basically no feedback of any sort, and no go-ahead to >> implement >> it, and any attempt to get it approved has failed. > > Probably because webwork isn't fun The work was done. We only needed to vote on it. > and nobody feels like they have the > 'authority' to approve or disapprove updates. Well, the system is set up to do just that. So if no one feels they can do what the system is setup to do, then we have a problem. > Moving to the wiki allows for changes to happen more rapidly, and if > they appear to be bad changes, we can roll them back fairly easily. The changes to the overview are in the wiki. Has not helped one bit. The previous "idea" which you created was that we created docs in the wiki (easy to do, let's everyone collaborate, etc) and when finished they are moved to the web... > Yes > you can do this now with our website, but there is one you, and it is > non trivial to add more people to the current web system to be able to > do updates and such. Whether that is true or not doesn't matter, as it is not relevant to the issue. I'm talking about a document in the wiki, which no one has bothered to approve over the course of years... A document that is supposed to define our group and our purpose. A document who's official version which is on the web is comically out of date. This is not a web issue. This is a leadership issue, and a participation issue. Not having updated our overview makes us look bad, makes us look unprofessional, makes us look like a dead project. Similarly, I feel moving to the wiki will make us look bad, and make us look unprofessional, but maybe at least it will get someone to edit pages and at least we might not look so dead... So there might be at least one upside to it. In any case, this is my last reply to the thread, and it is just, at least in my own postings, too negative to bear. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From jkeating at j2solutions.net Wed Feb 22 20:12:07 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 22 Feb 2006 12:12:07 -0800 Subject: FC3 yum instructions In-Reply-To: <20060222133945.8zz05vra95sk8o0w@mail.ph.utexas.edu> References: <20060221142119.jpl2sxuize0o8o8s@mail.ph.utexas.edu> <1140554189.17286.115.camel@ender> <20060221145002.g0u662hkipswos4c@mail.ph.utexas.edu> <1140555764.17286.118.camel@ender> <20060221214955.rus1d0357csg8oco@mail.ph.utexas.edu> <1140590848.17286.157.camel@ender> <20060222102100.ucqeeyc1ctko44ck@mail.ph.utexas.edu> <1140632646.4578.13.camel@ender> <20060222125248.pzecjgur76w4c48k@mail.ph.utexas.edu> <1140634709.3959.35.camel@cutter> <20060222132039.6qaxgalawdmkg8so@mail.ph.utexas.edu> <1140636466.4578.34.camel@ender> <20060222133945.8zz05vra95sk8o0w@mail.ph.utexas.edu> Message-ID: <1140639128.4578.46.camel@ender> On Wed, 2006-02-22 at 13:39 -0600, Eric Rostetter wrote: > The changes to the overview are in the wiki. Has not helped one bit. > > The previous "idea" which you created was that we created docs in the > wiki (easy to do, let's everyone collaborate, etc) and when finished > they are moved to the web... > Ah, this was a poor idea on my part. We shouldn't have had a two stage process. It is changed on the wiki and should be good on the Wiki. No need to copy it back to a static web page. > > Yes > > you can do this now with our website, but there is one you, and it is > > non trivial to add more people to the current web system to be able to > > do updates and such. > > Whether that is true or not doesn't matter, as it is not relevant to the > issue. I'm talking about a document in the wiki, which no one has bothered > to approve over the course of years... A document that is supposed to > define our group and our purpose. A document who's official version which > is on the web is comically out of date. > > This is not a web issue. This is a leadership issue, and a participation > issue. Not having updated our overview makes us look bad, makes us > look unprofessional, makes us look like a dead project. Again, this is a failure on perhaps my part, not realizing that there was something I was supposed to approve. People looking on the wiki see our updated content. We can update the wiki much quicker and be a much more 'live' project. Carrying around a static website that takes effort to change is what slows things down IMHO. > Similarly, I feel moving to the wiki will make us look bad, and make us > look unprofessional, but maybe at least it will get someone to edit pages > and at least we might not look so dead... So there might be at least > one upside to it. > The reality of it is we are NOT a professional project. We are a community project put together by community collaboration. A wiki system is for exactly that, community collaboration. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From marcdeslauriers at videotron.ca Thu Feb 23 00:07:28 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 22 Feb 2006 19:07:28 -0500 Subject: [UPDATED] Fedora Legacy Test Update Notification: gpdf Message-ID: <43FCFCC0.2030602@videotron.ca> Fedora Core 3 packages were updated to add a missing signature. --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-176751 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176751 2006-02-22 --------------------------------------------------------------------- Name : gpdf Versions : fc1: gpdf-0.110-1.5.legacy Versions : fc2: gpdf-2.8.2-4.1.1.legacy Versions : fc3: gpdf-2.8.2-7.2.1.legacy Summary : viewer for Portable Document Format (PDF) files for GNOME Description : This is GPdf, a viewer for Portable Document Format (PDF) files for GNOME. GPdf is based on the Xpdf program and uses additional GNOME libraries for better desktop integration. --------------------------------------------------------------------- Update Information: An updated gpdf package that fixes several security issues is now available. The gpdf package is a GNOME based viewer for Portable Document Format (PDF) files. A flaw was discovered in gpdf. An attacker could construct a carefully crafted PDF file that would cause gpdf to consume all available disk space in /tmp when opened. The Common Vulnerabilities and Exposures project assigned the name CVE-2005-2097 to this issue. Several flaws were discovered in gpdf. An attacker could construct a carefully crafted PDF file that could cause gpdf to crash or possibly execute arbitrary code when opened. The Common Vulnerabilities and Exposures project assigned the names CVE-2005-3191, CVE-2005-3192, CVE-2005-3193, CVE-2005-3624, CVE-2005-3625, CVE-2005-3626, CVE-2005-3627 and CVE-2005-3628 to these issues. Users of gpdf should upgrade to this updated package, which contains backported patches to resolve these issues. --------------------------------------------------------------------- Changelogs fc1: * Sat Feb 18 2006 Marc Deslauriers 0.110-1.5.legacy - Use better patch for CVE-2004-0888 (from RHEL3 xpdf) - Add patch for CVE-2005-3193 fc2: * Sat Feb 18 2006 Marc Deslauriers 2.8.2-4.1.1.legacy - Rebuilt as Fedora Legacy security update for Fedora Core 2 - Removed the desktop-file-utils dependencies * Fri Jan 06 2006 Ray Strode 2.8.2-7.4 - Apply fix for CVE-2005-3624 (also covers CVE-2005-3193) (bug 176865) * Wed Dec 14 2005 Ray Strode 2.8.2-7.3 - apply updated patch for CVE-2005-3193 (bug 175102) fc3: * Sat Feb 18 2006 Marc Deslauriers 2.8.2-7.2.1.legacy - Rebuilt as Fedora Legacy security update for Fedora Core 3 * Fri Jan 06 2006 Ray Strode 2.8.2-7.4 - Apply fix for CVE-2005-3624 (also covers CVE-2005-3193) (bug 176865) * Wed Dec 14 2005 Ray Strode 2.8.2-7.3 - apply updated patch for CVE-2005-3193 (bug 175102) --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) fc1: 646edd9bdaf07a2f74d0b9874a666f94dc4f7982 fedora/1/updates-testing/i386/gpdf-0.110-1.5.legacy.i386.rpm 23f1172453f4e6572bd5a5bebcf093fda9c9ef62 fedora/1/updates-testing/SRPMS/gpdf-0.110-1.5.legacy.src.rpm fc2: 2798a8e5ba37214b4ad3d537aa38b65c62c9e7c7 fedora/2/updates-testing/i386/gpdf-2.8.2-4.1.1.legacy.i386.rpm e6d36329145bd25d5646da0064124f4b3a3faf99 fedora/2/updates-testing/SRPMS/gpdf-2.8.2-4.1.1.legacy.src.rpm fc3: 2a08ad7afb9cecc7e41d80603a536b191d85f776 fedora/3/updates-testing/i386/gpdf-2.8.2-7.2.1.legacy.i386.rpm 3d3ab23bea79b424aaac1c26e3c16a3dfbee7af0 fedora/3/updates-testing/SRPMS/gpdf-2.8.2-7.2.1.legacy.src.rpm a434ff117af22aeacc3c76773fa6985be9c107c0 fedora/3/updates-testing/x86_64/gpdf-2.8.2-7.2.1.legacy.x86_64.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Thu Feb 23 00:09:27 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 22 Feb 2006 19:09:27 -0500 Subject: Fedora Legacy Test Update Notification: gpdf In-Reply-To: <20060222165729.GA19837@mail.harddata.com> References: <43FA65C1.3060706@videotron.ca> <20060222165729.GA19837@mail.harddata.com> Message-ID: <1140653367.32646.3.camel@mdlinux> On Wed, 2006-02-22 at 09:57 -0700, Michal Jaegermann wrote: > On Mon, Feb 20, 2006 at 07:58:41PM -0500, Marc Deslauriers wrote: > > --------------------------------------------------------------------- > > Fedora Legacy Test Update Notification > > FEDORALEGACY-2006-176751 > .... > > fedora/3/updates-testing/i386/gpdf-2.8.2-7.2.1.legacy.i386.rpm > > At least this package is unsigned so yum, in a default configuration > from legacy-yumconf-3-4.fc3 plus enabled 'legacy-testing', will not > install that. sha1sum agrees with what was posted, though. Thanks for noticing. I just pushed out signed ones. Marc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From pekkas at netcore.fi Thu Feb 23 06:04:51 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 23 Feb 2006 08:04:51 +0200 (EET) Subject: FC3 yum instructions In-Reply-To: <20060222105016.ja1cw9c7tvcwo0c4@mail.ph.utexas.edu> References: <20060221142119.jpl2sxuize0o8o8s@mail.ph.utexas.edu> <1140554189.17286.115.camel@ender> <20060221145002.g0u662hkipswos4c@mail.ph.utexas.edu> <1140555764.17286.118.camel@ender> <20060221214955.rus1d0357csg8oco@mail.ph.utexas.edu> <1140590848.17286.157.camel@ender> <20060222105016.ja1cw9c7tvcwo0c4@mail.ph.utexas.edu> Message-ID: On Wed, 22 Feb 2006, Eric Rostetter wrote: > Quoting Pekka Savola : >> I'm all for getting FL closer to common Fedora infrastructure, >> especially as the focus on Fedora Core support is increasing. Hence, >> Fedora CVS, buildsystem, etc. is the direction we should go. > > But what about web vs. wiki? Should we move to Fedora wiki, or stay > as a more traditional web site, or some of each? Fedora Extras is > at one end, Fedora Documentation Project is in the middle, we were at > one end but are moving towards the other, etc. Where should the FL web > be moving; towards wiki or towards web or towards a split between them? Wiki is probably better for most stuff. The web site might need to have non-wiki content though, and that should be realized as a requirement: for example, the FL advisories, hopefully buglist*.html, and other similar more or less autogenerated text. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From rostetter at mail.utexas.edu Thu Feb 23 16:36:13 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 23 Feb 2006 10:36:13 -0600 Subject: FC3 yum instructions In-Reply-To: References: <20060221142119.jpl2sxuize0o8o8s@mail.ph.utexas.edu> <1140554189.17286.115.camel@ender> <20060221145002.g0u662hkipswos4c@mail.ph.utexas.edu> <1140555764.17286.118.camel@ender> <20060221214955.rus1d0357csg8oco@mail.ph.utexas.edu> <1140590848.17286.157.camel@ender> <20060222105016.ja1cw9c7tvcwo0c4@mail.ph.utexas.edu> Message-ID: <20060223103613.e1yfy0w8kwa888o8@mail.ph.utexas.edu> Quoting Pekka Savola : > On Wed, 22 Feb 2006, Eric Rostetter wrote: >> Quoting Pekka Savola : >>> I'm all for getting FL closer to common Fedora infrastructure, >>> especially as the focus on Fedora Core support is increasing. Hence, >>> Fedora CVS, buildsystem, etc. is the direction we should go. >> >> But what about web vs. wiki? Should we move to Fedora wiki, or stay >> as a more traditional web site, or some of each? Fedora Extras is >> at one end, Fedora Documentation Project is in the middle, we were at >> one end but are moving towards the other, etc. Where should the FL web >> be moving; towards wiki or towards web or towards a split between them? > > Wiki is probably better for most stuff. Or at least some stuff (docs and FAQ for example). > The web site might need to have non-wiki content though, and that > should be realized as a requirement: for example, the FL advisories, > hopefully buglist*.html, and other similar more or less autogenerated > text. And perhaps more trusted data, like the security page which lists our GPG KEYS and so on? I'd rather trust a restricted web server than a fairly unrestricted wiki for things like key signatures, etc. I mentioned some of this in private e-mail to Jesse back a few weeks ago (when the FC3 transition was happening) but don't know his opinion or feelings on it. Only know he was asking if we could get rid of the web site altogether, and I was replying that it would be difficult to do things like the advisories in the wiki... Personally, there is a lot of content I don't think should be in a wiki for various reasons, such as the security info, advisories, home page itself, and there is other stuff I don't really care about the location of such as the FAQ, docs, participation pages, etc. I'm against the wholesale move from web to wiki though, which is how this was presented to me (though obviously as a gradual process, with the goal of eventually having no web site). -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From smooge at gmail.com Thu Feb 23 19:21:26 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Thu, 23 Feb 2006 12:21:26 -0700 Subject: Fedora Legacy Test Update Notification: kernel (fc3) In-Reply-To: <43FA65AD.70809@videotron.ca> References: <43FA65AD.70809@videotron.ca> Message-ID: <80d7e4090602231121m393a63d2y5cd36da495a7ec50@mail.gmail.com> On 2/20/06, Marc Deslauriers wrote: > --------------------------------------------------------------------- > Fedora Legacy Test Update Notification > FEDORALEGACY-2006-157459-4 > Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157459 > 2006-02-20 > --------------------------------------------------------------------- > > Name : kernel > Versions : fc3: kernel-2.6.12-2.3.legacy_FC3 > Summary : The Linux kernel (the core of the Linux operating system). Tested on FC3 on Dell PowerEdge SC420. No regressions. Found SATA drives. tcpdump works.. HTTP applications work. -- Stephen J Smoogen. CSIRT/Linux System Administrator From marcdeslauriers at videotron.ca Fri Feb 24 00:08:48 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 23 Feb 2006 19:08:48 -0500 Subject: Fedora Legacy Test Update Notification: gdk-pixbuf Message-ID: <43FE4E90.6050905@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-173274 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173274 2006-02-23 --------------------------------------------------------------------- Name : gdk-pixbuf Versions : rh73: gdk-pixbuf-0.22.0-7.73.4.legacy Versions : rh9: gdk-pixbuf-0.22.0-7.90.4.legacy Versions : fc1: gdk-pixbuf-0.22.0-11.3.4.2.legacy Versions : fc2: gdk-pixbuf-0.22.0-12.fc2.1.legacy Summary : An image loading library used with GNOME. Description : The gdk-pixbuf package contains an image loading library used with the GNOME desktop environment. The GdkPixBuf library provides image loading facilities, the rendering of a GdkPixBuf into various formats (drawables or GdkRGB buffers), and a cache interface. --------------------------------------------------------------------- Update Information: Updated gdk-pixbuf packages that fix several security issues are now available. The gdk-pixbuf package contains an image loading library used with the GNOME GUI desktop environment. A bug was found in the way gdk-pixbuf processes XPM images. An attacker could create a carefully crafted XPM file in such a way that it could cause an application linked with gdk-pixbuf to execute arbitrary code when the file was opened by a victim. The Common Vulnerabilities and Exposures project has assigned the name CVE-2005-3186 to this issue. Ludwig Nussel discovered an integer overflow bug in the way gdk-pixbuf processes XPM images. An attacker could create a carefully crafted XPM file in such a way that it could cause an application linked with gdk-pixbuf to execute arbitrary code or crash when the file was opened by a victim. The Common Vulnerabilities and Exposures project has assigned the name CVE-2005-2976 to this issue. Ludwig Nussel also discovered an infinite-loop denial of service bug in the way gdk-pixbuf processes XPM images. An attacker could create a carefully crafted XPM file in such a way that it could cause an application linked with gdk-pixbuf to stop responding when the file was opened by a victim. The Common Vulnerabilities and Exposures project has assigned the name CVE-2005-2975 to this issue. Users of gdk-pixbuf are advised to upgrade to these updated packages, which contain backported patches and are not vulnerable to these issues. --------------------------------------------------------------------- Changelogs rh73: * Sun Feb 19 2006 Marc Deslauriers - 1:0.22.0-7.73.4.legacy - Prevent another integer overflow in the xpm loader (CVE-2005-2976) - Prevent an infinite loop in the xpm loader (CVE-2005-2975) - Prevent an integer overflow in the xpm loader (CVE-2005-3186) rh9: * Sun Feb 19 2006 Marc Deslauriers - 1:0.22.0-7.90.4.legacy - Prevent another integer overflow in the xpm loader (CVE-2005-2976) - Prevent an infinite loop in the xpm loader (CVE-2005-2975) - Prevent an integer overflow in the xpm loader (CVE-2005-3186) fc1: * Sun Feb 19 2006 Marc Deslauriers - 1:0.22.0-11.3.4.2.legacy - Prevent another integer overflow in the xpm loader (CVE-2005-2976) - Prevent an infinite loop in the xpm loader (CVE-2005-2975) - Prevent an integer overflow in the xpm loader (CVE-2005-3186) fc2: * Sun Feb 19 2006 Marc Deslauriers - 1:0.22.0-12.fc2.1.legacy - Prevent another integer overflow in the xpm loader (CVE-2005-2976) - Prevent an infinite loop in the xpm loader (CVE-2005-2975) - Prevent an integer overflow in the xpm loader (CVE-2005-3186) --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 68920e1aa48821ef2712597cfbb738a308fed989 redhat/7.3/updates-testing/i386/gdk-pixbuf-0.22.0-7.73.4.legacy.i386.rpm bed67c95aeba203d572601c03f61f4a87738577e redhat/7.3/updates-testing/i386/gdk-pixbuf-devel-0.22.0-7.73.4.legacy.i386.rpm 83b2d6fa22c90b3335c80e8516bbf7c013f3e0ce redhat/7.3/updates-testing/i386/gdk-pixbuf-gnome-0.22.0-7.73.4.legacy.i386.rpm 72d3a78c075cbd1108551c0f003d1d546474f345 redhat/7.3/updates-testing/SRPMS/gdk-pixbuf-0.22.0-7.73.4.legacy.src.rpm rh9: d2f5f242b378c44caa4b05ff2d157732b4f50896 redhat/9/updates-testing/i386/gdk-pixbuf-0.22.0-7.90.4.legacy.i386.rpm 5a4b0b7566fb195e3ae9ac9df3a1d0d85f86d53d redhat/9/updates-testing/i386/gdk-pixbuf-devel-0.22.0-7.90.4.legacy.i386.rpm 99deb34f608c31c177acc48aae2a5a22dbef5e27 redhat/9/updates-testing/i386/gdk-pixbuf-gnome-0.22.0-7.90.4.legacy.i386.rpm 34b8e79dfcfabfbd375636077a606f4c7193aabb redhat/9/updates-testing/SRPMS/gdk-pixbuf-0.22.0-7.90.4.legacy.src.rpm fc1: 0c08e3ec62a3ffc2cf4bf020f56dbce6c6abe55e fedora/1/updates-testing/i386/gdk-pixbuf-0.22.0-11.3.4.2.legacy.i386.rpm b51c2c8928ef71b22375ef359262f5ab0467ede1 fedora/1/updates-testing/i386/gdk-pixbuf-devel-0.22.0-11.3.4.2.legacy.i386.rpm c36d9f5d78ddb75cfade93741fac76b692159fc0 fedora/1/updates-testing/i386/gdk-pixbuf-gnome-0.22.0-11.3.4.2.legacy.i386.rpm a33a275c1c2ff62a4256cd360aa2377989db4fd9 fedora/1/updates-testing/SRPMS/gdk-pixbuf-0.22.0-11.3.4.2.legacy.src.rpm fc2: 6b55923c343d97bd131685a02cb36aba60be94a2 fedora/2/updates-testing/i386/gdk-pixbuf-0.22.0-12.fc2.1.legacy.i386.rpm a391b3b8ee9c42bf0f4fed872bfa5aea61cd34a7 fedora/2/updates-testing/i386/gdk-pixbuf-devel-0.22.0-12.fc2.1.legacy.i386.rpm a76c91bbdb0ff8fc1a30bf7c46a7392fbecf412b fedora/2/updates-testing/i386/gdk-pixbuf-gnome-0.22.0-12.fc2.1.legacy.i386.rpm 1ee0fd9996c89480305d4831e77406696030ec3f fedora/2/updates-testing/SRPMS/gdk-pixbuf-0.22.0-12.fc2.1.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Fri Feb 24 00:09:13 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 23 Feb 2006 19:09:13 -0500 Subject: Fedora Legacy Test Update Notification: libungif Message-ID: <43FE4EA9.2000203@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-174479 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174479 2006-02-23 --------------------------------------------------------------------- Name : libungif Versions : rh73: libungif-4.1.0-10.2.legacy Versions : rh9: libungif-4.1.0-15.2.legacy Versions : fc1: libungif-4.1.0-16.2.legacy Versions : fc2: libungif-4.1.0-17.3.legacy Summary : A library for manipulating GIF format image files. Description : The libungif package contains a shared library of functions for loading and saving GIF format image files. The libungif library can load any GIF file, but it will save GIFs only in uncompressed format; it will not use the patented LZW compression used to save "normal" compressed GIF files. --------------------------------------------------------------------- Update Information: Updated libungif packages that fix two security issues are now available. The libungif package contains a shared library of functions for loading and saving GIF format image files. Several bugs in the way libungif decodes GIF images were discovered. An attacker could create a carefully crafted GIF image file in such a way that it could cause an application linked with libungif to crash or execute arbitrary code when the file is opened by a victim. The Common Vulnerabilities and Exposures project has assigned the names CVE-2005-2974 and CVE-2005-3350 to these issues. All users of libungif are advised to upgrade to these updated packages, which contain backported patches that resolve these issues. --------------------------------------------------------------------- Changelogs rh73: * Wed Feb 22 2006 Marc Deslauriers 4.1.0-10.2.legacy - Added missing XFree86-devel, netpbm-devel and texinfo to BuildRequires - Added patch from RHEL to get librle in * Sun Feb 19 2006 Marc Deslauriers 4.1.0-10.1.legacy - Added patch for CVE-2005-2974 and CVE-2005-3350 rh9: * Wed Feb 22 2006 Marc Deslauriers 4.1.0-15.2.legacy - Added missing XFree86-devel, netpbm-devel and texinfo to BuildRequires - Added patch from RHEL to get librle in * Sun Feb 19 2006 Marc Deslauriers 4.1.0-15.1.legacy - Added patch to fix CVE-2005-2974 and CVE-2005-3350 fc1: * Thu Feb 23 2006 Marc Deslauriers 4.1.0-16.2.legacy - Added missing XFree86-devel to BuildRequires * Sun Feb 19 2006 Marc Deslauriers 4.1.0-16.1.legacy - Added patch to fix CVE-2005-2974 and CVE-2005-3350 fc2: * Thu Feb 23 2006 Marc Deslauriers 4.1.0-17.3.legacy - Added missing xorg-x11-devel to BuildRequires * Sun Feb 19 2006 Marc Deslauriers 4.1.0-17.2.legacy - Added patch to fix CVE-2005-2974 and CVE-2005-3350 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 540bf946dff308b065de73d7ce6ab9eb8d8c504a redhat/7.3/updates-testing/i386/libungif-4.1.0-10.2.legacy.i386.rpm 840791ef661042f779275b7c835760ab521a8d80 redhat/7.3/updates-testing/i386/libungif-devel-4.1.0-10.2.legacy.i386.rpm 81f2ed8f2bae2785ec2820234875b870f583c7ce redhat/7.3/updates-testing/i386/libungif-progs-4.1.0-10.2.legacy.i386.rpm 8e039159be2bf479bf2bdb84ebadc2a364b3bd06 redhat/7.3/updates-testing/SRPMS/libungif-4.1.0-10.2.legacy.src.rpm rh9: c78cfe7b9a7e46d45865fcebad0956efb8962970 redhat/9/updates-testing/i386/libungif-4.1.0-15.2.legacy.i386.rpm 1b8a2ff811fca4b56850adfc5fc602bd140876d8 redhat/9/updates-testing/i386/libungif-devel-4.1.0-15.2.legacy.i386.rpm 35f6365684cec0da676b5c5fea9bdf2e9863d1ff redhat/9/updates-testing/i386/libungif-progs-4.1.0-15.2.legacy.i386.rpm cb023ca008db9d81ad6d730cb714cb1f51ea97f3 redhat/9/updates-testing/SRPMS/libungif-4.1.0-15.2.legacy.src.rpm fc1: 351c84419dfff38690db6f343fa91a41e6b2af1e fedora/1/updates-testing/i386/libungif-4.1.0-16.2.legacy.i386.rpm 72af8bc46a9deb31ede1fc773866e67f20f0da0b fedora/1/updates-testing/i386/libungif-devel-4.1.0-16.2.legacy.i386.rpm 3d36816c8ec4479647419402be97568fade3088e fedora/1/updates-testing/i386/libungif-progs-4.1.0-16.2.legacy.i386.rpm 92a4859d10e58f5abc85e7e22c89e4cf4911fbf0 fedora/1/updates-testing/SRPMS/libungif-4.1.0-16.2.legacy.src.rpm fc2: 3a87b57220b6b788150d240977774dc54f6732fe fedora/2/updates-testing/i386/libungif-4.1.0-17.3.legacy.i386.rpm c2d7e51e31ecb48546712d0c6f9998601af6daec fedora/2/updates-testing/i386/libungif-devel-4.1.0-17.3.legacy.i386.rpm fbde1aceba27f12aacb41c8acbe2cf58a59cc121 fedora/2/updates-testing/i386/libungif-progs-4.1.0-17.3.legacy.i386.rpm 609e3081132c7dca0da32f631e5ec4117df51265 fedora/2/updates-testing/SRPMS/libungif-4.1.0-17.3.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Fri Feb 24 00:10:05 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 23 Feb 2006 19:10:05 -0500 Subject: [FLSA-2006:162750] Updated sudo packages fix security issue Message-ID: <43FE4EDD.7080500@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated sudo packages fix security issue Advisory ID: FLSA:162750 Issue date: 2006-02-23 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2005-1993 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: An updated sudo package is available that fixes a race condition in sudo's pathname validation. The sudo (superuser do) utility allows system administrators to give certain users the ability to run commands as root with logging. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 3. Problem description: A race condition bug was found in the way sudo handles pathnames. It is possible that a local user with limited sudo access could create a race condition that would allow the execution of arbitrary commands as the root user. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-1993 to this issue. Users of sudo should update to this updated package, which contains a backported patch and is not vulnerable to 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: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162750 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/sudo-1.6.5p2-2.3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/sudo-1.6.5p2-2.3.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/sudo-1.6.6-3.3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/sudo-1.6.6-3.3.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/sudo-1.6.7p5-2.3.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/sudo-1.6.7p5-2.3.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/sudo-1.6.7p5-26.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/sudo-1.6.7p5-26.2.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 5eed8171a2be78f8a03de987b86220b1c8ecb9d4 redhat/7.3/updates/i386/sudo-1.6.5p2-2.3.legacy.i386.rpm f1fdc4b82456cf66f89764ec7f9c0909a0603805 redhat/7.3/updates/SRPMS/sudo-1.6.5p2-2.3.legacy.src.rpm 7a84e2d96bba56142ca8c6dec2603577e31b2072 redhat/9/updates/i386/sudo-1.6.6-3.3.legacy.i386.rpm 4aca97be1c9e5f61efa1165955eb219fce3af70e redhat/9/updates/SRPMS/sudo-1.6.6-3.3.legacy.src.rpm 4e7b55e41c355e51b4cdd3a820a6d5c94df43fdc fedora/1/updates/i386/sudo-1.6.7p5-2.3.legacy.i386.rpm 6843f6ee7792e8c63f1034107a4a4e464a613798 fedora/1/updates/SRPMS/sudo-1.6.7p5-2.3.legacy.src.rpm 954a6e7098b7e86e7bc1f1532a72f8a3dab32380 fedora/2/updates/i386/sudo-1.6.7p5-26.2.legacy.i386.rpm 82c884d6bcff123dd510ffdb8a0d81ce63606364 fedora/2/updates/SRPMS/sudo-1.6.7p5-26.2.legacy.src.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=CVE-2005-1993 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Fri Feb 24 00:10:48 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 23 Feb 2006 19:10:48 -0500 Subject: [FLSA-2006:180036-1] Updated mozilla packages fix security issues Message-ID: <43FE4F08.1090105@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated mozilla packages fix security issues Advisory ID: FLSA:180036-1 Issue date: 2006-02-23 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2005-4134 CVE-2006-0292 CVE-2006-0296 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated mozilla packages that fix several security bugs are now available. Mozilla is an open source Web browser, advanced email and newsgroup client, IRC chat client, and HTML editor. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 Fedora Core 3 - i386, x86_64 3. Problem description: Igor Bukanov discovered a bug in the way Mozilla's Javascript interpreter dereferences objects. If a user visits a malicious web page, Mozilla could crash or execute arbitrary code as the user running Mozilla. The Common Vulnerabilities and Exposures project assigned the name CVE-2006-0292 to this issue. moz_bug_r_a4 discovered a bug in Mozilla's XULDocument.persist() function. A malicious web page could inject arbitrary RDF data into a user's localstore.rdf file, which can cause Mozilla to execute arbitrary javascript when a user runs Mozilla. (CVE-2006-0296) A denial of service bug was found in the way Mozilla saves history information. If a user visits a web page with a very long title, it is possible Mozilla will crash or take a very long time the next time it is run. (CVE-2005-4134) Users of Mozilla are advised to upgrade to these updated packages, which contain backported patches to 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/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180036 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/mozilla-1.7.12-0.73.3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-1.7.12-0.73.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-chat-1.7.12-0.73.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-devel-1.7.12-0.73.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-dom-inspector-1.7.12-0.73.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-js-debugger-1.7.12-0.73.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-mail-1.7.12-0.73.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-nspr-1.7.12-0.73.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-nspr-devel-1.7.12-0.73.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-nss-1.7.12-0.73.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-nss-devel-1.7.12-0.73.3.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/mozilla-1.7.12-0.90.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-1.7.12-0.90.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-chat-1.7.12-0.90.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-devel-1.7.12-0.90.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-dom-inspector-1.7.12-0.90.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-js-debugger-1.7.12-0.90.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-mail-1.7.12-0.90.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-nspr-1.7.12-0.90.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-nspr-devel-1.7.12-0.90.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-nss-1.7.12-0.90.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-nss-devel-1.7.12-0.90.2.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/mozilla-1.7.12-1.1.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/mozilla-1.7.12-1.1.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/mozilla-chat-1.7.12-1.1.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/mozilla-devel-1.7.12-1.1.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/mozilla-dom-inspector-1.7.12-1.1.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/mozilla-js-debugger-1.7.12-1.1.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/mozilla-mail-1.7.12-1.1.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/mozilla-nspr-1.7.12-1.1.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/mozilla-nspr-devel-1.7.12-1.1.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/mozilla-nss-1.7.12-1.1.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/mozilla-nss-devel-1.7.12-1.1.2.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/mozilla-1.7.12-1.2.3.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/mozilla-1.7.12-1.2.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/mozilla-chat-1.7.12-1.2.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/mozilla-devel-1.7.12-1.2.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/mozilla-dom-inspector-1.7.12-1.2.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/mozilla-js-debugger-1.7.12-1.2.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/mozilla-mail-1.7.12-1.2.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/mozilla-nspr-1.7.12-1.2.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/mozilla-nspr-devel-1.7.12-1.2.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/mozilla-nss-1.7.12-1.2.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/mozilla-nss-devel-1.7.12-1.2.3.legacy.i386.rpm Fedora Core 3: SRPM: http://download.fedoralegacy.org/fedora/3/updates/SRPMS/mozilla-1.7.12-1.3.3.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/3/updates/i386/mozilla-1.7.12-1.3.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/3/updates/i386/mozilla-chat-1.7.12-1.3.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/3/updates/i386/mozilla-devel-1.7.12-1.3.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/3/updates/i386/mozilla-dom-inspector-1.7.12-1.3.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/3/updates/i386/mozilla-js-debugger-1.7.12-1.3.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/3/updates/i386/mozilla-mail-1.7.12-1.3.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/3/updates/i386/mozilla-nspr-1.7.12-1.3.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/3/updates/i386/mozilla-nspr-devel-1.7.12-1.3.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/3/updates/i386/mozilla-nss-1.7.12-1.3.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/3/updates/i386/mozilla-nss-devel-1.7.12-1.3.3.legacy.i386.rpm x86_64: http://download.fedoralegacy.org/fedora/3/updates/x86_64/mozilla-1.7.12-1.3.3.legacy.x86_64.rpm http://download.fedoralegacy.org/fedora/3/updates/x86_64/mozilla-chat-1.7.12-1.3.3.legacy.x86_64.rpm http://download.fedoralegacy.org/fedora/3/updates/x86_64/mozilla-devel-1.7.12-1.3.3.legacy.x86_64.rpm http://download.fedoralegacy.org/fedora/3/updates/x86_64/mozilla-dom-inspector-1.7.12-1.3.3.legacy.x86_64.rpm http://download.fedoralegacy.org/fedora/3/updates/x86_64/mozilla-js-debugger-1.7.12-1.3.3.legacy.x86_64.rpm http://download.fedoralegacy.org/fedora/3/updates/x86_64/mozilla-mail-1.7.12-1.3.3.legacy.x86_64.rpm http://download.fedoralegacy.org/fedora/3/updates/x86_64/mozilla-nspr-1.7.12-1.3.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/3/updates/x86_64/mozilla-nspr-1.7.12-1.3.3.legacy.x86_64.rpm http://download.fedoralegacy.org/fedora/3/updates/x86_64/mozilla-nspr-devel-1.7.12-1.3.3.legacy.x86_64.rpm http://download.fedoralegacy.org/fedora/3/updates/x86_64/mozilla-nss-1.7.12-1.3.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/3/updates/x86_64/mozilla-nss-1.7.12-1.3.3.legacy.x86_64.rpm http://download.fedoralegacy.org/fedora/3/updates/x86_64/mozilla-nss-devel-1.7.12-1.3.3.legacy.x86_64.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- baf937574b92b01271c70169e5e6465eb7736c81 redhat/7.3/updates/i386/mozilla-1.7.12-0.73.3.legacy.i386.rpm 4e401f2064201c290aa00527d148141904532d8a redhat/7.3/updates/i386/mozilla-chat-1.7.12-0.73.3.legacy.i386.rpm d97acf0463781ac5600754b02b5a902125df5fd4 redhat/7.3/updates/i386/mozilla-devel-1.7.12-0.73.3.legacy.i386.rpm 251eb4a2d0e0f8cf63b7b7975c9819a7e58fd5b3 redhat/7.3/updates/i386/mozilla-dom-inspector-1.7.12-0.73.3.legacy.i386.rpm 584062b1c063fb8c2375693b49e48b8ae7530a00 redhat/7.3/updates/i386/mozilla-js-debugger-1.7.12-0.73.3.legacy.i386.rpm aa3594680a3224f6b8b7abb9a6b9585fa6f519c1 redhat/7.3/updates/i386/mozilla-mail-1.7.12-0.73.3.legacy.i386.rpm 1676c32cd8143b9ff939b45269b2423b50d062f1 redhat/7.3/updates/i386/mozilla-nspr-1.7.12-0.73.3.legacy.i386.rpm 9d9d350082b38b94d45e458e02f3345b0a4e3ed0 redhat/7.3/updates/i386/mozilla-nspr-devel-1.7.12-0.73.3.legacy.i386.rpm 33753a720edea798966550963426db05a409a6c4 redhat/7.3/updates/i386/mozilla-nss-1.7.12-0.73.3.legacy.i386.rpm b17dec4e9eab3acca07dc0345d01fa522c3f43d8 redhat/7.3/updates/i386/mozilla-nss-devel-1.7.12-0.73.3.legacy.i386.rpm 169c96bd3eae5e8f4220ed87291ceb176bf1f6b2 redhat/7.3/updates/SRPMS/mozilla-1.7.12-0.73.3.legacy.src.rpm ffa6d9ff83d69b2aa32fb92a660775cbb92f2b53 redhat/9/updates/i386/mozilla-1.7.12-0.90.2.legacy.i386.rpm d4bc650d1652ae30bb4df3037bcd1f9f77781774 redhat/9/updates/i386/mozilla-chat-1.7.12-0.90.2.legacy.i386.rpm 0148688359ca6168c0c77160c8891315ac319147 redhat/9/updates/i386/mozilla-devel-1.7.12-0.90.2.legacy.i386.rpm 2be970089280e3b23401402e5ea5019cc57b95ba redhat/9/updates/i386/mozilla-dom-inspector-1.7.12-0.90.2.legacy.i386.rpm 653ceef20cbbd2d415ab8453b5c6d6e81193b6b3 redhat/9/updates/i386/mozilla-js-debugger-1.7.12-0.90.2.legacy.i386.rpm 1c576446d6eef094adf576310d6fa773ee52259b redhat/9/updates/i386/mozilla-mail-1.7.12-0.90.2.legacy.i386.rpm a2bf3a3f3cbf90a1d0f73bc3ecba5b3d48a8e151 redhat/9/updates/i386/mozilla-nspr-1.7.12-0.90.2.legacy.i386.rpm 8eb53c3254fdbfcb78c229672a28c22d4ef0e4c7 redhat/9/updates/i386/mozilla-nspr-devel-1.7.12-0.90.2.legacy.i386.rpm 4ca88669c7390d9181673af47c954512d6dd7eef redhat/9/updates/i386/mozilla-nss-1.7.12-0.90.2.legacy.i386.rpm ccc8207ee4ee6dac6b23715884c011dd023acfb0 redhat/9/updates/i386/mozilla-nss-devel-1.7.12-0.90.2.legacy.i386.rpm 9f0c42c95eee533f46cb69e9ca24983d598b7c19 redhat/9/updates/SRPMS/mozilla-1.7.12-0.90.2.legacy.src.rpm ccc9f1f2f0a31d46cc69af0a7b3fc8279347c855 fedora/1/updates/i386/mozilla-1.7.12-1.1.2.legacy.i386.rpm 22fb3e89d2484c03774aa28756082ad7fd68c9a9 fedora/1/updates/i386/mozilla-chat-1.7.12-1.1.2.legacy.i386.rpm 971284c2c887c7de98cae3fc5fc48c542ff6934f fedora/1/updates/i386/mozilla-devel-1.7.12-1.1.2.legacy.i386.rpm e7c1727896f18603d38ad40a6f209d19d3049f0a fedora/1/updates/i386/mozilla-dom-inspector-1.7.12-1.1.2.legacy.i386.rpm 938aa693e2a7a499a33c6605cfa3a74e8673df27 fedora/1/updates/i386/mozilla-js-debugger-1.7.12-1.1.2.legacy.i386.rpm d6a2a1f6974ab09ec1d02af7592e782c27f578e6 fedora/1/updates/i386/mozilla-mail-1.7.12-1.1.2.legacy.i386.rpm 67cb0d096878aed78036e5ea0970f1147bf74d44 fedora/1/updates/i386/mozilla-nspr-1.7.12-1.1.2.legacy.i386.rpm cd48424e01cfe88b1f438c932a673b97f2101704 fedora/1/updates/i386/mozilla-nspr-devel-1.7.12-1.1.2.legacy.i386.rpm dd89685756cbe81a3928075f14310f58ce409af3 fedora/1/updates/i386/mozilla-nss-1.7.12-1.1.2.legacy.i386.rpm e193799b982e920ebb932fcc06c49a5228f704f6 fedora/1/updates/i386/mozilla-nss-devel-1.7.12-1.1.2.legacy.i386.rpm a07447de816fe5b143dd3f6a3476d3334e01576c fedora/1/updates/SRPMS/mozilla-1.7.12-1.1.2.legacy.src.rpm f22f8ad6584a2e8ff16f52858181f145a27ad88e fedora/2/updates/i386/mozilla-1.7.12-1.2.3.legacy.i386.rpm 9c1600eb0de0484a292b4b556b6e13d579cba87a fedora/2/updates/i386/mozilla-chat-1.7.12-1.2.3.legacy.i386.rpm 86859e409dc365f5bec29d0a93b175ac0bcba1b7 fedora/2/updates/i386/mozilla-devel-1.7.12-1.2.3.legacy.i386.rpm 2d9fccb410dc48ec08d16a34924db7be85b5270e fedora/2/updates/i386/mozilla-dom-inspector-1.7.12-1.2.3.legacy.i386.rpm 089f2798d5a48d3dbff41b750c0fa263d3c084b2 fedora/2/updates/i386/mozilla-js-debugger-1.7.12-1.2.3.legacy.i386.rpm 7f7cfb22bab08e5cafb4179ab400fb20f9f0e92d fedora/2/updates/i386/mozilla-mail-1.7.12-1.2.3.legacy.i386.rpm 122072963825101d273120c4efc5e0b414d8363c fedora/2/updates/i386/mozilla-nspr-1.7.12-1.2.3.legacy.i386.rpm 377d51c94a02e610a0085a3805a51d97896c56ed fedora/2/updates/i386/mozilla-nspr-devel-1.7.12-1.2.3.legacy.i386.rpm 255a282fed707f6730d559e5e182e15db1a2c647 fedora/2/updates/i386/mozilla-nss-1.7.12-1.2.3.legacy.i386.rpm 63f3f43a95d43c8d03a63a7d9914544d020e36af fedora/2/updates/i386/mozilla-nss-devel-1.7.12-1.2.3.legacy.i386.rpm 3763ccd5bb56555376b15e3b6719addea3d72e94 fedora/2/updates/SRPMS/mozilla-1.7.12-1.2.3.legacy.src.rpm 1dc7f066ff6b1edc46037b874c88871b92e689bd fedora/3/updates/i386/mozilla-1.7.12-1.3.3.legacy.i386.rpm d42189ed08ecb23f10fa811233191da00a6d2b86 fedora/3/updates/i386/mozilla-chat-1.7.12-1.3.3.legacy.i386.rpm 178fde65f593bfb2c97feef7a9368acd6a85e0a1 fedora/3/updates/i386/mozilla-devel-1.7.12-1.3.3.legacy.i386.rpm 934df1335c0409c5d200d3afcf0c5d1bb619d7a0 fedora/3/updates/i386/mozilla-dom-inspector-1.7.12-1.3.3.legacy.i386.rpm 44a98a9a93f06916e80028e436f3cb5a7e757403 fedora/3/updates/i386/mozilla-js-debugger-1.7.12-1.3.3.legacy.i386.rpm d70a4a67cae1c047ddd515ff466cc3964dc21639 fedora/3/updates/i386/mozilla-mail-1.7.12-1.3.3.legacy.i386.rpm 628cb7537726199cf5ecd459e7cbf2bb27acdca5 fedora/3/updates/i386/mozilla-nspr-1.7.12-1.3.3.legacy.i386.rpm 6c4a6afd3c1b3538a1ab0f691af18b75ae910f0a fedora/3/updates/i386/mozilla-nspr-devel-1.7.12-1.3.3.legacy.i386.rpm 6df7e4d99d0b5b0634eaf71816aff3a76308850c fedora/3/updates/i386/mozilla-nss-1.7.12-1.3.3.legacy.i386.rpm 86a0ea171fa09f02a13307cfd742aa4d7669dbf3 fedora/3/updates/i386/mozilla-nss-devel-1.7.12-1.3.3.legacy.i386.rpm cc1ee55af3e20e520347b8d54604c49a3a687a68 fedora/3/updates/x86_64/mozilla-1.7.12-1.3.3.legacy.x86_64.rpm 2365e1dd78f64bfb6888e8a7c5ad16ce10a222f9 fedora/3/updates/x86_64/mozilla-chat-1.7.12-1.3.3.legacy.x86_64.rpm 1dc8b590ba623365a07c33c8a98c5d6eb7057486 fedora/3/updates/x86_64/mozilla-devel-1.7.12-1.3.3.legacy.x86_64.rpm abdf5d08629556a3335ad70eb565b65dbec226b3 fedora/3/updates/x86_64/mozilla-dom-inspector-1.7.12-1.3.3.legacy.x86_64.rpm 3489b08fbbe7dab2e913c6c79c24296bc0ac0078 fedora/3/updates/x86_64/mozilla-js-debugger-1.7.12-1.3.3.legacy.x86_64.rpm b544c2a6807963113eb2234ff3d846eb2c435661 fedora/3/updates/x86_64/mozilla-mail-1.7.12-1.3.3.legacy.x86_64.rpm 628cb7537726199cf5ecd459e7cbf2bb27acdca5 fedora/3/updates/x86_64/mozilla-nspr-1.7.12-1.3.3.legacy.i386.rpm 6cf873ef9085f915b38f2bc70f16adfcfa155bfd fedora/3/updates/x86_64/mozilla-nspr-1.7.12-1.3.3.legacy.x86_64.rpm 5eb2b843489853ea7d395502c492383557d1d7ce fedora/3/updates/x86_64/mozilla-nspr-devel-1.7.12-1.3.3.legacy.x86_64.rpm 6df7e4d99d0b5b0634eaf71816aff3a76308850c fedora/3/updates/x86_64/mozilla-nss-1.7.12-1.3.3.legacy.i386.rpm f7c34c932da9b4f65f134123ee8b86af16c7667d fedora/3/updates/x86_64/mozilla-nss-1.7.12-1.3.3.legacy.x86_64.rpm 5889b94be3ad690867bf59697b6d4704757d1402 fedora/3/updates/x86_64/mozilla-nss-devel-1.7.12-1.3.3.legacy.x86_64.rpm c4051d635668658df5f1ce4df69becc721fb752a fedora/3/updates/SRPMS/mozilla-1.7.12-1.3.3.legacy.src.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=CVE-2005-4134 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0292 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0296 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Fri Feb 24 00:11:28 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 23 Feb 2006 19:11:28 -0500 Subject: [FLSA-2006:180036-2] Updated firefox package fixes security issues Message-ID: <43FE4F30.4010607@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated firefox package fixes security issues Advisory ID: FLSA:180036-2 Issue date: 2006-02-23 Product: Fedora Core Keywords: Bugfix CVE Names: CVE-2005-4134 CVE-2006-0292 CVE-2006-0296 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: An updated firefox package that fixes several security bugs is now available. Mozilla Firefox is an open-source web browser, designed for standards compliance, performance and portability. 2. Relevant releases/architectures: Fedora Core 3 - i386, x86_64 3. Problem description: Igor Bukanov discovered a bug in the way Firefox's Javascript interpreter derefernces objects. If a user visits a malicious web page, Firefox could crash or execute arbitrary code as the user running Firefox. The Common Vulnerabilities and Exposures project assigned the name CVE-2006-0292 to this issue. moz_bug_r_a4 discovered a bug in Firefox's XULDocument.persist() function. A malicious web page could inject arbitrary RDF data into a user's localstore.rdf file, which can cause Firefox to execute arbitrary javascript when a user runs Firefox. (CVE-2006-0296) A denial of service bug was found in the way Firefox saves history information. If a user visits a web page with a very long title, it is possible Firefox will crash or take a very long time the next time it is run. (CVE-2005-4134) Users of Firefox are advised to upgrade to this updated package, which contains backported patches to 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/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180036 6. RPMs required: Fedora Core 3: SRPM: http://download.fedoralegacy.org/fedora/3/updates/SRPMS/firefox-1.0.7-1.3.fc3.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/3/updates/i386/firefox-1.0.7-1.3.fc3.legacy.i386.rpm x86_64: http://download.fedoralegacy.org/fedora/3/updates/x86_64/firefox-1.0.7-1.3.fc3.legacy.x86_64.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 3b05d93992aba7369a418d53344250aa275330ac fedora/3/updates/i386/firefox-1.0.7-1.3.fc3.legacy.i386.rpm 850534b4cfa591372d8245808e46378c5923e086 fedora/3/updates/x86_64/firefox-1.0.7-1.3.fc3.legacy.x86_64.rpm a167dc9061c484aa26f89703dc0228883409235e fedora/3/updates/SRPMS/firefox-1.0.7-1.3.fc3.legacy.src.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=CVE-2005-4134 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0292 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0296 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From d.terweij at nettuning.net Fri Feb 24 10:44:55 2006 From: d.terweij at nettuning.net (Danny Terweij - Net Tuning | Net) Date: Fri, 24 Feb 2006 11:44:55 +0100 Subject: Announces Message-ID: <07cb01c6392f$5a48e290$1e00a8c0@prvd321> At the legacy announce list i see only package update messages for Legacy Test. At the fedora announce list i only see for some time now only FC4 updated packages. Where do i see (mailing list) a list of the legacy FC3 new/updated announces? A mixed one is okay too with FC1/2/3 and up. Danny. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nils at lemonbit.nl Fri Feb 24 11:27:31 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Fri, 24 Feb 2006 12:27:31 +0100 Subject: Announces In-Reply-To: <07cb01c6392f$5a48e290$1e00a8c0@prvd321> References: <07cb01c6392f$5a48e290$1e00a8c0@prvd321> Message-ID: <4389C8E0-5342-42CE-BD37-29AE001BDFF4@lemonbit.nl> Danny Terweij wrote: > At the legacy announce list i see only package update messages for > Legacy Test. > At the fedora announce list i only see for some time now only FC4 > updated packages. > > Where do i see (mailing list) a list of the legacy FC3 new/updated > announces? > A mixed one is okay too with FC1/2/3 and up. You will see announces when they become available. A lot of packages still need QA and are therefor still in testing. If you could help doing QA (http://www.fedoraproject.org/wiki/Legacy/QATesting) they might be released sooner. :o) Nils Breunese. From d.terweij at nettuning.net Fri Feb 24 11:35:19 2006 From: d.terweij at nettuning.net (Danny Terweij - Net Tuning | Net) Date: Fri, 24 Feb 2006 12:35:19 +0100 Subject: Announces References: <07cb01c6392f$5a48e290$1e00a8c0@prvd321> <4389C8E0-5342-42CE-BD37-29AE001BDFF4@lemonbit.nl> Message-ID: <080e01c63936$6478bf90$1e00a8c0@prvd321> From: "Nils Breunese (Lemonbit Internet)" > > At the legacy announce list i see only package update messages for > > Legacy Test. > > At the fedora announce list i only see for some time now only FC4 > > updated packages. > > > > Where do i see (mailing list) a list of the legacy FC3 new/updated > > announces? > > A mixed one is okay too with FC1/2/3 and up. > > You will see announces when they become available. A lot of packages > still need QA and are therefor still in testing. If you could help > doing QA (http://www.fedoraproject.org/wiki/Legacy/QATesting) they > might be released sooner. :o) So where are the announces of : Update: mozilla.i386 37:1.7.12-1.3.3.legacy - legacy-updates Update: mozilla-nspr.i386 37:1.7.12-1.3.3.legacy - legacy-updates Update: mozilla-nss.i386 37:1.7.12-1.3.3.legacy - legacy-updates ?. Those and some others i did get today and dont see it on any anounce list i am subscribed to. As i see a lot FC4/5 talk on the many lists i am subscribed to. I guess FC123 talk go on this list right? Danny. From nils at lemonbit.nl Fri Feb 24 11:41:29 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Fri, 24 Feb 2006 12:41:29 +0100 Subject: Announces In-Reply-To: <080e01c63936$6478bf90$1e00a8c0@prvd321> References: <07cb01c6392f$5a48e290$1e00a8c0@prvd321> <4389C8E0-5342-42CE-BD37-29AE001BDFF4@lemonbit.nl> <080e01c63936$6478bf90$1e00a8c0@prvd321> Message-ID: Danny Terweij wrote: > So where are the announces of : > Update: mozilla.i386 37:1.7.12-1.3.3.legacy - legacy-updates > Update: mozilla-nspr.i386 37:1.7.12-1.3.3.legacy - legacy-updates > Update: mozilla-nss.i386 37:1.7.12-1.3.3.legacy - legacy-updates > > ?. Those and some others i did get today and dont see it on any > anounce list > i am subscribed to. I did get those announces... > As i see a lot FC4/5 talk on the many lists i am subscribed to. I > guess > FC123 talk go on this list right? Correct. Nils Breunese. From d.terweij at nettuning.net Fri Feb 24 13:59:43 2006 From: d.terweij at nettuning.net (Danny Terweij - Net Tuning | Net) Date: Fri, 24 Feb 2006 14:59:43 +0100 Subject: Announces References: <07cb01c6392f$5a48e290$1e00a8c0@prvd321> <4389C8E0-5342-42CE-BD37-29AE001BDFF4@lemonbit.nl> <080e01c63936$6478bf90$1e00a8c0@prvd321> Message-ID: <082901c6394a$906418c0$1e00a8c0@prvd321> From: "Nils Breunese (Lemonbit Internet)" > > Update: mozilla-nss.i386 37:1.7.12-1.3.3.legacy - legacy-updates > > ?. Those and some others i did get today and dont see it on any > > anounce list > > i am subscribed to. > I did get those announces... Could you say me on what list that is announced? maybe i missed a subscribtion :) On the QAtests wiki page i can't find how to enable test repo on yum. I have a "play" FC3 box with a lot repo's enabled (also mixed) and still yum updates fine with no deps problems :) However, i did found out that if you install a clean FC3 system with install option "server" and enable Xwindows GUI and add all those repo's, like kde redhat, dag, dries, atrpms, legacy and the standard ones, then its a hell for yum :) I am still try to fix all those deb errors by install by hand some packages then try yum update end see what error next is showing :-) Just a nice gamble game lol :) Danny From nils at lemonbit.nl Fri Feb 24 14:19:17 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Fri, 24 Feb 2006 15:19:17 +0100 Subject: Announces In-Reply-To: <082901c6394a$906418c0$1e00a8c0@prvd321> References: <07cb01c6392f$5a48e290$1e00a8c0@prvd321> <4389C8E0-5342-42CE-BD37-29AE001BDFF4@lemonbit.nl> <080e01c63936$6478bf90$1e00a8c0@prvd321> <082901c6394a$906418c0$1e00a8c0@prvd321> Message-ID: <5CAA9303-026F-4321-8B94-11A15335F560@lemonbit.nl> Danny Terweij wrote: > From: "Nils Breunese (Lemonbit Internet)" > >>> Update: mozilla-nss.i386 37:1.7.12-1.3.3.legacy - legacy-updates >>> ?. Those and some others i did get today and dont see it on any >>> anounce list >>> i am subscribed to. >> I did get those announces... > > Could you say me on what list that is announced? maybe i missed a > subscribtion :) See http://www.fedoralegacy.org/mail/ for the Fedora Legacy Mailinglists. There's an announce list there and you can browse the archives. > On the QAtests wiki page i can't find how to enable test repo on > yum. I > have a "play" FC3 box with a lot repo's enabled (also mixed) and > still yum > updates fine with no deps problems :) Did you add your own .repo file to /etc/yum.repos.d/ or did you add the info to /etc/yum.conf? Or did you download the rpm that installs the repo file? > However, i did found out that if you install a clean FC3 system > with install > option "server" and enable Xwindows GUI and add all those repo's, > like kde > redhat, dag, dries, atrpms, legacy and the standard ones, then its > a hell > for yum :) Some repositories don't mix well and mention that fact on their website. Don't just enable every repository you come across; see what it provides and whether you need that. Nils. From d.terweij at nettuning.net Fri Feb 24 14:59:40 2006 From: d.terweij at nettuning.net (Danny Terweij - Net Tuning | Net) Date: Fri, 24 Feb 2006 15:59:40 +0100 Subject: Announces References: <07cb01c6392f$5a48e290$1e00a8c0@prvd321><4389C8E0-5342-42CE-BD37-29AE001BDFF4@lemonbit.nl><080e01c63936$6478bf90$1e00a8c0@prvd321><082901c6394a$906418c0$1e00a8c0@prvd321> <5CAA9303-026F-4321-8B94-11A15335F560@lemonbit.nl> Message-ID: <086501c63952$f0c7b840$1e00a8c0@prvd321> From: "Nils Breunese (Lemonbit Internet)" > Did you add your own .repo file to /etc/yum.repos.d/ or did you add > the info to /etc/yum.conf? Or did you download the rpm that installs > the repo file? I add them manual as xxxx.repo at yum.repos.d > Some repositories don't mix well and mention that fact on their > website. Don't just enable every repository you come across; see what > it provides and whether you need that. Yes, i know that. But the software i run comes from all of them. And some repo's are faster with newest versions then other repos. Pitty that there is not 1 big repo :) I must say, the most active repo with fast and good updates is repo atrpms. But if you enable atrpms repo on FC3 system that is a fresh installation or a running some time box.. you see so much fro atrpm that you think.. holy moly i get a new Linux install :) It still works, what I want and what repo's offers for FC3. But i guess as readed on the wiki pages.. there comes a day for a mayor upgrade.. maybe FC7 is out then.. so FC3>FC7 will be happen some day :P But so long FC3 security patches and new software versions provides, i am happy :) Its that i am not lazy, i did install for example latest mysql5 on my play FC3 machine, and more builded from sources to see how it works and then do it the same on my other FC3 box(es).. Danny From jkeating at j2solutions.net Fri Feb 24 19:51:13 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 24 Feb 2006 11:51:13 -0800 Subject: Wiki news update person wanted Message-ID: <1140810673.28073.17.camel@ender> Hi all. I'm being queried if one of you would be willing to post at http://fedoraproject.org/wiki/Docs/Beats/Legacy to show whats been happening w/ our project. Stuff like package updates, infrastructure changes, etc... Anybody willing? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From nils at lemonbit.nl Fri Feb 24 20:08:07 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Fri, 24 Feb 2006 21:08:07 +0100 Subject: Announces In-Reply-To: <086501c63952$f0c7b840$1e00a8c0@prvd321> References: <07cb01c6392f$5a48e290$1e00a8c0@prvd321><4389C8E0-5342-42CE-BD37-29AE001BDFF4@lemonbit.nl><080e01c63936$6478bf90$1e00a8c0@prvd321><082901c6394a$906418c0$1e00a8c0@prvd321> <5CAA9303-026F-4321-8B94-11A15335F560@lemonbit.nl> <086501c63952$f0c7b840$1e00a8c0@prvd321> Message-ID: Danny Terweij wrote: > From: "Nils Breunese (Lemonbit Internet)" > >> Did you add your own .repo file to /etc/yum.repos.d/ or did you add >> the info to /etc/yum.conf? Or did you download the rpm that installs >> the repo file? > > I add them manual as xxxx.repo at yum.repos.d Add this to your .repo file: [updates-testing] name=Fedora Core $releasever - $basearch - Updates Testing baseurl=http://download.fedoralegacy.org/fedora/$releasever/updates- testing/$basearch gpgcheck=1 enabled=1 (Actually, you can just copy paste the info for updates en replace updates with updates-testing in the baseurl and change the name to your liking.) By the way, if you have Legacy Updates enabled in your yum config you don't need the normal Fedora updates channel anymore. All updates that were released before the transfer to Legacy are included in the Legacy version of the updates channel. > I must say, the most active repo with fast and good > updates is repo atrpms. But if you enable atrpms repo on FC3 system > that is > a fresh installation or a running some time box.. you see so much > fro atrpm > that you think.. holy moly i get a new Linux install :) That's why I've pretty much always avoided using ATrpms. But if you like it, that's great for you. Nils Breunese. From jkeating at j2solutions.net Fri Feb 24 20:17:38 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 24 Feb 2006 12:17:38 -0800 Subject: FC3 yum instructions In-Reply-To: References: <20060221142119.jpl2sxuize0o8o8s@mail.ph.utexas.edu> <1140554189.17286.115.camel@ender> <20060221145002.g0u662hkipswos4c@mail.ph.utexas.edu> <1140555764.17286.118.camel@ender> <20060221214955.rus1d0357csg8oco@mail.ph.utexas.edu> <1140590848.17286.157.camel@ender> <20060222105016.ja1cw9c7tvcwo0c4@mail.ph.utexas.edu> Message-ID: <1140812258.28073.25.camel@ender> On Thu, 2006-02-23 at 08:04 +0200, Pekka Savola wrote: > > The web site might need to have non-wiki content though, and that > should be realized as a requirement: for example, the FL advisories, > hopefully buglist*.html, and other similar more or less autogenerated > text. The autogeneration can generate wiki content and auto publish it there. Or we can have external links to external pages from within the wiki for the dynamic content. However these things should be discussed with the rest of the Fedora website team to keep a consistent look/feel throughout the rest of the Fedora sites. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From jkeating at j2solutions.net Fri Feb 24 20:19:04 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 24 Feb 2006 12:19:04 -0800 Subject: FC3 yum instructions In-Reply-To: <20060223103613.e1yfy0w8kwa888o8@mail.ph.utexas.edu> References: <20060221142119.jpl2sxuize0o8o8s@mail.ph.utexas.edu> <1140554189.17286.115.camel@ender> <20060221145002.g0u662hkipswos4c@mail.ph.utexas.edu> <1140555764.17286.118.camel@ender> <20060221214955.rus1d0357csg8oco@mail.ph.utexas.edu> <1140590848.17286.157.camel@ender> <20060222105016.ja1cw9c7tvcwo0c4@mail.ph.utexas.edu> <20060223103613.e1yfy0w8kwa888o8@mail.ph.utexas.edu> Message-ID: <1140812345.28073.27.camel@ender> On Thu, 2006-02-23 at 10:36 -0600, Eric Rostetter wrote: > > And perhaps more trusted data, like the security page which lists our > GPG KEYS and so on? I'd rather trust a restricted web server than a > fairly unrestricted wiki for things like key signatures, etc. Through the use of ACLs (Access Control Lists) any wiki page can be locked down very securely. Also more narrow control can be given to various parts of the wiki, like a top level Legacy page. The ACLs provide a very good balance between openess and security. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From jkeating at j2solutions.net Fri Feb 24 20:25:19 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 24 Feb 2006 12:25:19 -0800 Subject: Announces In-Reply-To: <086501c63952$f0c7b840$1e00a8c0@prvd321> References: <07cb01c6392f$5a48e290$1e00a8c0@prvd321> <4389C8E0-5342-42CE-BD37-29AE001BDFF4@lemonbit.nl> <080e01c63936$6478bf90$1e00a8c0@prvd321> <082901c6394a$906418c0$1e00a8c0@prvd321> <5CAA9303-026F-4321-8B94-11A15335F560@lemonbit.nl> <086501c63952$f0c7b840$1e00a8c0@prvd321> Message-ID: <1140812720.28073.30.camel@ender> On Fri, 2006-02-24 at 15:59 +0100, Danny Terweij - Net Tuning | Net wrote: > It still works, what I want and what repo's offers for FC3. But i guess as > readed on the wiki pages.. there comes a day for a mayor upgrade.. maybe FC7 > is out then.. so FC3>FC7 will be happen some day :P But so long FC3 security > patches and new software versions provides, i am happy :) Its that i am not > lazy, i did install for example latest mysql5 on my play FC3 machine, and > more builded from sources to see how it works and then do it the same on my > other FC3 box(es).. Please note that Legacy only works within the Fedora Core space. The packages we produce and test are tested against a pure Core system. You may run into complications by using these other systems and various upgraded by 3rd party versions of Core packages when using Legacy packages. Use at your own risk and if things break, you get to keep all the pieces. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Fri Feb 24 21:59:48 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 24 Feb 2006 22:59:48 +0100 Subject: Announces In-Reply-To: <1140812720.28073.30.camel@ender> References: <07cb01c6392f$5a48e290$1e00a8c0@prvd321> <4389C8E0-5342-42CE-BD37-29AE001BDFF4@lemonbit.nl> <080e01c63936$6478bf90$1e00a8c0@prvd321> <082901c6394a$906418c0$1e00a8c0@prvd321> <5CAA9303-026F-4321-8B94-11A15335F560@lemonbit.nl> <086501c63952$f0c7b840$1e00a8c0@prvd321> <1140812720.28073.30.camel@ender> Message-ID: <20060224215948.GN21359@neu.nirvana> On Fri, Feb 24, 2006 at 12:25:19PM -0800, Jesse Keating wrote: > On Fri, 2006-02-24 at 15:59 +0100, Danny Terweij - Net Tuning | Net wrote: > > It still works, what I want and what repo's offers for FC3. But i guess as > > readed on the wiki pages.. there comes a day for a mayor upgrade.. maybe FC7 > > is out then.. so FC3>FC7 will be happen some day :P But so long FC3 security > > patches and new software versions provides, i am happy :) Its that i am not > > lazy, i did install for example latest mysql5 on my play FC3 machine, and > > more builded from sources to see how it works and then do it the same on my > > other FC3 box(es).. > > Please note that Legacy only works within the Fedora Core space. That and the fact that FL tries to keep the legacy's system's API/ABI stable is already enough for ISVs/IHVs. Nothing more is needed for 3rd party support, that's one of FL's strengths. > The packages we produce and test are tested against a pure Core > system. You may run into complications by using these other systems > and various upgraded by 3rd party versions of Core packages when > using Legacy packages. Use at your own risk and if things break, > you get to keep all the pieces. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From marcdeslauriers at videotron.ca Sat Feb 25 14:57:37 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sat, 25 Feb 2006 09:57:37 -0500 Subject: [FLSA-2006:138098] Updated nfs-utils package fixes security issues Message-ID: <44007061.6070402@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated nfs-utils package fixes security issues Advisory ID: FLSA:138098 Issue date: 2006-02-25 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2004-0946 CVE-2004-1014 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: An updated nfs-utils package that fixes security issues is now available. The nfs-utils package provides a daemon for the kernel NFS server and related tools, providing a much higher level of performance than the traditional Linux NFS server used by most users. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 3. Problem description: Arjan van de Ven discovered a buffer overflow in rquotad. On 64-bit architectures, an improper integer conversion can lead to a buffer overflow. An attacker with access to an NFS share could send a specially crafted request which could lead to the execution of arbitrary code. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2004-0946 to this issue. In addition, the Fedora Core 2 update fixes the following issue: SGI reported that the statd daemon did not properly handle the SIGPIPE signal. A misconfigured or malicious peer could cause statd to crash, leading to a denial of service. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2004-1014 to this issue. All users of nfs-utils should upgrade to this updated package, which resolves 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/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138098 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/nfs-utils-0.3.3-6.73.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/nfs-utils-0.3.3-6.73.2.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/nfs-utils-1.0.1-3.9.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/nfs-utils-1.0.1-3.9.2.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/nfs-utils-1.0.6-1.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/nfs-utils-1.0.6-1.2.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/nfs-utils-1.0.6-22.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/nfs-utils-1.0.6-22.2.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- fc563f70e9f2b5eeafb51b9444469689185ef504 redhat/7.3/updates/i386/nfs-utils-0.3.3-6.73.2.legacy.i386.rpm 79dd718df766c23fc8ab4880a0e1557ca990c181 redhat/7.3/updates/SRPMS/nfs-utils-0.3.3-6.73.2.legacy.src.rpm 45c4f3a310d3090271f0d0798cae1e3148ab8299 redhat/9/updates/i386/nfs-utils-1.0.1-3.9.2.legacy.i386.rpm bf009c4fe075b7105316084c6ca577f15c5bdb52 redhat/9/updates/SRPMS/nfs-utils-1.0.1-3.9.2.legacy.src.rpm 1c96ae93420683ad79b675b205ecb5d6ddb61ef4 fedora/1/updates/i386/nfs-utils-1.0.6-1.2.legacy.i386.rpm 6d4ee9e13e8b3bf1278d59b48ccb0c48f7645f7f fedora/1/updates/SRPMS/nfs-utils-1.0.6-1.2.legacy.src.rpm 2063735e17273d7967c8fa1f3649ab86921c910e fedora/2/updates/i386/nfs-utils-1.0.6-22.2.legacy.i386.rpm dc3207c089204dd1c47653dc4918fe45b81a8654 fedora/2/updates/SRPMS/nfs-utils-1.0.6-22.2.legacy.src.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=CVE-2004-0946 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1014 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Sat Feb 25 14:58:20 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sat, 25 Feb 2006 09:58:20 -0500 Subject: [FLSA-2006:158543] Updated gaim package fixes security issues Message-ID: <4400708C.9090604@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated gaim package fixes security issues Advisory ID: FLSA:158543 Issue date: 2006-02-25 Products: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2005-0208 CVE-2005-0473 CVE-2005-0472 CVE-2005-0965 CVE-2005-0966 CVE-2005-0967 CVE-2005-1261 CVE-2005-1262 CVE-2005-2103 CVE-2005-2102 CVE-2005-2370 CVE-2005-1269 CVE-2005-1934 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: An updated gaim package that fixes various security issues as well as a number of bugs is now available. The Gaim application is a multi-protocol instant messaging client. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 3. Problem description: Two HTML parsing bugs were discovered in Gaim. It is possible that a remote attacker could send a specially crafted message to a Gaim client, causing it to crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CVE-2005-0208 and CVE-2005-0473 to these issues. A bug in the way Gaim processes SNAC packets was discovered. It is possible that a remote attacker could send a specially crafted SNAC packet to a Gaim client, causing the client to stop responding. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0472 to this issue. A buffer overflow bug was found in the way gaim escapes HTML. It is possible that a remote attacker could send a specially crafted message to a Gaim client, causing it to crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0965 to this issue. A bug was found in several of gaim's IRC processing functions. These functions fail to properly remove various markup tags within an IRC message. It is possible that a remote attacker could send a specially crafted message to a Gaim client connected to an IRC server, causing it to crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0966 to this issue. A bug was found in gaim's Jabber message parser. It is possible for a remote Jabber user to send a specially crafted message to a Gaim client, causing it to crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0967 to this issue. A stack based buffer overflow bug was found in the way gaim processes a message containing a URL. A remote attacker could send a carefully crafted message resulting in the execution of arbitrary code on a victim's machine. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-1261 to this issue. A bug was found in the way gaim handles malformed MSN messages. A remote attacker could send a carefully crafted MSN message causing gaim to crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-1262 to this issue. A heap based buffer overflow issue was discovered in the way Gaim processes away messages. A remote attacker could send a specially crafted away message to a Gaim user logged into AIM or ICQ that could result in arbitrary code execution. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-2103 to this issue. Daniel Atallah discovered a denial of service issue in Gaim. A remote attacker could attempt to upload a file with a specially crafted name to a user logged into AIM or ICQ, causing Gaim to crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-2102 to this issue. A denial of service bug was found in Gaim's Gadu Gadu protocol handler. A remote attacker could send a specially crafted message to a Gaim user logged into Gadu Gadu, causing Gaim to crash. Please note that this issue only affects PPC and IBM S/390 systems running Gaim. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-2370 to this issue. Jacopo Ottaviani discovered a bug in the way Gaim handles Yahoo! Messenger file transfers. It is possible for a malicious user to send a specially crafted file transfer request that causes Gaim to crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-1269 to this issue. Additionally, Hugo de Bokkenrijder discovered a bug in the way Gaim parses MSN Messenger messages. It is possible for a malicious user to send a specially crafted MSN Messenger message that causes Gaim to crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-1934 to this issue. Additionally, various client crashes, memory leaks, and protocol issues have been resolved. Users of Gaim are advised to upgrade to this updated package which contains Gaim version 1.5.0 and is not vulnerable to 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/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158543 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/gaim-1.5.0-0.73.1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/gaim-1.5.0-0.73.1.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/gaim-1.5.0-0.90.1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/gaim-1.5.0-0.90.1.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/gaim-1.5.0-1.fc1.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/gaim-1.5.0-1.fc1.1.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/gaim-1.5.0-1.fc2.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/gaim-1.5.0-1.fc2.1.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- a51c47a7e69e2ae0de301b5aea04a078a34bd494 redhat/7.3/updates/i386/gaim-1.5.0-0.73.1.legacy.i386.rpm cf664d6dea2391a620286c2a0558f344128dc09b redhat/7.3/updates/SRPMS/gaim-1.5.0-0.73.1.legacy.src.rpm 99901a3c55dc899071cd0373c71ce18b694e38d0 redhat/9/updates/i386/gaim-1.5.0-0.90.1.legacy.i386.rpm 47f2231f0085bfd8c24e3a01ae707781543bb243 redhat/9/updates/SRPMS/gaim-1.5.0-0.90.1.legacy.src.rpm fda20f97bf8c2ce8a5075c579bcbf6c3e3a66e81 fedora/1/updates/i386/gaim-1.5.0-1.fc1.1.legacy.i386.rpm 8be725ea3874e315278e4926ed72930c74a3d6df fedora/1/updates/SRPMS/gaim-1.5.0-1.fc1.1.legacy.src.rpm d8c6b98a019633a8a2debd6e2a86daccae6cdeda fedora/2/updates/i386/gaim-1.5.0-1.fc2.1.legacy.i386.rpm 46e6ff8101c40018ab98b7f3c5e01f656eb2cdfe fedora/2/updates/SRPMS/gaim-1.5.0-1.fc2.1.legacy.src.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=CVE-2005-0208 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0473 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0472 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0965 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0966 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0967 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1261 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1262 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2103 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2102 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2370 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1269 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1934 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Sat Feb 25 14:59:04 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sat, 25 Feb 2006 09:59:04 -0500 Subject: [FLSA-2006:176731] Updated perl packages fix security issue Message-ID: <440070B8.8090105@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated perl packages fix security issue Advisory ID: FLSA:176731 Issue date: 2006-02-25 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2005-3962 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated perl packages that fix a security flaw are now available. Perl is a high-level programming language commonly used for system administration utilities and Web programming. 2. Relevant releases/architectures: Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 3. Problem description: An integer overflow bug was found in Perl's format string processor. It is possible for an attacker to cause perl to crash or execute arbitrary code if the attacker is able to process a malicious format string. This issue is only exploitable through a script which passes arbitrary untrusted strings to the format string processor. The Common Vulnerabilities and Exposures project assigned the name CVE-2005-3962 to this issue. Note that this vulnerability do not affect perl packages in Red Hat Linux 7.3 Users of perl are advised to upgrade to these packages which contain a backported patch and are not vulnerable to 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: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176731 6. RPMs required: Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/perl-5.8.0-90.0.13.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/perl-5.8.0-90.0.13.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/perl-CGI-2.81-90.0.13.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/perl-CPAN-1.61-90.0.13.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/perl-DB_File-1.804-90.0.13.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/perl-suidperl-5.8.0-90.0.13.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/perl-5.8.3-17.5.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/perl-5.8.3-17.5.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/perl-suidperl-5.8.3-17.5.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/perl-5.8.3-19.5.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/perl-5.8.3-19.5.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/perl-suidperl-5.8.3-19.5.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 4d2401a09f2cc0b126df88659bd9e259a528146d redhat/9/updates/i386/perl-5.8.0-90.0.13.legacy.i386.rpm 3b5448a2a8d8241a85c4c54ad5d5deb4b9d466d4 redhat/9/updates/i386/perl-CGI-2.81-90.0.13.legacy.i386.rpm 40a05fcf3a7d128e7fa79b00022d54d0542bd3af redhat/9/updates/i386/perl-CPAN-1.61-90.0.13.legacy.i386.rpm 5444ce68de7e8f0b1b051a15a1658c7d497be61b redhat/9/updates/i386/perl-DB_File-1.804-90.0.13.legacy.i386.rpm 76ff3cdbe78a2e7c92c1f95760906fd396f974bf redhat/9/updates/i386/perl-suidperl-5.8.0-90.0.13.legacy.i386.rpm 62fbcae6dd839fd18aabcf5c9fcc6babfd844d94 redhat/9/updates/SRPMS/perl-5.8.0-90.0.13.legacy.src.rpm 3267a9d83ac3cadcfa650b1625cf5c458adb5540 fedora/1/updates/i386/perl-5.8.3-17.5.legacy.i386.rpm 2445d66c7ced8bccc7d875a21404216a0cd5cdb6 fedora/1/updates/i386/perl-suidperl-5.8.3-17.5.legacy.i386.rpm 297a649694e03e67b13cfbac7ae8211554cea44b fedora/1/updates/SRPMS/perl-5.8.3-17.5.legacy.src.rpm 772f9571df3a0eab7749bb0d162311f4cd539879 fedora/2/updates/i386/perl-5.8.3-19.5.legacy.i386.rpm 83cf2b36b48760eb1f99a042214eead7a9650d38 fedora/2/updates/i386/perl-suidperl-5.8.3-19.5.legacy.i386.rpm 260cf2c8b759afe09f205318e1fd78cabdeefcb0 fedora/2/updates/SRPMS/perl-5.8.3-19.5.legacy.src.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=CVE-2005-3962 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From deisenst at gtw.net Sun Feb 26 10:20:26 2006 From: deisenst at gtw.net (David Eisenstein) Date: Sun, 26 Feb 2006 04:20:26 -0600 (CST) Subject: Discussion of content, security Re: FC3 yum instructions In-Reply-To: <20060221142119.jpl2sxuize0o8o8s@mail.ph.utexas.edu> Message-ID: On Tue, 21 Feb 2006, Eric Rostetter wrote: > I've added the following to the web site: > > http://www.fedoralegacy.org/docs/yum-fc3.php > > and would appreciate testing, feedback, etc. Thanks! Hey Eric, I think you have done a wonderful job with this web-page. The instruc- tions are clear, concise, easy-to-read and understand, even by a Linux novice, and seem to cover all of the technical points necessary for a Fedora Core 3 user to get his/her system(s) to use YUM to continue keeping his/her system up-to-date with Fedora Legacy updates, and to do so securely. It is also well-formatted and looks professional. Good job! STEP 2 AND STEP 1.4 I am wondering ... it seems to me that we included code in the RPM "legacy-yumconf-3-4.fc3.noarch.rpm" that includes and automatically installs the Fedora Legacy GPG key when this RPM package is installed. Can someone confirm or deny that? If so, then "Step 2: Configure yum for Fedora Legacy" already takes care of the work that Step 1.4 asks the user to do. HOWEVER, as the legacy-yumconf RPM file itself is signed by the Fedora Legacy key, the "rpm -Uvh" step in step 2 would be downloading and installing the legacy-yumconf package without the benefit of the Legacy GPG key to check to make sure it is not tampered with. So it seems to me that Step 1.4 isn't necessarily a duplication of effort, as it verifies that the legacy-yumconf package installed in Step 2 is signed with the key installed in Step 1.4. It seems a little more secure to go ahead and let users *do* step 1.4, and if they're lazy and don't want to do it, it gets done for them anyway. SO, is my interpretation correct? Do we need to ask the user still to do Step 1.4 if Step 2 takes care of it? Considering the warning the user may get in Step 2 if Legacy's key isn't already installed -- ("warning: legacy-yumconf-3-4.fc3.noarch.rpm: V3 DSA signature: NOKEY, key ID 731002fa") -- would that be confusing enough to warrant keeping Step 1.4 there and asking the user to do it? If we removed Step 1.4, would we introduce some kind of risk to the user -- say, if a Fedora Legacy downloading site or mirror were to be compromised by some attacker, who might put in his/her own legacy-yumconf package and install a gpg key of his/her choice? By the way, the legacy-yumconf rpm the user installs not only updates this user's YUM configuration, it also updates the user's up2date configuration as well, if the user is inclined to use the up2date tool, and the RHN desktop icon (I believe). (Please correct me if I am wrong.) Do we need updated up2date documentation for Fedora Core 3? Core 2 as well? STEP 7 Was thinking that maybe a little more information about how to get more detailed knowledge about yum would be appropriate here. Something like, "For more information about these yum commands and other yum abilities, do 'man yum' or go to website." What do you think? Warm regards, David Eisenstein From nils at lemonbit.nl Sun Feb 26 10:42:35 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Sun, 26 Feb 2006 11:42:35 +0100 Subject: Discussion of content, security Re: FC3 yum instructions In-Reply-To: References: Message-ID: <593BD398-DB24-4340-B4D0-431F9790CF34@lemonbit.nl> David Eisenstein wrote: > STEP 2 AND STEP 1.4 > > I am wondering ... it seems to me that we included code in the RPM > "legacy-yumconf-3-4.fc3.noarch.rpm" that includes and automatically > installs the Fedora Legacy GPG key when this RPM package is installed. > Can someone confirm or deny that? If so, then "Step 2: Configure > yum for > Fedora Legacy" already takes care of the work that Step 1.4 asks > the user > to do. > > HOWEVER, as the legacy-yumconf RPM file itself is signed by the Fedora > Legacy key, the "rpm -Uvh" step in step 2 would be downloading and > installing the legacy-yumconf package without the benefit of the > Legacy > GPG key to check to make sure it is not tampered with. So it seems > to me > that Step 1.4 isn't necessarily a duplication of effort, as it > verifies > that the legacy-yumconf package installed in Step 2 is signed with the > key installed in Step 1.4. > > It seems a little more secure to go ahead and let users *do* step > 1.4, and > if they're lazy and don't want to do it, it gets done for them anyway. > > SO, is my interpretation correct? Do we need to ask the user still > to do > Step 1.4 if Step 2 takes care of it? Considering the warning the > user may > get in Step 2 if Legacy's key isn't already installed -- > ("warning: legacy-yumconf-3-4.fc3.noarch.rpm: V3 DSA signature: > NOKEY, > key ID 731002fa") > > -- would that be confusing enough to warrant keeping Step 1.4 there > and > asking the user to do it? If we removed Step 1.4, would we > introduce some > kind of risk to the user -- say, if a Fedora Legacy downloading > site or > mirror were to be compromised by some attacker, who might put in > his/her > own legacy-yumconf package and install a gpg key of his/her choice? Would it be possible to get legacy-yumconf signed with the regulat (non-legacy) FC3 key? Nils. From marcdeslauriers at videotron.ca Sun Feb 26 16:11:55 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sun, 26 Feb 2006 11:11:55 -0500 Subject: Fedora Legacy Test Update Notification: pcre Message-ID: <4401D34B.3050302@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-168516 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168516 2006-02-26 --------------------------------------------------------------------- Name : pcre Versions : rh73: pcre-3.9-2.1.legacy Versions : rh9: pcre-3.9-10.1.legacy Versions : fc1: pcre-4.4-1.2.legacy Versions : fc2: pcre-4.5-2.2.legacy Summary : Perl-compatible regular expression library. Description : Perl-compatible regular expression library. PCRE has its own native API, but a set of "wrapper" functions that are based on the POSIX API are also supplied in the library libpcreposix. Note that this just provides a POSIX calling interface to PCRE; the regular expressions themselves still follow Perl syntax and semantics. The header file for the POSIX-style functions is called pcreposix.h. --------------------------------------------------------------------- Update Information: Updated pcre packages are now available to correct a security issue. PCRE is a Perl-compatible regular expression library. An integer overflow flaw was found in PCRE, triggered by a maliciously crafted regular expression. On systems that accept arbitrary regular expressions from untrusted users, this could be exploited to execute arbitrary code with the privileges of the application using the library. The Common Vulnerabilities and Exposures project assigned the name CVE-2005-2491 to this issue. Users should update to these erratum packages that contain a backported patch to correct this issue. --------------------------------------------------------------------- Changelogs rh73: * Fri Oct 28 2005 Leonard den Ottolander 3.9-2.1.legacy - Fix CAN-2005-2491 rh9: * Sun Feb 19 2006 Marc Deslauriers 3.9-10.1.legacy - Added patch for CVE-2005-2491 fc1: * Sat Feb 25 2006 Marc Deslauriers 4.4-1.2.legacy - Added pcre-devel to BuildPrereq * Sun Feb 19 2006 Marc Deslauriers 4.4-1.1.legacy - Added patch for CVE-2005-2491 fc2: * Sat Feb 25 2006 Marc Deslauriers 4.5-2.2.legacy - Added pcre-devel to BuildPrereq * Mon Feb 20 2006 Marc Deslauriers 4.5-2.1.legacy - Added patch for CVE-2005-2491 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 9b641aa989639c706065bafc146d34bb6e282a22 redhat/7.3/updates-testing/i386/pcre-3.9-2.1.legacy.i386.rpm 7d8b094083c7a85991d194d6741a0a664204a19d redhat/7.3/updates-testing/i386/pcre-devel-3.9-2.1.legacy.i386.rpm 9a49145385042483532254fb5d05fae6c3f252f3 redhat/7.3/updates-testing/SRPMS/pcre-3.9-2.1.legacy.src.rpm rh9: d876a7f4cdb3a936b2f72fb629fae928d3db6e96 redhat/9/updates-testing/i386/pcre-3.9-10.1.legacy.i386.rpm 9e516b5e44944b25a47171b15c0229423b10f99d redhat/9/updates-testing/i386/pcre-devel-3.9-10.1.legacy.i386.rpm 55de51292b97aacbad6c375b4ad8578561ac5fe3 redhat/9/updates-testing/SRPMS/pcre-3.9-10.1.legacy.src.rpm fc1: 4edc206f1e0fc0c3df459b6f8de289f27417974b fedora/1/updates-testing/i386/pcre-4.4-1.2.legacy.i386.rpm 0fcc5801dc238bb1fac0d59b8403e6cdcc72f126 fedora/1/updates-testing/i386/pcre-devel-4.4-1.2.legacy.i386.rpm 57b3a2c5c2bb3435d3c7971daf29c665fb2c1687 fedora/1/updates-testing/SRPMS/pcre-4.4-1.2.legacy.src.rpm fc2: bff4b330e8c9a76262020c7ddb2b48f71bf01788 fedora/2/updates-testing/i386/pcre-4.5-2.2.legacy.i386.rpm 8354926500e18905dd94dddc1e6bf44cd236df68 fedora/2/updates-testing/i386/pcre-devel-4.5-2.2.legacy.i386.rpm 9f43e7d484412d93734dfe4b08f87d2ef133100a fedora/2/updates-testing/SRPMS/pcre-4.5-2.2.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Sun Feb 26 16:12:19 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sun, 26 Feb 2006 11:12:19 -0500 Subject: Fedora Legacy Test Update Notification: xpdf Message-ID: <4401D363.5030108@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-175404 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175404 2006-02-26 --------------------------------------------------------------------- Name : xpdf Versions : rh73: xpdf-1.00-7.6.legacy Versions : rh9: xpdf-2.01-11.4.legacy Versions : fc1: xpdf-2.03-1.4.legacy Versions : fc2: xpdf-3.00-3.8.1.legacy Versions : fc3: xpdf-3.01-0.FC3.5.legacy Summary : A PDF file viewer for the X Window System. Description : Xpdf is an X Window System based viewer for Portable Document Format (PDF) files. Xpdf is a small and efficient program which uses standard X fonts. --------------------------------------------------------------------- Update Information: An updated xpdf package that fixes several security issues is now available. The xpdf package is an X Window System-based viewer for Portable Document Format (PDF) files. A flaw was discovered in Xpdf in that an attacker could construct a carefully crafted PDF file that would cause Xpdf to consume all available disk space in /tmp when opened. The Common Vulnerabilities and Exposures project assigned the name CVE-2005-2097 to this issue. Several flaws were discovered in Xpdf. An attacker could construct a carefully crafted PDF file that could cause Xpdf to crash or possibly execute arbitrary code when opened. The Common Vulnerabilities and Exposures project assigned the names CVE-2005-3191, CVE-2005-3192, CVE-2005-3193, CVE-2005-3624, CVE-2005-3625, CVE-2005-3626, CVE-2005-3627 and CVE-2005-3628 to these issues. A heap based buffer overflow bug was discovered in Xpdf. An attacker could construct a carefully crafted PDF file that could cause Xpdf to crash or possibly execute arbitrary code when opened. The Common Vulnerabilities and Exposures project assigned the name CVE-2006-0301 to this issue. Users of Xpdf should upgrade to this updated package, which contains backported patches to resolve these issues. --------------------------------------------------------------------- Changelogs rh73: * Mon Feb 20 2006 Marc Deslauriers 1.00-7.6.legacy - Added better patch for CVE-2004-0888 * Sun Feb 19 2006 Marc Deslauriers 1.00-7.5.legacy - Added patch for CVE-2005-3193 rh9: * Sun Feb 19 2006 Marc Deslauriers 2.01-11.4.legacy - Added better patch for CVE-2004-0888 - Added patch for CVE-2005-3193 fc1: * Sun Feb 19 2006 Marc Deslauriers 1:2.03-1.4.legacy - Added better patch for CVE-2004-0888 - Added patch for CVE-2005-3193 fc2: * Sun Feb 19 2006 Marc Deslauriers 1:3.00-3.8.1.legacy - Apply patches for CVE-2005-2097, CVE-2005-3193, CVE-2006-0301 fc3: * Sat Feb 18 2006 Marc Deslauriers 1:3.01-0.FC3.5.legacy - Added patch for CVE-2006-0301 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 6096aa2b487e635ae3003cf246ec66d53dc81d41 redhat/7.3/updates-testing/i386/xpdf-1.00-7.6.legacy.i386.rpm e670899dd04a31d466d0ba2cc213763157a3b101 redhat/7.3/updates-testing/i386/xpdf-chinese-simplified-1.00-7.6.legacy.i386.rpm c636a2b79eb22afe35993466675e9fdd086a84f2 redhat/7.3/updates-testing/i386/xpdf-chinese-traditional-1.00-7.6.legacy.i386.rpm 9a2bfe9e373cd20422a862f48d3d6ad787b7f0f1 redhat/7.3/updates-testing/i386/xpdf-japanese-1.00-7.6.legacy.i386.rpm bc47f11dea342606e74aff1a55cf74bd52783b60 redhat/7.3/updates-testing/i386/xpdf-korean-1.00-7.6.legacy.i386.rpm ace7a51b625269d9f5bd3355b07a842f0e1426f4 redhat/7.3/updates-testing/SRPMS/xpdf-1.00-7.6.legacy.src.rpm rh9: 4fe0714cdf2194cf0426e15210cbe509d77b2788 redhat/9/updates-testing/i386/xpdf-2.01-11.4.legacy.i386.rpm c54fad904f475d693c781632dbadfae9434e4c87 redhat/9/updates-testing/i386/xpdf-chinese-simplified-2.01-11.4.legacy.i386.rpm 1b6f0cf3f309515fd60b88576a1168f9d9bc7fe0 redhat/9/updates-testing/i386/xpdf-chinese-traditional-2.01-11.4.legacy.i386.rpm accef6df9ed9b1cee0e05fffa7e7dde085ae3f35 redhat/9/updates-testing/i386/xpdf-japanese-2.01-11.4.legacy.i386.rpm 69a7ae59cb1ddb5b422eccdec53711f459939c3f redhat/9/updates-testing/i386/xpdf-korean-2.01-11.4.legacy.i386.rpm 090ddacf36dc0180c16cef8526aedc9bb9c5225c redhat/9/updates-testing/SRPMS/xpdf-2.01-11.4.legacy.src.rpm fc1: 0349626a79f659adc0590938b99a6097f6898f10 fedora/1/updates-testing/i386/xpdf-2.03-1.4.legacy.i386.rpm 8612ba60a89cfb0ef195450d1c927487b868deec fedora/1/updates-testing/SRPMS/xpdf-2.03-1.4.legacy.src.rpm fc2: f60fc20854386ef91f6769aabd29f3a77e29084d fedora/2/updates-testing/i386/xpdf-3.00-3.8.1.legacy.i386.rpm 64139c039afc0af67eadcc8c87e03aed6c6254d0 fedora/2/updates-testing/SRPMS/xpdf-3.00-3.8.1.legacy.src.rpm fc3: 268cba4fb5fd62699595cdeed78375f324c874f6 fedora/3/updates-testing/i386/xpdf-3.01-0.FC3.5.legacy.i386.rpm 021ec4bb4d86192a519261b3073a3d348e4fa14a fedora/3/updates-testing/x86_64/xpdf-3.01-0.FC3.5.legacy.x86_64.rpm 3e139055107af9057062154add60191331765e43 fedora/3/updates-testing/SRPMS/xpdf-3.01-0.FC3.5.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Sun Feb 26 16:12:39 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sun, 26 Feb 2006 11:12:39 -0500 Subject: Fedora Legacy Test Update Notification: udev Message-ID: <4401D377.5000105@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-175818 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175818 2006-02-26 --------------------------------------------------------------------- Name : udev Versions : fc2: udev-024-6.2.legacy Versions : fc3: udev-039-10.FC3.9.legacy Summary : A userspace implementation of devfs Description : udev is a implementation of devfs in userspace using sysfs and /sbin/hotplug. It requires a 2.6 kernel to run properly. --------------------------------------------------------------------- Update Information: Updated udev packages that fix a security issue are now available. The udev package contains an implementation of devfs in userspace using sysfs and /sbin/hotplug. Richard Cunningham discovered a flaw in the way udev sets permissions on various files in /dev/input. It may be possible for an authenticated attacker to gather sensitive data entered by a user at the console, such as passwords. The Common Vulnerabilities and Exposures project has assigned the name CVE-2005-3631 to this issue. All users of udev should upgrade to these updated packages, which contain a backported patch and are not vulnerable to this issue. --------------------------------------------------------------------- Changelogs fc2: * Sun Feb 26 2006 Marc Deslauriers 024-6.2.legacy - Added missing glib2-devel to BuildRequires * Sun Feb 19 2006 Marc Deslauriers 024-6.1.legacy - Changed permissions for input to fix CVE-2005-3631 fc3: * Sun Feb 19 2006 Marc Deslauriers - 039-10.FC3.9.legacy - Change input permissions to fix CVE-2005-3631 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) fc2: d2b2850b4066a595a4d3c162e151dc27c5b43198 fedora/2/updates-testing/i386/udev-024-6.2.legacy.i386.rpm 9ed5ef68d64987f8f644da065399d6885e7e1176 fedora/2/updates-testing/SRPMS/udev-024-6.2.legacy.src.rpm fc3: a2682a89f6fe03c2f2c2401caa511c299c1ae1cc fedora/3/updates-testing/i386/udev-039-10.FC3.9.legacy.i386.rpm fbcf92e15337b34511d4a305100d6797d644a84e fedora/3/updates-testing/x86_64/udev-039-10.FC3.9.legacy.x86_64.rpm fe4e15a6ac3d4d80ce3db01f08a75c93985964e8 fedora/3/updates-testing/SRPMS/udev-039-10.FC3.9.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Tue Feb 28 00:55:48 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 27 Feb 2006 19:55:48 -0500 Subject: [FLSA-2006:157366] Updated PostgreSQL packages fix security issues Message-ID: <44039F94.701@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated PostgreSQL packages fix security issues Advisory ID: FLSA:157366 Issue date: 2006-02-27 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2005-1409 CVE-2005-1410 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated postgresql packages that fix several security vulnerabilities and risks of data loss are now available. PostgreSQL is an advanced Object-Relational database management system (DBMS) that supports almost all SQL constructs (including transactions, subselects and user-defined types and functions). 2. Relevant releases/architectures: Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 3. Problem description: The PostgreSQL community discovered two distinct errors in initial system catalog entries that could allow authorized database users to crash the database and possibly escalate their privileges. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CVE-2005-1409 and CVE-2005-1410 to these issues. Although installing this update will protect new (freshly initdb'd) database installations from these errors, administrators MUST TAKE MANUAL ACTION to repair the errors in pre-existing databases. The appropriate procedures are explained at http://www.postgresql.org/docs/8.0/static/release-7-4-8.html for Fedora Core 2 users, or http://www.postgresql.org/docs/8.0/static/release-7-3-10.html for Fedora Core 1 and Red Hat Linux 9 users. This update also includes fixes for several other errors, including two race conditions that could result in apparent data inconsistency or actual data loss. All users of PostgreSQL are advised to upgrade to these updated packages and to apply the recommended manual corrections to existing databases. 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: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157366 6. RPMs required: Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/postgresql-7.3.10-0.90.1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/postgresql-7.3.10-0.90.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/postgresql-contrib-7.3.10-0.90.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/postgresql-devel-7.3.10-0.90.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/postgresql-docs-7.3.10-0.90.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/postgresql-jdbc-7.3.10-0.90.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/postgresql-libs-7.3.10-0.90.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/postgresql-pl-7.3.10-0.90.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/postgresql-python-7.3.10-0.90.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/postgresql-server-7.3.10-0.90.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/postgresql-tcl-7.3.10-0.90.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/postgresql-test-7.3.10-0.90.1.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/postgresql-7.3.10-1.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/postgresql-7.3.10-1.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/postgresql-contrib-7.3.10-1.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/postgresql-devel-7.3.10-1.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/postgresql-docs-7.3.10-1.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/postgresql-jdbc-7.3.10-1.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/postgresql-libs-7.3.10-1.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/postgresql-pl-7.3.10-1.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/postgresql-python-7.3.10-1.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/postgresql-server-7.3.10-1.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/postgresql-tcl-7.3.10-1.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/postgresql-test-7.3.10-1.1.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/postgresql-7.4.8-1.FC2.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/postgresql-7.4.8-1.FC2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/postgresql-contrib-7.4.8-1.FC2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/postgresql-devel-7.4.8-1.FC2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/postgresql-docs-7.4.8-1.FC2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/postgresql-jdbc-7.4.8-1.FC2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/postgresql-libs-7.4.8-1.FC2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/postgresql-pl-7.4.8-1.FC2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/postgresql-python-7.4.8-1.FC2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/postgresql-server-7.4.8-1.FC2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/postgresql-tcl-7.4.8-1.FC2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/postgresql-test-7.4.8-1.FC2.1.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 88bf97be3530effdf1c7c3a779bfe7f80e7ea6be redhat/9/updates/i386/postgresql-7.3.10-0.90.1.legacy.i386.rpm 6130777335db38d64a44d52106353cd76154ca23 redhat/9/updates/i386/postgresql-contrib-7.3.10-0.90.1.legacy.i386.rpm 4bce5f9e6e80edb944a7aa24839f34c609c44c99 redhat/9/updates/i386/postgresql-devel-7.3.10-0.90.1.legacy.i386.rpm f6d7a63730df0a33b4f7582077472bf8cecc0f4e redhat/9/updates/i386/postgresql-docs-7.3.10-0.90.1.legacy.i386.rpm 3f76bb95ef0ce2da9b6a58993cdf7a1000e33019 redhat/9/updates/i386/postgresql-jdbc-7.3.10-0.90.1.legacy.i386.rpm a7a9187c41f2820ca9c2d2364f63859d33d21044 redhat/9/updates/i386/postgresql-libs-7.3.10-0.90.1.legacy.i386.rpm 0d0e4d4e566583111f30f4c06f255daeaf9bbd49 redhat/9/updates/i386/postgresql-pl-7.3.10-0.90.1.legacy.i386.rpm def9d9581141c219e013a875146c75b65af67e91 redhat/9/updates/i386/postgresql-python-7.3.10-0.90.1.legacy.i386.rpm 43590dabe9601ddbefbc6d9086c9b7dfb363acaa redhat/9/updates/i386/postgresql-server-7.3.10-0.90.1.legacy.i386.rpm e4769b82d862178d6d395f52ebcbd56a75e36e71 redhat/9/updates/i386/postgresql-tcl-7.3.10-0.90.1.legacy.i386.rpm fbd07e5eaad5e4ee5bd1b30e02001a043331daff redhat/9/updates/i386/postgresql-test-7.3.10-0.90.1.legacy.i386.rpm 57fc00132f9d66263729566666fd1eba3d7a9d2f redhat/9/updates/SRPMS/postgresql-7.3.10-0.90.1.legacy.src.rpm de59e42459e24cd8846fbd6d765bc892d621a0dc fedora/1/updates/i386/postgresql-7.3.10-1.1.legacy.i386.rpm 88abba3e24f01c6189be15b6481d77b135b6191c fedora/1/updates/i386/postgresql-contrib-7.3.10-1.1.legacy.i386.rpm 39a6163dffc299ba088f8f71c0393fca08648ae9 fedora/1/updates/i386/postgresql-devel-7.3.10-1.1.legacy.i386.rpm 0ac78a44e03f5b31113b7b110d35472aded5ecbd fedora/1/updates/i386/postgresql-docs-7.3.10-1.1.legacy.i386.rpm e8a17936599c1c2aa7a26056ee3449e43a460d07 fedora/1/updates/i386/postgresql-jdbc-7.3.10-1.1.legacy.i386.rpm 421fc09afacbeb0e6773a8c2c1dd2ebb45406fd9 fedora/1/updates/i386/postgresql-libs-7.3.10-1.1.legacy.i386.rpm f79b142305ab70af54594478e248830edfdb8247 fedora/1/updates/i386/postgresql-pl-7.3.10-1.1.legacy.i386.rpm ab86d2fbf57b470934131cb78916117fdf177a4d fedora/1/updates/i386/postgresql-python-7.3.10-1.1.legacy.i386.rpm 71c2abb0a89a19fa88eaa3a22048062ea4d938f3 fedora/1/updates/i386/postgresql-server-7.3.10-1.1.legacy.i386.rpm 92e2b78d179c4aa378875b6ab42c488cad6b44c7 fedora/1/updates/i386/postgresql-tcl-7.3.10-1.1.legacy.i386.rpm 44a3837dd2f7ae68790637be50fe1f29b8d86814 fedora/1/updates/i386/postgresql-test-7.3.10-1.1.legacy.i386.rpm de79d4182b566ec3c4a623cd26c51af2e8938ffb fedora/1/updates/SRPMS/postgresql-7.3.10-1.1.legacy.src.rpm 0046d088278b0c08740222a41ca511d0c0fa3d99 fedora/2/updates/i386/postgresql-7.4.8-1.FC2.1.legacy.i386.rpm 184dd4304908b60a216f3be9f0756fde449c729e fedora/2/updates/i386/postgresql-contrib-7.4.8-1.FC2.1.legacy.i386.rpm 8ae68e66295eddb1936c31fe15cf95662db4b345 fedora/2/updates/i386/postgresql-devel-7.4.8-1.FC2.1.legacy.i386.rpm 7e547b6ee8c0e1b06bc803aa45086971158ced10 fedora/2/updates/i386/postgresql-docs-7.4.8-1.FC2.1.legacy.i386.rpm 646cba1375fa3548aff2a791035f5eacb7927869 fedora/2/updates/i386/postgresql-jdbc-7.4.8-1.FC2.1.legacy.i386.rpm 642feb043c19a5584f60ef45713bf8249c689216 fedora/2/updates/i386/postgresql-libs-7.4.8-1.FC2.1.legacy.i386.rpm 6955df9f381e1683d1d79aa779f5f295e74e2b68 fedora/2/updates/i386/postgresql-pl-7.4.8-1.FC2.1.legacy.i386.rpm 99b1ee5e4c26370d39e52437c10bb9cdcbc5d273 fedora/2/updates/i386/postgresql-python-7.4.8-1.FC2.1.legacy.i386.rpm 167fb15d6f300bd4aaf8a0b080dfa42136ee9f1c fedora/2/updates/i386/postgresql-server-7.4.8-1.FC2.1.legacy.i386.rpm 62f4e5798b3179a49cbe8c515343a0db4687834b fedora/2/updates/i386/postgresql-tcl-7.4.8-1.FC2.1.legacy.i386.rpm 1c8feebe8cf8d2ef07cb004b10cd4cf69e654989 fedora/2/updates/i386/postgresql-test-7.4.8-1.FC2.1.legacy.i386.rpm c2b44a61fdbf644cecccb3edcf78a80dbda9cfa4 fedora/2/updates/SRPMS/postgresql-7.4.8-1.FC2.1.legacy.src.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=CVE-2005-1409 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1410 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Tue Feb 28 00:56:31 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 27 Feb 2006 19:56:31 -0500 Subject: [FLSA-2006:175818] Updated udev packages fix a security issue Message-ID: <44039FBF.5090405@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated udev packages fix a security issue Advisory ID: FLSA:175818 Issue date: 2006-02-27 Product: Fedora Core Keywords: Bugfix CVE Names: CVE-2005-3631 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated udev packages that fix a security issue are now available. The udev package contains an implementation of devfs in userspace using sysfs and /sbin/hotplug. 2. Relevant releases/architectures: Fedora Core 2 - i386 Fedora Core 3 - i386, x86_64 3. Problem description: Richard Cunningham discovered a flaw in the way udev sets permissions on various files in /dev/input. It may be possible for an authenticated attacker to gather sensitive data entered by a user at the console, such as passwords. The Common Vulnerabilities and Exposures project has assigned the name CVE-2005-3631 to this issue. All users of udev should upgrade to these updated packages, which contain a backported patch and are not vulnerable to 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: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175818 6. RPMs required: Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/udev-024-6.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/udev-024-6.2.legacy.i386.rpm Fedora Core 3: SRPM: http://download.fedoralegacy.org/fedora/3/updates/SRPMS/udev-039-10.FC3.9.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/3/updates/i386/udev-039-10.FC3.9.legacy.i386.rpm x86_64: http://download.fedoralegacy.org/fedora/3/updates/x86_64/udev-039-10.FC3.9.legacy.x86_64.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- d2b2850b4066a595a4d3c162e151dc27c5b43198 fedora/2/updates/i386/udev-024-6.2.legacy.i386.rpm 9ed5ef68d64987f8f644da065399d6885e7e1176 fedora/2/updates/SRPMS/udev-024-6.2.legacy.src.rpm a2682a89f6fe03c2f2c2401caa511c299c1ae1cc fedora/3/updates/i386/udev-039-10.FC3.9.legacy.i386.rpm fbcf92e15337b34511d4a305100d6797d644a84e fedora/3/updates/x86_64/udev-039-10.FC3.9.legacy.x86_64.rpm fe4e15a6ac3d4d80ce3db01f08a75c93985964e8 fedora/3/updates/SRPMS/udev-039-10.FC3.9.legacy.src.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=CVE-2005-3631 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Tue Feb 28 00:57:14 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 27 Feb 2006 19:57:14 -0500 Subject: [FLSA-2006:177326] Updated mod_auth_pgsql package fixes security issue Message-ID: <44039FEA.1000700@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated mod_auth_pgsql package fixes security issue Advisory ID: FLSA:177326 Issue date: 2006-02-27 Product: Fedora Core Keywords: Bugfix CVE Names: CVE-2005-3656 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: An updated mod_auth_pgsql package that fixes a format string flaw is now available. The mod_auth_pgsql package is an httpd module that allows user authentication against information stored in a PostgreSQL database. 2. Relevant releases/architectures: Fedora Core 1 - i386 Fedora Core 2 - i386 3. Problem description: Several format string flaws were found in the way mod_auth_pgsql logs information. It may be possible for a remote attacker to execute arbitrary code as the 'apache' user if mod_auth_pgsql is used for user authentication. The Common Vulnerabilities and Exposures project assigned the name CVE-2005-3656 to this issue. Please note that this issue only affects servers which have mod_auth_pgsql installed and configured to perform user authentication against a PostgreSQL database. All users of mod_auth_pgsql should upgrade to these updated packages, which contain a backported patch to resolve 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: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177326 6. RPMs required: Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/mod_auth_pgsql-2.0.1-3.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/mod_auth_pgsql-2.0.1-3.1.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/mod_auth_pgsql-2.0.1-4.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/mod_auth_pgsql-2.0.1-4.2.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- e6ce19c8be5f4638e2050437c4529b0d4a0f5e1f fedora/1/updates/i386/mod_auth_pgsql-2.0.1-3.1.legacy.i386.rpm 119b3b6045eaa3b175ebe3d613daca8e9c81b35c fedora/1/updates/SRPMS/mod_auth_pgsql-2.0.1-3.1.legacy.src.rpm 8f9c2503b417db84b73483e6daca445c4789e4e4 fedora/2/updates/i386/mod_auth_pgsql-2.0.1-4.2.legacy.i386.rpm 52aabaff10fb0f862e1b96199facb7da046e94dc fedora/2/updates/SRPMS/mod_auth_pgsql-2.0.1-4.2.legacy.src.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=CVE-2005-3656 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Tue Feb 28 00:57:46 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 27 Feb 2006 19:57:46 -0500 Subject: [FLSA-2006:177694] Updated auth_ldap package fixes security issue Message-ID: <4403A00A.6060108@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated auth_ldap package fixes security issue Advisory ID: FLSA:177694 Issue date: 2006-02-27 Product: Red Hat Linux Keywords: Bugfix CVE Names: CVE-2006-0150 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: An updated auth_ldap package that fixes a format string security issue is now available for Red Hat Linux 7.3. The auth_ldap package is an httpd module that allows user authentication against information stored in an LDAP database. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 3. Problem description: A format string flaw was found in the way auth_ldap logs information. It may be possible for a remote attacker to execute arbitrary code as the 'apache' user if auth_ldap is used for user authentication. The Common Vulnerabilities and Exposures project (cve.mitre.org) assigned the name CVE-2006-0150 to this issue. Note that this issue only affects servers that have auth_ldap installed and configured to perform user authentication against an LDAP database. All users of auth_ldap should upgrade to this updated package, which contains a backported patch to resolve 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: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177694 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/auth_ldap-1.6.0-4.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/auth_ldap-1.6.0-4.2.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 38f70135bc17c313fecdb81f61e776ac032b796e redhat/7.3/updates/i386/auth_ldap-1.6.0-4.2.legacy.i386.rpm 78b7ee876d5b900ff5268b1a396a59ca9f2385f0 redhat/7.3/updates/SRPMS/auth_ldap-1.6.0-4.2.legacy.src.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=CVE-2006-0150 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Tue Feb 28 00:58:20 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 27 Feb 2006 19:58:20 -0500 Subject: [FLSA-2006:181014] Updated gnutls packages fix a security issue Message-ID: <4403A02C.7050407@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated gnutls packages fix a security issue Advisory ID: FLSA:181014 Issue date: 2006-02-27 Product: Fedora Core Keywords: Bugfix CVE Names: CVE-2006-0645 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated gnutls packages that fix a security issue are now available. The GNU TLS Library provides support for cryptographic algorithms and protocols such as TLS. GNU TLS includes Libtasn1, a library developed for ASN.1 structures management that includes DER encoding and decoding. 2. Relevant releases/architectures: Fedora Core 3 - i386, x86_64 3. Problem description: Several flaws were found in the way libtasn1 decodes DER. An attacker could create a carefully crafted invalid X.509 certificate in such a way that could trigger this flaw if parsed by an application that uses GNU TLS. This could lead to a denial of service (application crash). It is not certain if this issue could be escalated to allow arbitrary code execution. The Common Vulnerabilities and Exposures project assigned the name CVE-2006-0645 to this issue. Users are advised to upgrade to these updated packages, which contain a backported patch from the GNU TLS maintainers to correct 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: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181014 6. RPMs required: Fedora Core 3: SRPM: http://download.fedoralegacy.org/fedora/3/updates/SRPMS/gnutls-1.0.20-3.1.3.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/3/updates/i386/gnutls-1.0.20-3.1.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/3/updates/i386/gnutls-devel-1.0.20-3.1.3.legacy.i386.rpm x86_64: http://download.fedoralegacy.org/fedora/3/updates/x86_64/gnutls-1.0.20-3.1.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/3/updates/x86_64/gnutls-1.0.20-3.1.3.legacy.x86_64.rpm http://download.fedoralegacy.org/fedora/3/updates/x86_64/gnutls-devel-1.0.20-3.1.3.legacy.x86_64.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 87b93af583ea3abaa48337b0a8c71cba97a45410 fedora/3/updates/i386/gnutls-1.0.20-3.1.3.legacy.i386.rpm dca7e6e11093d7b8528d82cc9c3f5f1b1c78ea23 fedora/3/updates/i386/gnutls-devel-1.0.20-3.1.3.legacy.i386.rpm 87b93af583ea3abaa48337b0a8c71cba97a45410 fedora/3/updates/x86_64/gnutls-1.0.20-3.1.3.legacy.i386.rpm 742be40634dc2a32b245f78caf610d0a6b45cb75 fedora/3/updates/x86_64/gnutls-1.0.20-3.1.3.legacy.x86_64.rpm 762630c8973f02bcc934adc8f5a946383f8479cc fedora/3/updates/x86_64/gnutls-devel-1.0.20-3.1.3.legacy.x86_64.rpm cce2a463b57be400362624f09dc49a4fdde09305 fedora/3/updates/SRPMS/gnutls-1.0.20-3.1.3.legacy.src.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=CVE-2006-0645 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: