From matteo at iuav.it Thu May 4 13:37:03 2006 From: matteo at iuav.it (Matteo Parpagiola) Date: Thu, 4 May 2006 15:37:03 +0200 Subject: Cyrus SASL CVE-2006-1721 Message-ID: <002d01c66f7f$d3dacf20$eacd8a9d@iuav.it> Hi, I've got Fedora Core 3 with Cyrus SASL 2.1.19. What about the bug reported at this address: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1721 ? Are you planning to correct this bug with a security fix in a short time? Thanks, Matteo Parpagiola From deisenst at gtw.net Thu May 4 15:34:05 2006 From: deisenst at gtw.net (David Eisenstein) Date: Thu, 4 May 2006 10:34:05 -0500 (CDT) Subject: Cyrus SASL CVE-2006-1721 In-Reply-To: <002d01c66f7f$d3dacf20$eacd8a9d@iuav.it> Message-ID: On Thu, 4 May 2006, Matteo Parpagiola wrote: > Hi, > I've got Fedora Core 3 with Cyrus SASL 2.1.19. > What about the bug reported at this address: > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1721 ? > Are you planning to correct this bug with a security fix in a short > time? > > Thanks, > Matteo Parpagiola Bug ticket entered: . -David From deisenst at gtw.net Fri May 12 06:44:52 2006 From: deisenst at gtw.net (David Eisenstein) Date: Fri, 12 May 2006 01:44:52 -0500 (CDT) Subject: Apache 1.3.7 (RH73) question wrt CVEs In-Reply-To: <4463F59B.9090803@yahoo.com> Message-ID: On Thu, 11 May 2006, Jim Popovitch wrote: > In another arena I saw a list of CVEs against Apache 1.3.7. RH73 ships > with Apache 1.3.7-9 so I thought I would query BZ and see what I could > find of these. (I am a BZ newbie when it comes to queries). > > CVE-2002-1233 Apache HTTP Server htpasswd and htdigest Multiple > Vulnerabilities > > CVE-2004-0748, CVE-2004-0751 Apache HTTP Server mod_ssl Denial of Service > > CVE-2003-0083, CVE-2003-0020 Linux/Unix: Apache Escape Sequence > Vulnerabilities > > CVE-2003-0993 Apache mod_access Security Bypass > > CVE-2004-0700 Apache mod_ssl Format String Vulnerability > > > Unfortunately I couldn't find any of those in the Comments under Apache > for Fedora Legacy Redhat 7.3. I can't believe that all of those > aren't addressed, so lack of query results suggests to me that I am > missing something. Some of those CVE/CANs are several years old, but > wouldn't the still be in BZ comments somewhere? It appears that Red Hat Linux 7.3 shipped with apache-1.3.23-11... I don't know what shipped with apache-1.3.7 ... From Fedora Legacy's archives, RHL 7.3's apache was shipped on 16-Apr-2002. The latest update for Red Hat 7.3's apache appears to have been released by the Fedora Legacy project on 18-Feb-2006 and is apache-1.3.27-9.legacy. The latest mod_ssl for RHL 7.3 is mod_ssl-2.8.12-8.legacy, released 9-Nov-2005. A couple of things. First, not all Legacy work is documented in Red Hat's Bugzilla. Initial Fedora Legacy group work thru Mar 2005 was tracked in http://bugzilla.fedora.us/. For example, a quick peek there shows that CAN-2004-0700 was handled here: . The second thing is that you may wish to check the apache's and mod_ssl's changelogs. If you have a RH7.3 system, you can do a query on the RPMs you have installed: $ rpm -q --changelog apache $ rpm -q --changelog mod_ssl All vulnerabilities that are fixed *ought* to be mentioned in the changelog, mentioning the CVE # in the changelog entry. However, sometimes CVE's are taken care of by updating a package to a newer upstream version, so package maintainers may or may not mention the CVE's that an upstream-upgrade fixes. Again, I think they *ought* to, but they don't always. Item-by-item: * CVE-2002-1233. The description in the CVE database for this entry goes: "A regression error in the Debian distributions of the apache-ssl package (before 1.3.9 on Debian 2.2, and before 1.3.26 on Debian 3.0), for Apache 1.3.27 and earlier, allows local users to read or modify the Apache password file via a symlink attack on temporary files when the administrator runs (1) htpasswd or (2) htdigest, a re-introduction of a vulnerability that was originally identified and addressed by CVE-2001-0131." Further comment disputing the validity of the CVE is present also: "Cox> Many vendors have included fixes for CVE-2001-0131 in their distributions of Apache even though this has not been fixed upstream. I still believe that this is not worthy of a separate CVE name since this is just Debian forgetting to include their fix for CVE-2001-0131 in one of their versions, and then correcting it." Since this is a Debian-only issue, I would not expect to find mention of CAN-2002-1233 in any Bugzilla nor the changelogs. * CVE-2003-0020. This was fixed with Red Hat's release of apache- 1.3.27-3 with their advisory RHSA-2003:243-07, issued on 2003-09-22 when RH Linux 7.3 was still under Red Hat's care. One can find this issue mentioned in apache-1.3.27-9.legacy's changelogs. Ref: . * CVE-2003-0083. According to this CVE, this vulnerability only affects Apache 1.3 before 1.3.25, so it would not have affected this version of apache. * CVE-2003-0993. I don't see this one mentioned in the changelogs. But I don't think this one would affect Legacy, as this issue only seems to affect Apache 1.3 when running on big-endian 64-bit platforms, according to the CVE. Legacy only supports x86 for RH Linux 7.3. * CVE-2004-0700. This was was fixed by legacy in mod_ssl-2.8.12-5.legacy. See the bugzilla.fedora.us mentioned above, as well as mod_ssl's changelogs. * CVE-2004-0748. Looking at how it was reported for RHEL 3, in RH's Bugzilla # 130749, it appears to not affect mod_ssl with Apache 1.3. . So this would not have affected Red Hat Linux 7.3 For FC1 & newer distros that use Apache 2.0.xx, this appears to have been fixed with an upgrade to httpd-2.0.51. For RHL 9, I am not fin- ding where this was fixed, as the update advisory that included verbiage for this CVE indicated that RHL 9 was not affected by this vulnerability. * CVE-2004-0751. From the text of the CVE, this is a bug in the char_buffer_read function in the mod_ssl module for Apache 2.xx. This vulnerability apparently does not affect Apache 1.3.xx. Hope this helped, Jim. > -Jim P. > > -- > Fedora-security-list mailing list > Fedora-security-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-security-list From jimpop at yahoo.com Fri May 12 06:52:47 2006 From: jimpop at yahoo.com (Jim Popovitch) Date: Fri, 12 May 2006 02:52:47 -0400 Subject: Apache 1.3.7 (RH73) question wrt CVEs In-Reply-To: References: Message-ID: <446430BF.3070407@yahoo.com> David Eisenstein wrote: > On Thu, 11 May 2006, Jim Popovitch wrote: > >> In another arena I saw a list of CVEs against Apache 1.3.7. RH73 ships >> with Apache 1.3.7-9 so I thought I would query BZ and see what I could >> find of these. (I am a BZ newbie when it comes to queries). >> >> CVE-2002-1233 Apache HTTP Server htpasswd and htdigest Multiple >> Vulnerabilities >> >> CVE-2004-0748, CVE-2004-0751 Apache HTTP Server mod_ssl Denial of Service >> >> CVE-2003-0083, CVE-2003-0020 Linux/Unix: Apache Escape Sequence >> Vulnerabilities >> >> CVE-2003-0993 Apache mod_access Security Bypass >> >> CVE-2004-0700 Apache mod_ssl Format String Vulnerability >> >> >> Unfortunately I couldn't find any of those in the Comments under Apache >> for Fedora Legacy Redhat 7.3. I can't believe that all of those >> aren't addressed, so lack of query results suggests to me that I am >> missing something. Some of those CVE/CANs are several years old, but >> wouldn't the still be in BZ comments somewhere? > > It appears that Red Hat Linux 7.3 shipped with apache-1.3.23-11... I > don't know what shipped with apache-1.3.7 ... From Fedora Legacy's > archives, RHL 7.3's apache was shipped on 16-Apr-2002. > > The latest update for Red Hat 7.3's apache appears to have been released > by the Fedora Legacy project on 18-Feb-2006 and is apache-1.3.27-9.legacy. Thank you David for the insight as well as the ground work on going through all of those. It wasn't my intention to have you or someone else do that, but I do appreciate your doing so. Apologies for specifying apache-1.3.7, that was a copy/paste error, I meant apache-1.3.27. Again, Thank you for digging through all of that. -Jim P. From ashishs at us.ibm.com Fri May 12 07:31:29 2006 From: ashishs at us.ibm.com (Ashish N Shah) Date: Fri, 12 May 2006 01:31:29 -0600 Subject: Ashish N Shah Message-ID: I will be out of the office starting 05/05/2006 and will not return until 05/06/2007. I am no longer with IBM, please contact Terri Van Der Werff f(werff at us.ibm.com) for assistance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcdeslauriers at videotron.ca Sat May 13 00:49:30 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Fri, 12 May 2006 20:49:30 -0400 Subject: [FLSA-2006:152868] Updated tetex packages fix security issues Message-ID: <44652D1A.4060404@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated tetex packages fix security issues Advisory ID: FLSA:152868 Issue date: 2006-05-12 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2004-0888 CVE-2004-1125 CVE-2005-3191 CVE-2005-3192 CVE-2005-3193 CVE-2005-3624 CVE-2005-3625 CVE-2005-3626 CVE-2005-3627 CVE-2005-3628 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated tetex packages that fix several security issues are now available. TeTeX is an implementation of TeX. TeX takes a text file and a set of formatting commands as input and creates a typesetter-independent .dvi (DeVice Independent) file as output. 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 number of integer overflow bugs that affect Xpdf were discovered. The teTeX package contains a copy of the Xpdf code used for parsing PDF files and is therefore affected by these bugs. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CVE-2004-0888 and CVE-2004-1125 to these issues. Several flaws were discovered in the teTeX PDF parsing library. An attacker could construct a carefully crafted PDF file that could cause teTeX 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 teTeX should upgrade to these updated packages, which contain backported patches and are 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=152868 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/tetex-1.0.7-47.5.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/tetex-1.0.7-47.5.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/tetex-afm-1.0.7-47.5.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/tetex-doc-1.0.7-47.5.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/tetex-dvilj-1.0.7-47.5.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/tetex-dvips-1.0.7-47.5.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/tetex-fonts-1.0.7-47.5.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/tetex-latex-1.0.7-47.5.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/tetex-xdvi-1.0.7-47.5.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/tetex-1.0.7-66.3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/tetex-1.0.7-66.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/tetex-afm-1.0.7-66.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/tetex-doc-1.0.7-66.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/tetex-dvips-1.0.7-66.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/tetex-fonts-1.0.7-66.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/tetex-latex-1.0.7-66.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/tetex-xdvi-1.0.7-66.3.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/tetex-2.0.2-8.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/tetex-2.0.2-8.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/tetex-afm-2.0.2-8.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/tetex-doc-2.0.2-8.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/tetex-dvips-2.0.2-8.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/tetex-fonts-2.0.2-8.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/tetex-latex-2.0.2-8.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/tetex-xdvi-2.0.2-8.2.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/tetex-2.0.2-14FC2.3.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/tetex-2.0.2-14FC2.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/tetex-afm-2.0.2-14FC2.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/tetex-doc-2.0.2-14FC2.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/tetex-dvips-2.0.2-14FC2.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/tetex-fonts-2.0.2-14FC2.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/tetex-latex-2.0.2-14FC2.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/tetex-xdvi-2.0.2-14FC2.3.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 80b05b7896c5db589e960da0d73b1cd4ae120cce redhat/7.3/updates/i386/tetex-1.0.7-47.5.legacy.i386.rpm 28c6022b4f6a237d4695d1f268276ec6b18dcf4c redhat/7.3/updates/i386/tetex-afm-1.0.7-47.5.legacy.i386.rpm 017fa321d9834685f04819070d4f5fb799e05d01 redhat/7.3/updates/i386/tetex-doc-1.0.7-47.5.legacy.i386.rpm 3303175840f2fc37c5f3f77e672eeb3fafae718a redhat/7.3/updates/i386/tetex-dvilj-1.0.7-47.5.legacy.i386.rpm fa43c7cbdf02cb7d439c9beeb0e358f8c69a5f22 redhat/7.3/updates/i386/tetex-dvips-1.0.7-47.5.legacy.i386.rpm 1e69a574c3d47cec5b58963387956dfc8337d6ec redhat/7.3/updates/i386/tetex-fonts-1.0.7-47.5.legacy.i386.rpm bb229acb3b38ae16025d56a77c41cab939a512ac redhat/7.3/updates/i386/tetex-latex-1.0.7-47.5.legacy.i386.rpm d21419415faefcb90b688f8d8dc60a57a6374bad redhat/7.3/updates/i386/tetex-xdvi-1.0.7-47.5.legacy.i386.rpm f646b3f3c2ebafa6ae264f20a3f056c778bd84db redhat/7.3/updates/SRPMS/tetex-1.0.7-47.5.legacy.src.rpm 26f54ca0403372b21e6fd441d9bb64073f23e7de redhat/9/updates/i386/tetex-1.0.7-66.3.legacy.i386.rpm e74de7855d1d07bcef6a713f4a8735e8008f5249 redhat/9/updates/i386/tetex-afm-1.0.7-66.3.legacy.i386.rpm c836a796ad112f79c84c528006a14a3ff1f99a20 redhat/9/updates/i386/tetex-doc-1.0.7-66.3.legacy.i386.rpm 5d60fb658c5581eff85e589b2f71e49b4b7132b0 redhat/9/updates/i386/tetex-dvips-1.0.7-66.3.legacy.i386.rpm 7ea6340fe95a63586bebc82f0869f962a178a8b2 redhat/9/updates/i386/tetex-fonts-1.0.7-66.3.legacy.i386.rpm 62790eea2119387ad7c9ff4dc52aa9f24ae188f3 redhat/9/updates/i386/tetex-latex-1.0.7-66.3.legacy.i386.rpm 55f398c9781e6a75c14becd57930afd91632c8fb redhat/9/updates/i386/tetex-xdvi-1.0.7-66.3.legacy.i386.rpm a696b9b616557bf0d9b8ae7f884e543061e0e110 redhat/9/updates/SRPMS/tetex-1.0.7-66.3.legacy.src.rpm 5560c992700e00a6f69d9ee7d2835522142fb93b fedora/1/updates/i386/tetex-2.0.2-8.2.legacy.i386.rpm 416e95e8c3241c6fb239ca534dbb5654f5bb4206 fedora/1/updates/i386/tetex-afm-2.0.2-8.2.legacy.i386.rpm 55adc5facf3a5c44cd5eb8b57559b03728fb7a64 fedora/1/updates/i386/tetex-doc-2.0.2-8.2.legacy.i386.rpm e893ad3c1c95abd91830b43fa74138be297da25e fedora/1/updates/i386/tetex-dvips-2.0.2-8.2.legacy.i386.rpm b5b4de3d22bf7696ed5194f68c271d08d912d571 fedora/1/updates/i386/tetex-fonts-2.0.2-8.2.legacy.i386.rpm 57029989a0bba05d33c566bdb0df6ff921f3addd fedora/1/updates/i386/tetex-latex-2.0.2-8.2.legacy.i386.rpm 857555c989ce1db61ddec8a7fdaf30a21bd1a207 fedora/1/updates/i386/tetex-xdvi-2.0.2-8.2.legacy.i386.rpm f4cd83ce6594ce3a2ba6f3371d22b46435be8fbd fedora/1/updates/SRPMS/tetex-2.0.2-8.2.legacy.src.rpm b02943e6007fc24a8c187d94c1511110d3d6e6e0 fedora/2/updates/i386/tetex-2.0.2-14FC2.3.legacy.i386.rpm 08f84cc10ee1b4ea4a0a28b0d06cba8209c0c5f3 fedora/2/updates/i386/tetex-afm-2.0.2-14FC2.3.legacy.i386.rpm ea6b0ea52e2784a8d4de505e8866b6ca24ff94dd fedora/2/updates/i386/tetex-doc-2.0.2-14FC2.3.legacy.i386.rpm 61298e2841be9ce39260139387502f2caa555653 fedora/2/updates/i386/tetex-dvips-2.0.2-14FC2.3.legacy.i386.rpm 42271d0bf5aab0b7b77c6ccb90723588395e06a2 fedora/2/updates/i386/tetex-fonts-2.0.2-14FC2.3.legacy.i386.rpm 555556960f4e116cc1f92d57d8896284cf125935 fedora/2/updates/i386/tetex-latex-2.0.2-14FC2.3.legacy.i386.rpm 23d0051001771158b6573c846d1e736308cba424 fedora/2/updates/i386/tetex-xdvi-2.0.2-14FC2.3.legacy.i386.rpm c05978c27472e3a8fbfc12896e26d78ae18e065b fedora/2/updates/SRPMS/tetex-2.0.2-14FC2.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-2004-0888 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1125 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3191 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3192 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3193 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3624 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3625 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3626 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3627 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3628 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: 189 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Sat May 13 00:50:37 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Fri, 12 May 2006 20:50:37 -0400 Subject: [FLSA-2006:152898] Updated emacs packages fix a security issue Message-ID: <44652D5D.7070009@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated emacs packages fix a security issue Advisory ID: FLSA:152898 Issue date: 2006-05-12 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2005-0100 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated Emacs packages that fix a string format issue are now available. Emacs is a powerful, customizable, self-documenting, modeless text editor. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 3. Problem description: Max Vozeler discovered several format string vulnerabilities in the movemail utility of Emacs. If a user connects to a malicious POP server, an attacker can execute arbitrary code as the user running emacs. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0100 to this issue. Users of Emacs are advised to upgrade to these updated packages, which contain backported patches 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=152898 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/emacs-21.2-3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/emacs-21.2-3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/emacs-el-21.2-3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/emacs-leim-21.2-3.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/emacs-21.2-34.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/emacs-21.2-34.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/emacs-el-21.2-34.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/emacs-leim-21.2-34.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/emacs-21.3-9.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/emacs-21.3-9.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/emacs-el-21.3-9.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/emacs-leim-21.3-9.2.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 4441c55cfe91aabf2203d68bcbc0cf2bbd5f8798 redhat/7.3/updates/i386/emacs-21.2-3.legacy.i386.rpm 33e802e8f306f13519dd2c3f045eb9efe5e4680a redhat/7.3/updates/i386/emacs-el-21.2-3.legacy.i386.rpm f6293ffe1c51c3bb31f1b3941da0938d8a98eff2 redhat/7.3/updates/i386/emacs-leim-21.2-3.legacy.i386.rpm a5767f1100037b49602abb80831fa22da135c081 redhat/7.3/updates/SRPMS/emacs-21.2-3.legacy.src.rpm ae56dba68d59f5d49105f7afb6918ac945ad8b01 redhat/9/updates/i386/emacs-21.2-34.legacy.i386.rpm 84047366c8488fa3c95070466b1bd20ce5d8687a redhat/9/updates/i386/emacs-el-21.2-34.legacy.i386.rpm 8eb8449c456e7d475157992c3e6f8bc4bdf64c7b redhat/9/updates/i386/emacs-leim-21.2-34.legacy.i386.rpm 4cf0ba484c3ab93210d186beb3c79b68b4e56984 redhat/9/updates/SRPMS/emacs-21.2-34.legacy.src.rpm d56260f010b4603c89516ccf2ddd09c33c8c53c4 fedora/1/updates/i386/emacs-21.3-9.2.legacy.i386.rpm 6bf7cb9bacc6c0f9374849fa4507ededa13193cf fedora/1/updates/i386/emacs-el-21.3-9.2.legacy.i386.rpm fb23df114772b6c758499401751dfc389e2e1d88 fedora/1/updates/i386/emacs-leim-21.3-9.2.legacy.i386.rpm 1a1133d917d4993c92a03c30ba08e8916c6a7bfe fedora/1/updates/SRPMS/emacs-21.3-9.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-0100 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: 189 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Sat May 13 00:53:06 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Fri, 12 May 2006 20:53:06 -0400 Subject: [FLSA-2006:152904] Updated ncpfs package fixes security issues Message-ID: <44652DF2.5000908@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated ncpfs package fixes security issues Advisory ID: FLSA:152904 Issue date: 2006-05-12 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2004-1079 CVE-2005-0013 CVE-2005-0014 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: An updated ncpfs package is now available. Ncpfs is a file system that understands the Novell NetWare(TM) NCP protocol. 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: Buffer overflows were found in the nwclient program. An attacker, using a long -T option, could possibly execute arbitrary code and gain privileges. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2004-1079 to this issue. A bug was found in the way ncpfs handled file permissions. ncpfs did not sufficiently check if the file owner matched the user attempting to access the file, potentially violating the file permissions. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0013 to this issue. A buffer overflow was found in the ncplogin program. A remote malicious NetWare server could execute arbitrary code on a victim's machine. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0014 to this issue. All users of ncpfs are advised to upgrade to this updated package, which contains backported fixes for 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=152904 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/ncpfs-2.2.0.18-6.1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/ncpfs-2.2.0.18-6.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/ipxutils-2.2.0.18-6.1.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/ncpfs-2.2.1-1.1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/ncpfs-2.2.1-1.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/ipxutils-2.2.1-1.1.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/ncpfs-2.2.3-1.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/ncpfs-2.2.3-1.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/ipxutils-2.2.3-1.1.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/ncpfs-2.2.4-1.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/ncpfs-2.2.4-1.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/ipxutils-2.2.4-1.1.legacy.i386.rpm Fedora Core 3: SRPM: http://download.fedoralegacy.org/fedora/3/updates/SRPMS/ncpfs-2.2.4-5.FC3.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/3/updates/i386/ncpfs-2.2.4-5.FC3.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/3/updates/i386/ipxutils-2.2.4-5.FC3.1.legacy.i386.rpm x86_64: http://download.fedoralegacy.org/fedora/3/updates/x86_64/ncpfs-2.2.4-5.FC3.1.legacy.x86_64.rpm http://download.fedoralegacy.org/fedora/3/updates/x86_64/ipxutils-2.2.4-5.FC3.1.legacy.x86_64.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 16740d3fa5e17a46429ad3586e4adf9a14a64f8d redhat/7.3/updates/i386/ncpfs-2.2.0.18-6.1.legacy.i386.rpm 21f8520c8a2a3d60e55041c0db028e03549f8544 redhat/7.3/updates/i386/ipxutils-2.2.0.18-6.1.legacy.i386.rpm 6704d55f1f43360b6ad4211e2ca0f92e9f2174c8 redhat/7.3/updates/SRPMS/ncpfs-2.2.0.18-6.1.legacy.src.rpm 6acd3b7b7d09cb0e47769b43a888adf72a6278ac redhat/9/updates/i386/ncpfs-2.2.1-1.1.legacy.i386.rpm c49d83f88b229ce57c689d313eccb4df7b89f36b redhat/9/updates/i386/ipxutils-2.2.1-1.1.legacy.i386.rpm ac833c51fcf831bca3edef5d0275ccd1ae0a530f redhat/9/updates/SRPMS/ncpfs-2.2.1-1.1.legacy.src.rpm 8379face8f68fe556d40bf32f72a5ab368e8eb6d fedora/1/updates/i386/ncpfs-2.2.3-1.1.legacy.i386.rpm eefaa839a26179ca5d41897eacf7bbf3c49661e1 fedora/1/updates/i386/ipxutils-2.2.3-1.1.legacy.i386.rpm ede00a8544200515b5e09a7a40836d8f558cac9d fedora/1/updates/SRPMS/ncpfs-2.2.3-1.1.legacy.src.rpm 1d32d2f0c39475f98206d78f87c587d4f96ddb70 fedora/2/updates/i386/ncpfs-2.2.4-1.1.legacy.i386.rpm c095ce2d66184b605516231609cddc30520c3eb5 fedora/2/updates/i386/ipxutils-2.2.4-1.1.legacy.i386.rpm 874f8a48f85fef80615b5892a70d214f0935ed7a fedora/2/updates/SRPMS/ncpfs-2.2.4-1.1.legacy.src.rpm dc329c8b3558f67350486358b01b6a62f6f467af fedora/3/updates/i386/ncpfs-2.2.4-5.FC3.1.legacy.i386.rpm 1ddd6caafe4a693d4a69d341be69600df446de3b fedora/3/updates/i386/ipxutils-2.2.4-5.FC3.1.legacy.i386.rpm db8660759a23570a6d06bda37c619e0931425ef8 fedora/3/updates/x86_64/ncpfs-2.2.4-5.FC3.1.legacy.x86_64.rpm 1e8bc7d10995fde90688b424f5001c14f7d3e3bc fedora/3/updates/x86_64/ipxutils-2.2.4-5.FC3.1.legacy.x86_64.rpm 7f29dd88dcf31f19970e22c8c3af7267c62a5508 fedora/3/updates/SRPMS/ncpfs-2.2.4-5.FC3.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-2004-1079 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0013 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0014 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: 189 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Sat May 13 00:53:46 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Fri, 12 May 2006 20:53:46 -0400 Subject: [FLSA-2006:152923] Updated xloadimage package fixes security issues Message-ID: <44652E1A.6020301@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated xloadimage package fixes security issues Advisory ID: FLSA:152923 Issue date: 2006-05-12 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2005-0638 CVE-2005-3178 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: A new xloadimage package that fixes bugs in handling malformed tiff and pbm/pnm/ppm images, and in handling metacharacters in file names is now available. The xloadimage utility displays images in an X Window System window, loads images into the root window, or writes images into a file. Xloadimage supports many image types (including GIF, TIFF, JPEG, XPM, and XBM). 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 flaw was discovered in xloadimage where filenames were not properly quoted when calling the gunzip command. An attacker could create a file with a carefully crafted filename so that it would execute arbitrary commands if opened by a victim. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0638 to this issue. A flaw was discovered in xloadimage via which an attacker can construct a NIFF image with a very long embedded image title. This image can cause a buffer overflow. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-3178 to this issue. All users of xloadimage should upgrade to this erratum 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=152923 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/xloadimage-4.1-21.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/xloadimage-4.1-21.2.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/xloadimage-4.1-27.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/xloadimage-4.1-27.2.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/xloadimage-4.1-29.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/xloadimage-4.1-29.2.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/xloadimage-4.1-34.FC2.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/xloadimage-4.1-34.FC2.2.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 88326ff1a0753287240180322b36f8174686e0cc redhat/7.3/updates/i386/xloadimage-4.1-21.2.legacy.i386.rpm 663b64ed039000824bacd3475e807c29c835f388 redhat/7.3/updates/SRPMS/xloadimage-4.1-21.2.legacy.src.rpm 7fef8d73737dfacb3d56f203bf31f3c8e2014925 redhat/9/updates/i386/xloadimage-4.1-27.2.legacy.i386.rpm 2b4223a41ab2127ee3b173e0803635f3c441bb4f redhat/9/updates/SRPMS/xloadimage-4.1-27.2.legacy.src.rpm c24c7a2ae4d703b00a3f84623cae24775674d5d7 fedora/1/updates/i386/xloadimage-4.1-29.2.legacy.i386.rpm ec2c5a9b5049aeca3cd4d12e7b84c650fec1c295 fedora/1/updates/SRPMS/xloadimage-4.1-29.2.legacy.src.rpm 2910727dcd74a462a2f137746592e53ba5fcdfac fedora/2/updates/i386/xloadimage-4.1-34.FC2.2.legacy.i386.rpm 924f5e4ffc9ff7190dc1808def838e57377f5fd6 fedora/2/updates/SRPMS/xloadimage-4.1-34.FC2.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-0638 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3178 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: 189 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Sat May 13 00:55:22 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Fri, 12 May 2006 20:55:22 -0400 Subject: [FLSA-2006:164512] Updated fetchmail packages fix security issues Message-ID: <44652E7A.8070608@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated fetchmail packages fix security issues Advisory ID: FLSA:164512 Issue date: 2006-05-12 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2003-0792 CVE-2005-2335 CVE-2005-3088 CVE-2005-4348 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated fetchmail packages that fix security flaws are now available. Fetchmail is a remote mail retrieval and forwarding utility. 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 bug was found in the way fetchmail allocates memory for long lines. A remote attacker could cause a denial of service by sending a specially- crafted email. The Common Vulnerabilities and Exposures project has assigned the name CVE-2003-0792 to this issue. A buffer overflow was discovered in fetchmail's POP3 client. A malicious server could cause send a carefully crafted message UID and cause fetchmail to crash or potentially execute arbitrary code as the user running fetchmail. The Common Vulnerabilities and Exposures project assigned the name CVE-2005-2335 to this issue. A bug was found in the way the fetchmailconf utility program writes configuration files. The default behavior of fetchmailconf is to write a configuration file which may be world readable for a short period of time. This configuration file could provide passwords to a local malicious attacker within the short window before fetchmailconf sets secure permissions. The Common Vulnerabilities and Exposures project has assigned the name CVE-2005-3088 to this issue. A bug was found when fetchmail is running in multidrop mode. A malicious mail server can cause a denial of service by sending a message without headers. The Common Vulnerabilities and Exposures project has assigned the name CVE-2005-4348 to this issue. Users of fetchmail should update to this erratum 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=164512 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/fetchmail-5.9.0-21.7.3.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/fetchmail-5.9.0-21.7.3.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/fetchmailconf-5.9.0-21.7.3.2.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/fetchmail-6.2.0-3.4.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/fetchmail-6.2.0-3.4.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/fetchmail-6.2.0-8.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/fetchmail-6.2.0-8.2.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/fetchmail-6.2.5-2.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/fetchmail-6.2.5-2.2.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 8b49bca60dc8bcbba7634b8e0559c82fbeef3db5 redhat/7.3/updates/i386/fetchmail-5.9.0-21.7.3.2.legacy.i386.rpm 9c9c861757b4b8b2866f1d0e91dbc16d5037d956 redhat/7.3/updates/i386/fetchmailconf-5.9.0-21.7.3.2.legacy.i386.rpm 9cca4f274cb21928d459ed25883e5d3c1f758f10 redhat/7.3/updates/SRPMS/fetchmail-5.9.0-21.7.3.2.legacy.src.rpm 0fd22e51f83aab97d8c1790ed95423882f01aa9b redhat/9/updates/i386/fetchmail-6.2.0-3.4.legacy.i386.rpm 7d2eb582d0aba96e07710eb89cd8c4c41c4530d3 redhat/9/updates/SRPMS/fetchmail-6.2.0-3.4.legacy.src.rpm 5df158a0ba6bb0c323a75464e04b11e246dd8f98 fedora/1/updates/i386/fetchmail-6.2.0-8.2.legacy.i386.rpm 927ed2783b8b4a29d0669e7936c1d27fd05564eb fedora/1/updates/SRPMS/fetchmail-6.2.0-8.2.legacy.src.rpm 418f533e86f4c04a5fc41235b0618db470a63471 fedora/2/updates/i386/fetchmail-6.2.5-2.2.legacy.i386.rpm d5a948f76f51032c05ab44b0ca7e47e36f7e4042 fedora/2/updates/SRPMS/fetchmail-6.2.5-2.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-2003-0792 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2335 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3088 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4348 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: 189 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Sat May 13 00:56:02 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Fri, 12 May 2006 20:56:02 -0400 Subject: [FLSA-2006:185355] Updated gnupg package fixes security issues Message-ID: <44652EA2.2050708@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated gnupg package fixes security issues Advisory ID: FLSA:185355 Issue date: 2006-05-12 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2006-0049 CVE-2006-0455 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: An updated GnuPG package that fixes signature verification flaws is now available. GnuPG is a utility for encrypting data and creating digital signatures. 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: Tavis Ormandy discovered a bug in the way GnuPG verifies cryptographically signed data with detached signatures. It is possible for an attacker to construct a cryptographically signed message which could appear to come from a third party. When a victim processes a GnuPG message with a malformed detached signature, GnuPG ignores the malformed signature, processes and outputs the signed data, and exits with status 0, just as it would if the signature had been valid. In this case, GnuPG's exit status would not indicate that no signature verification had taken place. This issue would primarily be of concern when processing GnuPG results via an automated script. The Common Vulnerabilities and Exposures project assigned the name CVE-2006-0455 to this issue. Tavis Ormandy also discovered a bug in the way GnuPG verifies cryptographically signed data with inline signatures. It is possible for an attacker to inject unsigned data into a signed message in such a way that when a victim processes the message to recover the data, the unsigned data is output along with the signed data, gaining the appearance of having been signed. The Common Vulnerabilities and Exposures project assigned the name CVE-2006-0049 to this issue. Please note that neither of these issues affect the way RPM or up2date verify RPM package files, nor is RPM vulnerable to either of these issues. All users of GnuPG 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=185355 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/gnupg-1.0.7-13.3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/gnupg-1.0.7-13.3.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/gnupg-1.2.1-9.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/gnupg-1.2.1-9.2.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/gnupg-1.2.3-2.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/gnupg-1.2.3-2.2.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/gnupg-1.2.4-2.3.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/gnupg-1.2.4-2.3.legacy.i386.rpm Fedora Core 3: SRPM: http://download.fedoralegacy.org/fedora/3/updates/SRPMS/gnupg-1.2.7-1.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/3/updates/i386/gnupg-1.2.7-1.2.legacy.i386.rpm x86_64: http://download.fedoralegacy.org/fedora/3/updates/x86_64/gnupg-1.2.7-1.2.legacy.x86_64.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 8908e71fbca5c2bae5f3aadd774e42a49a5cb957 redhat/7.3/updates/i386/gnupg-1.0.7-13.3.legacy.i386.rpm dd9dc31630ca66faffb4f214f425b973cb3212cf redhat/7.3/updates/SRPMS/gnupg-1.0.7-13.3.legacy.src.rpm b551dcbc9739ca6af6ca175c61709d5a4209fee6 redhat/9/updates/i386/gnupg-1.2.1-9.2.legacy.i386.rpm 937e799801ee740b3076aaf7bae40aedad8150bf redhat/9/updates/SRPMS/gnupg-1.2.1-9.2.legacy.src.rpm 69c6c0d7cd4250e7e9ce1dc67ce4f3da3ee3b810 fedora/1/updates/i386/gnupg-1.2.3-2.2.legacy.i386.rpm b0f065bc8326fdc3f842dbc368be479f5d6b27c0 fedora/1/updates/SRPMS/gnupg-1.2.3-2.2.legacy.src.rpm 4c9c5887459282cf336cc18c161eb3a243ea4b6d fedora/2/updates/i386/gnupg-1.2.4-2.3.legacy.i386.rpm ffdee44401e55625c991eb20a6fcf316f0fae7c9 fedora/2/updates/SRPMS/gnupg-1.2.4-2.3.legacy.src.rpm 56347e77b9f310b8b9f13b5105f50720d114660f fedora/3/updates/i386/gnupg-1.2.7-1.2.legacy.i386.rpm 42858f6256ed2aed3ebacaa1ea948ab245713ad6 fedora/3/updates/x86_64/gnupg-1.2.7-1.2.legacy.x86_64.rpm 66087d787f7707eb181ceff7e37d3f2ca624201a fedora/3/updates/SRPMS/gnupg-1.2.7-1.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-0049 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0455 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: 189 bytes Desc: OpenPGP digital signature URL: From jkeating at j2solutions.net Mon May 15 19:20:22 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 15 May 2006 15:20:22 -0400 Subject: Fedora products, to upgrade rather than backport? Message-ID: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> So in the RHL space, the choice was clear. Backport whenever possible. However the Fedora landscape is different. "Upstream" Core does not do backporting, they more often than not version upgrade to resolve security issues. Why should Legacy be any different? If we want to be transparent to end users we should follow what "upstream" does. Flames? 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 rostetter at mail.utexas.edu Mon May 15 19:29:03 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 15 May 2006 14:29:03 -0500 Subject: Fedora products, to upgrade rather than backport? In-Reply-To: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> References: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> Message-ID: <20060515142903.9h8qj5b09dwkcgcs@mail.ph.utexas.edu> Quoting Jesse Keating : > So in the RHL space, the choice was clear. Backport whenever possible. True. > However the Fedora landscape is different. "Upstream" Core does not do > backporting, they more often than not version upgrade to resolve > security issues. Why should Legacy be any different? Only because FL was originally "do no harm" type of philosophy, based on the idea that people would want stability, for example for servers. Now, one could argue that one shouldn't use FC for servers, and one shouldn't expect FC to be stable, and if so, one could say there is no reason to worry about backporting FC and that one should just upgrade packages. > If we want to be > transparent to end users we should follow what "upstream" does. Depends on what transparent means. If you want to be transparent in the sense of not breaking people's working machines, then no, you should backport. If you want to be transparent in the the sense of keeping with FC practices, then yes, you should upgrade instead of backporting. > Flames? Thoughts? No flames, only thoughts, and not very deep thoughts at that. > -- > 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 pekkas at netcore.fi Mon May 15 19:40:53 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 15 May 2006 22:40:53 +0300 (EEST) Subject: Fedora products, to upgrade rather than backport? In-Reply-To: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> References: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> Message-ID: On Mon, 15 May 2006, Jesse Keating wrote: > So in the RHL space, the choice was clear. Backport whenever possible. > However the Fedora landscape is different. "Upstream" Core does not do > backporting, they more often than not version upgrade to resolve > security issues. Why should Legacy be any different? If we want to be > transparent to end users we should follow what "upstream" does. My opinion here is: do whichever is the easiest. In some cases, doing a backport may be easier than upgrade [*]. One should also look at the approach chosen by other Fedora Core/RHEL releases. Other things being equal, prefer backporting. [*] For example: if you'd need to upgrade a package with a lot of dependencies which might need to be re-spun as well; or if the result would be a significant upgrade, getting assurance that the package would work, spec file updates required etc. could be significant 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 matt at followers.net Mon May 15 19:44:18 2006 From: matt at followers.net (Matt Nuzum) Date: Mon, 15 May 2006 14:44:18 -0500 Subject: Fedora products, to upgrade rather than backport? In-Reply-To: <20060515142903.9h8qj5b09dwkcgcs@mail.ph.utexas.edu> References: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> <20060515142903.9h8qj5b09dwkcgcs@mail.ph.utexas.edu> Message-ID: <27c475ec0605151244g7469561eq4fffc39ee0d87181@mail.gmail.com> On 5/15/06, Eric Rostetter wrote: > Quoting Jesse Keating : > > If we want to be > > transparent to end users we should follow what "upstream" does. > > Depends on what transparent means. If you want to be transparent in the > sense of not breaking people's working machines, then no, you should backport. > > If you want to be transparent in the the sense of keeping with FC practices, > then yes, you should upgrade instead of backporting. > > > Flames? Thoughts? > > No flames, only thoughts, and not very deep thoughts at that. Also not a flame... I've done this on some occassions in order to get up-to-date software onto my RH7.3 boxes and have found that dependency problems can make this *very* difficult. How concerned are you about this? My stuff is pretty application specific so inter-dependcy problems are minimal, but what about things like db3 or gd that are used across a lot of different packages? -- Matthew Nuzum www.followers.net - Makers of "Elite Content Management System" View samples of Elite CMS in action by visiting http://www.followers.net/portfolio/ From tseaver at palladion.com Mon May 15 19:53:03 2006 From: tseaver at palladion.com (Tres Seaver) Date: Mon, 15 May 2006 15:53:03 -0400 Subject: Fedora products, to upgrade rather than backport? In-Reply-To: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> References: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: > So in the RHL space, the choice was clear. Backport whenever possible. > However the Fedora landscape is different. "Upstream" Core does not do > backporting, they more often than not version upgrade to resolve > security issues. Why should Legacy be any different? If we want to be > transparent to end users we should follow what "upstream" does. > > Flames? Thoughts? - -1 to preferring upgrades. FL is about 'stability', which is an explicit non-goal for FC. Except in cases where a backport is more likely to create instability than an upgrade, we should prefer backporting. 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 iD8DBQFEaNwf+gerLs4ltQ4RAi+HAKCS4ndoHA8hkicsUMwIwmZJH4t7dACfZzUp wGPYc9TXtwNXeTYu/G8/9L0= =K3Rd -----END PGP SIGNATURE----- From smooge at gmail.com Mon May 15 19:57:12 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 15 May 2006 13:57:12 -0600 Subject: Fedora products, to upgrade rather than backport? In-Reply-To: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> References: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> Message-ID: <80d7e4090605151257r10143e60hbc40631f3a077a51@mail.gmail.com> On 5/15/06, Jesse Keating wrote: > So in the RHL space, the choice was clear. Backport whenever possible. > However the Fedora landscape is different. "Upstream" Core does not do > backporting, they more often than not version upgrade to resolve > security issues. Why should Legacy be any different? If we want to be > transparent to end users we should follow what "upstream" does. > I think that we should try and take some reasonable goals for timelines for security: What should our goal be for turn-around time be for a vulnerability? [Off the wall answers below.] Critical: 48 hours Moderate: 168 hours Low: 720 hours Second, how hard is it to backport? Hard: Code is no longer maintained and a quick patch attempt showed lots of collisions and rewrites. Moderate: Code is maintained, but code is different. Low: Patch was given for this version or code is only slightly different. Third, how expert are you (the patcher) on what the vulnerability is, what the code is, and how you are 'stopping' the vulnerability from being there. I think from those three, one could work out a decision tree on backporting or new release. In the case of new releases, we would make it part of the QA process to try and give a quick documentation of changes between old version and new version. > Flames? Thoughts? > > -- > Jesse Keating RHCE (geek.j2solutions.net) > Fedora Legacy Team (www.fedoralegacy.org) > GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (GNU/Linux) > > iD8DBQBEaNR24v2HLvE71NURAlEtAJ4j6pIvTI7HWRbEbO08JM1DRdz4EgCcC8fj > ZiIA6+ltESrc4RKxmK2298o= > =2J1I > -----END PGP SIGNATURE----- > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > > -- Stephen J Smoogen. CSIRT/Linux System Administrator From smooge at gmail.com Mon May 15 19:57:12 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 15 May 2006 13:57:12 -0600 Subject: Fedora products, to upgrade rather than backport? In-Reply-To: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> References: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> Message-ID: <80d7e4090605151257r10143e60hbc40631f3a077a51@mail.gmail.com> On 5/15/06, Jesse Keating wrote: > So in the RHL space, the choice was clear. Backport whenever possible. > However the Fedora landscape is different. "Upstream" Core does not do > backporting, they more often than not version upgrade to resolve > security issues. Why should Legacy be any different? If we want to be > transparent to end users we should follow what "upstream" does. > I think that we should try and take some reasonable goals for timelines for security: What should our goal be for turn-around time be for a vulnerability? [Off the wall answers below.] Critical: 48 hours Moderate: 168 hours Low: 720 hours Second, how hard is it to backport? Hard: Code is no longer maintained and a quick patch attempt showed lots of collisions and rewrites. Moderate: Code is maintained, but code is different. Low: Patch was given for this version or code is only slightly different. Third, how expert are you (the patcher) on what the vulnerability is, what the code is, and how you are 'stopping' the vulnerability from being there. I think from those three, one could work out a decision tree on backporting or new release. In the case of new releases, we would make it part of the QA process to try and give a quick documentation of changes between old version and new version. > Flames? Thoughts? > > -- > Jesse Keating RHCE (geek.j2solutions.net) > Fedora Legacy Team (www.fedoralegacy.org) > GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (GNU/Linux) > > iD8DBQBEaNR24v2HLvE71NURAlEtAJ4j6pIvTI7HWRbEbO08JM1DRdz4EgCcC8fj > ZiIA6+ltESrc4RKxmK2298o= > =2J1I > -----END PGP SIGNATURE----- > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > > -- Stephen J Smoogen. CSIRT/Linux System Administrator From jkeating at j2solutions.net Mon May 15 20:09:52 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 15 May 2006 16:09:52 -0400 Subject: Fedora products, to upgrade rather than backport? In-Reply-To: References: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> Message-ID: <1147723792.8578.27.camel@dhcp83-49.boston.redhat.com> On Mon, 2006-05-15 at 15:53 -0400, Tres Seaver wrote: > -1 to preferring upgrades. FL is about 'stability', which is an > explicit non-goal for FC. Except in cases where a backport is more > likely to create instability than an upgrade, we should prefer > backporting. > Sure, for RHL it is about stability. But with FC it was more about extending the lifespan. And to me, it really doesn't make sense to change the way in which the Fedora Project treats a release just because a different set of folks are touching it. I'm trying to establish a scenario where the Fedora Project as a whole has a certain lifespan for a Fedora (core+extras) release. An end user really shouldn't care how the updates are generated, just that they are published and announced in the same spaces, and that the content of said updates. -- 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 michal at harddata.com Mon May 15 20:07:47 2006 From: michal at harddata.com (Michal Jaegermann) Date: Mon, 15 May 2006 14:07:47 -0600 Subject: Fedora products, to upgrade rather than backport? In-Reply-To: <20060515142903.9h8qj5b09dwkcgcs@mail.ph.utexas.edu> References: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> <20060515142903.9h8qj5b09dwkcgcs@mail.ph.utexas.edu> Message-ID: <20060515200747.GA25848@mail.harddata.com> On Mon, May 15, 2006 at 02:29:03PM -0500, Eric Rostetter wrote: > > Depends on what transparent means. If you want to be transparent in the > sense of not breaking people's working machines, then no, you should > backport. When people intimately familiar with a given code, because they authored it, do not even attempt to provide security patches for older versions as internals were completely re-written and it is not even clear how to patch old holes, you expect that a small group of volunteers will do a deep analysis and come quickly with correct and safe patches for whatever? Such request is not even funny. In case you wonder the above was exactly the case with relatively recent updates to sendmail and is normally the case with mozilla (try to peek into that code and you will see why). What is more such "leaf" applications, as opposed to deeply intertwined libraries, are not a real problem - packaging hiccups notwithstanding. On one occasion I was replacing sendmail with a current version on a system with a provenience susbtantially earlier than whatever is supported by Legacy. It was not an issue. True, compile options had to be adjusted to what was available and a symlink or two was needed, and one had to be mildly careful with a configuration, but no real "show stoppers". Not mentioning, of course, that if you know proven patches to old versions then you should not sit on that information. Michal From marcdeslauriers at videotron.ca Mon May 15 20:14:13 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 15 May 2006 16:14:13 -0400 Subject: Fedora products, to upgrade rather than backport? In-Reply-To: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> References: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> Message-ID: <1147724053.2673.6.camel@mdlinux> On Mon, 2006-05-15 at 15:20 -0400, Jesse Keating wrote: > So in the RHL space, the choice was clear. Backport whenever possible. > However the Fedora landscape is different. "Upstream" Core does not do > backporting, they more often than not version upgrade to resolve > security issues. Why should Legacy be any different? If we want to be > transparent to end users we should follow what "upstream" does. Every time we've decided to upgrade a package instead of backporting security fixes, we've broken other stuff and have had to work twice as hard to get things back into working order. I don't think we have the resources to upgrade packages. Backporting is a lot less work... 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 jkeating at j2solutions.net Mon May 15 20:16:32 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 15 May 2006 16:16:32 -0400 Subject: Fedora products, to upgrade rather than backport? In-Reply-To: <1147724053.2673.6.camel@mdlinux> References: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> <1147724053.2673.6.camel@mdlinux> Message-ID: <1147724192.8578.30.camel@dhcp83-49.boston.redhat.com> On Mon, 2006-05-15 at 16:14 -0400, Marc Deslauriers wrote: > > Every time we've decided to upgrade a package instead of backporting > security fixes, we've broken other stuff and have had to work twice as > hard to get things back into working order. > > I don't think we have the resources to upgrade packages. Backporting is > a lot less work... Odd, it would seem the opposite in most occasions to me. We've broken stuff on RHL releases sure, and even maybe FC1/2, but what about 3, and coming 4, and such? If we were better at checking broken deps and whatnot, would it not be easier to bump package A, respin B and C if necessary, then beating head on desk for a good long time trying to work out a backport when there is no backport available (like when our package version doesn't match any of the close RHELs to steal from?) -- 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 drees76 at gmail.com Mon May 15 20:29:36 2006 From: drees76 at gmail.com (David Rees) Date: Mon, 15 May 2006 13:29:36 -0700 Subject: Fedora products, to upgrade rather than backport? In-Reply-To: References: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> Message-ID: <72dbd3150605151329vc95bb5er4857e4eecbf7bd33@mail.gmail.com> On 5/15/06, Pekka Savola wrote: > My opinion here is: do whichever is the easiest. In some cases, doing > a backport may be easier than upgrade [*]. One should also look at > the approach chosen by other Fedora Core/RHEL releases. Other things > being equal, prefer backporting. This seems like a sane policy to me! -Dave From jkeating at j2solutions.net Mon May 15 20:34:36 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 15 May 2006 16:34:36 -0400 Subject: Fedora products, to upgrade rather than backport? In-Reply-To: <72dbd3150605151329vc95bb5er4857e4eecbf7bd33@mail.gmail.com> References: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> <72dbd3150605151329vc95bb5er4857e4eecbf7bd33@mail.gmail.com> Message-ID: <1147725276.8578.32.camel@dhcp83-49.boston.redhat.com> On Mon, 2006-05-15 at 13:29 -0700, David Rees wrote: > This seems like a sane policy to me! Honestly, I think this is the model that "upstream" fedora uses too. -- 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 marcdeslauriers at videotron.ca Mon May 15 20:40:10 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 15 May 2006 16:40:10 -0400 Subject: Fedora products, to upgrade rather than backport? In-Reply-To: <1147724192.8578.30.camel@dhcp83-49.boston.redhat.com> References: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> <1147724053.2673.6.camel@mdlinux> <1147724192.8578.30.camel@dhcp83-49.boston.redhat.com> Message-ID: <1147725611.2673.19.camel@mdlinux> On Mon, 2006-05-15 at 16:16 -0400, Jesse Keating wrote: > On Mon, 2006-05-15 at 16:14 -0400, Marc Deslauriers wrote: > > > > Every time we've decided to upgrade a package instead of backporting > > security fixes, we've broken other stuff and have had to work twice as > > hard to get things back into working order. > > > > I don't think we have the resources to upgrade packages. Backporting is > > a lot less work... > > Odd, it would seem the opposite in most occasions to me. We've broken > stuff on RHL releases sure, and even maybe FC1/2, but what about 3, and > coming 4, and such? FL updated PHP a while ago as FC had updated PHP and it seemed the easiest way to tackle the security issues. Of course, the newer PHP was broken so it introduced a bunch of new bugs and I got a ton of email about it. FL had to fix the problem, even though it never got fixed in FC because we broke people's applications. I have a bunch of other examples of upgrades causing grief for us. > If we were better at checking broken deps and > whatnot, would it not be easier to bump package A, respin B and C if > necessary, then beating head on desk for a good long time trying to work > out a backport when there is no backport available (like when our > package version doesn't match any of the close RHELs to steal from?) That works for relatively current releases, like fc4 and fc5. The problem with older releases is to get all the dependencies updated also. Updating gnome versions on a legacy distro is not a very fun thing to do :) Most security issues are easy fixes, and backports are available or aren't that much work. Of course, when the issue required substantial changes, even FL has released upgrades in the past. I'd say let's try and use backports, and use upgrades if it's the most logical solution. 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 jkeating at j2solutions.net Mon May 15 20:49:37 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 15 May 2006 16:49:37 -0400 Subject: Fedora products, to upgrade rather than backport? In-Reply-To: <1147725611.2673.19.camel@mdlinux> References: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> <1147724053.2673.6.camel@mdlinux> <1147724192.8578.30.camel@dhcp83-49.boston.redhat.com> <1147725611.2673.19.camel@mdlinux> Message-ID: <1147726177.8578.36.camel@dhcp83-49.boston.redhat.com> On Mon, 2006-05-15 at 16:40 -0400, Marc Deslauriers wrote: > I'd say let's try and use backports, and use upgrades if it's the most > logical solution. > And follow upstream example if possible. If "upstream" Fedora upgrades to fix an issue, we probably should to for the Fedora's we're supporting (shouldn't be more than 2 after this next transition), but if they decide to backport, we should as well. -- 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 Mon May 15 21:07:13 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 15 May 2006 16:07:13 -0500 Subject: Fedora products, to upgrade rather than backport? In-Reply-To: <80d7e4090605151257r10143e60hbc40631f3a077a51@mail.gmail.com> References: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> <80d7e4090605151257r10143e60hbc40631f3a077a51@mail.gmail.com> Message-ID: <20060515160713.d5ygv0b7tdgcs008@mail.ph.utexas.edu> Quoting Stephen John Smoogen : > I think that we should try and take some reasonable goals for > timelines for security: I don't think we have the man-power to set goals for all patches. But we should and do use the timeliness criterium for whether to backport or upgrade already. > Second, how hard is it to backport? We alread consider this, though we have no defined process for doing so. > Hard: Code is no longer maintained and a quick patch attempt showed > lots of collisions and rewrites. > Moderate: Code is maintained, but code is different. > Low: Patch was given for this version or code is only slightly different. Seems reasonable, and is probably how we already would approach the situation even though it isn't really quantified. But, it also needs to look at the other side of the coin, that of upgrading: How hard would it be to upgrade rather than backport: Hard: Requires the non-trivial updating of other packages too (e.g. 2.4 kernel to 2.6 kernel requires too many other changes to be reasonable, same for LVM1 to LVM2, etc). Moderate: Requires a lot of work for the end-user (e.g. upgrade apache 1.x to apache 2.x requires configuration changes, may break many modules or require module upgrades, etc). Easy: Upgrading this package does not require any other packages to be upgraded (or if it does, they are also trivial/easy), doesn't require configuration files be manually upgraded, etc. > Third, how expert are you (the patcher) on what the vulnerability is, > what the code is, and how you are 'stopping' the vulnerability from > being there. I'm not sure that should come into play per se. > I think from those three, one could work out a decision tree on > backporting or new release. In the case of new releases, we would make > it part of the QA process to try and give a quick documentation of > changes between old version and new version. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From rostetter at mail.utexas.edu Mon May 15 21:12:59 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 15 May 2006 16:12:59 -0500 Subject: Fedora products, to upgrade rather than backport? In-Reply-To: <1147723792.8578.27.camel@dhcp83-49.boston.redhat.com> References: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> <1147723792.8578.27.camel@dhcp83-49.boston.redhat.com> Message-ID: <20060515161259.i9eqdaow1hk4gocw@mail.ph.utexas.edu> Quoting Jesse Keating : > Sure, for RHL it is about stability. But with FC it was more about > extending the lifespan. And to me, it really doesn't make sense to > change the way in which the Fedora Project treats a release just because > a different set of folks are touching it. You can though think it does make sense to change the handling because it is EOL, independent of who is touching it. EOL means end of development which means end of upgrades, at least to some. One question is what size of upgrades are you talking about. There's a big difference in going from kernel 2.4.12 to 2.4.13 versus going from 2.4.12 to 2.6.10 (just made up version numbers, but you get the idea). Same with going from apache 1.x.5 to 1.x.6 versus going from apache 1.x.5 to apache 2.x.y. If the upgrade doesn't require other non-trivial upgrades, doesn't require too many other upgrades, doesn't require manual reconfiguration, doesn't break the command line API, doesn't break the system, then I don't have a problem with an upgrade. If the upgrade does any of the above, then I have a problem. > I'm trying to establish a scenario where the Fedora Project as a whole > has a certain lifespan for a Fedora (core+extras) release. An end user > really shouldn't care how the updates are generated, just that they are > published and announced in the same spaces, and that the content of said > updates. As long as they don't break more than they fix... > -- > 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 smooge at gmail.com Mon May 15 21:13:39 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 15 May 2006 15:13:39 -0600 Subject: Fedora products, to upgrade rather than backport? In-Reply-To: <20060515160713.d5ygv0b7tdgcs008@mail.ph.utexas.edu> References: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> <80d7e4090605151257r10143e60hbc40631f3a077a51@mail.gmail.com> <20060515160713.d5ygv0b7tdgcs008@mail.ph.utexas.edu> Message-ID: <80d7e4090605151413n6b4d11fbj722f00f1a9c7b73c@mail.gmail.com> On 5/15/06, Eric Rostetter wrote: > Quoting Stephen John Smoogen : > > > Third, how expert are you (the patcher) on what the vulnerability is, > > what the code is, and how you are 'stopping' the vulnerability from > > being there. > > I'm not sure that should come into play per se. > Does this explain it better? If you are not familiar with the code base and having to figure out a backpatch by hand (e.g. there is no available one for that release, etc), then how sure are you that you have fixed the security problem without opening another security problem? -- Stephen J Smoogen. CSIRT/Linux System Administrator From rostetter at mail.utexas.edu Mon May 15 21:16:59 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 15 May 2006 16:16:59 -0500 Subject: Fedora products, to upgrade rather than backport? In-Reply-To: <20060515200747.GA25848@mail.harddata.com> References: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> <20060515142903.9h8qj5b09dwkcgcs@mail.ph.utexas.edu> <20060515200747.GA25848@mail.harddata.com> Message-ID: <20060515161659.rjwyfj3jxn484kc4@mail.ph.utexas.edu> Quoting Michal Jaegermann : > On Mon, May 15, 2006 at 02:29:03PM -0500, Eric Rostetter wrote: >> >> Depends on what transparent means. If you want to be transparent in the >> sense of not breaking people's working machines, then no, you should >> backport. > > When people intimately familiar with a given code, because they > authored it, do not even attempt to provide security patches for > older versions as internals were completely re-written and it is > not even clear how to patch old holes, you expect that a small > group of volunteers will do a deep analysis and come quickly with > correct and safe patches for whatever? Such request is not even > funny. FL already has a policy, and it applies to RHL as well as FL. If the code can't reasonable be backported, we upgrade. End of discussion. > In case you wonder the above was exactly the case with relatively > recent updates to sendmail and is normally the case with mozilla > (try to peek into that code and you will see why). Yea, and postgresql, etc. But this isn't the issue at hand. > What is more such "leaf" applications, as opposed to deeply > intertwined libraries, are not a real problem - packaging hiccups > notwithstanding. They can be, like in the case of postgresql which requires you dump your DB, upgrade, restore the DB, or else you are SOL. And we already know how many people just set yum to do automatic updates and would be burned in such a case. Think about all the problems we would have if we upgraded from PHP 4.x to PHP 5.x. Man, that would be a nightmare for the users... > Michal -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From smooge at gmail.com Mon May 15 21:18:54 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 15 May 2006 15:18:54 -0600 Subject: Fedora products, to upgrade rather than backport? In-Reply-To: <20060515161259.i9eqdaow1hk4gocw@mail.ph.utexas.edu> References: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> <1147723792.8578.27.camel@dhcp83-49.boston.redhat.com> <20060515161259.i9eqdaow1hk4gocw@mail.ph.utexas.edu> Message-ID: <80d7e4090605151418m69e7f20k70dd908f52d7c492@mail.gmail.com> On 5/15/06, Eric Rostetter wrote: > Quoting Jesse Keating : > > > Sure, for RHL it is about stability. But with FC it was more about > > extending the lifespan. And to me, it really doesn't make sense to > > change the way in which the Fedora Project treats a release just because > > a different set of folks are touching it. > > > I'm trying to establish a scenario where the Fedora Project as a whole > > has a certain lifespan for a Fedora (core+extras) release. An end user > > really shouldn't care how the updates are generated, just that they are > > published and announced in the same spaces, and that the content of said > > updates. > > As long as they don't break more than they fix... > I think the problem with defining this is that the QA resources are even more limited than the developer resources. So a lot of problems do not get seen because we have a 3 'worksforme' and no "For Cthulhu's sake, don't push this" -- Stephen J Smoogen. CSIRT/Linux System Administrator From jkeating at j2solutions.net Mon May 15 21:23:23 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 15 May 2006 17:23:23 -0400 Subject: Fedora products, to upgrade rather than backport? In-Reply-To: <20060515161259.i9eqdaow1hk4gocw@mail.ph.utexas.edu> References: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> <1147723792.8578.27.camel@dhcp83-49.boston.redhat.com> <20060515161259.i9eqdaow1hk4gocw@mail.ph.utexas.edu> Message-ID: <1147728203.8578.44.camel@dhcp83-49.boston.redhat.com> On Mon, 2006-05-15 at 16:12 -0500, Eric Rostetter wrote: > You can though think it does make sense to change the handling because > it is EOL, independent of who is touching it. EOL means end of development > which means end of upgrades, at least to some. Can we agree to not use the term EOL in this way? I made a huge mistake in starting this trend. We really should be looking at 'EOL' as when _we_ stop touching it. It should be considered Maintenance Mode after Red Hat stops touching it. This line may blur if/when Core + Extras gets merged into one happy 'verse of packages maintained by a combination of external and internal folks, then the Maint Mode becomes a timeline issue not when RH stops touching it issue. Regardless, EOL shouldn't be until the Fedora Project in general stops touching it. > One question is what size of upgrades are you talking about. There's > a big difference in going from kernel 2.4.12 to 2.4.13 versus going > from 2.4.12 to 2.6.10 (just made up version numbers, but you get the idea). > Same with going from apache 1.x.5 to 1.x.6 versus going from apache > 1.x.5 to apache 2.x.y. True, those would be insane. -- 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 jkosin at beta.intcomgrp.com Mon May 15 21:28:20 2006 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Mon, 15 May 2006 17:28:20 -0400 Subject: Fedora products, to upgrade rather than backport? In-Reply-To: <1147726177.8578.36.camel@dhcp83-49.boston.redhat.com> References: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> <1147724053.2673.6.camel@mdlinux> <1147724192.8578.30.camel@dhcp83-49.boston.redhat.com> <1147725611.2673.19.camel@mdlinux> <1147726177.8578.36.camel@dhcp83-49.boston.redhat.com> Message-ID: <4468F274.9000004@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: > And follow upstream example if possible. If "upstream" Fedora > upgrades to fix an issue, we probably should to for the Fedora's > we're supporting (shouldn't be more than 2 after this next > transition), but if they decide to backport, we should as well. > I agree with Jesse here; but, I would like to add that the packages should be tested on the released platform by someone and not just released in this case. SendMail was a recent blunder of sorts because of this. - -James -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEaPJ0kNLDmnu1kSkRAolBAJ9tRSig3f1afywXIQIRENfqQCP5UACfdcne B1C0jnFOpzretFUs+PS5FtY= =ORAr -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From rostetter at mail.utexas.edu Mon May 15 21:33:08 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 15 May 2006 16:33:08 -0500 Subject: Fedora products, to upgrade rather than backport? In-Reply-To: <80d7e4090605151413n6b4d11fbj722f00f1a9c7b73c@mail.gmail.com> References: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> <80d7e4090605151257r10143e60hbc40631f3a077a51@mail.gmail.com> <20060515160713.d5ygv0b7tdgcs008@mail.ph.utexas.edu> <80d7e4090605151413n6b4d11fbj722f00f1a9c7b73c@mail.gmail.com> Message-ID: <20060515163308.f2sq3lsdv5s0s8gc@mail.ph.utexas.edu> Quoting Stephen John Smoogen : > On 5/15/06, Eric Rostetter wrote: >> Quoting Stephen John Smoogen : >> > >>> Third, how expert are you (the patcher) on what the vulnerability is, >>> what the code is, and how you are 'stopping' the vulnerability from >>> being there. >> >> I'm not sure that should come into play per se. >> > > Does this explain it better? > > If you are not familiar with the code base and having to figure out a > backpatch by hand (e.g. there is no available one for that release, > etc), then how sure are you that you have fixed the security problem > without opening another security problem? If you are upgrading the package to a vastly different version, how sure are you that you didn't open another security problem, or break something? -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From michal at harddata.com Mon May 15 22:49:34 2006 From: michal at harddata.com (Michal Jaegermann) Date: Mon, 15 May 2006 16:49:34 -0600 Subject: Fedora products, to upgrade rather than backport? In-Reply-To: <20060515161659.rjwyfj3jxn484kc4@mail.ph.utexas.edu> References: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> <20060515142903.9h8qj5b09dwkcgcs@mail.ph.utexas.edu> <20060515200747.GA25848@mail.harddata.com> <20060515161659.rjwyfj3jxn484kc4@mail.ph.utexas.edu> Message-ID: <20060515224934.GA29839@mail.harddata.com> On Mon, May 15, 2006 at 04:16:59PM -0500, Eric Rostetter wrote: > > Think about all the problems we would have if we upgraded from PHP 4.x > to PHP 5.x. Man, that would be a nightmare for the users... I never tried to imply that automatic "version chase" is a good thing, and is definitely bad in case of libraries, but there are situations when you simply do not have a choice. Avoiding security updates because you do not want to change versions is in general not an option. I also think that for systems where you really want a long-term stable software base you should use nowadays distros like RHEL, or "clones" like CentOS, and for other pushing them far beyond EOL quickly becomes more trouble then it is worth. Michal From marcdeslauriers at videotron.ca Tue May 16 00:15:01 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 15 May 2006 20:15:01 -0400 Subject: Fedora Legacy Test Update Notification: mozilla Message-ID: <44691985.9090702@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-189137-1 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189137 2006-05-15 --------------------------------------------------------------------- Name : mozilla Versions : rh7.3: mozilla-1.7.13-0.73.1.legacy Versions : rh9: mozilla-1.7.13-0.90.1.legacy Versions : fc1: mozilla-1.7.13-1.1.1.legacy Versions : fc2: mozilla-1.7.13-1.2.1.legacy Versions : fc3: mozilla-1.7.13-1.3.1.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. Several bugs were found in the way Mozilla processes malformed javascript. A malicious web page could modify the content of a different open web page, possibly stealing sensitive information or conducting a cross-site scripting attack. (CVE-2006-1731, CVE-2006-1732, CVE-2006-1741) Several bugs were found in the way Mozilla processes certain javascript actions. A malicious web page could execute arbitrary javascript instructions with the permissions of "chrome", allowing the page to steal sensitive information or install browser malware. (CVE-2006-1727, CVE-2006-1728, CVE-2006-1733, CVE-2006-1734, CVE-2006-1735, CVE-2006-1742) Several bugs were found in the way Mozilla processes malformed web pages. A carefully crafted malicious web page could cause the execution of arbitrary code as the user running Mozilla. (CVE-2006-0748, CVE-2006-0749, CVE-2006-1730, CVE-2006-1737, CVE-2006-1738, CVE-2006-1739, CVE-2006-1790) A bug was found in the way Mozilla displays the secure site icon. If a browser is configured to display the non-default secure site modal warning dialog, it may be possible to trick a user into believing they are viewing a secure site. (CVE-2006-1740) A bug was found in the way Mozilla allows javascript mutation events on "input" form elements. A malicious web page could be created in such a way that when a user submits a form, an arbitrary file could be uploaded to the attacker. (CVE-2006-1729) A bug was found in the way Mozilla executes in-line mail forwarding. If a user can be tricked into forwarding a maliciously crafted mail message as in-line content, it is possible for the message to execute javascript with the permissions of "chrome". (CVE-2006-0884) Users of Mozilla are advised to upgrade to these updated packages containing Mozilla version 1.7.13 which corrects these issues. --------------------------------------------------------------------- Changelogs rh7.3: * Sat Apr 22 2006 Marc Deslauriers 37:1.7.13-0.73.1.legacy - Updated to 1.7.13 to fix security issues rh9: * Sat Apr 22 2006 Marc Deslauriers 37:1.7.13-0.90.1.legacy - Updated to 1.7.13 to fix security issues fc1: * Fri Apr 21 2006 Marc Deslauriers 37:1.7.13-1.1.1.legacy - Updated to 1.7.13 to fix security issues fc2: * Fri Apr 21 2006 Marc Deslauriers 37:1.7.13-1.2.1.legacy - Updated to 1.7.13 to fix security issues fc3: * Fri Apr 21 2006 Marc Deslauriers 37:1.7.13-1.3.1.legacy - Updated to 1.7.13 to fix security issues --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh7.3: b7616c52ee2776f3577fcda0a0628c5ec6cffae7 redhat/7.3/updates-testing/i386/mozilla-1.7.13-0.73.1.legacy.i386.rpm a6234bd3b89616ce5b924a36c95ba1421b6b8ecf redhat/7.3/updates-testing/i386/mozilla-chat-1.7.13-0.73.1.legacy.i386.rpm 3d7b92d47b825f5a936c54ca63679916f428917e redhat/7.3/updates-testing/i386/mozilla-devel-1.7.13-0.73.1.legacy.i386.rpm 2b4c765543b3f4fc5ac04127ca70c70a33fddaec redhat/7.3/updates-testing/i386/mozilla-dom-inspector-1.7.13-0.73.1.legacy.i386.rpm c15eceb55105a87f8d5dc0db24b9cf95e815a5a2 redhat/7.3/updates-testing/i386/mozilla-js-debugger-1.7.13-0.73.1.legacy.i386.rpm 09dcdb176779a013efc6b1819e5391854d94a751 redhat/7.3/updates-testing/i386/mozilla-mail-1.7.13-0.73.1.legacy.i386.rpm 5126d56d8ff98dfdcd69ed6864821120fc959c55 redhat/7.3/updates-testing/i386/mozilla-nspr-1.7.13-0.73.1.legacy.i386.rpm d2db357f5fe0d1ffce22db18f7d95c96dcfcffa3 redhat/7.3/updates-testing/i386/mozilla-nspr-devel-1.7.13-0.73.1.legacy.i386.rpm 7b3a403f4981d5ffa676aa38e5699fca9e7c2f18 redhat/7.3/updates-testing/i386/mozilla-nss-1.7.13-0.73.1.legacy.i386.rpm 3eea1812fa6a6ef13ed8826cd7734bd266c9b0fb redhat/7.3/updates-testing/i386/mozilla-nss-devel-1.7.13-0.73.1.legacy.i386.rpm 46393b4afb72fcd8100de2c61b6531d9ffe1dbf5 redhat/7.3/updates-testing/i386/galeon-1.2.14-0.73.6.legacy.i386.rpm d7222582e0c6d2cb635e07d91f6ffd4f85d36a49 redhat/7.3/updates-testing/SRPMS/mozilla-1.7.13-0.73.1.legacy.src.rpm b437ce5a3b53a11730c42590f28f8a8437622a2f redhat/7.3/updates-testing/SRPMS/galeon-1.2.14-0.73.6.legacy.src.rpm rh9: 624c5f90520fba704ad4f66dbf90b1f1c957b13c redhat/9/updates-testing/i386/mozilla-1.7.13-0.90.1.legacy.i386.rpm d774d70acfa13e6fdfaed04fe99dc72f6d2ff9e8 redhat/9/updates-testing/i386/mozilla-chat-1.7.13-0.90.1.legacy.i386.rpm c97b2a1d23cdcec966ad0f578ae7ed54298e0539 redhat/9/updates-testing/i386/mozilla-devel-1.7.13-0.90.1.legacy.i386.rpm 494506d66fe98871e624009969ac642c98a1f812 redhat/9/updates-testing/i386/mozilla-dom-inspector-1.7.13-0.90.1.legacy.i386.rpm b844468a52354d6e9233a3f2b423c21879c7ca2f redhat/9/updates-testing/i386/mozilla-js-debugger-1.7.13-0.90.1.legacy.i386.rpm 2313fc46b0f7192d2e50675b978a6132fef9c7e3 redhat/9/updates-testing/i386/mozilla-mail-1.7.13-0.90.1.legacy.i386.rpm c37ce58b4bc86d84585e53c97ef63f3733ffa038 redhat/9/updates-testing/i386/mozilla-nspr-1.7.13-0.90.1.legacy.i386.rpm c99c3912597d83cdb161c1e2d4476985ebbe301f redhat/9/updates-testing/i386/mozilla-nspr-devel-1.7.13-0.90.1.legacy.i386.rpm 82f292d71571e66844a0b6b59252271bcf26c5a9 redhat/9/updates-testing/i386/mozilla-nss-1.7.13-0.90.1.legacy.i386.rpm 8da1e54eed9099c2dbb4c04e97157bf742128488 redhat/9/updates-testing/i386/mozilla-nss-devel-1.7.13-0.90.1.legacy.i386.rpm 99041c948b0fb28092be0b817e2f631b76a05614 redhat/9/updates-testing/i386/galeon-1.2.14-0.90.6.legacy.i386.rpm d20d8e1985145c55a185f67e4209a01f1654c0ac redhat/9/updates-testing/SRPMS/mozilla-1.7.13-0.90.1.legacy.src.rpm aa35ab30634d4f5018e3f3e7bb4c290a23e8b1f0 redhat/9/updates-testing/SRPMS/galeon-1.2.14-0.90.6.legacy.src.rpm fc1: 3d510a0a221fd0af801d32075cfec02b54e07422 fedora/1/updates-testing/i386/mozilla-1.7.13-1.1.1.legacy.i386.rpm becd9c7a44a82ccfbe3cf6b03f051ecd4a273131 fedora/1/updates-testing/i386/mozilla-chat-1.7.13-1.1.1.legacy.i386.rpm 1ba6d5e1f14397c25baebb208b3f94de04d46131 fedora/1/updates-testing/i386/mozilla-devel-1.7.13-1.1.1.legacy.i386.rpm bc3d9984f60bbe6794c205e3222c9ea2335bd42e fedora/1/updates-testing/i386/mozilla-dom-inspector-1.7.13-1.1.1.legacy.i386.rpm 27b23b8f5be8a15c8294a1a40b62aafd0c8b8da8 fedora/1/updates-testing/i386/mozilla-js-debugger-1.7.13-1.1.1.legacy.i386.rpm fac226fb8ed3c08bd5c38729ca4bdcb7cbfa7155 fedora/1/updates-testing/i386/mozilla-mail-1.7.13-1.1.1.legacy.i386.rpm 50de7263571cfdca103af679b2b4824cf5e4b733 fedora/1/updates-testing/i386/mozilla-nspr-1.7.13-1.1.1.legacy.i386.rpm 6864171e9ad26571bc9fae8c22d9b713e790e217 fedora/1/updates-testing/i386/mozilla-nspr-devel-1.7.13-1.1.1.legacy.i386.rpm 231222af647baca7cf8ad3aa70102baf065844ea fedora/1/updates-testing/i386/mozilla-nss-1.7.13-1.1.1.legacy.i386.rpm b2a45de48fd072f61c4887c9fb7b1e28d5ceb724 fedora/1/updates-testing/i386/mozilla-nss-devel-1.7.13-1.1.1.legacy.i386.rpm 4278190ae02b1ba55ab8f7bff797aa0b7c6367cf fedora/1/updates-testing/i386/epiphany-1.0.8-1.fc1.6.legacy.i386.rpm d7698a730ded9bf23f9cf50af0b311344d6a32c9 fedora/1/updates-testing/SRPMS/mozilla-1.7.13-1.1.1.legacy.src.rpm 98e8156234d0d70503b2e35958b6c16fd6af9839 fedora/1/updates-testing/SRPMS/epiphany-1.0.8-1.fc1.6.legacy.src.rpm fc2: 159c63cf7ea9fdc986cea0e5f5385dfb5b6305b4 fedora/2/updates-testing/i386/mozilla-1.7.13-1.2.1.legacy.i386.rpm f407853505e31c18da4b7f6cb381eda08f92e95a fedora/2/updates-testing/i386/mozilla-chat-1.7.13-1.2.1.legacy.i386.rpm 34b9bfcbadd11a46d9c8e83bb74cadb20f5e4923 fedora/2/updates-testing/i386/mozilla-devel-1.7.13-1.2.1.legacy.i386.rpm dee1265fd2e11184729411971ebbf78cb563a0e5 fedora/2/updates-testing/i386/mozilla-dom-inspector-1.7.13-1.2.1.legacy.i386.rpm c04910085005cd7e6df6f94ef59c97df8825c07b fedora/2/updates-testing/i386/mozilla-js-debugger-1.7.13-1.2.1.legacy.i386.rpm 4d7705a6ca92e8508dfc129f9d230b655fcaf1d5 fedora/2/updates-testing/i386/mozilla-mail-1.7.13-1.2.1.legacy.i386.rpm a77cbd95adaf8033fd41a79c8fa5834f5bf6966b fedora/2/updates-testing/i386/mozilla-nspr-1.7.13-1.2.1.legacy.i386.rpm bac22ca27bd47b5568016b836655c0205f412f07 fedora/2/updates-testing/i386/mozilla-nspr-devel-1.7.13-1.2.1.legacy.i386.rpm a2a5c35a60ce9a77776ca68f85540f4b36a5d687 fedora/2/updates-testing/i386/mozilla-nss-1.7.13-1.2.1.legacy.i386.rpm bc9bed78a37a55ee2c7c0447e28454117d75b2f5 fedora/2/updates-testing/i386/mozilla-nss-devel-1.7.13-1.2.1.legacy.i386.rpm 82050caf931b8f86483430536d1044ca0e18e26c fedora/2/updates-testing/i386/epiphany-1.2.10-0.2.7.legacy.i386.rpm fd3a6e7733046ab57d5d0578942b63039f60549f fedora/2/updates-testing/i386/devhelp-0.9.1-0.2.10.legacy.i386.rpm dbfc536e2d5fb26ae710550517d00eb7b5c1c425 fedora/2/updates-testing/i386/devhelp-devel-0.9.1-0.2.10.legacy.i386.rpm 7d3714941a249cf2706860c80d5fdd2f6f9d6a49 fedora/2/updates-testing/SRPMS/mozilla-1.7.13-1.2.1.legacy.src.rpm b63f40f2d2c84c6a23ba9668a0ad523600208b88 fedora/2/updates-testing/SRPMS/epiphany-1.2.10-0.2.7.legacy.src.rpm e0d504c88489904fe8c94cf552ba4c91ba78dd69 fedora/2/updates-testing/SRPMS/devhelp-0.9.1-0.2.10.legacy.src.rpm fc3: fc30ba78ef98ffc0f4d7830a293a5a45532487a1 fedora/3/updates-testing/i386/mozilla-1.7.13-1.3.1.legacy.i386.rpm 6046bfef309c48de5545ded1dff026bda82aa12a fedora/3/updates-testing/i386/mozilla-chat-1.7.13-1.3.1.legacy.i386.rpm 2cb20e33c2931ce7f12a0149b8a2f1992ff47459 fedora/3/updates-testing/i386/mozilla-devel-1.7.13-1.3.1.legacy.i386.rpm 182a9e1a32e9d354b6ffedb5b7be7dd49192b119 fedora/3/updates-testing/i386/mozilla-dom-inspector-1.7.13-1.3.1.legacy.i386.rpm fbac943985224c5bdbbce8b83157614f48f2c11d fedora/3/updates-testing/i386/mozilla-js-debugger-1.7.13-1.3.1.legacy.i386.rpm dc733cb3312c3d105e4414bf969e84ddfa5ff435 fedora/3/updates-testing/i386/mozilla-mail-1.7.13-1.3.1.legacy.i386.rpm fd7ef3c6ab771fd368c81bd1925c0194c0503dc7 fedora/3/updates-testing/i386/mozilla-nspr-1.7.13-1.3.1.legacy.i386.rpm 6ca450fb3bda3d9acc3e9dcd86c7480fda7c881b fedora/3/updates-testing/i386/mozilla-nspr-devel-1.7.13-1.3.1.legacy.i386.rpm 25d618ca1f740e9ce6a8d18878dcef447f0dcfbe fedora/3/updates-testing/i386/mozilla-nss-1.7.13-1.3.1.legacy.i386.rpm f61c46c5e3a6bbfcd84c1d1db0948ad351568cfb fedora/3/updates-testing/i386/mozilla-nss-devel-1.7.13-1.3.1.legacy.i386.rpm 3d0a3210e82fe5059d4dd97dfad797522a8dd566 fedora/3/updates-testing/i386/epiphany-1.4.9-1.1.legacy.i386.rpm 9e1b3c5029b1da72303b87566d0fe98ae80316ad fedora/3/updates-testing/i386/epiphany-devel-1.4.9-1.1.legacy.i386.rpm 2700c95dbed803c53f4a632d818df4e6045abede fedora/3/updates-testing/i386/devhelp-0.9.2-2.3.7.legacy.i386.rpm 0635473154c90a0654938e15eea3e0fab24cbcee fedora/3/updates-testing/i386/devhelp-devel-0.9.2-2.3.7.legacy.i386.rpm 2b9902cc94ef38dac784342d1330cdb34a0308c2 fedora/3/updates-testing/x86_64/mozilla-1.7.13-1.3.1.legacy.x86_64.rpm d6c6635c7a9004b90a20ff32330f3e2aef755e7e fedora/3/updates-testing/x86_64/mozilla-chat-1.7.13-1.3.1.legacy.x86_64.rpm ec5ca5851ea31e60f5211d4f308b2d4eae65e97b fedora/3/updates-testing/x86_64/mozilla-devel-1.7.13-1.3.1.legacy.x86_64.rpm 74ac4472c45fecb4562fe73c1aba2c8fbc381da6 fedora/3/updates-testing/x86_64/mozilla-dom-inspector-1.7.13-1.3.1.legacy.x86_64.rpm 0b136eb099b9262271d29d1c55f08e3623fd9b9e fedora/3/updates-testing/x86_64/mozilla-js-debugger-1.7.13-1.3.1.legacy.x86_64.rpm 45aaade65400ab18d12525de0949a96d06c1d784 fedora/3/updates-testing/x86_64/mozilla-mail-1.7.13-1.3.1.legacy.x86_64.rpm fd7ef3c6ab771fd368c81bd1925c0194c0503dc7 fedora/3/updates-testing/x86_64/mozilla-nspr-1.7.13-1.3.1.legacy.i386.rpm 19919ed666049efdb10a571441b32733e3a928c9 fedora/3/updates-testing/x86_64/mozilla-nspr-1.7.13-1.3.1.legacy.x86_64.rpm 2020bad33430a1c9cf6e9298fb3ea8f264262e23 fedora/3/updates-testing/x86_64/mozilla-nspr-devel-1.7.13-1.3.1.legacy.x86_64.rpm 25d618ca1f740e9ce6a8d18878dcef447f0dcfbe fedora/3/updates-testing/x86_64/mozilla-nss-1.7.13-1.3.1.legacy.i386.rpm 1c9d432246665f03ad4c24c7a21ed2d40eea736c fedora/3/updates-testing/x86_64/mozilla-nss-1.7.13-1.3.1.legacy.x86_64.rpm 2e47b9e82c433533cd3e39c2380c511e03e9b320 fedora/3/updates-testing/x86_64/mozilla-nss-devel-1.7.13-1.3.1.legacy.x86_64.rpm 8e763b21f9289a454484fa65ed27053f87b83527 fedora/3/updates-testing/x86_64/epiphany-1.4.9-1.1.legacy.x86_64.rpm a5b5f6d6dbbb2385a13d8b5290d92c119c837c43 fedora/3/updates-testing/x86_64/epiphany-devel-1.4.9-1.1.legacy.x86_64.rpm 54b0234a8abf2b04f45b8062806bc500347a0ce2 fedora/3/updates-testing/x86_64/devhelp-0.9.2-2.3.7.legacy.x86_64.rpm 18374065d2a67b4d0838e4c63bff44d25658ff53 fedora/3/updates-testing/x86_64/devhelp-devel-0.9.2-2.3.7.legacy.x86_64.rpm 5a9ebd563c86b57673ee717a777b2b828cb6f7ae fedora/3/updates-testing/SRPMS/mozilla-1.7.13-1.3.1.legacy.src.rpm 9b7f3d9405d50fb5f52931ef8f18d9e1f2b4fe58 fedora/3/updates-testing/SRPMS/epiphany-1.4.9-1.1.legacy.src.rpm 71a4112fbd0411c57a8b37ba2179b7ec5b8f024e fedora/3/updates-testing/SRPMS/devhelp-0.9.2-2.3.7.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 Tue May 16 00:15:30 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 15 May 2006 20:15:30 -0400 Subject: Fedora Legacy Test Update Notification: firefox Message-ID: <446919A2.9080706@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-189137-2 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189137 2006-05-15 --------------------------------------------------------------------- Name : firefox Versions : fc3: firefox-1.0.8-1.1.fc3.1.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. Several bugs were found in the way Firefox processes malformed javascript. A malicious web page could modify the content of a different open web page, possibly stealing sensitive information or conducting a cross-site scripting attack. (CVE-2006-1731, CVE-2006-1732, CVE-2006-1741) Several bugs were found in the way Firefox processes certain javascript actions. A malicious web page could execute arbitrary javascript instructions with the permissions of "chrome", allowing the page to steal sensitive information or install browser malware. (CVE-2006-1727, CVE-2006-1728, CVE-2006-1733, CVE-2006-1734, CVE-2006-1735, CVE-2006-1742) Several bugs were found in the way Firefox processes malformed web pages. A carefully crafted malicious web page could cause the execution of arbitrary code as the user running Firefox. (CVE-2006-0748, CVE-2006-0749, CVE-2006-1724, CVE-2006-1730, CVE-2006-1737, CVE-2006-1738, CVE-2006-1739, CVE-2006-1790) A bug was found in the way Firefox displays the secure site icon. If a browser is configured to display the non-default secure site modal warning dialog, it may be possible to trick a user into believing they are viewing a secure site. (CVE-2006-1740) A bug was found in the way Firefox allows javascript mutation events on "input" form elements. A malicious web page could be created in such a way that when a user submits a form, an arbitrary file could be uploaded to the attacker. (CVE-2006-1729) Users of Firefox are advised to upgrade to these updated packages containing Firefox version 1.0.8 which corrects these issues. --------------------------------------------------------------------- Changelogs fc3: * Wed Apr 19 2006 Marc Deslauriers 0:1.0.8-1.1.fc3.1.legacy - Update to firefox 1.0.8 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) fc3: 8b719bb18c6dfe14b472c684ac5133d82d1b96d0 fedora/3/updates-testing/i386/firefox-1.0.8-1.1.fc3.1.legacy.i386.rpm 946f2ccbc412675ee6959a3dee50c2cb3ba90c3a fedora/3/updates-testing/x86_64/firefox-1.0.8-1.1.fc3.1.legacy.x86_64.rpm 0747aa65730e328a9274ec66c0de8dc30645dc1d fedora/3/updates-testing/SRPMS/firefox-1.0.8-1.1.fc3.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 Tue May 16 00:16:08 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 15 May 2006 20:16:08 -0400 Subject: Fedora Legacy Test Update Notification: xorg-x11 Message-ID: <446919C8.1000609@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-190777 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190777 2006-05-15 --------------------------------------------------------------------- Name : xorg-x11 Versions : fc3: xorg-x11-6.8.2-1.FC3.45.3.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 such as GNOME and KDE are designed upon. A buffer overflow flaw in the X.org server RENDER extension was discovered. A malicious authorized client could exploit this issue to cause a denial of service (crash) or potentially execute arbitrary code with root privileges on the X.org server. (CVE-2006-1526) Users of X.org should upgrade to these updated packages, which contain a backported patch and is not vulnerable to this issue. --------------------------------------------------------------------- Changelogs fc3: * Thu May 04 2006 Marc Deslauriers 6.8.2-1.FC3.45.3.legacy - Added xorg-x11-6.8.2-render-tris-CVE-2006-1526.patch to fix a buffer overflow documented in CVE-2006-1526. --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) fc3: 6c4f8cc2a12da27bc7eba148b139bbbc0c16c877 fedora/3/updates-testing/i386/xorg-x11-6.8.2-1.FC3.45.3.legacy.i386.rpm 3f94f87fb882c2f5116fc7e153db8a27b47902d9 fedora/3/updates-testing/i386/xorg-x11-deprecated-libs-6.8.2-1.FC3.45.3.legacy.i386.rpm 7f4c16bed758307fc89963cdc0e60d6104690384 fedora/3/updates-testing/i386/xorg-x11-deprecated-libs-devel-6.8.2-1.FC3.45.3.legacy.i386.rpm 07b928bdc56bc8d2fe0828afbe59d8dfcfabbede fedora/3/updates-testing/i386/xorg-x11-devel-6.8.2-1.FC3.45.3.legacy.i386.rpm c7adb504db755f139b2b8454c37b6add3204c2b0 fedora/3/updates-testing/i386/xorg-x11-doc-6.8.2-1.FC3.45.3.legacy.i386.rpm dd5caa2e8fadf2eff908615231819cf69cf130ea fedora/3/updates-testing/i386/xorg-x11-font-utils-6.8.2-1.FC3.45.3.legacy.i386.rpm 8e30c1a599b8f2bb39abdce9dbd9c0559926f63e fedora/3/updates-testing/i386/xorg-x11-libs-6.8.2-1.FC3.45.3.legacy.i386.rpm 23fc45993a3e83844ad2029653c580e9c9fba606 fedora/3/updates-testing/i386/xorg-x11-Mesa-libGL-6.8.2-1.FC3.45.3.legacy.i386.rpm 13b96e8dca25068c884a5bdf2fd188f684472eb5 fedora/3/updates-testing/i386/xorg-x11-Mesa-libGLU-6.8.2-1.FC3.45.3.legacy.i386.rpm 2ecbdbc243d2fed742d56b7183367625c318029a fedora/3/updates-testing/i386/xorg-x11-sdk-6.8.2-1.FC3.45.3.legacy.i386.rpm 7bba05d923dde98a77233a5cb4ef7b67660ad345 fedora/3/updates-testing/i386/xorg-x11-tools-6.8.2-1.FC3.45.3.legacy.i386.rpm 9d51ef13a3ba67eb4afe4e4417ff1735cf659829 fedora/3/updates-testing/i386/xorg-x11-twm-6.8.2-1.FC3.45.3.legacy.i386.rpm 61201dd9054fbe6336381d9532f3d0ec60d9b537 fedora/3/updates-testing/i386/xorg-x11-xauth-6.8.2-1.FC3.45.3.legacy.i386.rpm 8c0f9419d979a3defbe376693c1d39cbdb8eeabb fedora/3/updates-testing/i386/xorg-x11-xdm-6.8.2-1.FC3.45.3.legacy.i386.rpm 132c26d0cc1fe2c5e3946aae493a6bf16ec8b659 fedora/3/updates-testing/i386/xorg-x11-Xdmx-6.8.2-1.FC3.45.3.legacy.i386.rpm 9f71fe79b510f7dd06a41b01eeb5c4850ee88411 fedora/3/updates-testing/i386/xorg-x11-xfs-6.8.2-1.FC3.45.3.legacy.i386.rpm 2b36b8679d782f6d1f0899262d1ad961fb3703e0 fedora/3/updates-testing/i386/xorg-x11-Xnest-6.8.2-1.FC3.45.3.legacy.i386.rpm aba6d27d8bb5befdb4694546b66cbc88d945973b fedora/3/updates-testing/i386/xorg-x11-Xvfb-6.8.2-1.FC3.45.3.legacy.i386.rpm 9ac2f2b492165554bb358c39d8e4d031e1a4ee1b fedora/3/updates-testing/x86_64/xorg-x11-6.8.2-1.FC3.45.3.legacy.x86_64.rpm 3f94f87fb882c2f5116fc7e153db8a27b47902d9 fedora/3/updates-testing/x86_64/xorg-x11-deprecated-libs-6.8.2-1.FC3.45.3.legacy.i386.rpm 26d851236ece4e649845a0923420b5a257cd1bde fedora/3/updates-testing/x86_64/xorg-x11-deprecated-libs-6.8.2-1.FC3.45.3.legacy.x86_64.rpm c19744109a7e088d79f7ced7349af8ac8ed5d561 fedora/3/updates-testing/x86_64/xorg-x11-deprecated-libs-devel-6.8.2-1.FC3.45.3.legacy.x86_64.rpm 07b928bdc56bc8d2fe0828afbe59d8dfcfabbede fedora/3/updates-testing/x86_64/xorg-x11-devel-6.8.2-1.FC3.45.3.legacy.i386.rpm 8f030968d84bcd3d602eb7aaf836a0d15b75c44d fedora/3/updates-testing/x86_64/xorg-x11-devel-6.8.2-1.FC3.45.3.legacy.x86_64.rpm a1337070e3c6362133fde9d7779edf7533072133 fedora/3/updates-testing/x86_64/xorg-x11-doc-6.8.2-1.FC3.45.3.legacy.x86_64.rpm a7feafa8ded15cf48d844366c1e3be37f23a1cfd fedora/3/updates-testing/x86_64/xorg-x11-font-utils-6.8.2-1.FC3.45.3.legacy.x86_64.rpm 8e30c1a599b8f2bb39abdce9dbd9c0559926f63e fedora/3/updates-testing/x86_64/xorg-x11-libs-6.8.2-1.FC3.45.3.legacy.i386.rpm 0eaa41f3cf3ac8871444908aafc1691a0008e0d5 fedora/3/updates-testing/x86_64/xorg-x11-libs-6.8.2-1.FC3.45.3.legacy.x86_64.rpm 23fc45993a3e83844ad2029653c580e9c9fba606 fedora/3/updates-testing/x86_64/xorg-x11-Mesa-libGL-6.8.2-1.FC3.45.3.legacy.i386.rpm 6a0b603f3acb00c85ea9d20148ecba46e7d21368 fedora/3/updates-testing/x86_64/xorg-x11-Mesa-libGL-6.8.2-1.FC3.45.3.legacy.x86_64.rpm 13b96e8dca25068c884a5bdf2fd188f684472eb5 fedora/3/updates-testing/x86_64/xorg-x11-Mesa-libGLU-6.8.2-1.FC3.45.3.legacy.i386.rpm 1c479506c5b7ebd1d49063770233d431fc754004 fedora/3/updates-testing/x86_64/xorg-x11-Mesa-libGLU-6.8.2-1.FC3.45.3.legacy.x86_64.rpm b4f4b333906a9eeed08eb6ffcb830f8584c478dd fedora/3/updates-testing/x86_64/xorg-x11-sdk-6.8.2-1.FC3.45.3.legacy.x86_64.rpm 0f661c108936ea85fe38a478ee45b5bf8058b3ca fedora/3/updates-testing/x86_64/xorg-x11-tools-6.8.2-1.FC3.45.3.legacy.x86_64.rpm 37ad2d9f35dd213b684dda7513d98420daf4834e fedora/3/updates-testing/x86_64/xorg-x11-twm-6.8.2-1.FC3.45.3.legacy.x86_64.rpm 33705cb293a6bfe37e55244153e5e23175d2c4e2 fedora/3/updates-testing/x86_64/xorg-x11-xauth-6.8.2-1.FC3.45.3.legacy.x86_64.rpm 2771026feae63c0362bfa5daa6d9666d5b8acc89 fedora/3/updates-testing/x86_64/xorg-x11-xdm-6.8.2-1.FC3.45.3.legacy.x86_64.rpm 5d03a8e36c3c9474d4de53d3d7cc2c7d7d936528 fedora/3/updates-testing/x86_64/xorg-x11-Xdmx-6.8.2-1.FC3.45.3.legacy.x86_64.rpm 46afe47ebc3548b092fa74d831cdbb80a1092213 fedora/3/updates-testing/x86_64/xorg-x11-xfs-6.8.2-1.FC3.45.3.legacy.x86_64.rpm 60276aa97510fc4be52aa3720a0d20a650a0c968 fedora/3/updates-testing/x86_64/xorg-x11-Xnest-6.8.2-1.FC3.45.3.legacy.x86_64.rpm 21260daa99910a143934800229f7acfc9f256b75 fedora/3/updates-testing/x86_64/xorg-x11-Xvfb-6.8.2-1.FC3.45.3.legacy.x86_64.rpm 699a18fb173a9e3a23e9fd653e152d73e7aae737 fedora/3/updates-testing/SRPMS/xorg-x11-6.8.2-1.FC3.45.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 Tue May 16 00:16:30 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 15 May 2006 20:16:30 -0400 Subject: Fedora Legacy Test Update Notification: ipsec-tools Message-ID: <446919DE.6020000@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-190941 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190941 2006-05-15 --------------------------------------------------------------------- Name : ipsec-tools Versions : fc2: ipsec-tools-0.5-2.fc2.1.legacy Versions : fc3: ipsec-tools-0.5-2.fc3.1.legacy Summary : Tools for configuring and using IPSEC Description : This is the IPsec-Tools package. You need this package in order to really use the IPsec functionality in the linux-2.5+ kernels. --------------------------------------------------------------------- Update Information: Updated ipsec-tools packages that fix a bug in racoon are now available. The ipsec-tools package is used in conjunction with the IPsec functionality in the linux kernel and includes racoon, an IKEv1 keying daemon. A denial of service flaw was found in the ipsec-tools racoon daemon. If a victim's machine has racoon configured in a non-recommended insecure manner, it is possible for a remote attacker to crash the racoon daemon. (CVE-2005-3732) Users of ipsec-tools should upgrade to these updated packages, which contain backported patches, and are not vulnerable to these issues. --------------------------------------------------------------------- Changelogs fc2: * Sat May 06 2006 Marc Deslauriers 0.5-2.fc2.1.legacy - add patch for DoS (CVE-2005-3732) fc3: * Sat May 06 2006 Marc Deslauriers 0.5-2.fc3.1.legacy - add patch for DoS (CVE-2005-3732) --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) fc2: e8f91c085fb9533106c6ebc442572bd0b22f2470 fedora/2/updates-testing/i386/ipsec-tools-0.5-2.fc2.1.legacy.i386.rpm 292a0a1426bc75abf0b34a3c91279a40ea78aac2 fedora/2/updates-testing/SRPMS/ipsec-tools-0.5-2.fc2.1.legacy.src.rpm fc3: e49b07bcc0e3dbe56401056b65b36133dabb4b6c fedora/3/updates-testing/i386/ipsec-tools-0.5-2.fc3.1.legacy.i386.rpm 10eed18767204b88c2811115d889c0a372079ec2 fedora/3/updates-testing/x86_64/ipsec-tools-0.5-2.fc3.1.legacy.x86_64.rpm 0832eb1da62b597bc32b26ce9e8429d7e67f43d2 fedora/3/updates-testing/SRPMS/ipsec-tools-0.5-2.fc3.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 Tue May 16 00:16:51 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 15 May 2006 20:16:51 -0400 Subject: Fedora Legacy Test Update Notification: squirrelmail Message-ID: <446919F3.4090801@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-190884 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190884 2006-05-15 --------------------------------------------------------------------- Name : squirrelmail Versions : rh9: squirrelmail-1.4.6-3.rh9.1.legacy Versions : fc1: squirrelmail-1.4.6-4.fc1.1.legacy Versions : fc2: squirrelmail-1.4.6-4.fc2.1.legacy Versions : fc3: squirrelmail-1.4.6-4.fc3.1.legacy Summary : SquirrelMail webmail client Description : SquirrelMail is a standards-based webmail package written in PHP4. It includes built-in pure PHP support for the IMAP and SMTP protocols, and all pages render in pure HTML 4.0 (with no Javascript) for maximum compatibility across browsers. It has very few requirements and is very easy to configure and install. SquirrelMail has a all the functionality you would want from an email client, including strong MIME support, address books, and folder manipulation. --------------------------------------------------------------------- Update Information: An updated squirrelmail package that fixes three security and many other bug issues is now available. SquirrelMail is a standards-based webmail package written in PHP4. A bug was found in the way SquirrelMail presents the right frame to the user. If a user can be tricked into opening a carefully crafted URL, it is possible to present the user with arbitrary HTML data. (CVE-2006-0188) A bug was found in the way SquirrelMail filters incoming HTML email. It is possible to cause a victim's web browser to request remote content by opening a HTML email while running a web browser that processes certain types of invalid style sheets. Only Internet Explorer is known to process such malformed style sheets. (CVE-2006-0195) A bug was found in the way SquirrelMail processes a request to select an IMAP mailbox. If a user can be tricked into opening a carefully crafted URL, it is possible to execute arbitrary IMAP commands as the user viewing their mail with SquirrelMail. (CVE-2006-0377) Users of SquirrelMail are advised to upgrade to this updated package, which contains SquirrelMail version 1.4.6 and is not vulnerable to these issues. --------------------------------------------------------------------- Changelogs rh9: * Fri May 05 2006 Marc Deslauriers 1.4.6-3.rh9.1.legacy - Rebuilt as Fedora Legacy update for rh9 - Remove default_folder_prefix changes - Remove php-mbstring Requires fc1: * Fri May 05 2006 Marc Deslauriers 1.4.6-4.fc1.1.legacy - Rebuilt as Fedora Legacy update for fc1 - Remove default_folder_prefix changes fc2: * Fri May 05 2006 Marc Deslauriers 1.4.6-4.fc2.1.legacy - Rebuilt as Fedora Legacy update for fc2 fc3: * Fri May 05 2006 Marc Deslauriers 1.4.6-4.fc3.1.legacy - Rebuilt as Fedora Legacy update for fc3 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh9: 62ae72ed168667c97e1b6ccc5bc23dea6c374bcb redhat/9/updates-testing/i386/squirrelmail-1.4.6-3.rh9.1.legacy.noarch.rpm 51264756a2f2bb5d8e6f5b6d1d33dcba40f41a68 redhat/9/updates-testing/SRPMS/squirrelmail-1.4.6-3.rh9.1.legacy.src.rpm fc1: 0e2dbf765d4df6592fad31ff331a3101fd33674e fedora/1/updates-testing/i386/squirrelmail-1.4.6-4.fc1.1.legacy.noarch.rpm 7c6d183c795bfd1da1e872a74e7ff1f197afb93a fedora/1/updates-testing/SRPMS/squirrelmail-1.4.6-4.fc1.1.legacy.src.rpm fc2: 36bc9ae701f8844d6369dde0f2d4a537b2dce85c fedora/2/updates-testing/i386/squirrelmail-1.4.6-4.fc2.1.legacy.noarch.rpm 60098c585bc6bab9df4e3883e3a0b0762fd4dc6d fedora/2/updates-testing/SRPMS/squirrelmail-1.4.6-4.fc2.1.legacy.src.rpm fc3: 9e96352495249c4aa526b24729128696467ca728 fedora/3/updates-testing/i386/squirrelmail-1.4.6-4.fc3.1.legacy.noarch.rpm 3003904d9a5594cb6e3ebb190930bb9d82d83f60 fedora/3/updates-testing/SRPMS/squirrelmail-1.4.6-4.fc3.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 nils at lemonbit.nl Tue May 16 00:38:57 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Tue, 16 May 2006 02:38:57 +0200 Subject: Fedora products, to upgrade rather than backport? In-Reply-To: <1147728203.8578.44.camel@dhcp83-49.boston.redhat.com> References: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> <1147723792.8578.27.camel@dhcp83-49.boston.redhat.com> <20060515161259.i9eqdaow1hk4gocw@mail.ph.utexas.edu> <1147728203.8578.44.camel@dhcp83-49.boston.redhat.com> Message-ID: <768586F7-4AEF-4C32-9D88-BDA9381A46BC@lemonbit.nl> Jesse Keating wrote: > On Mon, 2006-05-15 at 16:12 -0500, Eric Rostetter wrote: >> You can though think it does make sense to change the handling >> because >> it is EOL, independent of who is touching it. EOL means end of >> development >> which means end of upgrades, at least to some. > > Can we agree to not use the term EOL in this way? I made a huge > mistake > in starting this trend. We really should be looking at 'EOL' as when > _we_ stop touching it. Maybe the front page of fedoralegacy.org should be changed as well then. It currently reads: "(...) The goal of The Fedora Legacy Project is to work with the Linux community to provide security and critical bug fix errata packages for select End of Life Red Hat Linux and Fedora Core distributions. (...)" Nils Breunese. From jkeating at j2solutions.net Tue May 16 00:41:32 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 15 May 2006 20:41:32 -0400 Subject: Fedora products, to upgrade rather than backport? In-Reply-To: <768586F7-4AEF-4C32-9D88-BDA9381A46BC@lemonbit.nl> References: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> <1147723792.8578.27.camel@dhcp83-49.boston.redhat.com> <20060515161259.i9eqdaow1hk4gocw@mail.ph.utexas.edu> <1147728203.8578.44.camel@dhcp83-49.boston.redhat.com> <768586F7-4AEF-4C32-9D88-BDA9381A46BC@lemonbit.nl> Message-ID: <1147740092.32161.7.camel@ender> On Tue, 2006-05-16 at 02:38 +0200, Nils Breunese (Lemonbit Internet) wrote: > > Maybe the front page of fedoralegacy.org should be changed as well > then. It currently reads: "(...) The goal of The Fedora Legacy > Project is to work with the Linux community to provide security and > critical bug fix errata packages for select End of Life Red Hat > Linux > and Fedora Core distributions. (...)" Yep, like I said, I made a big mistake in using this terminology in the first place. I also want to move our site over to fedoraproject.org space (they have a plone system coming up soon that will satisfy our non-dynamic content needs) and can do the editing as we go. -- 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 May 16 01:39:05 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 15 May 2006 20:39:05 -0500 Subject: Fedora products, to upgrade rather than backport? In-Reply-To: <20060515224934.GA29839@mail.harddata.com> References: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> <20060515142903.9h8qj5b09dwkcgcs@mail.ph.utexas.edu> <20060515200747.GA25848@mail.harddata.com> <20060515161659.rjwyfj3jxn484kc4@mail.ph.utexas.edu> <20060515224934.GA29839@mail.harddata.com> Message-ID: <20060515203905.desi3ugsdkgo8sc8@mail.ph.utexas.edu> Quoting Michal Jaegermann : > I never tried to imply that automatic "version chase" is a good > thing, and is definitely bad in case of libraries, but there are > situations when you simply do not have a choice. Avoiding security > updates because you do not want to change versions is in general > not an option. Exactly what I'm am saying. Now we just need consensus on what situations call for which method. To me, the existing methods are fine. Jesse raised the question of should we change it. I answered him honestly and simply. Then I replied to a bunch of other post, in which I took an extreme position to the conservative side, for no other reason than to counter the many extreme positions to the liberal. Kind of Devil's Advocate if you will. > I also think that for systems where you really want a long-term > stable software base you should use nowadays distros like RHEL, > or "clones" like CentOS, and for other pushing them far beyond > EOL quickly becomes more trouble then it is worth. Then why not just end the FL project? But seriously, it isn't just pushing them far beyond EOL. It is pushing them just slightly beyond EOL in many cases. I don't care if FC3 is pushed for more than 6 months. I just want some time to schedule an upgrade, not an indefinate lifetime. > Michal -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From jkosin at beta.intcomgrp.com Tue May 16 14:06:41 2006 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Tue, 16 May 2006 10:06:41 -0400 Subject: Fedora products, to upgrade rather than backport? In-Reply-To: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> References: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> Message-ID: <4469DC71.2030200@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: > So in the RHL space, the choice was clear. Backport whenever possible. > However the Fedora landscape is different. "Upstream" Core does not do > backporting, they more often than not version upgrade to resolve > security issues. Why should Legacy be any different? If we want to be > transparent to end users we should follow what "upstream" does. > > Flames? Thoughts? (1) A backport should be preferred over an outright upgrade in most circumstances. One example, we should not upgrade everyone to gcc-4.x just because upstream decides it fixes or performs better. This would break many things especially kernel trees. 2.4 kernels do not compile with 4.x of gcc and that group doing work on the 2.4 kernel have abandoned any support for 4.x of gcc. (2) System stability should factor into the equation. Many times the bleeding edge of technology is highly unstable or problematic. Like going from apache 1.x --> 2.0 or from 2.0 to 2.2. The large steps often break many things in the switch. My recent endeavor of updating subversion for web-dav for apache was a long process of updating package after package to fill all the new dependencies. Granted, I now have a full update for subversion for FC1 if anyone whats to use it; but, most people wouldn't want to take the chance that something is broken due to inadequate testing. (3) The less changes posed by a backport would be better than the massive amounts of changes in an upgrade or version bump. Which will mean more testing would be required for the later! This is a requirement for any large system changes. That said, even small changes can have a big impact on a system... Take the recent patches to apache for security issues have broken one of the features of Winki. I still am unable to login and have not heard anything from RedHat about any work on fixing this. I'm not bashing anyone on this issue; because it is not a frequently used feature when someone forgets their password. (4) We need to be sure we are not opening everyone up for a bigger problem of some security issue in the future with the newer versions of software. One of Linux's claim to security is the diversity of applications out there and the many differences between all the different versions. Virus writers need a stable platform to do their craft. If we fall into Windows trap of providing a common platform we open up the virus world to the Linux community in large scale attack. Security updates are important, but we also need to have a way of safeguarding the current users against attacks while the solution is merged in in a timely manner and fully tested to fix the problem and proven not to break anything catastrophically. - -James -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEadxwkNLDmnu1kSkRAs9QAJwMFvPxcdPTYR1dvq/Cs6qDP5XdxgCbBKYd b6GpiAJm+LKCWqIDhC/CBB0= =fQzC -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From jkeating at j2solutions.net Tue May 16 14:36:01 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 16 May 2006 10:36:01 -0400 Subject: Fedora products, to upgrade rather than backport? In-Reply-To: <4469DC71.2030200@beta.intcomgrp.com> References: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> <4469DC71.2030200@beta.intcomgrp.com> Message-ID: <1147790161.17182.6.camel@dhcp83-49.boston.redhat.com> On Tue, 2006-05-16 at 10:06 -0400, James Kosin wrote: > -James 1, 2, and 3, are totally great points for backport vs upgrade. I don't even begin to think that upgrading is a better solution. However I'm going for consistency with what our 'upstream' is doing. The Fedora project doesn't backport when it isn't easy, preferring to upgrade. I'm proposing that when we take over maintenance we do the same, when easy. -- 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 Tue May 16 14:42:16 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 16 May 2006 08:42:16 -0600 Subject: Fedora products, to upgrade rather than backport? In-Reply-To: <4469DC71.2030200@beta.intcomgrp.com> References: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> <4469DC71.2030200@beta.intcomgrp.com> Message-ID: <80d7e4090605160742p156a4265x14608a5194ef916@mail.gmail.com> On 5/16/06, James Kosin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jesse Keating wrote: > > So in the RHL space, the choice was clear. Backport whenever possible. > > However the Fedora landscape is different. "Upstream" Core does not do > > backporting, they more often than not version upgrade to resolve > > security issues. Why should Legacy be any different? If we want to be > > transparent to end users we should follow what "upstream" does. > > > > Flames? Thoughts? > (1) A backport should be preferred over an outright upgrade in most > circumstances. One example, we should not upgrade everyone to gcc-4.x > just because upstream decides it fixes or performs better. This would > break many things especially kernel trees. 2.4 kernels do not compile > with 4.x of gcc and that group doing work on the 2.4 kernel have > abandoned any support for 4.x of gcc. I would say that there are core items of any release that are what define the release and thus shouldnt be majorly upgraded kernel gcc glibc python perl come immediately to mind. something like pine may not be upgraded in say RHL-7 because of license changes. However at some point, we may just have to say "We cant fix this and will have to EOL this product chain because this vulnerability is too big." I mean if RHL-6 was on the list of products to be supported.. I would say that we don't have the expertise to fix glibc issues in it. > > (4) We need to be sure we are not opening everyone up for a bigger > problem of some security issue in the future with the newer versions > of software. One of Linux's claim to security is the diversity of > applications out there and the many differences between all the > different versions. Virus writers need a stable platform to do their > craft. If we fall into Windows trap of providing a common platform we > open up the virus world to the Linux community in large scale attack. > Security updates are important, but we also need to have a way of > safeguarding the current users against attacks while the solution is > merged in in a timely manner and fully tested to fix the problem and > proven not to break anything catastrophically. > This one is plain wrong. I address it because it used a lot and the quotes for truth are usually pointing to some mailing list where it was quoted before and no-one said otherwise. Malware writers need only a stable kernel ABI, and a stable libc ABI. The Linux malware I have seen works pretty much on any Linux platform because every distributor supplies a libc and a kernel that works with everyone else. The good ones work well in knowing the differences between say Apache-2.0 and Apache-1.3 and change tactics to deal with what is presented. The first reason that there are not large scale virus's for Linux is that it is a small percentage of the population and so doesn't have a good spreading mechanism (there is a difference if 2 machines on a network are chatty and 2000 machines). The second reason is that there isnt money in it for large scale virus attacks. It is more important to use small less noticable worms that create botmasters for windows farms or mine out data (credit cards, etc) from e-commerse sites. > -- Stephen J Smoogen. CSIRT/Linux System Administrator From jkosin at beta.intcomgrp.com Tue May 16 15:33:27 2006 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Tue, 16 May 2006 11:33:27 -0400 Subject: Fedora products, to upgrade rather than backport? In-Reply-To: <1147790161.17182.6.camel@dhcp83-49.boston.redhat.com> References: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> <4469DC71.2030200@beta.intcomgrp.com> <1147790161.17182.6.camel@dhcp83-49.boston.redhat.com> Message-ID: <4469F0C7.4080700@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: > 1, 2, and 3, are totally great points for backport vs upgrade. I > don't even begin to think that upgrading is a better solution. > However I'm going for consistency with what our 'upstream' is > doing. The Fedora project doesn't backport when it isn't easy, > preferring to upgrade. I'm proposing that when we take over > maintenance we do the same, when easy. > Ok, but then how difficult? One person's idea of difficult could be raising a finger to type something. Now we are going to have to define what is considered easy and what is difficult. I do agree we need a fall back option when patching is not easy or fixing the problem is too difficult, but we need to guard against it being the norm. Take what I've done with the FC1 packages I have... most are updates only in as far as the packages have the same major and in most cases minor version numbers as the FC1 counterparts. I have GCC 3.3.6 even though 3.4 and 4.x exist and are available. I just don't see the point in going that far ... granted, GCC 3.3.6 was EOL and unsupported past the point I downloaded and patched into FC1. Believe me, the upgrade was anything but EASY! - -James -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEafDHkNLDmnu1kSkRAtmXAJ9VZlWOXFziK1qq2uirSfG2hda5GACfZqZN PZweidIPMJkkuT9AOkUiBGs= =Q6F/ -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From jancio_wodnik at wp.pl Tue May 16 23:27:14 2006 From: jancio_wodnik at wp.pl (Jancio Wodnik) Date: Wed, 17 May 2006 01:27:14 +0200 Subject: Fetchmail from may 13 on rh9 Message-ID: <446A5FD2.8080109@wp.pl> Hi. This release of fetchmail (6.2.0-3.4.legacy.i386) on RH9 behaviour is wired. Any messages fetched from remote account to local system is doubled, always. I have recompiled from scratch the upstream fetchmail 6.3.4 and so far, this problem gone. So i think, some bugs are in this release. Regards. Irens From jancio_wodnik at wp.pl Tue May 16 23:30:41 2006 From: jancio_wodnik at wp.pl (Jancio Wodnik) Date: Wed, 17 May 2006 01:30:41 +0200 Subject: Fetchmail from may 13 on rh9 In-Reply-To: <446A5FD2.8080109@wp.pl> References: <446A5FD2.8080109@wp.pl> Message-ID: <446A60A1.5020000@wp.pl> Jancio Wodnik napisa?(a): > Hi. > > This release of fetchmail (6.2.0-3.4.legacy.i386) on RH9 behaviour is > wired. Any messages fetched from remote account to local system is > doubled, always. > > I have recompiled from scratch the upstream fetchmail 6.3.4 and so > far, this problem gone. > > So i think, some bugs are in this release. > > Regards. > > Irens > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > > Sorry for noise, i must investigate more. Irens. From jkosin at beta.intcomgrp.com Wed May 17 15:20:41 2006 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Wed, 17 May 2006 11:20:41 -0400 Subject: Fedora products, to upgrade rather than backport? In-Reply-To: References: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> <1147724053.2673.6.camel@mdlinux> <1147724192.8578.30.camel@dhcp83-49.boston.redhat.com> <1147725611.2673.19.camel@mdlinux> <1147726177.8578.36.camel@dhcp83-49.boston.redhat.com> <4468F274.9000004@beta.intcomgrp.com> Message-ID: <446B3F49.6060003@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Yates wrote: > On Mon, 15 May 2006, James Kosin wrote: > >> I agree with Jesse here; but, I would like to add that the >> packages should be tested on the released platform by someone and >> not just released in this case. SendMail was a recent blunder of >> sorts because of this. > > not to start any kind of flame war, but just for accuracy's sake, > the recent sendmail release *was* tested before public release - i > was one of the testers who signed off on it. in my case, the test > didn't show up anything because i *always* reroll my sendmail.cf > from m4 by hand, any time i upgrade sendmail (as my test report > stated); and i don't use SMTP AUTH. > > that may say that our required testing is insufficient; i wouldn't > presume to comment on that. but i don't believe sendmail was > rushed out the door any more untested than any other package would > have been. > > Thanks for clearing that up. I wasn't trying to start anything, only that many things that shouldn't have been broken got broken by this release. Which has been the only major upgrade of software apart from the security patches. - -James -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEaz9JkNLDmnu1kSkRAnH/AJ4mS40qSnVnxndoRxz8MiPKyzv7DQCfdXnA YSktDPJLUObN7/ZyQKwVh08= =SbzY -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From rostetter at mail.utexas.edu Wed May 17 16:01:16 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 17 May 2006 11:01:16 -0500 Subject: Fedora products, to upgrade rather than backport? In-Reply-To: <446B3F49.6060003@beta.intcomgrp.com> References: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> <1147724053.2673.6.camel@mdlinux> <1147724192.8578.30.camel@dhcp83-49.boston.redhat.com> <1147725611.2673.19.camel@mdlinux> <1147726177.8578.36.camel@dhcp83-49.boston.redhat.com> <4468F274.9000004@beta.intcomgrp.com> <446B3F49.6060003@beta.intcomgrp.com> Message-ID: <20060517110116.qc58kjpz2940goc0@mail.ph.utexas.edu> Quoting James Kosin : >> not to start any kind of flame war, but just for accuracy's sake, >> the recent sendmail release *was* tested before public release - i Yes, but IMHO not enough, but that is totally another matter. >> that may say that our required testing is insufficient; i wouldn't >> presume to comment on that. but i don't believe sendmail was >> rushed out the door any more untested than any other package would >> have been. It was tested as well as anything is, which isn't very well any more. But again, that is another issue. The relevant issue with this is that sendmail was indeed a case where backporting was not feasible, and upgrading was required, for some versions (in this case old RHL releases). And an example of both how FL does upgrade versions when needed, and what kind of issues can arise when that happens. As can be seen in the sendmail upgrade, lots of other things (alternatives, pam, etc) can come into play that are not immediately obvious. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From jkeating at j2solutions.net Wed May 17 16:45:16 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 17 May 2006 12:45:16 -0400 Subject: Fedora products, to upgrade rather than backport? In-Reply-To: <20060517110116.qc58kjpz2940goc0@mail.ph.utexas.edu> References: <1147720822.8578.23.camel@dhcp83-49.boston.redhat.com> <1147724053.2673.6.camel@mdlinux> <1147724192.8578.30.camel@dhcp83-49.boston.redhat.com> <1147725611.2673.19.camel@mdlinux> <1147726177.8578.36.camel@dhcp83-49.boston.redhat.com> <4468F274.9000004@beta.intcomgrp.com> <446B3F49.6060003@beta.intcomgrp.com> <20060517110116.qc58kjpz2940goc0@mail.ph.utexas.edu> Message-ID: <1147884316.5295.17.camel@dhcp83-49.boston.redhat.com> On Wed, 2006-05-17 at 11:01 -0500, Eric Rostetter wrote: > > As can be seen in the sendmail upgrade, lots of other things (alternatives, > pam, etc) can come into play that are not immediately obvious. > Right, thinks like sendmail are hard. Things like gaim, or evince, or other top level applications it should be fairly easy to upgrade those w/out causing a ripple effect. -- 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 jedgecombe at carolina.rr.com Tue May 23 12:41:47 2006 From: jedgecombe at carolina.rr.com (Jason Edgecombe) Date: Tue, 23 May 2006 08:41:47 -0400 Subject: connection refused to download.fedoralegacy.org Message-ID: <4473030B.3070706@carolina.rr.com> Hi, I'm receiving "connection refused" errors when trying to contact download.fedoralegacy.org. I got the error on two machines using both yum and wget. Does anyone have any info on this? Thanks, Jason From skvidal at linux.duke.edu Tue May 23 13:30:10 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 23 May 2006 09:30:10 -0400 Subject: connection refused to download.fedoralegacy.org In-Reply-To: <4473030B.3070706@carolina.rr.com> References: <4473030B.3070706@carolina.rr.com> Message-ID: <1148391010.6325.0.camel@cutter> On Tue, 2006-05-23 at 08:41 -0400, Jason Edgecombe wrote: > Hi, > > I'm receiving "connection refused" errors when trying to contact > download.fedoralegacy.org. I got the error on two machines using both > yum and wget. > > Does anyone have any info on this? I do - box was rebooted yesterday - seems like apache didn't come up. it should be fixed now. sorry. -sv From sven.kielmann at sinius.com Tue May 23 14:04:23 2006 From: sven.kielmann at sinius.com (Sven Kielmann) Date: Tue, 23 May 2006 16:04:23 +0200 Subject: Sven Kielmann ist =?iso-8859-15?q?au=DFer_Haus=2E?= Message-ID: Ich werde ab 22.05.2006 nicht im B?ro sein. Ich kehre zur?ck am 06.06.2006. Ihre Nachricht wurde nicht weitergeleitet. Bitte wenden Sie sich in dringenden F?llen an: Lars Gelfert (034204/700-240) -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerry at pathtech.org Tue May 23 14:11:06 2006 From: gerry at pathtech.org (G. Roderick Singleton) Date: Tue, 23 May 2006 10:11:06 -0400 Subject: connection refused to download.fedoralegacy.org In-Reply-To: <4473030B.3070706@carolina.rr.com> References: <4473030B.3070706@carolina.rr.com> Message-ID: <1148393466.4480.18.camel@www.pathtech.org> On Tue, 2006-05-23 at 08:41 -0400, Jason Edgecombe wrote: > Hi, > > I'm receiving "connection refused" errors when trying to contact > download.fedoralegacy.org. I got the error on two machines using both > yum and wget. > > Does anyone have any info on this? > When this occurs I find that mirrors useful. Try one that is near you. -- G. Roderick Singleton PATH tech -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 1865 bytes Desc: not available URL: From cave.dnb at tiscali.fr Tue May 23 13:08:34 2006 From: cave.dnb at tiscali.fr (Nigel Henry) Date: Tue, 23 May 2006 15:08:34 +0200 Subject: connection refused to download.fedoralegacy.org In-Reply-To: <4473030B.3070706@carolina.rr.com> References: <4473030B.3070706@carolina.rr.com> Message-ID: <200605231508.35109.cave.dnb@tiscali.fr> On Tuesday 23 May 2006 14:41, Jason Edgecombe wrote: > Hi, > > I'm receiving "connection refused" errors when trying to contact > download.fedoralegacy.org. I got the error on two machines using both > yum and wget. > > Does anyone have any info on this? > > Thanks, > Jason Hi Jason. No info, but I can confirm the same 111 connection refused, using apt-get on FC2. Nigel. > > -- > 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 Fri May 26 01:59:59 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 25 May 2006 21:59:59 -0400 Subject: Fedora Legacy Test Update Notification: thunderbird Message-ID: <4476611F.8050201@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-189672 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189672 2006-05-25 --------------------------------------------------------------------- Name : thunderbird Versions : fc3: thunderbird-1.0.8-1.1.fc3.4.legacy Summary : Mozilla Thunderbird mail/newsgroup client Description : Mozilla Thunderbird is a standalone mail and newsgroup client. --------------------------------------------------------------------- Update Information: Updated thunderbird packages that fix several security bugs are now available. Mozilla Thunderbird is a standalone mail and newsgroup client. Several bugs were found in the way Thunderbird processes malformed javascript. A malicious HTML mail message could modify the content of a different open HTML mail message, possibly stealing sensitive information or conducting a cross-site scripting attack. Please note that JavaScript support is disabled by default in Thunderbird. (CVE-2006-1731, CVE-2006-1732, CVE-2006-1741) Several bugs were found in the way Thunderbird processes certain javascript actions. A malicious HTML mail message could execute arbitrary javascript instructions with the permissions of 'chrome', allowing the page to steal sensitive information or install browser malware. Please note that JavaScript support is disabled by default in Thunderbird. (CVE-2006-0292, CVE-2006-0296, CVE-2006-1727, CVE-2006-1728, CVE-2006-1733, CVE-2006-1734, CVE-2006-1735, CVE-2006-1742) Several bugs were found in the way Thunderbird processes malformed HTML mail messages. A carefully crafted malicious HTML mail message could cause the execution of arbitrary code as the user running Thunderbird. (CVE-2006-0748, CVE-2006-0749, CVE-2006-1724, CVE-2006-1730, CVE-2006-1737, CVE-2006-1738, CVE-2006-1739, CVE-2006-1790) A bug was found in the way Thunderbird processes certain inline content in HTML mail messages. It may be possible for a remote attacker to send a carefully crafted mail message to the victim, which will fetch remote content, even if Thunderbird is configured not to fetch remote content. (CVE-2006-1045) A bug was found in the way Thunderbird executes in-line mail forwarding. If a user can be tricked into forwarding a maliciously crafted mail message as in-line content, it is possible for the message to execute javascript with the permissions of "chrome". (CVE-2006-0884) Users of Thunderbird are advised to upgrade to these updated packages containing Thunderbird version 1.0.8, which is not vulnerable to these issues. --------------------------------------------------------------------- Changelogs fc3: * Mon May 15 2006 David Eisenstein 1.0.8-1.1.fc3.4.legacy - Add buildrequires: libgnome-devel, libbonobo-devel, GConf2-devel, gnome-vfs2-devel, glib2-devel, ORBit2-devel, popt * Fri Apr 28 2006 David Eisenstein 1.0.8-1.1.fc3.2.legacy - Add buildrequires - desktop-file-utils * Tue Apr 25 2006 David Eisenstein 1.0.8-1.1.fc3.1.legacy - Portions of the firefox-1.0-gcc4-compile.patch are already applied in the src tarball. Remove those so remainder of patch will apply. * Tue Apr 25 2006 David Eisenstein 1.0.8-1.1.fc3.legacy - Update to 1.0.8, containing fixes for: CVE-2006-1731, CVE-2006-1732, CVE-2006-1741, CVE-2006-0292, CVE-2006-0296, CVE-2006-1727, CVE-2006-1728, CVE-2006-1733, CVE-2006-1734, CVE-2006-1735, CVE-2006-1742, CVE-2006-0749, CVE-2006-1724, CVE-2006-1730, CVE-2006-1737, CVE-2006-1738, CVE-2006-1739, CVE-2006-1790, CVE-2006-1045 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) fc3: f8af690feea54ca58a8844d165fa36f4663ae0b5 fedora/3/updates-testing/i386/thunderbird-1.0.8-1.1.fc3.4.legacy.i386.rpm 8fdfa93482e2a5de6c38e05a285e24360b12bbaa fedora/3/updates-testing/x86_64/thunderbird-1.0.8-1.1.fc3.4.legacy.x86_64.rpm b9b9cc2694512827633ecba95b8327b0efb68f40 fedora/3/updates-testing/SRPMS/thunderbird-1.0.8-1.1.fc3.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 Axel.Thimm at atrpms.net Fri May 26 13:20:40 2006 From: Axel.Thimm at atrpms.net (Axel Thimm) Date: Fri, 26 May 2006 15:20:40 +0200 Subject: Nvidia 1.0-8762 In-Reply-To: References: Message-ID: <20060526132040.GE17546@neu.nirvana> On Fri, May 26, 2006 at 11:10:59PM +1000, Phill Edwards wrote: > Does anyone know if Nvidia 1.0-8762 is available for kernel > 2.6.12-1.1381_FC3 on ATrpms? Yes and no. It's available for the latest kernel in FC3, which is coming from Fedora Legacy and is 2.6.12-2.3.legacy_FC3. Please enable fedora-legacy in your depsolver config (if you use ATrpms' atrpms-package-config and similar it already is) and upgrade your kernel to 2.6.12-2.3.legacy_FC3. -- 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 deisenst at gtw.net Wed May 31 00:58:52 2006 From: deisenst at gtw.net (David Eisenstein) Date: Tue, 30 May 2006 19:58:52 -0500 (CDT) Subject: We continue to be needed Message-ID: Hi, Catching up on a little reading, I ran across this arcitle on LWN.NET, which mentions Fedora Legacy a few times in the comments in a rather positive light. There are folks I think who wish there were a SUSE Legacy project. :) "Discontinued SUSE Linux Distribution: 9.1" posted May 16 by rls Warm regards, David