From marcdeslauriers at videotron.ca Thu Mar 2 01:20:52 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 01 Mar 2006 20:20:52 -0500 Subject: Fedora Legacy Test Update Notification: glibc Message-ID: <44064874.8000001@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-173091-1 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173091 2006-03-01 --------------------------------------------------------------------- Name : glibc Versions : rh73: glibc-2.2.5-44.legacy.8 Versions : rh9: glibc-2.3.2-27.9.7.4.legacy Summary : The GNU libc libraries. Description : The glibc package contains standard libraries which are used by multiple programs on the system. In order to save disk space and memory, as well as to make upgrading easier, common system code is kept in one place and shared between programs. This particular package contains the most important sets of shared libraries: the standard C library and the standard math library. Without these two libraries, a Linux system will not function. --------------------------------------------------------------------- Update Information: Updated glibc packages that add daylight savings rule enhancements for various countries are now available. The GNU libc packages (known as glibc) contain the standard C libraries used by applications. This update adjusts timezone files for countries where daylight savings rules have recently changed or are going to change in the near future. Users in those countries should upgrade to these updated packages and rerun redhat-config-date to update the local timezone in /etc/localtime. --------------------------------------------------------------------- Changelogs rh73: * Mon Feb 20 2006 Marc Deslauriers 2.2.4-44.legacy.8 - Bring timezone info up to version 2006a * Sat Feb 18 2006 Marc Deslauriers 2.2.4-44.legacy.7 - Bring timezone info up to version 2005m rh9: * Tue Feb 21 2006 Marc Deslauriers 2.3.2-27.9.7.4.legacy - Bring timezone info up to version 2006a * Sun Feb 12 2006 Marc Deslauriers 2.3.2-27.9.7.3.legacy - Bring timezone info up to version 2005m --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 8977060010fc16bbaf2aba545c3b958e4a953ec8 redhat/7.3/updates-testing/i386/glibc-2.2.5-44.legacy.8.i386.rpm 4e4fce10ff1cfbdda21dbd0ca19132ffa3b34a15 redhat/7.3/updates-testing/i386/glibc-2.2.5-44.legacy.8.i686.rpm ccc856a5f596cffca0d76f124ffff2df7cecd413 redhat/7.3/updates-testing/i386/glibc-common-2.2.5-44.legacy.8.i386.rpm f301116e857b0d3d63c39af5003dcbab897b4af2 redhat/7.3/updates-testing/i386/glibc-debug-2.2.5-44.legacy.8.i386.rpm c7f784964cff0af15108e981fb0eed5f5b49b8b4 redhat/7.3/updates-testing/i386/glibc-debug-2.2.5-44.legacy.8.i686.rpm 2f59c12525a171646595f56126f882a656107fb7 redhat/7.3/updates-testing/i386/glibc-debug-static-2.2.5-44.legacy.8.i386.rpm fbc27b34ed90759a4a8572c11b714e42bd2e3bda redhat/7.3/updates-testing/i386/glibc-devel-2.2.5-44.legacy.8.i386.rpm 1a53624c0e7ee609a57d60740769fcb8e661244f redhat/7.3/updates-testing/i386/glibc-profile-2.2.5-44.legacy.8.i386.rpm f316b55111db5e4e6afb6e7defdf04b4a5505867 redhat/7.3/updates-testing/i386/glibc-utils-2.2.5-44.legacy.8.i386.rpm 18bb566cbc5b0e8abb1f7d72db364601584efb92 redhat/7.3/updates-testing/i386/nscd-2.2.5-44.legacy.8.i386.rpm 3e8f11366500b362ef7040173912e0f07607b51c redhat/7.3/updates-testing/SRPMS/glibc-2.2.5-44.legacy.8.src.rpm rh9: 91117fc583591c8bcc04939cc2c02af012356fb3 redhat/9/updates-testing/i386/glibc-2.3.2-27.9.7.4.legacy.i386.rpm 18a13ba104fd958e1abcbe42cdf2ae31c9b0cb30 redhat/9/updates-testing/i386/glibc-2.3.2-27.9.7.4.legacy.i686.rpm cb5501a39b03cacda052757f8265bc6f02c92883 redhat/9/updates-testing/i386/glibc-common-2.3.2-27.9.7.4.legacy.i386.rpm bbf1af111006a214efde3da5b734372ec98c75d9 redhat/9/updates-testing/i386/glibc-debug-2.3.2-27.9.7.4.legacy.i386.rpm 753ea0d554610c4dd35cc54764def86269c2c148 redhat/9/updates-testing/i386/glibc-devel-2.3.2-27.9.7.4.legacy.i386.rpm 1ccda9c9ca1b424d5714016fad7b49280d981e3a redhat/9/updates-testing/i386/glibc-profile-2.3.2-27.9.7.4.legacy.i386.rpm 112788df6619fb9fc39282ab0eeaf7718d34f8b5 redhat/9/updates-testing/i386/glibc-utils-2.3.2-27.9.7.4.legacy.i386.rpm 6a8728560054bce9a0e4ddc8de897085fa54a8c6 redhat/9/updates-testing/i386/nscd-2.3.2-27.9.7.4.legacy.i386.rpm 326be845c248a3d35e66550b54fbcd3a9556cae7 redhat/9/updates-testing/i386/nptl-devel-2.3.2-27.9.7.4.legacy.i686.rpm 1cdcc8fa2428568fb571a6428b80217c17ec8183 redhat/9/updates-testing/SRPMS/glibc-2.3.2-27.9.7.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: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Thu Mar 2 01:21:13 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 01 Mar 2006 20:21:13 -0500 Subject: Fedora Legacy Test Update Notification: tzdata Message-ID: <44064889.8050403@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-173091-2 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173091 2006-03-01 --------------------------------------------------------------------- Name : tzdata Versions : fc1: tzdata-2005r-3.fc1.1.legacy Versions : fc2: tzdata-2005r-3.fc2.1.legacy Summary : Timezone data Description : This package contains data files with rules for various timezones around the world. --------------------------------------------------------------------- Update Information: An updated tzdata package that adds daylight savings rule enhancements for various countries is now available. The tzdata package contains data files with rules for various timezones around the world. This update adjusts timezone files for countries where daylight savings rules have recently changed or are going to change in the near future. Users in those countries should upgrade to these updated packages and rerun redhat-config-date (or system-config-date in FC2) to update the local timezone in /etc/localtime. --------------------------------------------------------------------- Changelogs fc1: * Sat Feb 18 2006 Marc Deslauriers 2005r-3.fc1.1.legacy - Rebuilt as a Fedora Legacy update to Fedora Core 1 fc2: * Sat Feb 18 2006 Marc Deslauriers 2005r-3.fc2.1.legacy - Rebuilt as a Fedora Legacy update to Fedora Core 2 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) fc1: 87a51c9f24d223e74e1c0c658a5e687953989e7d fedora/1/updates-testing/i386/tzdata-2005r-3.fc1.1.legacy.noarch.rpm cb64a4e80ad60994f21a95bf2f7e5043a1ca2f2a fedora/1/updates-testing/SRPMS/tzdata-2005r-3.fc1.1.legacy.src.rpm fc2: e308480e1839d599fe08fa795de988cb68711ce0 fedora/2/updates-testing/i386/tzdata-2005r-3.fc2.1.legacy.noarch.rpm cd90b47e9e6d5074194805c27a2eddaf948c78e8 fedora/2/updates-testing/SRPMS/tzdata-2005r-3.fc2.1.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Thu Mar 2 01:21:36 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 01 Mar 2006 20:21:36 -0500 Subject: Fedora Legacy Test Update Notification: kdelibs Message-ID: <440648A0.9040101@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-178606 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178606 2006-03-01 --------------------------------------------------------------------- Name : kdelibs Versions : rh73: kdelibs-3.0.5a-0.73.7.legacy Versions : rh9: kdelibs-3.1-17.1.legacy Versions : fc1: kdelibs-3.1.4-9.FC1.1.legacy Versions : fc2: kdelibs-3.2.2-14.FC2.2.legacy Versions : fc3: kdelibs-3.4.2-1.fc3.1.legacy Summary : K Desktop Environment - Libraries Description : Libraries for the K Desktop Environment. KDE Libraries include: kdecore (KDE core library), kdeui (user interface), kfm (file manager), khtmlw (HTML widget), kio (Input/Output, networking), kspell (spelling checker), jscript (javascript), kab (addressbook), kimgio (image manipulation). --------------------------------------------------------------------- Update Information: Updated kdelibs packages that fix several security issues are now available. The kdelibs package provides libraries for the K Desktop Environment. The International Domain Name (IDN) support in the Konqueror browser allowed remote attackers to spoof domain names using punycode encoded domain names. Such domain names are decoded in URLs and SSL certificates in a way that uses homograph characters from other character sets, which facilitates phishing attacks. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0237 to this issue. Sebastian Krahmer discovered a flaw in dcopserver, the KDE Desktop Communication Protocol (DCOP) daemon. A local user could use this flaw to stall the DCOP authentication process, affecting any local desktop users and causing a reduction in their desktop functionality. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0396 to this issue. A buffer overflow was found in the kimgio library for KDE 3.4.0. An attacker could create a carefully crafted PCX image in such a way that it would cause kimgio to execute arbitrary code when processing the image. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-1046 to this issue. A flaw was discovered affecting Kate, the KDE advanced text editor, and Kwrite. Depending on system settings, it may be possible for a local user to read the backup files created by Kate or Kwrite. The Common Vulnerabilities and Exposures project assigned the name CVE-2005-1920 to this issue. A heap overflow flaw was discovered affecting kjs, the JavaScript interpreter engine used by Konqueror and other parts of KDE. An attacker could create a malicious web site containing carefully crafted JavaScript code that would trigger this flaw and possibly lead to arbitrary code execution. The Common Vulnerabilities and Exposures project assigned the name CVE-2006-0019 to this issue. Users of KDE should upgrade to these erratum packages, which contain backported patches to correct these issues. --------------------------------------------------------------------- Changelogs rh73: * Thu Feb 23 2006 David Eisenstein 6:3.0.5a-0.73.7.legacy - Add patch #26 for CAN-2005-0396, local DCOP denial of service vulnerability. Bugzilla #178606. rh9: * Thu Feb 23 2006 David Eisenstein 6:3.0.5a-0.73.7.legacy - Add patch #106 for CAN-2005-0396, local DCOP denial of service vulnerability. Bugzilla #178606. fc1: * Fri Feb 24 2006 David Eisenstein 6:3.1.4-9.FC1.1.legacy - Add patch #107 for CAN-2005-0396, local DCOP denial of service vulnerability. Bugzilla #178606. fc2: * Tue Feb 14 2006 David Eisenstein 6:3.2.2-14.FC2.2.legacy - Make slight mod to Konqueror IDN patch, changing the paths in the patch, so it will apply correctly. * Tue Feb 14 2006 David Eisenstein 6:3.2.2-14.FC2.1.legacy - Applied patch for Konqueror International Domain Name Spoofing, CAN-2005-0237, #178606 - Patch for kimgio input validation errors, CAN-2005-1046, #178606 - Patch for Kate backup file permission leak, CAN-2005-1920, #178606 - Add critical patch for kjs encodeuri/decodeuri heap overflow vulnerability, CVE-2006-0019, #178606. fc3: * Wed Feb 08 2006 David Eisenstein 6:3.4.2-1.fc3.1.legacy - Add fix for CVE-2006-0019, kjs encodeuri/decodeuri heap overflow vulnerability Bug #178606. --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 2f2d25474d7f6c68b77e376684f3835cd61123e4 redhat/7.3/updates-testing/i386/kdelibs-3.0.5a-0.73.7.legacy.i386.rpm c153c581d132fc5ae882167d3319f103652043dd redhat/7.3/updates-testing/i386/kdelibs-devel-3.0.5a-0.73.7.legacy.i386.rpm 7ad24efea3cd775ad8bc649128d64875eec1554e redhat/7.3/updates-testing/SRPMS/kdelibs-3.0.5a-0.73.7.legacy.src.rpm rh9: f527dda13ccda9cd86542014e749587548b82a32 redhat/9/updates-testing/i386/kdelibs-3.1-17.1.legacy.i386.rpm 6e22f76a8310051d285d60817066659f4429b633 redhat/9/updates-testing/i386/kdelibs-devel-3.1-17.1.legacy.i386.rpm 7d8b9b30352004864252d7f2a72a877f062adf0f redhat/9/updates-testing/SRPMS/kdelibs-3.1-17.1.legacy.src.rpm fc1: 3de25dd41842099dca0cf142adef2c4fe35bcfce fedora/1/updates-testing/i386/kdelibs-3.1.4-9.FC1.1.legacy.i386.rpm 5d48525f08c39c3f73ca1d547be6aa0335c02a02 fedora/1/updates-testing/i386/kdelibs-devel-3.1.4-9.FC1.1.legacy.i386.rpm 14c5cab3afedd32f05324ced28cd9abda3349ff1 fedora/1/updates-testing/SRPMS/kdelibs-3.1.4-9.FC1.1.legacy.src.rpm fc2: 944bbc21e569bc63544f540783eedf4ecf430d2f fedora/2/updates-testing/i386/kdelibs-3.2.2-14.FC2.2.legacy.i386.rpm 6d15fbaa66fbadf6fa19ce3feb04e4c71ef18dfe fedora/2/updates-testing/i386/kdelibs-devel-3.2.2-14.FC2.2.legacy.i386.rpm 1b2a47dcae3e180dc2b0ccecdff5dca12b914393 fedora/2/updates-testing/SRPMS/kdelibs-3.2.2-14.FC2.2.legacy.src.rpm fc3: 4d217b3e16c4624ff14b9615ab7720efbaaff7e8 fedora/3/updates-testing/i386/kdelibs-3.4.2-1.fc3.1.legacy.i386.rpm c861158a8f3734f0ae633fc46cd8705c6d5fc0ad fedora/3/updates-testing/i386/kdelibs-devel-3.4.2-1.fc3.1.legacy.i386.rpm 4d217b3e16c4624ff14b9615ab7720efbaaff7e8 fedora/3/updates-testing/x86_64/kdelibs-3.4.2-1.fc3.1.legacy.i386.rpm 8d37c651ebe27beb56c34383972128a18e8e3c4d fedora/3/updates-testing/x86_64/kdelibs-3.4.2-1.fc3.1.legacy.x86_64.rpm 10cabc626d4c0570999ccd70aa8e248f31b49f8f fedora/3/updates-testing/x86_64/kdelibs-devel-3.4.2-1.fc3.1.legacy.x86_64.rpm bb0dc7875106e2b71d30a5a8f2df6737aee4a80a fedora/3/updates-testing/SRPMS/kdelibs-3.4.2-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: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Thu Mar 2 01:22:16 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 01 Mar 2006 20:22:16 -0500 Subject: [FLSA-2006:178989] Updated perl-DBI package fixes security issue Message-ID: <440648C8.30609@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated perl-DBI package fixes security issue Advisory ID: FLSA:178989 Issue date: 2006-03-01 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2005-0077 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: An updated perl-DBI package that fixes a temporary file flaw in DBI::ProxyServer is now available. DBI is a database access Application Programming Interface (API) for the Perl programming language. 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: The Debian Security Audit Project discovered that the DBI library creates a temporary PID file in an insecure manner. A local user could overwrite or create files as a different user who happens to run an application which uses DBI::ProxyServer. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0077 to this issue. Users should update to this erratum package which disables the temporary PID file unless configured. 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=178989 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/perl-DBI-1.21-1.1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/perl-DBI-1.21-1.1.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/perl-DBI-1.32-5.1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/perl-DBI-1.32-5.1.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/perl-DBI-1.37-1.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/perl-DBI-1.37-1.1.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/perl-DBI-1.40-4.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/perl-DBI-1.40-4.1.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 847cb03e61abf1bbb965b2fa6e7c0f812e7edde1 redhat/7.3/updates/i386/perl-DBI-1.21-1.1.legacy.i386.rpm 7c0c13670d8da3620d6bdc0d24f96201ff3feee8 redhat/7.3/updates/SRPMS/perl-DBI-1.21-1.1.legacy.src.rpm 2e473b5822a019a10b7b9577f4de60933e75fecc redhat/9/updates/i386/perl-DBI-1.32-5.1.legacy.i386.rpm 19934b803bf33b0cc93466ae43e2ac14302ac0df redhat/9/updates/SRPMS/perl-DBI-1.32-5.1.legacy.src.rpm 50a02fd2d68f47d35f76bc690281253bbdf9a486 fedora/1/updates/i386/perl-DBI-1.37-1.1.legacy.i386.rpm 0018ffba083fd98b88a4bcec3383005ed32d5e6a fedora/1/updates/SRPMS/perl-DBI-1.37-1.1.legacy.src.rpm 69a623c7db409341705bfc125b5fd6f0c056af7b fedora/2/updates/i386/perl-DBI-1.40-4.1.legacy.i386.rpm 4443111b0e9137bd1624183b9d209b2cada204dd fedora/2/updates/SRPMS/perl-DBI-1.40-4.1.legacy.src.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0077 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From jkeating at j2solutions.net Thu Mar 2 21:47:11 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 02 Mar 2006 13:47:11 -0800 Subject: [Fwd: Announcing fedora-security-list] Message-ID: <1141336032.31231.159.camel@ender> I would encourage those of you that are interested in discussing security issues to join this new list. -------- Forwarded Message -------- From: Josh Bressers Reply-To: List for Fedora Package Maintainers To: fedora-devel-list at redhat.com, fedora-maintainers at redhat.com, fedora-extras-list at redhat.com, fedora-security-list at redhat.com Subject: Announcing fedora-security-list Date: Thu, 02 Mar 2006 15:47:56 -0500 There has been a fair amount of talk regarding how to handle security updates in Fedora Extras. Current handling of these updates is up to the package maintainer. The fedora-security-list has been created for just such discussions, with the hope of the community to devise a solution to deal with Extras security issues. The scope of this list is not limited to Extras security, but rather a list with a focus on security issues in Fedora along with how the various security groups can work together. You can subscribe to the list here: https://www.redhat.com/mailman/listinfo/fedora-security-list Thanks, Josh -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From mht at research.dfci.harvard.edu Fri Mar 3 17:48:41 2006 From: mht at research.dfci.harvard.edu (Matt Temple) Date: Fri, 03 Mar 2006 12:48:41 -0500 Subject: Documentation question at fedoralegacy.org In-Reply-To: <1141336032.31231.159.camel@ender> References: <1141336032.31231.159.camel@ender> Message-ID: <44088179.2090304@research.dfci.harvard.edu> At the Fedora Legacy website, I see the following statement in the Fedora Core 3 paragraph. > Fedora Core 3 on the x86_64 architecture is not available at this > point. Users and interested community members can participate in the > discussions on Fedora Legacy List > . But looking at the download site, it /looks/ as though the x86_64 rpms are there. (Not so for core 2). Does the site need this updated? Matt Temple -- ============================================================= Matthew Temple Tel: 617/632-2597 Director, Research Computing Fax: 617/582-7820 Dana-Farber Cancer Institute mht at research.dfci.harvard.edu 44 Binney Street, LG300/300 http://research.dfci.harvard.edu Boston, MA 02115 Choice is the Choice! From jkosin at beta.intcomgrp.com Fri Mar 3 19:35:08 2006 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Fri, 03 Mar 2006 14:35:08 -0500 Subject: Documentation question at fedoralegacy.org In-Reply-To: <44088179.2090304@research.dfci.harvard.edu> References: <1141336032.31231.159.camel@ender> <44088179.2090304@research.dfci.harvard.edu> Message-ID: <44089A6C.1080901@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matt Temple wrote: > > But looking at the download site, it /looks/ as though the x86_64 rpms > are there. > (Not so for core 2). > Does the site need this updated? > Matt, Good point; but, they may be holding off updating this fact until we see the workload involved with this. Since x86_64 stuff adds a layer of complexity to the issue. - -James -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFECJpskNLDmnu1kSkRAlY5AJ9tS3sbBCDER/fruOiCXuptgEdnmwCcCn2Z T2oqX0v8n9zvrrQ5SiCeXeA= =X3cN -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From mht at research.dfci.harvard.edu Fri Mar 3 19:44:38 2006 From: mht at research.dfci.harvard.edu (Matt Temple) Date: Fri, 03 Mar 2006 14:44:38 -0500 Subject: Documentation question at fedoralegacy.org In-Reply-To: <44089A6C.1080901@beta.intcomgrp.com> References: <1141336032.31231.159.camel@ender> <44088179.2090304@research.dfci.harvard.edu> <44089A6C.1080901@beta.intcomgrp.com> Message-ID: <44089CA6.2090000@research.dfci.harvard.edu> James Kosin wrote: > Matt Temple wrote: > > >But looking at the download site, it /looks/ as though the x86_64 rpms > >are there. > >(Not so for core 2). > >Does the site need this updated? > > Matt, > > Good point; but, they may be holding off updating this fact until we see > the workload involved with this. Since x86_64 stuff adds a layer of > complexity to the issue. > > -James I'm not sure I understand. The x86_64 rpms are already in the download area for core 3. They're really there. Matt -- ============================================================= Matthew Temple Tel: 617/632-2597 Director, Research Computing Fax: 617/582-7820 Dana-Farber Cancer Institute mht at research.dfci.harvard.edu 44 Binney Street, LG300/300 http://research.dfci.harvard.edu Boston, MA 02115 Choice is the Choice! From jkeating at j2solutions.net Fri Mar 3 19:48:06 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 03 Mar 2006 11:48:06 -0800 Subject: Documentation question at fedoralegacy.org In-Reply-To: <44088179.2090304@research.dfci.harvard.edu> References: <1141336032.31231.159.camel@ender> <44088179.2090304@research.dfci.harvard.edu> Message-ID: <1141415287.17519.0.camel@ender> On Fri, 2006-03-03 at 12:48 -0500, Matt Temple wrote: > But looking at the download site, it /looks/ as though the x86_64 > rpms > are there. > (Not so for core 2). > > Does the site need this updated? We're testing a new build system and the by product of that testing is some x86_64 packages. We haven't yet started rebuilding all the old updates to spit out x86_64 packages, just new updates are getting them. We haven't made any official announcements or updated the pages, we're still evaluating the build system and the packages it generates. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From jkosin at beta.intcomgrp.com Fri Mar 3 20:43:05 2006 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Fri, 03 Mar 2006 15:43:05 -0500 Subject: Documentation question at fedoralegacy.org In-Reply-To: <44089CA6.2090000@research.dfci.harvard.edu> References: <1141336032.31231.159.camel@ender> <44088179.2090304@research.dfci.harvard.edu> <44089A6C.1080901@beta.intcomgrp.com> <44089CA6.2090000@research.dfci.harvard.edu> Message-ID: <4408AA59.60109@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matt Temple wrote: > > I'm not sure I understand. The x86_64 rpms are already in the download > area for > core 3. They're really there. > > Matt Matt, I'm not saying they are not there. Like Jesse just posted, "they are evaluating the build system and they have not officially announced support for the x86_64 platform until a consensus can be made on weather support will be continued." If you have a x86_64 system and want to test the builds that are there and say yea or no on the packages then go right ahead. But, until we are sure they don't break anything we can't officially say yes to this. - -James -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFECKpZkNLDmnu1kSkRAhyZAJ4+ts3azkjGW6Q1yP2FQwQBEvNgVACfRfuw yhfx+PJGsaF+ew4z65YX/Z8= =u8ll -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From jkeating at j2solutions.net Fri Mar 3 20:50:27 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 03 Mar 2006 12:50:27 -0800 Subject: Documentation question at fedoralegacy.org In-Reply-To: <4408AA59.60109@beta.intcomgrp.com> References: <1141336032.31231.159.camel@ender> <44088179.2090304@research.dfci.harvard.edu> <44089A6C.1080901@beta.intcomgrp.com> <44089CA6.2090000@research.dfci.harvard.edu> <4408AA59.60109@beta.intcomgrp.com> Message-ID: <1141419027.17519.8.camel@ender> On Fri, 2006-03-03 at 15:43 -0500, James Kosin wrote: > If you have a x86_64 system and want to test the builds that are there > and say yea or no on the packages then go right ahead. But, until we > are sure they don't break anything we can't officially say yes to this. This really comes down to lack of verbosity on my part. I think it went something like this: Hey I noticed our new buildsystem we're testing is kicking out x86_64 packages. Neat. Yeah, thats one of the main reasons why we're looking at this. The 32bit stuff is looking really good and we're going to publish this update as built by the new system. Should we include the x86_64 package? ... um... Sure why not? Hey, I see this release announcement mentions x86_64, cool! But the packages aren't on the server, wtf? oh crap! I guess I actually have to do some work to get x86_64 published, let me fix that.... hey there they are cool. So is this official? ... um.... (; -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From mht at research.dfci.harvard.edu Fri Mar 3 21:13:20 2006 From: mht at research.dfci.harvard.edu (Matt Temple) Date: Fri, 03 Mar 2006 16:13:20 -0500 Subject: Documentation question at fedoralegacy.org In-Reply-To: <4408AA59.60109@beta.intcomgrp.com> References: <1141336032.31231.159.camel@ender> <44088179.2090304@research.dfci.harvard.edu> <44089A6C.1080901@beta.intcomgrp.com> <44089CA6.2090000@research.dfci.harvard.edu> <4408AA59.60109@beta.intcomgrp.com> Message-ID: <4408B170.2020407@research.dfci.harvard.edu> James Kosin wrote: > Matt Temple wrote: > > >I'm not sure I understand. The x86_64 rpms are already in the download > >area for > >core 3. They're really there. Thanks. Let me see if anyone using this machine has significant objections. They might well, though. > > > Matt > > Matt, > > I'm not saying they are not there. Like Jesse just posted, "they are > evaluating the build system and they have not officially announced > support for the x86_64 platform until a consensus can be made on weather > support will be continued." > > If you have a x86_64 system and want to test the builds that are there > and say yea or no on the packages then go right ahead. But, until we > are sure they don't break anything we can't officially say yes to this. > > -James -- ============================================================= Matthew Temple Tel: 617/632-2597 Director, Research Computing Fax: 617/582-7820 Dana-Farber Cancer Institute mht at research.dfci.harvard.edu 44 Binney Street, LG300/300 http://research.dfci.harvard.edu Boston, MA 02115 Choice is the Choice! From unix at bikesn4x4s.com Sat Mar 4 01:51:05 2006 From: unix at bikesn4x4s.com (Paul) Date: Fri, 3 Mar 2006 20:51:05 -0500 (EST) Subject: Latest squirrelmail for Fedora Core 1, 2, 3 Message-ID: <2015.192.168.103.1.1141437065.squirrel@bikesn4x4s> http://www.squirrelmail.org/download.php Just thought I'd let you all know if you don't already. I run Core 1 and I've been having a problem with squirrelmail chopping the last attachment when doing multiple attachments after one of the recent php updates. Anyhow, I have verified the latest squirrelmail 1.4.5-1 fixes this bug. From michal at harddata.com Sat Mar 4 02:21:49 2006 From: michal at harddata.com (Michal Jaegermann) Date: Fri, 3 Mar 2006 19:21:49 -0700 Subject: Latest squirrelmail for Fedora Core 1, 2, 3 In-Reply-To: <2015.192.168.103.1.1141437065.squirrel@bikesn4x4s> References: <2015.192.168.103.1.1141437065.squirrel@bikesn4x4s> Message-ID: <20060304022149.GA5473@mail.harddata.com> On Fri, Mar 03, 2006 at 08:51:05PM -0500, Paul wrote: > Anyhow, I have verified the latest squirrelmail 1.4.5-1 fixes this bug. The latest one is squirrelmail-1.4.6-1. Well, for FC4 but it will recompile anyway and it is fixing security issues. Is the above a typo? Michal From unix at bikesn4x4s.com Sat Mar 4 02:51:25 2006 From: unix at bikesn4x4s.com (Paul) Date: Fri, 3 Mar 2006 21:51:25 -0500 (EST) Subject: Latest squirrelmail for Fedora Core 1, 2, 3 In-Reply-To: <20060304022149.GA5473@mail.harddata.com> References: <2015.192.168.103.1.1141437065.squirrel@bikesn4x4s> <20060304022149.GA5473@mail.harddata.com> Message-ID: <2423.192.168.103.1.1141440685.squirrel@bikesn4x4s> On Fri, March 3, 2006 9:21 pm, Michal Jaegermann wrote: > On Fri, Mar 03, 2006 at 08:51:05PM -0500, Paul wrote: >> Anyhow, I have verified the latest squirrelmail 1.4.5-1 fixes this bug. > > The latest one is squirrelmail-1.4.6-1. Well, for FC4 but it will > recompile anyway and it is fixing security issues. Is the above a typo? No typo. I assume 1.4.5-1 fixes security bugs in 1.4.5 for Core 1,2,3. Now, this is for legacy. This is a Legacy list and Core 4 is not yet legacy. ;-> From jkeating at j2solutions.net Sat Mar 4 04:20:49 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 03 Mar 2006 20:20:49 -0800 Subject: Rebuild exisitng errata for x86_64? Message-ID: <1141446049.17519.53.camel@ender> So with the new build software that we're having good success with we can produce x86_64 packages (and with future hardware donations ppc packages too). We've been spinning all FC3 updates with x86_64 packages, but the question remains, do we want to rebuild all previously released errata for x86_64, for releases that have x86_64 (FC1,2,3). This could be a lot of work, and I'm concerned about the difference in build systems. Releasing x86_64 versions of packages built with a different build system than that which produced the i386 versions just doesn't sit well with me. Then again, neither does rebuilding EVERY errata on the new build system and re-releasing all the packages. So I guess the bottom line question is, is there a significant amount of users in the community that need these older FC's updates built for x86_64, would be willing to do some basic QA on them, and would be willing to accept packages built on a different build system? Or should we just continue from this point forward with just FC3+ supporting x86_64? (and set policy for if/when we get support for ppc packages) I welcome your input. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Sat Mar 4 04:36:49 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 04 Mar 2006 10:06:49 +0530 Subject: Rebuild exisitng errata for x86_64? In-Reply-To: <1141446049.17519.53.camel@ender> References: <1141446049.17519.53.camel@ender> Message-ID: <44091961.6060200@fedoraproject.org> Jesse Keating wrote: >So with the new build software that we're having good success with we >can produce x86_64 packages (and with future hardware donations ppc >packages too). We've been spinning all FC3 updates with x86_64 >packages, but the question remains, do we want to rebuild all previously >released errata for x86_64, for releases that have x86_64 (FC1,2,3). >This could be a lot of work, and I'm concerned about the difference in >build systems. Releasing x86_64 versions of packages built with a >different build system than that which produced the i386 versions just >doesn't sit well with me. Then again, neither does rebuilding EVERY >errata on the new build system and re-releasing all the packages. > >So I guess the bottom line question is, is there a significant amount of >users in the community that need these older FC's updates built for >x86_64, would be willing to do some basic QA on them, and would be >willing to accept packages built on a different build system? Or should >we just continue from this point forward with just FC3+ supporting >x86_64? (and set policy for if/when we get support for ppc packages) > >I welcome your input. > > So perhaps an obvious question is could Red Hat internal build systems used by Fedora Core or the ones used for Fedora Extras be spared a few cycles for Fedora legacy on x86_64/PPC or do you want to keep the infrastructure independent?. If we are waiting for the community to donate time, money or resources to the project we need to list what exactly is required for them to participate. While the QA procedures for example are documented, the requirement for a PPC system is not. The website needs a highlighted list of such documentation. -- Rahul From jkeating at j2solutions.net Sat Mar 4 04:42:29 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 03 Mar 2006 20:42:29 -0800 Subject: Rebuild exisitng errata for x86_64? In-Reply-To: <44091961.6060200@fedoraproject.org> References: <1141446049.17519.53.camel@ender> <44091961.6060200@fedoraproject.org> Message-ID: <1141447350.17519.58.camel@ender> On Sat, 2006-03-04 at 10:06 +0530, Rahul Sundaram wrote: > So perhaps an obvious question is could Red Hat internal build systems > used by Fedora Core or the ones used for Fedora Extras be spared a few > cycles for Fedora legacy on x86_64/PPC or do you want to keep the > infrastructure independent?. If we are waiting for the community to > donate time, money or resources to the project we need to list what > exactly is required for them to participate. While the QA procedures for > example are documented, the requirement for a PPC system is not. The > website needs a highlighted list of such documentation. When I brought up the thought of using the Extras build system for doing Legacy updates, it was turned down and requested that we use our own infrastructure. Honestly I don't remember the reasons behind this, but I think a lot of it was we're still carrying around content for RHL. As far as money/resources, this is actually something I'm looking to Red Hat for. Red Hat wants the Fedora project to continue to grow, and Legacy is part of that project. I'm waiting for after FC5 is released so that we have some cycles for other project tasks, such as getting a copy of the CVS trees for our use and a few other things. At that time I'd like to talk to them about some infrastructure, or revisit the idea of using Extras infrastructure for Legacy building and publishing. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Sat Mar 4 04:56:21 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 04 Mar 2006 10:26:21 +0530 Subject: Rebuild exisitng errata for x86_64? In-Reply-To: <1141447350.17519.58.camel@ender> References: <1141446049.17519.53.camel@ender> <44091961.6060200@fedoraproject.org> <1141447350.17519.58.camel@ender> Message-ID: <44091DF5.3010007@fedoraproject.org> Jesse Keating wrote: >On Sat, 2006-03-04 at 10:06 +0530, Rahul Sundaram wrote: > > >>So perhaps an obvious question is could Red Hat internal build systems >>used by Fedora Core or the ones used for Fedora Extras be spared a few >>cycles for Fedora legacy on x86_64/PPC or do you want to keep the >>infrastructure independent?. If we are waiting for the community to >>donate time, money or resources to the project we need to list what >>exactly is required for them to participate. While the QA procedures for >>example are documented, the requirement for a PPC system is not. The >>website needs a highlighted list of such documentation. >> >> > >When I brought up the thought of using the Extras build system for doing >Legacy updates, it was turned down and requested that we use our own >infrastructure. Honestly I don't remember the reasons behind this, but >I think a lot of it was we're still carrying around content for RHL. > > Thats strange. How does RHL content affect the ability of Fedora Legacy to use Fedora Extras buildsystems?. I didnt see any public discussion happening on this and we definitely need the details spelled out more precisely. >As far as money/resources, this is actually something I'm looking to Red >Hat for. Red Hat wants the Fedora project to continue to grow, and >Legacy is part of that project. I'm waiting for after FC5 is released >so that we have some cycles for other project tasks, such as getting a >copy of the CVS trees for our use and a few other things. At that time >I'd like to talk to them about some infrastructure, or revisit the idea >of using Extras infrastructure for Legacy building and publishing. > I think we need to start sharing all the infrastructure more commonly within the various sub projects. Fedora directory server for example is using their own wiki for some odd reason (http://directory.fedora.redhat.com/wiki/Main_Page). The infrastructure pieces can be part of Red Hat or external to it but if there is already something available for Fedora Core or Extras, we need to take advantage of that. I dont understand the reluctance in doing this. -- Rahul From jkeating at j2solutions.net Sat Mar 4 05:16:08 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 03 Mar 2006 21:16:08 -0800 Subject: Rebuild exisitng errata for x86_64? In-Reply-To: <44091DF5.3010007@fedoraproject.org> References: <1141446049.17519.53.camel@ender> <44091961.6060200@fedoraproject.org> <1141447350.17519.58.camel@ender> <44091DF5.3010007@fedoraproject.org> Message-ID: <1141449369.17519.68.camel@ender> On Sat, 2006-03-04 at 10:26 +0530, Rahul Sundaram wrote: > Thats strange. How does RHL content affect the ability of Fedora Legacy > to use Fedora Extras buildsystems?. I didnt see any public discussion > happening on this and we definitely need the details spelled out more > precisely. Again, I'm not quite sure what it was. I just don't remember. I think it was discussed during a Fedora board meeting. I could ask the board if they remembered or if minutes were taken. So I just talked w/ one of the board members and the main reasons were resource contention and clear separation. So while we'd need our own equipment and space, there isn't many reasons why we couldn't be hosted right along side the Extras systems. Again, this just needs to be discussed. We've been working fairly well with just one system to do all our builds, and that system is in no way suitable to be colocated with the Extras equipment. However with me moving away from the place that has donated hosting up until now, it makes more sense to get systems located in a place that others can manage it. > >As far as money/resources, this is actually something I'm looking to Red > >Hat for. Red Hat wants the Fedora project to continue to grow, and > >Legacy is part of that project. I'm waiting for after FC5 is released > >so that we have some cycles for other project tasks, such as getting a > >copy of the CVS trees for our use and a few other things. At that time > >I'd like to talk to them about some infrastructure, or revisit the idea > >of using Extras infrastructure for Legacy building and publishing. > > > I think we need to start sharing all the infrastructure more commonly > within the various sub projects. Fedora directory server for example is > using their own wiki for some odd reason > (http://directory.fedora.redhat.com/wiki/Main_Page). The infrastructure > pieces can be part of Red Hat or external to it but if there is already > something available for Fedora Core or Extras, we need to take advantage > of that. I dont understand the reluctance in doing this. So as far as Legacy goes, we're using the Fedora wiki, we're considering collapsing all of our website into the Wiki, we're moving to use the same software as Extras, moving to get our repo data in Core directly, send announcements via fedora-announce, etc... If our systems are in the same place as Extras systems, and Fedora Sysadmins have access to them as well, and we share of the publish space, is that not integration? I don't think we need to shove other projects onto the same systems that do Extras builds. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Sat Mar 4 05:21:22 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 04 Mar 2006 10:51:22 +0530 Subject: Rebuild exisitng errata for x86_64? In-Reply-To: <1141449369.17519.68.camel@ender> References: <1141446049.17519.53.camel@ender> <44091961.6060200@fedoraproject.org> <1141447350.17519.58.camel@ender> <44091DF5.3010007@fedoraproject.org> <1141449369.17519.68.camel@ender> Message-ID: <440923D2.10106@fedoraproject.org> Jesse Keating wrote: >On Sat, 2006-03-04 at 10:26 +0530, Rahul Sundaram wrote: > > >>Thats strange. How does RHL content affect the ability of Fedora Legacy >>to use Fedora Extras buildsystems?. I didnt see any public discussion >>happening on this and we definitely need the details spelled out more >>precisely. >> >> > >Again, I'm not quite sure what it was. I just don't remember. I think >it was discussed during a Fedora board meeting. I could ask the board >if they remembered or if minutes were taken. > > Ya. It would be good to see an yes or no along with the details so that we understand better where the bottle neck is if any. >So as far as Legacy goes, we're using the Fedora wiki, we're considering >collapsing all of our website into the Wiki, we're moving to use the >same software as Extras, moving to get our repo data in Core directly, >send announcements via fedora-announce, etc... If our systems are in >the same place as Extras systems, and Fedora Sysadmins have access to >them as well, and we share of the publish space, is that not >integration? I don't think we need to shove other projects onto the >same systems that do Extras builds. > The way I see it, Fedora Extras and Core already have access to PPC systems and Legacy is meanwhile waiting for hardware donations. If we share the infrastructure and we are well integrated, that shouldnt be happening. This is not about shoving anything but tapping into the resources available till we can separate it more in the future if thats desirable. -- Rahul From jkeating at j2solutions.net Sat Mar 4 05:30:03 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 03 Mar 2006 21:30:03 -0800 Subject: Rebuild exisitng errata for x86_64? In-Reply-To: <440923D2.10106@fedoraproject.org> References: <1141446049.17519.53.camel@ender> <44091961.6060200@fedoraproject.org> <1141447350.17519.58.camel@ender> <44091DF5.3010007@fedoraproject.org> <1141449369.17519.68.camel@ender> <440923D2.10106@fedoraproject.org> Message-ID: <1141450204.17519.73.camel@ender> On Sat, 2006-03-04 at 10:51 +0530, Rahul Sundaram wrote: > The way I see it, Fedora Extras and Core already have access to PPC > systems and Legacy is meanwhile waiting for hardware donations. If we > share the infrastructure and we are well integrated, that shouldnt be > happening. This is not about shoving anything but tapping into the > resources available till we can separate it more in the future if thats > desirable. > This 'donation' could come from Red Hat, much like the Extras systems came from Red Hat. The thing is we want separation now, so rather than get settled into a system and then move out later, we'd rather do it right to begin with. Some of the resources can be shared, such as a repo of all the Fedora packages to pull from on a high speed link. So think of it as adding a couple more systems into the existing infrastructure and just tagging them for use by Legacy. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From donjr at maner.org Sat Mar 4 04:57:09 2006 From: donjr at maner.org (Donald Maner) Date: Fri, 3 Mar 2006 22:57:09 -0600 Subject: Rebuild exisitng errata for x86_64? Message-ID: <9CD490EAC0F62A40A780878421D4A730520A@amun.home.maner.org> > -----Original Message----- > From: fedora-legacy-list-bounces at redhat.com > [mailto:fedora-legacy-list-bounces at redhat.com] On Behalf Of > Jesse Keating > Sent: Friday, March 03, 2006 10:21 PM > To: fedora-legacy-list at redhat.com > Subject: Rebuild exisitng errata for x86_64? > So I guess the bottom line question is, is there a > significant amount of users in the community that need these > older FC's updates built for x86_64, would be willing to do > some basic QA on them, and would be willing to accept > packages built on a different build system? I'll do QA for FC3 x86_64, and as soon as I can get an Opteron or Xeon that can do 64 bit virtual machines, I'll do fc1 and fc2. Don't know when that will be, so all I will commit to is FC3 x86_64. From sundaram at fedoraproject.org Sat Mar 4 05:38:39 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 04 Mar 2006 11:08:39 +0530 Subject: Rebuild exisitng errata for x86_64? In-Reply-To: <1141450204.17519.73.camel@ender> References: <1141446049.17519.53.camel@ender> <44091961.6060200@fedoraproject.org> <1141447350.17519.58.camel@ender> <44091DF5.3010007@fedoraproject.org> <1141449369.17519.68.camel@ender> <440923D2.10106@fedoraproject.org> <1141450204.17519.73.camel@ender> Message-ID: <440927DF.4070902@fedoraproject.org> Jesse Keating wrote: >On Sat, 2006-03-04 at 10:51 +0530, Rahul Sundaram wrote: > > >>The way I see it, Fedora Extras and Core already have access to PPC >>systems and Legacy is meanwhile waiting for hardware donations. If we >>share the infrastructure and we are well integrated, that shouldnt be >>happening. This is not about shoving anything but tapping into the >>resources available till we can separate it more in the future if thats >>desirable. >> >> >> > >This 'donation' could come from Red Hat, much like the Extras systems >came from Red Hat. The thing is we want separation now, so rather than >get settled into a system and then move out later, we'd rather do it >right to begin with. Some of the resources can be shared, such as a >repo of all the Fedora packages to pull from on a high speed link. So >think of it as adding a couple more systems into the existing >infrastructure and just tagging them for use by Legacy. > > I dont think legacy is going to be using the build system as much as core and extras. It might be better to use a common pool of build systems separated by access time or build cycles rather than a physical allocation of individual build systems. In other words, does the current model of separation serve any real purpose other than being theoretically more clean? -- Rahul From jkeating at j2solutions.net Sat Mar 4 05:48:58 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 03 Mar 2006 21:48:58 -0800 Subject: Rebuild exisitng errata for x86_64? In-Reply-To: <440927DF.4070902@fedoraproject.org> References: <1141446049.17519.53.camel@ender> <44091961.6060200@fedoraproject.org> <1141447350.17519.58.camel@ender> <44091DF5.3010007@fedoraproject.org> <1141449369.17519.68.camel@ender> <440923D2.10106@fedoraproject.org> <1141450204.17519.73.camel@ender> <440927DF.4070902@fedoraproject.org> Message-ID: <1141451339.17519.85.camel@ender> On Sat, 2006-03-04 at 11:08 +0530, Rahul Sundaram wrote: > I dont think legacy is going to be using the build system as much as > core and extras. It might be better to use a common pool of build > systems separated by access time or build cycles rather than a physical > allocation of individual build systems. In other words, does the current > model of separation serve any real purpose other than being > theoretically more clean? More clean. It allows us to make modifications to plague/mock that are necessary for Legacy w/out interrupting what Extras is doing or using. Sure our patches would go upstream, but it shouldn't be necessary to interrupt the Extras system to make a change for the Legacy systems. Core doesn't use these systems so that is a completely different ball of wax (that doesn't need to be discussed here) -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From lsomike at futzin.com Sat Mar 4 05:53:21 2006 From: lsomike at futzin.com (Mike Klinke) Date: Fri, 3 Mar 2006 23:53:21 -0600 Subject: Latest squirrelmail for Fedora Core 1, 2, 3 In-Reply-To: <2423.192.168.103.1.1141440685.squirrel@bikesn4x4s> References: <2015.192.168.103.1.1141437065.squirrel@bikesn4x4s> <20060304022149.GA5473@mail.harddata.com> <2423.192.168.103.1.1141440685.squirrel@bikesn4x4s> Message-ID: <200603032353.21721.lsomike@futzin.com> On Friday 03 March 2006 20:51, Paul wrote: > On Fri, March 3, 2006 9:21 pm, Michal Jaegermann wrote: > > On Fri, Mar 03, 2006 at 08:51:05PM -0500, Paul wrote: > >> Anyhow, I have verified the latest squirrelmail 1.4.5-1 fixes > >> this bug. > > > > The latest one is squirrelmail-1.4.6-1. Well, for FC4 but it > > will recompile anyway and it is fixing security issues. Is the > > above a typo? > > No typo. I assume 1.4.5-1 fixes security bugs in 1.4.5 for Core > 1,2,3. Now, this is for legacy. This is a Legacy list and Core 4 > is not yet legacy. ;-> > FC3's current release ( August 2005 or so ) is: squirrelmail-1.4.6-0.cvs20050812.1.fc3 You may want to check to see if you missed and update along the way. Regards, Mike Klinke From phale at zues.tamucc.edu Sat Mar 4 07:10:39 2006 From: phale at zues.tamucc.edu (Phil Hale) Date: Sat, 04 Mar 2006 01:10:39 -0600 Subject: Documentation question at fedoralegacy.org In-Reply-To: <4408B170.2020407@research.dfci.harvard.edu> References: <1141336032.31231.159.camel@ender> <44088179.2090304@research.dfci.harvard.edu> <44089A6C.1080901@beta.intcomgrp.com> <44089CA6.2090000@research.dfci.harvard.edu> <4408AA59.60109@beta.intcomgrp.com> <4408B170.2020407@research.dfci.harvard.edu> Message-ID: <1141456239.3833.2.camel@gurney> Hello Everybody, If it is any help, I've been rebuilding all fedora legacy patches for FC2 in a production environment since Fedora Legacy took over maintenance of FC2. All legacy source RPMS have built without issues and the updates have been running flawlessly. If there is some way I can help to get the status changed for FC2 x86_64 patches to "okay" just let me know. Phil Hale Systems Programmer II Linux Systems Administrator Computer Services Texas A&M University-Corpus Christi On Fri, 2006-03-03 at 16:13 -0500, Matt Temple wrote: > James Kosin wrote: > > > Matt Temple wrote: > > > > >I'm not sure I understand. The x86_64 rpms are already in the download > > >area for > > >core 3. They're really there. > > Thanks. Let me see if anyone using this machine has significant > objections. > They might well, though. > > > > > > Matt > > > > Matt, > > > > I'm not saying they are not there. Like Jesse just posted, "they are > > evaluating the build system and they have not officially announced > > support for the x86_64 platform until a consensus can be made on weather > > support will be continued." > > > > If you have a x86_64 system and want to test the builds that are there > > and say yea or no on the packages then go right ahead. But, until we > > are sure they don't break anything we can't officially say yes to this. > > > > -James > > From michal at harddata.com Sat Mar 4 07:27:55 2006 From: michal at harddata.com (Michal Jaegermann) Date: Sat, 4 Mar 2006 00:27:55 -0700 Subject: Latest squirrelmail for Fedora Core 1, 2, 3 In-Reply-To: <2423.192.168.103.1.1141440685.squirrel@bikesn4x4s> References: <2015.192.168.103.1.1141437065.squirrel@bikesn4x4s> <20060304022149.GA5473@mail.harddata.com> <2423.192.168.103.1.1141440685.squirrel@bikesn4x4s> Message-ID: <20060304072755.GA9362@mail.harddata.com> On Fri, Mar 03, 2006 at 09:51:25PM -0500, Paul wrote: > On Fri, March 3, 2006 9:21 pm, Michal Jaegermann wrote: > > On Fri, Mar 03, 2006 at 08:51:05PM -0500, Paul wrote: > >> Anyhow, I have verified the latest squirrelmail 1.4.5-1 fixes this bug. > > > > The latest one is squirrelmail-1.4.6-1. Well, for FC4 but it will > > recompile anyway and it is fixing security issues. Is the above a typo? > > No typo. I assume 1.4.5-1 fixes security bugs in 1.4.5 for Core 1,2,3. No, it does not. This is from a changelog: * Wed Mar 01 2006 David Woodhouse 1.4.6-1 - Upgrade to 1.4.6 proper for CVE-2006-0377 CVE-2006-0195 CVE-2006-0188 Note "2006". New security problems were revealed in the meantime. > Now, this is for legacy. Does not help unless you backport security fixes and I am not even going to try with PHP. Michal From rostetter at mail.utexas.edu Sat Mar 4 07:58:01 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Sat, 4 Mar 2006 01:58:01 -0600 Subject: Rebuild exisitng errata for x86_64? In-Reply-To: <1141446049.17519.53.camel@ender> References: <1141446049.17519.53.camel@ender> Message-ID: <20060304015801.7eg44s5lpxs800o4@mail.ph.utexas.edu> Quoting Jesse Keating : > packages, but the question remains, do we want to rebuild all previously > released errata for x86_64, for releases that have x86_64 (FC1,2,3). Yes, if possible, but this is something to be done "in the background, at lower priority, as time permits." In any case, I think we should _at least_ release all FC3 packages for x86_64. In other words, we shouldn't release new FC3 x86_64 without releasing also the older FC3 x86_64, for consistency. > This could be a lot of work, and I'm concerned about the difference in > build systems. Releasing x86_64 versions of packages built with a > different build system than that which produced the i386 versions just > doesn't sit well with me. Then again, neither does rebuilding EVERY > errata on the new build system and re-releasing all the packages. Understandable. I'll let you and others who know more about this decide. That is why I said "yes, if possible" above rather than "yes." > So I guess the bottom line question is, is there a significant amount of > users in the community that need these older FC's updates built for > x86_64, would be willing to do some basic QA on them, and would be > willing to accept packages built on a different build system? I am only interested in FC3 myself... Sorry. > Or should > we just continue from this point forward with just FC3+ supporting > x86_64? (and set policy for if/when we get support for ppc packages) I'll let those who know more about the build system issues decide. > I welcome your input. > > -- > 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 marcdeslauriers at videotron.ca Sat Mar 4 14:15:27 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sat, 04 Mar 2006 09:15:27 -0500 Subject: Rebuild exisitng errata for x86_64? In-Reply-To: <20060304015801.7eg44s5lpxs800o4@mail.ph.utexas.edu> References: <1141446049.17519.53.camel@ender> <20060304015801.7eg44s5lpxs800o4@mail.ph.utexas.edu> Message-ID: <1141481727.15116.6.camel@mdlinux> On Sat, 2006-03-04 at 01:58 -0600, Eric Rostetter wrote: > In any case, I think we should _at least_ release all FC3 packages > for x86_64. In other words, we shouldn't release new FC3 x86_64 > without releasing also the older FC3 x86_64, for consistency. So far, all FC3 updates have had x86_64 packages. Marc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From marcdeslauriers at videotron.ca Sun Mar 5 19:20:53 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sun, 05 Mar 2006 14:20:53 -0500 Subject: [UPDATED] Fedora Legacy Test Update Notification: kernel (rh73 and rh9) Message-ID: <440B3A15.1070007@videotron.ca> These packages were updated to fix an incorrect patch that caused instability under heavy load. --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-157459-1 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157459 2006-03-05 --------------------------------------------------------------------- Name : kernel Versions : rh7.3: kernel-2.4.20-46.7.legacy Versions : rh9: kernel-2.4.20-46.9.legacy Summary : The Linux kernel (the core of the Linux operating system). Description : The kernel package contains the Linux kernel (vmlinuz), the core of the Red Hat Linux operating system. The kernel handles the basic functions of the operating system: memory allocation, process allocation, device input and output, etc. --------------------------------------------------------------------- Update Information: Updated kernel packages that fix several security issues are now available. The Linux kernel handles the basic functions of the operating system. These new kernel packages contain fixes for the security issues described below: - a flaw in network IGMP processing that a allowed a remote user on the local network to cause a denial of service (disabling of multicast reports) if the system is running multicast applications (CVE-2002-2185) - a recent Internet Draft by Fernando Gont recommended that ICMP Source Quench messages be ignored by hosts. A patch to ignore these messages is included. (CVE-2004-0791) - flaws in the coda module that allowed denial-of-service attacks (crashes) or local privilege escalations (CVE-2005-0124) - a flaw between execve() syscall handling and core dumping of ELF-format executables allowed local unprivileged users to cause a denial of service (system crash) or possibly gain privileges (CVE-2005-1263) - a flaw in gzip/zlib handling internal to the kernel that may allow a local user to cause a denial of service (crash) (CVE-2005-2458) - a flaw in sendmsg() syscall handling on 64-bit systems that allowed a local user to cause a denial of service or potentially gain privileges (CAN-2005-2490) - a flaw in exec() handling on some 64-bit architectures that allowed a local user to cause a denial of service (crash) (CVE-2005-2708) - a flaw in procfs handling during unloading of modules that allowed a local user to cause a denial of service or potentially gain privileges (CVE-2005-2709) - a flaw in IPv6 network UDP port hash table lookups that allowed a local user to cause a denial of service (hang) (CVE-2005-2973) - a network buffer info leak using the orinoco driver that allowed a remote user to possibly view uninitialized data (CVE-2005-3180) - a flaw in the packet radio ROSE protocol that allowed a user to trigger out-of-bounds errors. (CVE-2005-3273) - a flaw in IPv4 network TCP and UDP netfilter handling that allowed a local user to cause a denial of service (crash) (CVE-2005-3275) - a minor info leak with the get_thread_area() syscall that allowed a local user to view uninitialized kernel stack data (CVE-2005-3276) - a flaw in the IPv6 flowlabel code that allowed a local user to cause a denial of service (crash) (CVE-2005-3806) - a flaw in file lease time-out handling that allowed a local user to cause a denial of service (log file overflow) (CVE-2005-3857) All users are advised to upgrade their kernels to the packages associated with their machine architectures and configurations as listed in this erratum. --------------------------------------------------------------------- Changelogs rh73: * Thu Mar 02 2006 Marc Deslauriers 2.4.20-46.9.legacy - Fixed the broken CVE-2005-0749 patch that was causing unstability * Sat Feb 04 2006 Marc Deslauriers 2.4.20-45.9.legacy - Removed CVE-2005-3044 patch (it was 64-bit only) - Fixed CVE-2005-2709 patch - Added patch for CVE-2002-2185 (potential IGMP DoS) * Fri Feb 03 2006 Marc Deslauriers 2.4.20-44.9.legacy - Added patches for: CVE-2004-0791 (source quench DoS) CVE-2005-0124 (coda fs flaw) CVE-2005-1263 (ELF core dump privilege elevation) CVE-2005-2458 (gzip/zlib flaws) CVE-2005-2490 (compat layer sendmsg() races) CVE-2005-2708 (user code panics kernel in exec.c) CVE-2005-2709 (sysctl races) CVE-2005-2973 (ipv6 infinite loop) CVE-2005-3044 (lost fput and sockfd_put could lead to DoS) CVE-2005-3180 (orinoco driver information leakage) CVE-2005-3273 (ROSE ndigis verification) CVE-2005-3275 (NAT DoS) CVE-2005-3276 (sys_get_thread_area minor info leak) CVE-2005-3806 (ipv6 flowlabel DOS) CVE-2005-3857 (lease printk DoS) rh9: * Thu Mar 02 2006 Marc Deslauriers 2.4.20-46.9.legacy - Fixed the broken CVE-2005-0749 patch that was causing unstability * Sat Feb 04 2006 Marc Deslauriers 2.4.20-45.9.legacy - Removed CVE-2005-3044 patch (it was 64-bit only) - Fixed CVE-2005-2709 patch - Added patch for CVE-2002-2185 (potential IGMP DoS) * Fri Feb 03 2006 Marc Deslauriers 2.4.20-44.9.legacy - Added patches for: CVE-2004-0791 (source quench DoS) CVE-2005-0124 (coda fs flaw) CVE-2005-1263 (ELF core dump privilege elevation) CVE-2005-2458 (gzip/zlib flaws) CVE-2005-2490 (compat layer sendmsg() races) CVE-2005-2708 (user code panics kernel in exec.c) CVE-2005-2709 (sysctl races) CVE-2005-2973 (ipv6 infinite loop) CVE-2005-3044 (lost fput and sockfd_put could lead to DoS) CVE-2005-3180 (orinoco driver information leakage) CVE-2005-3273 (ROSE ndigis verification) CVE-2005-3275 (NAT DoS) CVE-2005-3276 (sys_get_thread_area minor info leak) CVE-2005-3806 (ipv6 flowlabel DOS) CVE-2005-3857 (lease printk DoS) --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh7.3: 13d96ec3b350e2fe08a0b2daea0fbc903b55dba6 redhat/7.3/updates-testing/i386/kernel-2.4.20-46.7.legacy.athlon.rpm dd2a0de51955f130914b97e54002999398594e78 redhat/7.3/updates-testing/i386/kernel-2.4.20-46.7.legacy.i386.rpm c2a33858f1863b5aa8fc61812620bd538416eec1 redhat/7.3/updates-testing/i386/kernel-2.4.20-46.7.legacy.i586.rpm 82f9abe5137fe60c379e54ed4c30102e77a3d7ce redhat/7.3/updates-testing/i386/kernel-2.4.20-46.7.legacy.i686.rpm 2b7d00492c0bdd1c42f8e1fd60c69aa06d2af5b2 redhat/7.3/updates-testing/i386/kernel-bigmem-2.4.20-46.7.legacy.i686.rpm 18b774d3bbe7bc2c3b1326b31cf653fc4ec3dd02 redhat/7.3/updates-testing/i386/kernel-BOOT-2.4.20-46.7.legacy.i386.rpm 53e150d66bcd19881e6d3375b3921cbdcc19f9da redhat/7.3/updates-testing/i386/kernel-doc-2.4.20-46.7.legacy.i386.rpm 8451d90ea0f882cc95635eac07ad794fe3a80b73 redhat/7.3/updates-testing/i386/kernel-smp-2.4.20-46.7.legacy.athlon.rpm 70cbb1233156b94cb7adf05a9a60932bdebd01a7 redhat/7.3/updates-testing/i386/kernel-smp-2.4.20-46.7.legacy.i586.rpm df9078043ff5fb7a46de6c664c6009d1a17591d3 redhat/7.3/updates-testing/i386/kernel-smp-2.4.20-46.7.legacy.i686.rpm d41ae5e41700ea15838560c1ab4cff28b405ebc6 redhat/7.3/updates-testing/i386/kernel-source-2.4.20-46.7.legacy.i386.rpm 21f35ccaf8e57e440c3019b34feb9d9505400b35 redhat/7.3/updates-testing/SRPMS/kernel-2.4.20-46.7.legacy.src.rpm rh9: 109e959e391c02665c2683714476641b512b1d2a redhat/9/updates-testing/i386/kernel-2.4.20-46.9.legacy.athlon.rpm bf329aff38c0cc9c6976994ba8b4fecf23f9a842 redhat/9/updates-testing/i386/kernel-2.4.20-46.9.legacy.i386.rpm c805fe8f45b96104ad70e1886bd46de107dee452 redhat/9/updates-testing/i386/kernel-2.4.20-46.9.legacy.i586.rpm 8bd381c660a26da151afbd1e3fc732b83c2becc4 redhat/9/updates-testing/i386/kernel-2.4.20-46.9.legacy.i686.rpm 70e9a8644eee9902c0d19ebf6b73b382909f178b redhat/9/updates-testing/i386/kernel-bigmem-2.4.20-46.9.legacy.i686.rpm d6f9e20636ac96af35f9c001b51b0be121aed44f redhat/9/updates-testing/i386/kernel-BOOT-2.4.20-46.9.legacy.i386.rpm f6c3109670d2cea5c47f78f1852ad28764ac5f4f redhat/9/updates-testing/i386/kernel-doc-2.4.20-46.9.legacy.i386.rpm 4c6803f8075e975ce898fabd55cc1534db98e0e8 redhat/9/updates-testing/i386/kernel-smp-2.4.20-46.9.legacy.athlon.rpm 79c7bda4bfe36807fdd4144146e728ffe20e1a9a redhat/9/updates-testing/i386/kernel-smp-2.4.20-46.9.legacy.i586.rpm 833c41272f7836354359194344de076e566c7eb4 redhat/9/updates-testing/i386/kernel-smp-2.4.20-46.9.legacy.i686.rpm f56721c762dcf68d1021213cae598765d53b710f redhat/9/updates-testing/i386/kernel-source-2.4.20-46.9.legacy.i386.rpm 665d140e5dacf04a703408634be6619e6878112a redhat/9/updates-testing/SRPMS/kernel-2.4.20-46.9.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Sun Mar 5 19:21:28 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sun, 05 Mar 2006 14:21:28 -0500 Subject: [UPDATED] Fedora Legacy Test Update Notification: kernel (fc1) Message-ID: <440B3A38.2060909@videotron.ca> These packages were updated to fix an incorrect patch that caused instability under heavy load. --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-157459-2 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157459 2006-03-05 --------------------------------------------------------------------- Name : kernel Versions : fc1: kernel-2.4.22-1.2199.8.legacy.nptl Summary : The Linux kernel (the core of the Linux operating system). Description : The kernel package contains the Linux kernel (vmlinuz), the core of the Red Hat Linux operating system. The kernel handles the basic functions of the operating system: memory allocation, process allocation, device input and output, etc. --------------------------------------------------------------------- Update Information: Updated kernel packages that fix several security issues are now available. The Linux kernel handles the basic functions of the operating system. These new kernel packages contain fixes for the security issues described below: - a flaw in network IGMP processing that a allowed a remote user on the local network to cause a denial of service (disabling of multicast reports) if the system is running multicast applications (CVE-2002-2185) - a recent Internet Draft by Fernando Gont recommended that ICMP Source Quench messages be ignored by hosts. A patch to ignore these messages is included. (CVE-2004-0791) - flaws in ptrace() syscall handling on AMD64 and Intel EM64T systems that allowed a local user to cause a denial of service (crash) (CAN-2005-0756, CAN-2005-1762, CAN-2005-2553) - a flaw between execve() syscall handling and core dumping of ELF-format executables allowed local unprivileged users to cause a denial of service (system crash) or possibly gain privileges (CVE-2005-1263) - a flaw in gzip/zlib handling internal to the kernel that may allow a local user to cause a denial of service (crash) (CVE-2005-2458) - a flaw in sendmsg() syscall handling on 64-bit systems that allowed a local user to cause a denial of service or potentially gain privileges (CAN-2005-2490) - a flaw in exec() handling on some 64-bit architectures that allowed a local user to cause a denial of service (crash) (CVE-2005-2708) - a flaw in procfs handling during unloading of modules that allowed a local user to cause a denial of service or potentially gain privileges (CVE-2005-2709) - a flaw in IPv6 network UDP port hash table lookups that allowed a local user to cause a denial of service (hang) (CVE-2005-2973) - a flaw in 32-bit-compat handling of the TIOCGDEV ioctl that allowed a local user to cause a denial of service (crash) (CVE-2005-3044) - a network buffer info leak using the orinoco driver that allowed a remote user to possibly view uninitialized data (CVE-2005-3180) - a flaw in IPv4 network TCP and UDP netfilter handling that allowed a local user to cause a denial of service (crash) (CVE-2005-3275) - a minor info leak with the get_thread_area() syscall that allowed a local user to view uninitialized kernel stack data (CVE-2005-3276) - a flaw in the IPv6 flowlabel code that allowed a local user to cause a denial of service (crash) (CVE-2005-3806) - a flaw in file lease time-out handling that allowed a local user to cause a denial of service (log file overflow) (CVE-2005-3857) All users are advised to upgrade their kernels to the packages associated with their machine architectures and configurations as listed in this erratum. --------------------------------------------------------------------- Changelogs fc1: * Fri Mar 03 2006 Marc Deslauriers 2.4.22-1.2199.8.legacy.nptl - Fixed the broken CVE-2005-0749 patch that was causing unstability * Fri Feb 17 2006 Marc Deslauriers 2.4.22-1.2199.7.legacy.nptl - Added patch for CVE-2002-2185 (potential IGMP DoS) * Thu Feb 02 2006 Marc Deslauriers 2.4.22-1.2199.6.legacy.nptl - Added patches for: CVE-2004-0791 (source quench DoS) CVE-2005-0756 (ptrace-check-segment x86_64 crash) CVE-2005-1263 (ELF core dump privilege elevation) CVE-2005-1762 (ptrace can induce double-fault on x86_64) CVE-2005-2458 (gzip/zlib flaws) CVE-2005-2490 (compat layer sendmsg() races) CVE-2005-2553 (32-bit ptrace find_target() oops) CVE-2005-2708 (user code panics kernel in exec.c) CVE-2005-2709 (sysctl races) CVE-2005-2973 (ipv6 infinite loop) CVE-2005-3044 (lost fput and sockfd_put could lead to DoS) CVE-2005-3180 (orinoco driver information leakage) CVE-2005-3275 (NAT DoS) CVE-2005-3276 (sys_get_thread_area minor info leak) CVE-2005-3806 (ipv6 flowlabel DOS) CVE-2005-3857 (lease printk DoS) --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) fc1: 5ec641496db89906ce3e587bda826b38f0e2b2b4 fedora/1/updates-testing/i386/kernel-2.4.22-1.2199.8.legacy.nptl.athlon.rpm 70e345e1ff5427a4aa41fb4b72155e6ba73fcc38 fedora/1/updates-testing/i386/kernel-2.4.22-1.2199.8.legacy.nptl.i586.rpm a8b7fe13256306a237f7bbbcbabd9f20223d4ed9 fedora/1/updates-testing/i386/kernel-2.4.22-1.2199.8.legacy.nptl.i686.rpm 3917adb45e830432e875092aca7c7447eb2c8363 fedora/1/updates-testing/i386/kernel-BOOT-2.4.22-1.2199.8.legacy.nptl.i386.rpm 337feb3c89f824fe1191cdf9332497e84effe122 fedora/1/updates-testing/i386/kernel-doc-2.4.22-1.2199.8.legacy.nptl.i386.rpm e015d687b7cb7ce56396d0199686e9ea182adb1e fedora/1/updates-testing/i386/kernel-smp-2.4.22-1.2199.8.legacy.nptl.athlon.rpm 157b2e6c26d187f9706d201e60ee1ea025cbec1c fedora/1/updates-testing/i386/kernel-smp-2.4.22-1.2199.8.legacy.nptl.i586.rpm 987d9826216bdeadfdc364aaa1a8272a11a5c478 fedora/1/updates-testing/i386/kernel-smp-2.4.22-1.2199.8.legacy.nptl.i686.rpm 4d4b7eae72326f73abb03a6833b767ab1170e3e9 fedora/1/updates-testing/i386/kernel-source-2.4.22-1.2199.8.legacy.nptl.i386.rpm 973e0e5c1916951e9fac3dcf02999969e6da102d fedora/1/updates-testing/SRPMS/kernel-2.4.22-1.2199.8.legacy.nptl.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From jkeating at j2solutions.net Mon Mar 6 21:12:39 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 06 Mar 2006 13:12:39 -0800 Subject: Good news.... Message-ID: <1141679559.4451.60.camel@ender> Looks like we'll have Legacy repos and GPG key shipped with FC5. We're only shipping config for legacy-updates-released, legacy-updates-testing, and legacy-utils. They're currently pointed to mirrorlist files that will be on download.fedora.redhat.com soon. These mirror files currently just point to our main download server (which has fc5 (and 4) trees now), but I'm hoping that by the time FC5 goes into legacy we'll have our own directory in download.fedora.redhat.com, and be included in all the mirrors throughout. This way we can worry about just our updates and not copy all the existing FC updates and the FC tree itself around. Easier to mirror, easier to manage. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From jkeating at j2solutions.net Mon Mar 6 21:27:34 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 06 Mar 2006 13:27:34 -0800 Subject: Good news.... In-Reply-To: <1141679559.4451.60.camel@ender> References: <1141679559.4451.60.camel@ender> Message-ID: <1141680454.4451.64.camel@ender> On Mon, 2006-03-06 at 13:12 -0800, Jesse Keating wrote: > only shipping config for legacy-updates-released, > legacy-updates-testing, and legacy-utils. My mistake. Only shipping legacy-updates-released and legacy-updates-testing. No legacy-utils, as it was used for first yum / apt, then yum configs, and with 5 it should be useless. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From sheltren at cs.ucsb.edu Mon Mar 6 22:49:51 2006 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Mon, 6 Mar 2006 16:49:51 -0600 Subject: Good news.... In-Reply-To: <1141680454.4451.64.camel@ender> References: <1141679559.4451.60.camel@ender> <1141680454.4451.64.camel@ender> Message-ID: <3B755BE8-4FAC-4639-8F7C-E3468DA1100E@cs.ucsb.edu> On Mar 6, 2006, at 3:27 PM, Jesse Keating wrote: > On Mon, 2006-03-06 at 13:12 -0800, Jesse Keating wrote: >> only shipping config for legacy-updates-released, >> legacy-updates-testing, and legacy-utils. > > My mistake. Only shipping legacy-updates-released and > legacy-updates-testing. No legacy-utils, as it was used for first > yum / > apt, then yum configs, and with 5 it should be useless. > Hi Jesse, this is good news indeed. Are you planning to have both of those enabled by default, or will updates-testing be disabled? -Jeff From jkeating at j2solutions.net Mon Mar 6 22:57:10 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 06 Mar 2006 17:57:10 -0500 Subject: Good news.... In-Reply-To: <3B755BE8-4FAC-4639-8F7C-E3468DA1100E@cs.ucsb.edu> References: <1141679559.4451.60.camel@ender> <1141680454.4451.64.camel@ender> <3B755BE8-4FAC-4639-8F7C-E3468DA1100E@cs.ucsb.edu> Message-ID: <1141685831.4451.82.camel@ender> On Mon, 2006-03-06 at 16:49 -0600, Jeff Sheltren wrote: > > > Hi Jesse, this is good news indeed. Are you planning to have both of > those enabled by default, or will updates-testing be disabled? None of it is enabled by default. Fedora upstream still want users to make a choice to use it, however the path to make the choice is rather easy. Flip a bit in an existing file and you're done. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From sheltren at cs.ucsb.edu Mon Mar 6 23:10:05 2006 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Mon, 6 Mar 2006 17:10:05 -0600 Subject: Good news.... In-Reply-To: <1141685831.4451.82.camel@ender> References: <1141679559.4451.60.camel@ender> <1141680454.4451.64.camel@ender> <3B755BE8-4FAC-4639-8F7C-E3468DA1100E@cs.ucsb.edu> <1141685831.4451.82.camel@ender> Message-ID: <42F35918-087B-41E2-9CA7-EE54F0A11459@cs.ucsb.edu> On Mar 6, 2006, at 4:57 PM, Jesse Keating wrote: > On Mon, 2006-03-06 at 16:49 -0600, Jeff Sheltren wrote: >> >> >> Hi Jesse, this is good news indeed. Are you planning to have both of >> those enabled by default, or will updates-testing be disabled? > > None of it is enabled by default. Fedora upstream still want users to > make a choice to use it, however the path to make the choice is rather > easy. Flip a bit in an existing file and you're done. > Sounds good to me! -Jeff From marcdeslauriers at videotron.ca Tue Mar 7 00:06:34 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 06 Mar 2006 19:06:34 -0500 Subject: Good news.... In-Reply-To: <1141679559.4451.60.camel@ender> References: <1141679559.4451.60.camel@ender> Message-ID: <1141689994.16606.0.camel@mdlinux> On Mon, 2006-03-06 at 13:12 -0800, Jesse Keating wrote: > Looks like we'll have Legacy repos and GPG key shipped with FC5. We're Wow! Great news. :) Marc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Tue Mar 7 02:57:39 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 07 Mar 2006 08:27:39 +0530 Subject: Good news.... In-Reply-To: <1141685831.4451.82.camel@ender> References: <1141679559.4451.60.camel@ender> <1141680454.4451.64.camel@ender> <3B755BE8-4FAC-4639-8F7C-E3468DA1100E@cs.ucsb.edu> <1141685831.4451.82.camel@ender> Message-ID: <440CF6A3.7090505@fedoraproject.org> Jesse Keating wrote: >On Mon, 2006-03-06 at 16:49 -0600, Jeff Sheltren wrote: > > >>Hi Jesse, this is good news indeed. Are you planning to have both of >>those enabled by default, or will updates-testing be disabled? >> >> > >None of it is enabled by default. Fedora upstream still want users to >make a choice to use it, however the path to make the choice is rather >easy. Flip a bit in an existing file and you're done. > > Fedora legacy-updates-released repository should be enabled by default IMO. Since the updates are not directly pushed into the updates-released repository, users still have the option to disable it easily if they dont want it some odd reason but the default should be favorable to non technical end users and provide the updates in a smooth transition from Fedora Core to Fedora Legacy. Fedora Extras has repository has been shipped enabled by default since Fedora Core 4 and I dont see a single reason why Fedora Legacy is different. Flip a bit in an existing file if you *dont* want it and Pirut might add a graphical interface to do that even. -- Rahul From jkeating at j2solutions.net Tue Mar 7 03:03:39 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 06 Mar 2006 22:03:39 -0500 Subject: Good news.... In-Reply-To: <440CF6A3.7090505@fedoraproject.org> References: <1141679559.4451.60.camel@ender> <1141680454.4451.64.camel@ender> <3B755BE8-4FAC-4639-8F7C-E3468DA1100E@cs.ucsb.edu> <1141685831.4451.82.camel@ender> <440CF6A3.7090505@fedoraproject.org> Message-ID: <1141700619.29955.6.camel@ender> On Tue, 2006-03-07 at 08:27 +0530, Rahul Sundaram wrote: > Fedora legacy-updates-released repository should be enabled by default > IMO. Since the updates are not directly pushed into the updates-released > repository, users still have the option to disable it easily if they > dont want it some odd reason but the default should be favorable to non > technical end users and provide the updates in a smooth transition from > Fedora Core to Fedora Legacy. Fedora Extras has repository has been > shipped enabled by default since Fedora Core 4 and I dont see a single > reason why Fedora Legacy is different. Flip a bit in an existing file > if you *dont* want it and Pirut might add a graphical interface to do > that even. While not perfect, it is a big step. Further down the road, when we have more pieces in place, we could enable by default. We're still not sure where our updates will land by the time FC5 comes out so having it disabled by default is helping us to prevent breaking people's yum based tools. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From deisenst at gtw.net Tue Mar 7 05:23:11 2006 From: deisenst at gtw.net (David Eisenstein) Date: Mon, 6 Mar 2006 23:23:11 -0600 (CST) Subject: Awaiting testing, Re: kde kjs vulnerabiity? In-Reply-To: <43E29899.6020804@anu.edu.au> Message-ID: On Fri, 3 Feb 2006, David Houlder wrote: > Hi... > > Am I right in thinking that this... > http://www.kde.org/info/security/advisory-20060119-1.txt > ...currently affects FC3? > Thanks > Kdelibs packages remain available for testing in updates-testing that fix that. FC2 and FC3 kdelibs is vulnerable to CVE-2006-0019, the KDE javascript vulnerability. Since the konqueror web-browser uses kdelibs, then konqueror for FC2 & FC3 is also vulnerable to this (until kdelibs is updated). Red Hat's update that fixes CVE-2006-0019 in Red Hat Enterprise Linux has been rated as having critical security impact by the Red Hat Security Response Team. Kdelibs packages are also in testing for other vulnerabilities for RHL 7.3, RHL 9, and FC1. The more votes these packages get, the sooner we can release them. References: * "Heap-based buffer overflow in the encodeURI and decodeURI functions in the kjs JavaScript interpreter engine in KDE 3.2.0 through 3.5.0 allows remote attackers to execute arbitrary code via a crafted, UTF-8 encoded URI." * Announcement of KDE packages needing downloading and testing: * Bugzilla ticket for this and other kdelibs issues: Thanks. Kind regards, David Eisenstein From gene.heskett at verizon.net Tue Mar 7 16:23:06 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Tue, 07 Mar 2006 11:23:06 -0500 Subject: Need a bwidgit Message-ID: <200603071123.06415.gene.heskett@verizon.net> Greetings all; I'm rsyncing a directory that contains the software for a machine control app, emc2 TBE, into an identical path directory tree here on this box. I got the bright idea of running it in simulation mode, which doesn't need the RTAI stuff thats installed on the real box out in an unheated shop building. Unforch, when I run it, it fails saying it needs a thing called 'bwidgit', apparently a debianism that isn't available from legacy for an fc2 system. Is there such a beastie? and if so, where can I get it? -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From bdm at fenrir.org.uk Tue Mar 7 19:30:11 2006 From: bdm at fenrir.org.uk (Brian Morrison) Date: Tue, 7 Mar 2006 19:30:11 +0000 Subject: Need a bwidgit In-Reply-To: <200603071123.06415.gene.heskett@verizon.net> References: <200603071123.06415.gene.heskett@verizon.net> Message-ID: <20060307193011.1aff541d@peterson.fenrir.org.uk> On Tue, 07 Mar 2006 11:23:06 -0500 Gene Heskett wrote: > Unforch, when I run it, it fails saying it needs a thing called > 'bwidgit', apparently a debianism that isn't available from legacy for > an fc2 system. It's called bwidget AFAICS and you can get a Fedora src rpm from rpmfind for it, you'll need to try and rebuild it for FC2. With luck it won't need many dependencies, it isn't showing any at rpmfind.net. -- Brian Morrison bdm at fenrir dot org dot uk GnuPG key ID DE32E5C5 - http://wwwkeys.uk.pgp.net/pgpnet/wwwkeys.html From gene.heskett at verizon.net Tue Mar 7 19:42:09 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Tue, 07 Mar 2006 14:42:09 -0500 Subject: Need a bwidgit In-Reply-To: <20060307193011.1aff541d@peterson.fenrir.org.uk> References: <200603071123.06415.gene.heskett@verizon.net> <20060307193011.1aff541d@peterson.fenrir.org.uk> Message-ID: <200603071442.09489.gene.heskett@verizon.net> On Tuesday 07 March 2006 14:30, Brian Morrison wrote: >On Tue, 07 Mar 2006 11:23:06 -0500 > >Gene Heskett wrote: >> Unforch, when I run it, it fails saying it needs a thing called >> 'bwidgit', apparently a debianism that isn't available from legacy >> for an fc2 system. > >It's called bwidget AFAICS and you can get a Fedora src rpm from >rpmfind for it, you'll need to try and rebuild it for FC2. With luck > it won't need many dependencies, it isn't showing any at rpmfind.net. Thanks, I'll look into that. -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From marcdeslauriers at videotron.ca Tue Mar 7 23:36:35 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 07 Mar 2006 18:36:35 -0500 Subject: [FLSA-2006:168264-1] Updated XFree86 packages fix security issues Message-ID: <440E1903.80304@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated XFree86 packages fix security issues Advisory ID: FLSA:168264-1 Issue date: 2006-03-07 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2005-0605 CVE-2005-2495 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated XFree86 packages that fix security issues are now available. XFree86 is an open source implementation of the X Window System. It provides the basic low-level functionality that full-fledged graphical user interfaces (GUIs) such as GNOME and KDE are designed upon. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 3. Problem description: An integer overflow flaw was found in libXpm, which is used by some applications for loading of XPM images. An attacker could create a malicious XPM file that would execute arbitrary code if opened by a victim using an application linked to the vulnerable library. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0605 to this issue. Several integer overflow bugs were found in the way XFree86 parses pixmap images. It is possible for a user to gain elevated privileges by loading a specially crafted pixmap image. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-2495 to this issue. Users of XFree86 should upgrade to these updated packages, which contain backported patches and are not vulnerable to these issues. 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=168264 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/XFree86-4.2.1-16.73.31.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-100dpi-fonts-4.2.1-16.73.31.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-4.2.1-16.73.31.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-75dpi-fonts-4.2.1-16.73.31.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-base-fonts-4.2.1-16.73.31.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-cyrillic-fonts-4.2.1-16.73.31.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-devel-4.2.1-16.73.31.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-doc-4.2.1-16.73.31.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-font-utils-4.2.1-16.73.31.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-ISO8859-15-100dpi-fonts-4.2.1-16.73.31.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-ISO8859-15-75dpi-fonts-4.2.1-16.73.31.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-ISO8859-2-100dpi-fonts-4.2.1-16.73.31.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-ISO8859-2-75dpi-fonts-4.2.1-16.73.31.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-ISO8859-9-100dpi-fonts-4.2.1-16.73.31.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-ISO8859-9-75dpi-fonts-4.2.1-16.73.31.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-libs-4.2.1-16.73.31.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-tools-4.2.1-16.73.31.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-truetype-fonts-4.2.1-16.73.31.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-twm-4.2.1-16.73.31.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-xdm-4.2.1-16.73.31.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-xf86cfg-4.2.1-16.73.31.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-xfs-4.2.1-16.73.31.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-Xnest-4.2.1-16.73.31.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-Xvfb-4.2.1-16.73.31.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/XFree86-4.3.0-2.90.61.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-100dpi-fonts-4.3.0-2.90.61.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-4.3.0-2.90.61.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-75dpi-fonts-4.3.0-2.90.61.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-base-fonts-4.3.0-2.90.61.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-cyrillic-fonts-4.3.0-2.90.61.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-devel-4.3.0-2.90.61.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-doc-4.3.0-2.90.61.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-font-utils-4.3.0-2.90.61.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-ISO8859-14-100dpi-fonts-4.3.0-2.90.61.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-ISO8859-14-75dpi-fonts-4.3.0-2.90.61.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-ISO8859-15-100dpi-fonts-4.3.0-2.90.61.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-ISO8859-15-75dpi-fonts-4.3.0-2.90.61.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-ISO8859-2-100dpi-fonts-4.3.0-2.90.61.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-ISO8859-2-75dpi-fonts-4.3.0-2.90.61.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-ISO8859-9-100dpi-fonts-4.3.0-2.90.61.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-ISO8859-9-75dpi-fonts-4.3.0-2.90.61.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-libs-4.3.0-2.90.61.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-libs-data-4.3.0-2.90.61.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-Mesa-libGL-4.3.0-2.90.61.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-Mesa-libGLU-4.3.0-2.90.61.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-sdk-4.3.0-2.90.61.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-syriac-fonts-4.3.0-2.90.61.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-tools-4.3.0-2.90.61.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-truetype-fonts-4.3.0-2.90.61.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-twm-4.3.0-2.90.61.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-xauth-4.3.0-2.90.61.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-xdm-4.3.0-2.90.61.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-xfs-4.3.0-2.90.61.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-Xnest-4.3.0-2.90.61.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-Xvfb-4.3.0-2.90.61.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/XFree86-4.3.0-60.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-100dpi-fonts-4.3.0-60.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-4.3.0-60.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-75dpi-fonts-4.3.0-60.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-base-fonts-4.3.0-60.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-cyrillic-fonts-4.3.0-60.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-devel-4.3.0-60.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-doc-4.3.0-60.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-font-utils-4.3.0-60.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-ISO8859-14-100dpi-fonts-4.3.0-60.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-ISO8859-14-75dpi-fonts-4.3.0-60.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-ISO8859-15-100dpi-fonts-4.3.0-60.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-ISO8859-15-75dpi-fonts-4.3.0-60.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-ISO8859-2-100dpi-fonts-4.3.0-60.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-ISO8859-2-75dpi-fonts-4.3.0-60.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-ISO8859-9-100dpi-fonts-4.3.0-60.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-ISO8859-9-75dpi-fonts-4.3.0-60.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-libs-4.3.0-60.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-libs-data-4.3.0-60.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-Mesa-libGL-4.3.0-60.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-Mesa-libGLU-4.3.0-60.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-sdk-4.3.0-60.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-syriac-fonts-4.3.0-60.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-tools-4.3.0-60.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-truetype-fonts-4.3.0-60.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-twm-4.3.0-60.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-xauth-4.3.0-60.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-xdm-4.3.0-60.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-xfs-4.3.0-60.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-Xnest-4.3.0-60.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-Xvfb-4.3.0-60.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 0cbc1cb6499a8684d19f24cf111b4fea65ba92ae redhat/7.3/updates/i386/XFree86-100dpi-fonts-4.2.1-16.73.31.legacy.i386.rpm 8c2025d75448c2f03b9bd2493cdc42f84741ba14 redhat/7.3/updates/i386/XFree86-4.2.1-16.73.31.legacy.i386.rpm 45d182c851d2d98fcf551ee5f4229ba76f7fe1ae redhat/7.3/updates/i386/XFree86-75dpi-fonts-4.2.1-16.73.31.legacy.i386.rpm 57d848f52c35787175eb7556350cf6202a3acc9e redhat/7.3/updates/i386/XFree86-base-fonts-4.2.1-16.73.31.legacy.i386.rpm 6b7e1499d32cea54eda46c7a23586edff860b01f redhat/7.3/updates/i386/XFree86-cyrillic-fonts-4.2.1-16.73.31.legacy.i386.rpm 5ae4db073a051453c1ea05328ba611820c54ac6e redhat/7.3/updates/i386/XFree86-devel-4.2.1-16.73.31.legacy.i386.rpm 8f5ddf6f2ffc17a706368dbdcd9f6880cf163eca redhat/7.3/updates/i386/XFree86-doc-4.2.1-16.73.31.legacy.i386.rpm e80034e10d2babcab44f449040556f1c62b9c65b redhat/7.3/updates/i386/XFree86-font-utils-4.2.1-16.73.31.legacy.i386.rpm 67b6b5d8b00a4f53ad300bc07d5c35c6c023280f redhat/7.3/updates/i386/XFree86-ISO8859-15-100dpi-fonts-4.2.1-16.73.31.legacy.i386.rpm c25c85a92e2fb2e80fb9ee2c19b0cb017e92b065 redhat/7.3/updates/i386/XFree86-ISO8859-15-75dpi-fonts-4.2.1-16.73.31.legacy.i386.rpm a54081ce435b2ed6695231f895e8cce95972027f redhat/7.3/updates/i386/XFree86-ISO8859-2-100dpi-fonts-4.2.1-16.73.31.legacy.i386.rpm ceb5c88c82123d553c09ed2dceb7395abf893dfc redhat/7.3/updates/i386/XFree86-ISO8859-2-75dpi-fonts-4.2.1-16.73.31.legacy.i386.rpm 9d8a2d217d1161cd8e37187ab82826592fced64b redhat/7.3/updates/i386/XFree86-ISO8859-9-100dpi-fonts-4.2.1-16.73.31.legacy.i386.rpm 7b7684a8bca628231f42d04aa545624052ebd59b redhat/7.3/updates/i386/XFree86-ISO8859-9-75dpi-fonts-4.2.1-16.73.31.legacy.i386.rpm dc04b533163d6a61471e2ce404bbce11e8a026de redhat/7.3/updates/i386/XFree86-libs-4.2.1-16.73.31.legacy.i386.rpm 58388c03cb94a1b74c4e65246a21b364e3e9bec0 redhat/7.3/updates/i386/XFree86-tools-4.2.1-16.73.31.legacy.i386.rpm 23d5801937faf0b0033db434d4713719bf13992f redhat/7.3/updates/i386/XFree86-truetype-fonts-4.2.1-16.73.31.legacy.i386.rpm ea0187127b7e4177c7d1653fe65c86d1b95f2dd9 redhat/7.3/updates/i386/XFree86-twm-4.2.1-16.73.31.legacy.i386.rpm 05d935b6e8e5b2dcc443556a3f15522aaa054278 redhat/7.3/updates/i386/XFree86-xdm-4.2.1-16.73.31.legacy.i386.rpm 7ec5886f06e93eac890fd5c47ed96b811b218b17 redhat/7.3/updates/i386/XFree86-xf86cfg-4.2.1-16.73.31.legacy.i386.rpm cd5d813aa22857cea4ea75179befad39e643559d redhat/7.3/updates/i386/XFree86-xfs-4.2.1-16.73.31.legacy.i386.rpm 53f7b20ad43180b4b860974a867030c484656b23 redhat/7.3/updates/i386/XFree86-Xnest-4.2.1-16.73.31.legacy.i386.rpm e0629ed131499721c4384630364fa34a4338614f redhat/7.3/updates/i386/XFree86-Xvfb-4.2.1-16.73.31.legacy.i386.rpm f28c45eafb4b035d7fa814ed8b23c1270aea4d0b redhat/7.3/updates/SRPMS/XFree86-4.2.1-16.73.31.legacy.src.rpm fb1a1f39a9372aa0147c508eb5d4db52d581a1cc redhat/9/updates/i386/XFree86-100dpi-fonts-4.3.0-2.90.61.legacy.i386.rpm 562913cdf6f7237b852062d1c6fd8f1a03482f9f redhat/9/updates/i386/XFree86-4.3.0-2.90.61.legacy.i386.rpm a0a44151d9c0c7b73e2b266b3c81f4e5cd2ba712 redhat/9/updates/i386/XFree86-75dpi-fonts-4.3.0-2.90.61.legacy.i386.rpm 0b6ae5bf6ea0938feadc805890c1b46b5de98870 redhat/9/updates/i386/XFree86-base-fonts-4.3.0-2.90.61.legacy.i386.rpm 6e06fe3b0262230d005020b9176a0601f8fe17fd redhat/9/updates/i386/XFree86-cyrillic-fonts-4.3.0-2.90.61.legacy.i386.rpm 75ec411aeaa191642774ff3d6b2da778849fff86 redhat/9/updates/i386/XFree86-devel-4.3.0-2.90.61.legacy.i386.rpm 9ca5fb3e139559593e1d3b243c03fd660ebf1bde redhat/9/updates/i386/XFree86-doc-4.3.0-2.90.61.legacy.i386.rpm 77f4f6d9d41c8ae72ca152fa8c5d856dd0d14acb redhat/9/updates/i386/XFree86-font-utils-4.3.0-2.90.61.legacy.i386.rpm 8a3282947adcb55f210534fa7930a2caf35ee31b redhat/9/updates/i386/XFree86-ISO8859-14-100dpi-fonts-4.3.0-2.90.61.legacy.i386.rpm 00e356bf12d218e3cf4cfd16cbdbb3bb6c1f4ff6 redhat/9/updates/i386/XFree86-ISO8859-14-75dpi-fonts-4.3.0-2.90.61.legacy.i386.rpm ffa1bfa1925f88314a916835609d2567593fee7d redhat/9/updates/i386/XFree86-ISO8859-15-100dpi-fonts-4.3.0-2.90.61.legacy.i386.rpm 73ccf11e207edc656b4bb7dfce08ed804290ef4b redhat/9/updates/i386/XFree86-ISO8859-15-75dpi-fonts-4.3.0-2.90.61.legacy.i386.rpm 38b67c16ea8b8191edb4b3df890d017b4c498397 redhat/9/updates/i386/XFree86-ISO8859-2-100dpi-fonts-4.3.0-2.90.61.legacy.i386.rpm ec33602ea178f0c9b3133f5224c7230f373a19ff redhat/9/updates/i386/XFree86-ISO8859-2-75dpi-fonts-4.3.0-2.90.61.legacy.i386.rpm b47fb63d7c9dfbe83846a8c016a4e62725d8fad4 redhat/9/updates/i386/XFree86-ISO8859-9-100dpi-fonts-4.3.0-2.90.61.legacy.i386.rpm b9c0e2552ccd4ce1f2cdd3494d38d956cd0e8c52 redhat/9/updates/i386/XFree86-ISO8859-9-75dpi-fonts-4.3.0-2.90.61.legacy.i386.rpm f34539d0acccb62d0c39eda5d8e2f69677594505 redhat/9/updates/i386/XFree86-libs-4.3.0-2.90.61.legacy.i386.rpm 44c71e911bcbc53bf2692bdb4fa39d05b69777ec redhat/9/updates/i386/XFree86-libs-data-4.3.0-2.90.61.legacy.i386.rpm b65547fc07ae1c1880cbfb2905dbc61a3e97f7d3 redhat/9/updates/i386/XFree86-Mesa-libGL-4.3.0-2.90.61.legacy.i386.rpm 537c5f4aacb6eedd2c508ab2968f013396e52a76 redhat/9/updates/i386/XFree86-Mesa-libGLU-4.3.0-2.90.61.legacy.i386.rpm 2b4c1d714eec3c66cb5b01539ee8d179b49ffcc1 redhat/9/updates/i386/XFree86-sdk-4.3.0-2.90.61.legacy.i386.rpm 97b8aa8cf0cfcb6af5e594819d98486b32f9c965 redhat/9/updates/i386/XFree86-syriac-fonts-4.3.0-2.90.61.legacy.i386.rpm 7898a7ae919e67e4cfe63fd3121d815710240bf0 redhat/9/updates/i386/XFree86-tools-4.3.0-2.90.61.legacy.i386.rpm d8b6e93b6c4fa6c0563bf9bc4f82b1e4828c9b30 redhat/9/updates/i386/XFree86-truetype-fonts-4.3.0-2.90.61.legacy.i386.rpm 3fdf5b8877cef9d337ae13deff0c72fdea156291 redhat/9/updates/i386/XFree86-twm-4.3.0-2.90.61.legacy.i386.rpm 612a4e120fcd790c5e8a3481e0cadd76fddb1cc7 redhat/9/updates/i386/XFree86-xauth-4.3.0-2.90.61.legacy.i386.rpm 6ceb66f35332408b2a19474533285b3d0fc17c9d redhat/9/updates/i386/XFree86-xdm-4.3.0-2.90.61.legacy.i386.rpm 174dcc7e757da7175b270ff34f8ce9c4efd9563e redhat/9/updates/i386/XFree86-xfs-4.3.0-2.90.61.legacy.i386.rpm 22b32e9c6460e4a52704f43d78675f0cdcce8291 redhat/9/updates/i386/XFree86-Xnest-4.3.0-2.90.61.legacy.i386.rpm ec25c9cb7a1bff4eccd503fedd3b49862d9c2405 redhat/9/updates/i386/XFree86-Xvfb-4.3.0-2.90.61.legacy.i386.rpm 84bbfb5f2fa13f20d465a0a552041526cb26bc3b redhat/9/updates/SRPMS/XFree86-4.3.0-2.90.61.legacy.src.rpm 2a09c30f05a126480d06220affc808bed0ccd831 fedora/1/updates/i386/XFree86-100dpi-fonts-4.3.0-60.legacy.i386.rpm d168ebb164d69f9fa0edd668a27e50a4e43ea2dd fedora/1/updates/i386/XFree86-4.3.0-60.legacy.i386.rpm e6ab23ec2e99a2d6dcbfed6a073402d88e796563 fedora/1/updates/i386/XFree86-75dpi-fonts-4.3.0-60.legacy.i386.rpm 5573af42869b10f104a52ac6fa5221e4c125cd46 fedora/1/updates/i386/XFree86-base-fonts-4.3.0-60.legacy.i386.rpm 0ae445a93ae5b573b2afb72441a712ac858c002e fedora/1/updates/i386/XFree86-cyrillic-fonts-4.3.0-60.legacy.i386.rpm c453822bd9aa5cdd6d7497bf7e629928a0424ebb fedora/1/updates/i386/XFree86-devel-4.3.0-60.legacy.i386.rpm b8768066b3f60ae86ab32559748c33590ae58b61 fedora/1/updates/i386/XFree86-doc-4.3.0-60.legacy.i386.rpm 142309e5f990556c9789bbe8e5b29e7b99ce9131 fedora/1/updates/i386/XFree86-font-utils-4.3.0-60.legacy.i386.rpm 02f4ffe56217dac4c263317c754be2221f11c2b1 fedora/1/updates/i386/XFree86-ISO8859-14-100dpi-fonts-4.3.0-60.legacy.i386.rpm f5a98a73fcdc0ff03e2b24ed9b8e147c85e55487 fedora/1/updates/i386/XFree86-ISO8859-14-75dpi-fonts-4.3.0-60.legacy.i386.rpm 7d833db16f028ff40d6ee67e04c03e7bb351a0fd fedora/1/updates/i386/XFree86-ISO8859-15-100dpi-fonts-4.3.0-60.legacy.i386.rpm 318f747bcdbd0be642d3fe1d52382772dec56634 fedora/1/updates/i386/XFree86-ISO8859-15-75dpi-fonts-4.3.0-60.legacy.i386.rpm 38395a9806da0e234d74b7c1e6e3dbed5d525726 fedora/1/updates/i386/XFree86-ISO8859-2-100dpi-fonts-4.3.0-60.legacy.i386.rpm 507cc1c515c2fe3f901704153819bcc62c133b46 fedora/1/updates/i386/XFree86-ISO8859-2-75dpi-fonts-4.3.0-60.legacy.i386.rpm e5a19310f393f5fde53a72a7fa3d522e227bc7e7 fedora/1/updates/i386/XFree86-ISO8859-9-100dpi-fonts-4.3.0-60.legacy.i386.rpm f65b8b8da1484ce2dd20737cc0279865ab5fdbd8 fedora/1/updates/i386/XFree86-ISO8859-9-75dpi-fonts-4.3.0-60.legacy.i386.rpm 1bbdad4b6bd3117c6495d7c3bdef3da6bcb9ab0b fedora/1/updates/i386/XFree86-libs-4.3.0-60.legacy.i386.rpm 8a55ec0a7a0564c3cd3f4263b6cc8e4ed151ba8e fedora/1/updates/i386/XFree86-libs-data-4.3.0-60.legacy.i386.rpm c9eb4e6054d2159b1ff28a5ce52b640a4e9b0359 fedora/1/updates/i386/XFree86-Mesa-libGL-4.3.0-60.legacy.i386.rpm 5e9c2f7390b7200e573a77bd9051ec36eb67621f fedora/1/updates/i386/XFree86-Mesa-libGLU-4.3.0-60.legacy.i386.rpm 9cde04ebb5610324b158a9ae2b5f0d04d56ed7cb fedora/1/updates/i386/XFree86-sdk-4.3.0-60.legacy.i386.rpm 339d8521270468753b9db696306acd64cb8bbab1 fedora/1/updates/i386/XFree86-syriac-fonts-4.3.0-60.legacy.i386.rpm c011244e0b99ce7d3929c3ad6958f409de1f6139 fedora/1/updates/i386/XFree86-tools-4.3.0-60.legacy.i386.rpm 36ba1b374ee3fae3b65712e2cd2a6b1e131524a5 fedora/1/updates/i386/XFree86-truetype-fonts-4.3.0-60.legacy.i386.rpm 36f807093616e0615f4a70dc46ebd91b256ce8d2 fedora/1/updates/i386/XFree86-twm-4.3.0-60.legacy.i386.rpm 5f82fea2f05c74f2433ebc6bc2e4db188ad9e7d2 fedora/1/updates/i386/XFree86-xauth-4.3.0-60.legacy.i386.rpm 2b5768e46ce851b22564cc3b824d0987d027b8d1 fedora/1/updates/i386/XFree86-xdm-4.3.0-60.legacy.i386.rpm c11d8de359322a543e8876163581bc38fa06b954 fedora/1/updates/i386/XFree86-xfs-4.3.0-60.legacy.i386.rpm a3b20af14a192aa110f0fe247d7c6d0478cebd98 fedora/1/updates/i386/XFree86-Xnest-4.3.0-60.legacy.i386.rpm ba4f2c18b58be48594a48eafc97564d31aec0286 fedora/1/updates/i386/XFree86-Xvfb-4.3.0-60.legacy.i386.rpm d1fe795457c17ae1348c63e859414623d8fd5c02 fedora/1/updates/SRPMS/XFree86-4.3.0-60.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-0605 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2495 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Tue Mar 7 23:37:19 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 07 Mar 2006 18:37:19 -0500 Subject: [FLSA-2006:168264-2] Updated X.org packages fix security issue Message-ID: <440E192F.1070104@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated X.org packages fix security issue Advisory ID: FLSA:168264-2 Issue date: 2006-03-07 Product: Fedora Core Keywords: Bugfix CVE Names: CVE-2005-2495 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated X.org packages that fix a security issue are now available. X.org is an open source implementation of the X Window System. It provides the basic low-level functionality that full-fledged graphical user interfaces (GUIs) such as GNOME and KDE are designed upon. 2. Relevant releases/architectures: Fedora Core 2 - i386 3. Problem description: Several integer overflow bugs were found in the way X.org parses pixmap images. It is possible for a user to gain elevated privileges by loading a specially crafted pixmap image. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-2495 to this issue. Users of X.org should upgrade to these updated packages, which contain a backported patch and are not vulnerable to this issue. 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=168264 6. RPMs required: Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/xorg-x11-6.7.0-14.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-100dpi-fonts-6.7.0-14.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-6.7.0-14.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-75dpi-fonts-6.7.0-14.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-base-fonts-6.7.0-14.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-cyrillic-fonts-6.7.0-14.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-devel-6.7.0-14.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-doc-6.7.0-14.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-font-utils-6.7.0-14.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-ISO8859-14-100dpi-fonts-6.7.0-14.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-ISO8859-14-75dpi-fonts-6.7.0-14.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-ISO8859-15-100dpi-fonts-6.7.0-14.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-ISO8859-15-75dpi-fonts-6.7.0-14.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-ISO8859-2-100dpi-fonts-6.7.0-14.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-ISO8859-2-75dpi-fonts-6.7.0-14.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-ISO8859-9-100dpi-fonts-6.7.0-14.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-ISO8859-9-75dpi-fonts-6.7.0-14.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-libs-6.7.0-14.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-libs-data-6.7.0-14.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-Mesa-libGL-6.7.0-14.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-Mesa-libGLU-6.7.0-14.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-sdk-6.7.0-14.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-syriac-fonts-6.7.0-14.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-tools-6.7.0-14.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-truetype-fonts-6.7.0-14.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-twm-6.7.0-14.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-xauth-6.7.0-14.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-xdm-6.7.0-14.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-xfs-6.7.0-14.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-Xnest-6.7.0-14.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/xorg-x11-Xvfb-6.7.0-14.1.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- fb2e8bbd5c2f1132d19ee20bd773be9d3179db9d fedora/2/updates/i386/xorg-x11-100dpi-fonts-6.7.0-14.1.legacy.i386.rpm 02ff368c88f7907764b2da5e385f2e079f3849cd fedora/2/updates/i386/xorg-x11-6.7.0-14.1.legacy.i386.rpm c81dda89910ea896c7070eab733df161dba54a39 fedora/2/updates/i386/xorg-x11-75dpi-fonts-6.7.0-14.1.legacy.i386.rpm 501f87e1196be0a33d95f0d52ead826677a34f22 fedora/2/updates/i386/xorg-x11-base-fonts-6.7.0-14.1.legacy.i386.rpm 1e0c6b43d3965b5e7d2d049bbc790d9a8c73a7d0 fedora/2/updates/i386/xorg-x11-cyrillic-fonts-6.7.0-14.1.legacy.i386.rpm 82eb2326f5b8494f96761e6092e34056e700a809 fedora/2/updates/i386/xorg-x11-devel-6.7.0-14.1.legacy.i386.rpm c0d1461ddb2c070cdabddf6b3ebccc34ec66d3ef fedora/2/updates/i386/xorg-x11-doc-6.7.0-14.1.legacy.i386.rpm 3f6382954c75e22ab177abbe1707140feea0170d fedora/2/updates/i386/xorg-x11-font-utils-6.7.0-14.1.legacy.i386.rpm 6f0c373860e9d64c5efea95e77d3e6d5872dacc0 fedora/2/updates/i386/xorg-x11-ISO8859-14-100dpi-fonts-6.7.0-14.1.legacy.i386.rpm c861aa4032a4f169929f225d46e798f5e0f18890 fedora/2/updates/i386/xorg-x11-ISO8859-14-75dpi-fonts-6.7.0-14.1.legacy.i386.rpm 83eb270f4395c14edd17cc55a1d78965e5f602e8 fedora/2/updates/i386/xorg-x11-ISO8859-15-100dpi-fonts-6.7.0-14.1.legacy.i386.rpm a99b042654bd86640eea6e7e1b76bda402d49b85 fedora/2/updates/i386/xorg-x11-ISO8859-15-75dpi-fonts-6.7.0-14.1.legacy.i386.rpm 52b7c9ff7e29265605c4bb1d08a735b279287fc5 fedora/2/updates/i386/xorg-x11-ISO8859-2-100dpi-fonts-6.7.0-14.1.legacy.i386.rpm 4e3900230a90728563f1173c8af82af2272dec03 fedora/2/updates/i386/xorg-x11-ISO8859-2-75dpi-fonts-6.7.0-14.1.legacy.i386.rpm 5091477dffb64324caae7d3d558882ab73e26609 fedora/2/updates/i386/xorg-x11-ISO8859-9-100dpi-fonts-6.7.0-14.1.legacy.i386.rpm 9ef03f7f4355a5e1d3f19f71d597e541cad3e831 fedora/2/updates/i386/xorg-x11-ISO8859-9-75dpi-fonts-6.7.0-14.1.legacy.i386.rpm f1ea8740e9802ad98b194284e8afb3eee8e1106d fedora/2/updates/i386/xorg-x11-libs-6.7.0-14.1.legacy.i386.rpm 222037711ead385d31fac145142c10c9c93f8c51 fedora/2/updates/i386/xorg-x11-libs-data-6.7.0-14.1.legacy.i386.rpm c21a7c11d52eaabe8bae5145e270c5301fcf8c17 fedora/2/updates/i386/xorg-x11-Mesa-libGL-6.7.0-14.1.legacy.i386.rpm 3314b29f2bc32e4ccd837b7973fc07847d073df0 fedora/2/updates/i386/xorg-x11-Mesa-libGLU-6.7.0-14.1.legacy.i386.rpm 3eac8219f4e3753644511090657ddc513a75c0c8 fedora/2/updates/i386/xorg-x11-sdk-6.7.0-14.1.legacy.i386.rpm f99d01e683755302d4ed5ea8a03f09b4828b7ea0 fedora/2/updates/i386/xorg-x11-syriac-fonts-6.7.0-14.1.legacy.i386.rpm d265d17e698e8d2e3a40c9b8519fe70cd01a1ca2 fedora/2/updates/i386/xorg-x11-tools-6.7.0-14.1.legacy.i386.rpm ff8ff747514e3b9bf7945aac37ed19ab00293fbd fedora/2/updates/i386/xorg-x11-truetype-fonts-6.7.0-14.1.legacy.i386.rpm e6141cfe3188c556c6e8ba54eba44d5e8645f09b fedora/2/updates/i386/xorg-x11-twm-6.7.0-14.1.legacy.i386.rpm 05fc596a5a8956e8fcbd1ac788bbba855e87fbba fedora/2/updates/i386/xorg-x11-xauth-6.7.0-14.1.legacy.i386.rpm 70b47f7e0e944ef7402437135a044209cba064ae fedora/2/updates/i386/xorg-x11-xdm-6.7.0-14.1.legacy.i386.rpm f6b74e278a54a2477bbda52155daad7787721a81 fedora/2/updates/i386/xorg-x11-xfs-6.7.0-14.1.legacy.i386.rpm c362a7d289c0c8d56ad63f0364e879819185871f fedora/2/updates/i386/xorg-x11-Xnest-6.7.0-14.1.legacy.i386.rpm fd3251aec6f906005c34d5a6e3324e38a0dcc510 fedora/2/updates/i386/xorg-x11-Xvfb-6.7.0-14.1.legacy.i386.rpm af4f7aea4c1b550d1a0389c0f3213bc6c74d87e6 fedora/2/updates/SRPMS/xorg-x11-6.7.0-14.1.legacy.src.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2495 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Tue Mar 7 23:37:55 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 07 Mar 2006 18:37:55 -0500 Subject: [FLSA-2006:168516] Updated pcre packages fix a security issue Message-ID: <440E1953.4060806@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated pcre packages fix a security issue Advisory ID: FLSA:168516 Issue date: 2006-03-07 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2005-2491 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated pcre packages are now available to correct a security issue. PCRE is a Perl-compatible regular expression library. 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: An integer overflow flaw was found in PCRE, triggered by a maliciously crafted regular expression. On systems that accept arbitrary regular expressions from untrusted users, this could be exploited to execute arbitrary code with the privileges of the application using the library. The Common Vulnerabilities and Exposures project assigned the name CVE-2005-2491 to this issue. Users should update to these erratum packages that contain a backported patch to correct this issue. 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=168516 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/pcre-3.9-2.1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/pcre-3.9-2.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/pcre-devel-3.9-2.1.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/pcre-3.9-10.1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/pcre-3.9-10.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/pcre-devel-3.9-10.1.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/pcre-4.4-1.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/pcre-4.4-1.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/pcre-devel-4.4-1.2.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/pcre-4.5-2.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/pcre-4.5-2.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/pcre-devel-4.5-2.2.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 9b641aa989639c706065bafc146d34bb6e282a22 redhat/7.3/updates/i386/pcre-3.9-2.1.legacy.i386.rpm 7d8b094083c7a85991d194d6741a0a664204a19d redhat/7.3/updates/i386/pcre-devel-3.9-2.1.legacy.i386.rpm 9a49145385042483532254fb5d05fae6c3f252f3 redhat/7.3/updates/SRPMS/pcre-3.9-2.1.legacy.src.rpm d876a7f4cdb3a936b2f72fb629fae928d3db6e96 redhat/9/updates/i386/pcre-3.9-10.1.legacy.i386.rpm 9e516b5e44944b25a47171b15c0229423b10f99d redhat/9/updates/i386/pcre-devel-3.9-10.1.legacy.i386.rpm 55de51292b97aacbad6c375b4ad8578561ac5fe3 redhat/9/updates/SRPMS/pcre-3.9-10.1.legacy.src.rpm 4edc206f1e0fc0c3df459b6f8de289f27417974b fedora/1/updates/i386/pcre-4.4-1.2.legacy.i386.rpm 0fcc5801dc238bb1fac0d59b8403e6cdcc72f126 fedora/1/updates/i386/pcre-devel-4.4-1.2.legacy.i386.rpm 57b3a2c5c2bb3435d3c7971daf29c665fb2c1687 fedora/1/updates/SRPMS/pcre-4.4-1.2.legacy.src.rpm bff4b330e8c9a76262020c7ddb2b48f71bf01788 fedora/2/updates/i386/pcre-4.5-2.2.legacy.i386.rpm 8354926500e18905dd94dddc1e6bf44cd236df68 fedora/2/updates/i386/pcre-devel-4.5-2.2.legacy.i386.rpm 9f43e7d484412d93734dfe4b08f87d2ef133100a fedora/2/updates/SRPMS/pcre-4.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-2005-2491 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Tue Mar 7 23:38:31 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 07 Mar 2006 18:38:31 -0500 Subject: [FLSA-2006:176751] Updated gpdf package fixes security issues Message-ID: <440E1977.7070802@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated gpdf package fixes security issues Advisory ID: FLSA:176751 Issue date: 2006-03-07 Product: Fedora Core Keywords: Bugfix CVE Names: CVE-2005-2097 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: An updated gpdf package that fixes several security issues is now available. The gpdf package is a GNOME based viewer for Portable Document Format (PDF) files. 2. Relevant releases/architectures: Fedora Core 1 - i386 Fedora Core 2 - i386 Fedora Core 3 - i386, x86_64 3. Problem description: A flaw was discovered in gpdf. An attacker could construct a carefully crafted PDF file that would cause gpdf to consume all available disk space in /tmp when opened. The Common Vulnerabilities and Exposures project assigned the name CVE-2005-2097 to this issue. Several flaws were discovered in gpdf. An attacker could construct a carefully crafted PDF file that could cause gpdf to crash or possibly execute arbitrary code when opened. The Common Vulnerabilities and Exposures project assigned the names CVE-2005-3191, CVE-2005-3192, CVE-2005-3193, CVE-2005-3624, CVE-2005-3625, CVE-2005-3626, CVE-2005-3627 and CVE-2005-3628 to these issues. Users of gpdf should upgrade to this updated package, which contains backported patches to resolve these issues. 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=176751 6. RPMs required: Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/gpdf-0.110-1.5.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/gpdf-0.110-1.5.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/gpdf-2.8.2-4.1.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/gpdf-2.8.2-4.1.1.legacy.i386.rpm Fedora Core 3: SRPM: http://download.fedoralegacy.org/fedora/3/updates/SRPMS/gpdf-2.8.2-7.2.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/3/updates/i386/gpdf-2.8.2-7.2.1.legacy.i386.rpm x86_64: http://download.fedoralegacy.org/fedora/3/updates/x86_64/gpdf-2.8.2-7.2.1.legacy.x86_64.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 646edd9bdaf07a2f74d0b9874a666f94dc4f7982 fedora/1/updates-testing/i386/gpdf-0.110-1.5.legacy.i386.rpm 23f1172453f4e6572bd5a5bebcf093fda9c9ef62 fedora/1/updates-testing/SRPMS/gpdf-0.110-1.5.legacy.src.rpm 2798a8e5ba37214b4ad3d537aa38b65c62c9e7c7 fedora/2/updates-testing/i386/gpdf-2.8.2-4.1.1.legacy.i386.rpm e6d36329145bd25d5646da0064124f4b3a3faf99 fedora/2/updates-testing/SRPMS/gpdf-2.8.2-4.1.1.legacy.src.rpm 2a08ad7afb9cecc7e41d80603a536b191d85f776 fedora/3/updates-testing/i386/gpdf-2.8.2-7.2.1.legacy.i386.rpm 3d3ab23bea79b424aaac1c26e3c16a3dfbee7af0 fedora/3/updates-testing/SRPMS/gpdf-2.8.2-7.2.1.legacy.src.rpm a434ff117af22aeacc3c76773fa6985be9c107c0 fedora/3/updates-testing/x86_64/gpdf-2.8.2-7.2.1.legacy.x86_64.rpm 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-2097 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: 191 bytes Desc: OpenPGP digital signature URL: From d.terweij at nettuning.net Wed Mar 8 16:29:10 2006 From: d.terweij at nettuning.net (Danny Terweij - Net Tuning | Net) Date: Wed, 8 Mar 2006 17:29:10 +0100 Subject: X-Chat 2.4.0 to 2.6 Message-ID: <00a101c642cd$6e970e00$1e00a8c0@prvd321> Can someone provide a new version of X-Chat in legacy updates fc3 repo? its still at 2.4.0 but newest is in 2.6. Thank you. Danny. From rdieter at math.unl.edu Wed Mar 8 16:34:48 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 08 Mar 2006 10:34:48 -0600 Subject: X-Chat 2.4.0 to 2.6 In-Reply-To: <00a101c642cd$6e970e00$1e00a8c0@prvd321> References: <00a101c642cd$6e970e00$1e00a8c0@prvd321> Message-ID: <440F07A8.4080004@math.unl.edu> Danny Terweij - Net Tuning | Net wrote: > Can someone provide a new version of X-Chat in legacy updates fc3 repo? Probably not. legacy updates is for security and critical bug fixes only. -- Rex From d.terweij at nettuning.net Wed Mar 8 16:46:21 2006 From: d.terweij at nettuning.net (Danny Terweij - Net Tuning | Net) Date: Wed, 8 Mar 2006 17:46:21 +0100 Subject: X-Chat 2.4.0 to 2.6 References: <00a101c642cd$6e970e00$1e00a8c0@prvd321> <440F07A8.4080004@math.unl.edu> Message-ID: <00b501c642cf$d5c10ca0$1e00a8c0@prvd321> From: "Rex Dieter" > > Can someone provide a new version of X-Chat in legacy updates fc3 repo? > Probably not. legacy updates is for security and critical bug fixes only. Hmm that sucks. Not 1 of all the FC3 repo's providing a new version. I use RH since 5.0. But sinds Fedora i dislike it more and more. Are there here people that wants create a *real* legacy-updates repo for NEW versions? I suggest to rename the current legacy-updates to legacy-security or something like that. legacy-updates sounds like just updates of new versions to me like the normal repo's also is doing rather then security shit.. Danny. From rdieter at math.unl.edu Wed Mar 8 17:03:32 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 08 Mar 2006 11:03:32 -0600 Subject: X-Chat 2.4.0 to 2.6 In-Reply-To: <00b501c642cf$d5c10ca0$1e00a8c0@prvd321> References: <00a101c642cd$6e970e00$1e00a8c0@prvd321> <440F07A8.4080004@math.unl.edu> <00b501c642cf$d5c10ca0$1e00a8c0@prvd321> Message-ID: <440F0E64.8020009@math.unl.edu> Danny Terweij - Net Tuning | Net wrote: > From: "Rex Dieter" > >>>Can someone provide a new version of X-Chat in legacy updates fc3 repo? > > >>Probably not. legacy updates is for security and critical bug fixes only. > > > Hmm that sucks. It's prominent on http://fedoralegacy.org/ "What is The Fedora Legacy Project?" That's the price you pay for using a EOL'd release. Want new features/versions? Upgrade to a newer/supported release. -- Rex From smooge at gmail.com Wed Mar 8 17:00:55 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Wed, 8 Mar 2006 10:00:55 -0700 Subject: X-Chat 2.4.0 to 2.6 In-Reply-To: <00b501c642cf$d5c10ca0$1e00a8c0@prvd321> References: <00a101c642cd$6e970e00$1e00a8c0@prvd321> <440F07A8.4080004@math.unl.edu> <00b501c642cf$d5c10ca0$1e00a8c0@prvd321> Message-ID: <80d7e4090603080900o1c107830u427d918563629548@mail.gmail.com> On 3/8/06, Danny Terweij - Net Tuning | Net wrote: > > From: "Rex Dieter" > > > > Can someone provide a new version of X-Chat in legacy updates fc3 repo? > > > Probably not. legacy updates is for security and critical bug fixes only. > > Hmm that sucks. > > Not 1 of all the FC3 repo's providing a new version. I use RH since 5.0. But > sinds Fedora i dislike it more and more. > > Are there here people that wants create a *real* legacy-updates repo for NEW > versions? > > I suggest to rename the current legacy-updates to legacy-security or > something like that. > legacy-updates sounds like just updates of new versions to me like the > normal repo's also is doing rather then security shit.. > I have been using Red Hat since 3.0.3.. and pretty much whenever a release was frozen.. new stuff didnt get put into the channel. The amount of work to try and do new releases of packages is not trivial. Just trying to keep up with security updates is more than enough for the few people who have volunteered to do any legacy work. > Danny. > > -- > 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 kelson at speed.net Wed Mar 8 17:12:46 2006 From: kelson at speed.net (Kelson) Date: Wed, 08 Mar 2006 09:12:46 -0800 Subject: X-Chat 2.4.0 to 2.6 In-Reply-To: <00b501c642cf$d5c10ca0$1e00a8c0@prvd321> References: <00a101c642cd$6e970e00$1e00a8c0@prvd321> <440F07A8.4080004@math.unl.edu> <00b501c642cf$d5c10ca0$1e00a8c0@prvd321> Message-ID: <440F108E.9090804@speed.net> Danny Terweij - Net Tuning | Net wrote: > Not 1 of all the FC3 repo's providing a new version. I use RH since 5.0. But > sinds Fedora i dislike it more and more. > > Are there here people that wants create a *real* legacy-updates repo for NEW > versions? If you want new versions of Fedora's applications, you should upgrade to a newer version of Fedora Core. In this case, it looks like FC4 still uses X-Chat 2.4, but FC5 (which includes X-Chat 2.6.0) is due later this month. That has *always* been the usual way to update built-in apps with Linux: either update them manually, or wait until you get the next version of the OS. It's been like that at least as far back as Red Hat 5, and probably earlier. -- Kelson Vibber SpeedGate Communications From subscript at free.fr Wed Mar 8 17:19:10 2006 From: subscript at free.fr (wwp) Date: Wed, 8 Mar 2006 18:19:10 +0100 Subject: FC3 fedora-updates-testing Message-ID: <20060308181910.63283da8@localhost.localdomain> Hello all, I wonder what will happen to the packages in the FC3 fedora-updates-testing? Will they land to FC3's the fedora-updates, or is this -testing repos just dangling now that FC3 is over? I've well understood that it will not be managed by fedoralegacy. Regards, -- wwp -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From guallar at easternrad.com Wed Mar 8 17:32:41 2006 From: guallar at easternrad.com (Josep L. Guallar-Esteve) Date: Wed, 8 Mar 2006 12:32:41 -0500 Subject: X-Chat 2.4.0 to 2.6 In-Reply-To: <00b501c642cf$d5c10ca0$1e00a8c0@prvd321> References: <00a101c642cd$6e970e00$1e00a8c0@prvd321> <440F07A8.4080004@math.unl.edu> <00b501c642cf$d5c10ca0$1e00a8c0@prvd321> Message-ID: <200603081232.44932.guallar@easternrad.com> On Wednesday 08 March 2006 11:46, Danny Terweij - Net Tuning | Net wrote: > From: "Rex Dieter" > > > > Can someone provide a new version of X-Chat in legacy updates fc3 repo? > > > > Probably not. legacy updates is for security and critical bug fixes > > only. > > Hmm that sucks. > > Not 1 of all the FC3 repo's providing a new version. I use RH since 5.0. > But sinds Fedora i dislike it more and more. > > Are there here people that wants create a *real* legacy-updates repo for > NEW versions? > > I suggest to rename the current legacy-updates to legacy-security or > something like that. > legacy-updates sounds like just updates of new versions to me like the > normal repo's also is doing rather then security shit.. > > Danny. It doesn't suck. This is what the "Fedora legacy" is all about. Provide bugfixing for existing packages in their existing versions. And Fedora Core is supposed to be what it is: a fast-paced, fast-changing technology-hotbed with a very short supported life. If you cannot handle/don't like the release cycle, there are literally hundreds of other Linux distributions, including CentOS (RHEL clone) or many other rpm-based distributions. Regards, Josep -- Josep L. Guallar-Esteve -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From subscript at free.fr Wed Mar 8 17:52:16 2006 From: subscript at free.fr (wwp) Date: Wed, 8 Mar 2006 18:52:16 +0100 Subject: FC3 fedora-updates-testing In-Reply-To: <20060308181910.63283da8@localhost.localdomain> References: <20060308181910.63283da8@localhost.localdomain> Message-ID: <20060308185216.056e4bb3@localhost.localdomain> Hello, On Wed, 8 Mar 2006 18:19:10 +0100 wwp wrote: > Hello all, > > > I wonder what will happen to the packages in the FC3 fedora-updates-testing? > Will they land to FC3's the fedora-updates, or is this -testing repos just > dangling now that FC3 is over? I've well understood that it will not be > managed by fedoralegacy. .. and that I've posted this to the wrong mailing list :-). Sorry for the noise! Anyway, if anyone knows the answer, it would be welcome. Regards, -- wwp -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From drees76 at gmail.com Wed Mar 8 19:50:31 2006 From: drees76 at gmail.com (David Rees) Date: Wed, 8 Mar 2006 11:50:31 -0800 Subject: X-Chat 2.4.0 to 2.6 In-Reply-To: <00b501c642cf$d5c10ca0$1e00a8c0@prvd321> References: <00a101c642cd$6e970e00$1e00a8c0@prvd321> <440F07A8.4080004@math.unl.edu> <00b501c642cf$d5c10ca0$1e00a8c0@prvd321> Message-ID: <72dbd3150603081150r39b44856we86c32ee9a003ecc@mail.gmail.com> On 3/8/06, Danny Terweij - Net Tuning | Net wrote: > Are there here people that wants create a *real* legacy-updates repo for NEW > versions? I suggest you look at one of the many available 3rd party repos such as ATrpms or Dag RPMs: http://www.atrpms.net/ http://dag.wieers.com/home-made/apt/ I know that Axel who manages ATrpms is usually willing to add updates for packages to his repo, so you might want to ask him. Fedora Legacy is for security updates only for support distributions. -Dave From d.terweij at nettuning.net Fri Mar 10 15:37:58 2006 From: d.terweij at nettuning.net (Danny Terweij - Net Tuning | Net) Date: Fri, 10 Mar 2006 16:37:58 +0100 Subject: X-Chat 2.4.0 to 2.6 References: <00a101c642cd$6e970e00$1e00a8c0@prvd321> <440F07A8.4080004@math.unl.edu> <00b501c642cf$d5c10ca0$1e00a8c0@prvd321> <440FBE2B.7010705@NOSPAMsbcglobal.net> Message-ID: <017101c64458$9c7482d0$1e00a8c0@prvd321> From: "Mike McCarty" > >>>Can someone provide a new version of X-Chat in legacy updates fc3 repo? > >>Probably not. legacy updates is for security and critical bug fixes only. > > Hmm that sucks. > That's the mission. You *did* read the mission statement, didn't you? Nope. I dont like reading :P > > Not 1 of all the FC3 repo's providing a new version. I use RH since 5.0. But > > sinds Fedora i dislike it more and more. > > > > Are there here people that wants create a *real* legacy-updates repo for NEW > > versions? > Isn't that what FC4 is supposed to be? Where it ends? FC is not a good choice for production. Linux is stable, linux dont have to reboot much. Linux can run for years without a reboot. I do not want to upgrade my production machines every 6 months because FC has a new version. Those new versions holds new versions of software. Why cant they build one FC and update/upgrade just the installed versions? And as stated a lot in discussions lists/fora's, upgrading FC versions is not always without errors. > > I suggest to rename the current legacy-updates to legacy-security or > > something like that. > > legacy-updates sounds like just updates of new versions to me like the > > normal repo's also is doing rather then security shit.. > This has been gone over many times, here. I suggest you actually go > and read the mission statement. You think every "user" reading that? Here a practical "user" example: - Hmm no more updates when i do yum update - lets google - hey a new repo called legacy.. - Ah here i found how to add it to my yum - Nice i get updates again But actualy it are not updates, but fixes/patches. -After some time, he finds out that newer versions are not delivered. -Finds alternate repos like atrpms dag dries livna etc... -doing yum update, "oh look again new versions :)" This is a real example how most of the linux users are doing without read any statement text. Because its not intresting to read :) Danny From rdieter at math.unl.edu Fri Mar 10 15:41:51 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 10 Mar 2006 09:41:51 -0600 Subject: X-Chat 2.4.0 to 2.6 In-Reply-To: <017101c64458$9c7482d0$1e00a8c0@prvd321> References: <00a101c642cd$6e970e00$1e00a8c0@prvd321> <440F07A8.4080004@math.unl.edu> <00b501c642cf$d5c10ca0$1e00a8c0@prvd321> <440FBE2B.7010705@NOSPAMsbcglobal.net> <017101c64458$9c7482d0$1e00a8c0@prvd321> Message-ID: <44119E3F.6070802@math.unl.edu> Danny Terweij - Net Tuning | Net wrote: > From: "Mike McCarty" >>>Are there here people that wants create a *real* legacy-updates repo for > NEW >>>versions? >>Isn't that what FC4 is supposed to be? > Where it ends? FC is not a good choice for production. Easy: If you don't like that, don't use FC for production. -- Rex From jkeating at j2solutions.net Fri Mar 10 16:05:54 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 10 Mar 2006 11:05:54 -0500 Subject: X-Chat 2.4.0 to 2.6 In-Reply-To: <017101c64458$9c7482d0$1e00a8c0@prvd321> References: <00a101c642cd$6e970e00$1e00a8c0@prvd321> <440F07A8.4080004@math.unl.edu> <00b501c642cf$d5c10ca0$1e00a8c0@prvd321> <440FBE2B.7010705@NOSPAMsbcglobal.net> <017101c64458$9c7482d0$1e00a8c0@prvd321> Message-ID: <1142006755.2505.12.camel@ender> On Fri, 2006-03-10 at 16:37 +0100, Danny Terweij - Net Tuning | Net wrote: > You think every "user" reading that? > Here a practical "user" example: > - Hmm no more updates when i do yum update > - lets google > - hey a new repo called legacy.. > - Ah here i found how to add it to my yum > - Nice i get updates again > But actualy it are not updates, but fixes/patches. > -After some time, he finds out that newer versions are not delivered. > -Finds alternate repos like atrpms dag dries livna etc... > -doing yum update, "oh look again new versions :)" > > This is a real example how most of the linux users are doing without read > any statement text. Because its not intresting to read :) So here's the thing. These users aren't our "customers" as it were. Our service is not geared toward them, and frankly, I don't give a shit what they do. Our user base expects quality bugfix and security fix from us for stabilized releases of Fedora, and that's what we deliver. Anything else can take a flying leap. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From pekkas at netcore.fi Fri Mar 10 16:09:44 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 10 Mar 2006 18:09:44 +0200 (EET) Subject: issues list(s) Message-ID: Remember, there's always a need for folks to do some QA testing. See the wiki for instructions and how to get started: http://www.fedoraproject.org/wiki/Legacy/QATesting In particular, (IMHO) help would be particularly useful on: - QA for packages under 'All packages lacking VERIFY ...' sections, and - checking that all the (important) security bugs have been filed in bugzilla, and filing the missing ones. See the full lists at: http://www.netcore.fi/pekkas/buglist.html (all) .. or, if you're interested only in a very specific release: http://www.netcore.fi/pekkas/buglist-rhl73.html http://www.netcore.fi/pekkas/buglist-rhl9.html http://www.netcore.fi/pekkas/buglist-core1.html http://www.netcore.fi/pekkas/buglist-fc2.html http://www.netcore.fi/pekkas/buglist-fc3.html Thanks to everyone who has been involved lately -- I think we've made a lot of good progress with updates. In particular, I'd like to thank Marc who has (IMHO) done most of the "heavy lifting" in.. well, almost every step in the process. -- 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 Axel.Thimm at ATrpms.net Fri Mar 10 16:21:24 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 10 Mar 2006 17:21:24 +0100 Subject: X-Chat 2.4.0 to 2.6 In-Reply-To: <017101c64458$9c7482d0$1e00a8c0@prvd321> References: <00a101c642cd$6e970e00$1e00a8c0@prvd321> <440F07A8.4080004@math.unl.edu> <00b501c642cf$d5c10ca0$1e00a8c0@prvd321> <440FBE2B.7010705@NOSPAMsbcglobal.net> <017101c64458$9c7482d0$1e00a8c0@prvd321> Message-ID: <20060310162124.GA14872@neu.nirvana> On Fri, Mar 10, 2006 at 04:37:58PM +0100, Danny Terweij - Net Tuning | Net wrote: > From: "Mike McCarty" >>>>>Can someone provide a new version of X-Chat in legacy updates fc3 >>>>>repo? >>>>Probably not. legacy updates is for security and critical bug >>>>fixes only. > You think every "user" reading that? > Here a practical "user" example: > - Hmm no more updates when i do yum update > - lets google > - hey a new repo called legacy.. > - Ah here i found how to add it to my yum > - Nice i get updates again > But actualy it are not updates, but fixes/patches. > -After some time, he finds out that newer versions are not delivered. > -Finds alternate repos like atrpms dag dries livna etc... These are not *alternative* or disjunct repos in any way. In fact ATrpms highly recommends using fedora-legacy! Fedora Legacy extends the life of your precious Fedora Core X setup. If you need new software you can switch to Fedora Core X+N whose life span will also be extended by Fedora Legacy. You have the best of both: long-term stability with the legacy support and fresh software with often distribution releases. It's your choice. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From guallar at easternrad.com Fri Mar 10 16:24:48 2006 From: guallar at easternrad.com (Josep L. Guallar-Esteve) Date: Fri, 10 Mar 2006 11:24:48 -0500 Subject: X-Chat 2.4.0 to 2.6 In-Reply-To: <017101c64458$9c7482d0$1e00a8c0@prvd321> References: <00a101c642cd$6e970e00$1e00a8c0@prvd321> <440FBE2B.7010705@NOSPAMsbcglobal.net> <017101c64458$9c7482d0$1e00a8c0@prvd321> Message-ID: <200603101124.51138.guallar@easternrad.com> On Friday 10 March 2006 10:37, Danny Terweij - Net Tuning | Net wrote: > From: "Mike McCarty" > > That's the mission. You *did* read the mission statement, didn't you? > Nope. I dont like reading :P Part of the "Linux is free and cost is low" means that Linux users either must read and be informed themselves, or pay someone to read and be informed. You don't like reading. Fine. And you want to use Linux. Fine. All together means that you will have to get someone to do the reading for you. There is no black magic in Linux. You either read or you get someone who reads to work on your Linux. > > > Not 1 of all the FC3 repo's providing a new version. I use RH since > > > 5.0. > > > But sinds Fedora i dislike it more and more. Fedora is not RHL > > Isn't that what FC4 is supposed to be? > Where it ends? FC is not a good choice for production. Exactly, and Fedora site (at least used to) display information stating something like "...Fedora is the bleeding edge.... fine for home personal use...release cycles are short... support and bugfixing is time-limited...". You want a server. You want long maintenance cycles. You want to run Linux. Then pick another distribution. There are literally hundreds. Fedora is not the only Linux distro out there. Fedora is for testing bleeding-edge stuff for RHEL (Red Hat Enterprise Linux). If you were misguided, well, you said that you don't like to read. Now that you know the truth, the most sensible thing to do is to switch to a distro with long-term support. If you like "the Red Hat Way" , use RHEL or CentOS or WhiteBox or several others available, build from RHEL source code, and all of them have long maintenance cycles. IF you are open to other distros, there are many many many different distros. Check, say DistroWatch. Download a few, test them and use the one that you like with the support cycles that you like. > Linux is stable, > linux dont have to reboot much. Linux can run for years without a reboot. I > do not want to upgrade my production machines every 6 months because FC has > a new version. Then, use another Linux distro. Fedora is not the only Linux distro. > Those new versions holds new versions of software. Why cant they build one > FC and update/upgrade just the installed versions? "they"? who are they? And why should they do it? Maybe you can do it, whatever it is that you want. Nobody stops you. See, every distro has a pourpose. Fedora obviously does not fit your needs. No problem, use another distro. > And as stated a lot in discussions lists/fora's, upgrading FC versions is > not always without errors. As with any other distro. Maybe Fedora it is more error-prone than others, as it is bleeding-edge and brings many deep changes in every iteration. > > This has been gone over many times, here. I suggest you actually go > > and read the mission statement. > You think every "user" reading that? If users do not read... what do you propose? Magical Crystal balls? Do you think a whole project must abide to anybody's desires? Nope. This is why there are so many different distros. Each distro covers a need. Each distro published their mission statement in their webpage. Any user should read that mission statement and see if it fits them. And, if it fits, use the distro. > Here a practical "user" example: > - Hmm no more updates when i do yum update > - lets google > - hey a new repo called legacy.. > - Ah here i found how to add it to my yum > - Nice i get updates again > But actualy it are not updates, but fixes/patches. > -After some time, he finds out that newer versions are not delivered. > -Finds alternate repos like atrpms dag dries livna etc... > -doing yum update, "oh look again new versions :)" note: updates != upgrades > This is a real example how most of the linux users are doing without read > any statement text. Because its not intresting to read :) This is a real example of a lazy user that does not bother to read nor understand what is going on in his/her system. This is a real example who has no clue what (s)he is dong. This is a prime example of a user who needs a reality check and a different distro. > Danny Regards, Josep -- Josep L. Guallar-Esteve -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From d.terweij at nettuning.net Fri Mar 10 16:27:31 2006 From: d.terweij at nettuning.net (Danny Terweij - Net Tuning | Net) Date: Fri, 10 Mar 2006 17:27:31 +0100 Subject: X-Chat 2.4.0 to 2.6 References: <00a101c642cd$6e970e00$1e00a8c0@prvd321> <440F07A8.4080004@math.unl.edu> <00b501c642cf$d5c10ca0$1e00a8c0@prvd321> <440FBE2B.7010705@NOSPAMsbcglobal.net><017101c64458$9c7482d0$1e00a8c0@prvd321> <44119E3F.6070802@math.unl.edu> Message-ID: <01e001c6445f$883563a0$1e00a8c0@prvd321> From: "Rex Dieter" > > Where it ends? FC is not a good choice for production. > > Easy: If you don't like that, don't use FC for production. Nice advertising line.. put it on the FC website in big red letters :) Danny. From jkeating at j2solutions.net Fri Mar 10 16:31:19 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 10 Mar 2006 11:31:19 -0500 Subject: X-Chat 2.4.0 to 2.6 In-Reply-To: <01e001c6445f$883563a0$1e00a8c0@prvd321> References: <00a101c642cd$6e970e00$1e00a8c0@prvd321> <440F07A8.4080004@math.unl.edu> <00b501c642cf$d5c10ca0$1e00a8c0@prvd321> <440FBE2B.7010705@NOSPAMsbcglobal.net> <017101c64458$9c7482d0$1e00a8c0@prvd321> <44119E3F.6070802@math.unl.edu> <01e001c6445f$883563a0$1e00a8c0@prvd321> Message-ID: <1142008279.2505.23.camel@ender> On Fri, 2006-03-10 at 17:27 +0100, Danny Terweij - Net Tuning | Net wrote: > Nice advertising line.. put it on the FC website in big red letters :) Why? You wouldn't read it anyway. Neither would any of your other user examples. So whats the point? Those that can read and do read are able to evaluate the purposes of the Fedora Project and decide for themselves if they are willing to use such a release in a production environment. We let the user decide for themselves. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From rostetter at mail.utexas.edu Fri Mar 10 17:02:11 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 10 Mar 2006 11:02:11 -0600 Subject: X-Chat 2.4.0 to 2.6 In-Reply-To: <017101c64458$9c7482d0$1e00a8c0@prvd321> References: <00a101c642cd$6e970e00$1e00a8c0@prvd321> <440F07A8.4080004@math.unl.edu> <00b501c642cf$d5c10ca0$1e00a8c0@prvd321> <440FBE2B.7010705@NOSPAMsbcglobal.net> <017101c64458$9c7482d0$1e00a8c0@prvd321> Message-ID: <20060310110211.s05ajcznj8pwwwks@mail.ph.utexas.edu> Quoting Danny Terweij - Net Tuning | Net : >> Isn't that what FC4 is supposed to be? > > Where it ends? FC is not a good choice for production. Then don't use it. There are lots of other choices. > Linux is stable, > linux dont have to reboot much. Linux can run for years without a reboot. And it is that way exactly because we don't keep upgrading it to the lastest and greatest version of everything all the time. If you want the latest and greatest, you lose the stability. > I > do not want to upgrade my production machines every 6 months because FC has > a new version. Yet you do want to upgrade your applications every 6 months? What's the difference? > Those new versions holds new versions of software. Why cant they build one > FC and update/upgrade just the installed versions? Because that isn't the mission of FC. That is the mission of RHEL et al. If that is what you want, then you are using the wrong OS. >> > I suggest to rename the current legacy-updates to legacy-security or >> > something like that. The project is Fedora Legacy. That names implies that we deal in legacy OS and legacy packages. Our updates then become legacy updates. Not much way around that. While your proposal isn't bad, it is a bit late in the ball game to make the change now I think. >> > legacy-updates sounds like just updates of new versions to me like the >> > normal repo's also is doing rather then security shit.. Yes, but if you look at more than the yum/apt channel name, like the project's web site or docs, you shouldn't be too confused. It's just a matter of the yum/apt channel names being terse that is the problem here. >> This has been gone over many times, here. I suggest you actually go >> and read the mission statement. > > You think every "user" reading that? You mention "production" machines and OS and uses above. I sure hope that any serious production admin would do so. No, I don't expect all home users or the like to do so. But surely if you run a "production system" in the traditional sense than you would read enough to know what you were using. > But actualy it are not updates, but fixes/patches. Fixes/patches are updates. You're confusing symantics here. We _are_ updating your machine. We _are_ updating your software. We _are_ providing updates. What we are not doing is providing new versions of software when there are no known problems with the older versions. Note that we actually do, in some rare cases, provide newer versions of software packages. But we only do so if there is a need to, to fix a serious bug, or make support easier, or fix a security issue that can only be addressed that way. > -After some time, he finds out that newer versions are not delivered. Yes, he finds that he is running "legacy" software. That is why he needs "legacy" support. That is why we provide "legacy" updates. > -Finds alternate repos like atrpms dag dries livna etc... If he wants newer software, then yes, he should indeed find such sites. > -doing yum update, "oh look again new versions :)" And now, realize that your stable system is potentially much less stable. > This is a real example how most of the linux users are doing without read > any statement text. Because its not intresting to read :) And this is fine for a home user, or my personal desktop machine at work. But it is not how I would run my company or institution mail server or web server or payroll system and so on. In other words, what you say is all fine and dandy, if applied to the correct situation. :) > Danny -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From kelson at speed.net Fri Mar 10 17:42:28 2006 From: kelson at speed.net (Kelson) Date: Fri, 10 Mar 2006 09:42:28 -0800 Subject: X-Chat 2.4.0 to 2.6 In-Reply-To: <01e001c6445f$883563a0$1e00a8c0@prvd321> References: <00a101c642cd$6e970e00$1e00a8c0@prvd321> <440F07A8.4080004@math.unl.edu> <00b501c642cf$d5c10ca0$1e00a8c0@prvd321> <440FBE2B.7010705@NOSPAMsbcglobal.net><017101c64458$9c7482d0$1e00a8c0@prvd321> <44119E3F.6070802@math.unl.edu> <01e001c6445f$883563a0$1e00a8c0@prvd321> Message-ID: <4411BA84.4090004@speed.net> Danny Terweij - Net Tuning | Net wrote: >> Easy: If you don't like that, don't use FC for production. > > Nice advertising line.. put it on the FC website in big red letters :) It used to be there. Not sure what happened to it. Fedora Core was designed from the start to be a leading-edge (or, depending on your perspective, bleeding-edge) distribution. It's great if you want the latest and greatest and you don't mind upgrading your system every 9-12 months. Fedora Legacy was designed to provide extra support time so that people who wanted to use Fedora but only upgrade once every 1-1.5 years could do so without leaving their systems insecure for 6 months at a time, and to keep the last Red Hat Linux releases viable past their official end of life. If you really don't want to upgrade on a regular basis, there are other distributions that may be a better fit for you. If you still like the Red Hat way of doing things, but want long-term OS stability, there's Red Hat Enterprise Linux and its various clones like CentOS and White Box Linux (I've had good experiences with CentOS, and I'll recommend it). You can also move toward another distro like Debian. Keep in mind, though, that once you go to a long-term stability-focused distro like RHEL or Debian, you're going to find yourself upgrading applications manually or from third-party sources, because part of that stability is gained by not moving apps, libraries and services to new versions except for bug fixes and security fixes. Which brings us back to Fedora Legacy. Oh, and one more thing: You may have heard the phrase "You'll catch more flies with honey than with vinegar." Waltzing into a community and insulting their work is not likely to accomplish much beyond making people angry. -- Kelson Vibber SpeedGate Communications From jimpop at yahoo.com Fri Mar 10 18:32:22 2006 From: jimpop at yahoo.com (Jim Popovitch) Date: Fri, 10 Mar 2006 13:32:22 -0500 Subject: X-Chat 2.4.0 to 2.6 In-Reply-To: <01e001c6445f$883563a0$1e00a8c0@prvd321> References: <00a101c642cd$6e970e00$1e00a8c0@prvd321> <440F07A8.4080004@math.unl.edu> <00b501c642cf$d5c10ca0$1e00a8c0@prvd321> <440FBE2B.7010705@NOSPAMsbcglobal.net><017101c64458$9c7482d0$1e00a8c0@prvd321> <44119E3F.6070802@math.unl.edu> <01e001c6445f$883563a0$1e00a8c0@prvd321> Message-ID: <4411C636.9090108@yahoo.com> Danny Terweij - Net Tuning | Net wrote: > From: "Rex Dieter" >>> Where it ends? FC is not a good choice for production. >> Easy: If you don't like that, don't use FC for production. > > Nice advertising line.. put it on the FC website in big red letters :) Hey! That's my line! :-) -Jim P. From Mike.McCarty at sbcglobal.net Fri Mar 10 19:47:49 2006 From: Mike.McCarty at sbcglobal.net (Mike McCarty) Date: Fri, 10 Mar 2006 13:47:49 -0600 Subject: X-Chat 2.4.0 to 2.6 In-Reply-To: <017101c64458$9c7482d0$1e00a8c0@prvd321> References: <00a101c642cd$6e970e00$1e00a8c0@prvd321> <440F07A8.4080004@math.unl.edu> <00b501c642cf$d5c10ca0$1e00a8c0@prvd321> <440FBE2B.7010705@NOSPAMsbcglobal.net> <017101c64458$9c7482d0$1e00a8c0@prvd321> Message-ID: <4411D7E5.6040208@sbcglobal.net> Danny Terweij - Net Tuning | Net wrote: > From: "Mike McCarty" > >>>>>Can someone provide a new version of X-Chat in legacy updates fc3 repo? >>>> >>>>Probably not. legacy updates is for security and critical bug fixes > > only. > >>>Hmm that sucks. >> >>That's the mission. You *did* read the mission statement, didn't you? > > > Nope. I dont like reading :P It's considered rude and ill-mannered not to read the descriptions FAQs and whatnot before posting a message. [snip] > > You think every "user" reading that? It's rude not to do so before posting. > Here a practical "user" example: You are a practical example of a rude internet user. [snip] > This is a real example how most of the linux users are doing without read > any statement text. Because its not intresting to read :) You, apparently, are the type who "drops in" to eat without prior agreement not only with his friends, but also with complete strangers. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From jamie.saunders at featurecreep.com Fri Mar 10 23:43:23 2006 From: jamie.saunders at featurecreep.com (Jamie Saunders) Date: Fri, 10 Mar 2006 23:43:23 +0000 Subject: Introduction Message-ID: Hi, First off, here's a brief introduction. My name is Jamie, I'm an 'Interactive Developer' working for a web/media company based in Bristol, UK. I have roughly five years experience in Linux server administration from the days of Red Hat 5. I've been a member of the Fedora Legacy Project mailing lists for about a month now and joined primarily to keep up to date with the latest bug and security fixes. I've found the discussion between members to be quite insightful and informative, and have been able to glean some useful information and resources regarding the Fedora platform, so thanks all round. I'm sure I'll have my share of questions to put to the group and I will certainly contribute where I can. Although I work in a production environment my company has just invested in some server hardware to act as a test bed for any updates and/or modifications to our live set-up. This will give me the ability to install, test and give feedback on test updates released, and also put my limited experience and knowledge of Linux web-based server admin to good use, with a hope of giving something back to the online community. Regards, Jamie -- James Saunders Interactive Developer, Featurecreep Ltd. http://www.featurecreep.com Tel: +44 (0)117 905 5078 From Mike.McCarty at NOSPAMsbcglobal.net Thu Mar 9 05:33:31 2006 From: Mike.McCarty at NOSPAMsbcglobal.net (Mike McCarty) Date: Wed, 08 Mar 2006 23:33:31 -0600 Subject: X-Chat 2.4.0 to 2.6 In-Reply-To: <00b501c642cf$d5c10ca0$1e00a8c0@prvd321> References: <00a101c642cd$6e970e00$1e00a8c0@prvd321> <440F07A8.4080004@math.unl.edu> <00b501c642cf$d5c10ca0$1e00a8c0@prvd321> Message-ID: <440FBE2B.7010705@NOSPAMsbcglobal.net> Danny Terweij - Net Tuning | Net wrote: > From: "Rex Dieter" > >>>Can someone provide a new version of X-Chat in legacy updates fc3 repo? > > >>Probably not. legacy updates is for security and critical bug fixes only. > > > Hmm that sucks. That's the mission. You *did* read the mission statement, didn't you? > Not 1 of all the FC3 repo's providing a new version. I use RH since 5.0. But > sinds Fedora i dislike it more and more. > > Are there here people that wants create a *real* legacy-updates repo for NEW > versions? Isn't that what FC4 is supposed to be? > I suggest to rename the current legacy-updates to legacy-security or > something like that. > legacy-updates sounds like just updates of new versions to me like the > normal repo's also is doing rather then security shit.. This has been gone over many times, here. I suggest you actually go and read the mission statement. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From peak at argo.troja.mff.cuni.cz Mon Mar 13 23:17:49 2006 From: peak at argo.troja.mff.cuni.cz (Pavel Kankovsky) Date: Tue, 14 Mar 2006 00:17:49 +0100 (CET) Subject: Bugzilla status whiteboard explanation needed Message-ID: <20060313231749.1724.qmail@paddy.troja.mff.cuni.cz> I have found out the information about Bugzilla status whiteboard on is rather inaccurate and incomplete: - LEGACY is marked obsolete but it appears to be used - rh73 and rh9 is used instead of rhl73 and rhl9 - impact=xxx is not documented at all Can anyone provide answers? (And update the wiki if possible.) Thanks. --Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ] "Resistance is futile. Open your source code and prepare for assimilation." From pekkas at netcore.fi Tue Mar 14 05:36:03 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 14 Mar 2006 07:36:03 +0200 (EET) Subject: Bugzilla status whiteboard explanation needed In-Reply-To: <20060313231749.1724.qmail@paddy.troja.mff.cuni.cz> References: <20060313231749.1724.qmail@paddy.troja.mff.cuni.cz> Message-ID: On Tue, 14 Mar 2006, Pavel Kankovsky wrote: > - rh73 and rh9 is used instead of rhl73 and rhl9 This may have been typo in the wiki, and these should be rh73 and rh90 (or rh9), at least that's what all current packages use. > - impact=xxx is not documented at all It has no impact on FL ;-/ Should it? -- 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 nicholas at apiit.edu.my Tue Mar 14 09:06:56 2006 From: nicholas at apiit.edu.my (Nicholas A. Suppiah) Date: Tue, 14 Mar 2006 17:06:56 +0800 Subject: FC2 and mobile phone Message-ID: <1142327215.19731.53.camel@nicholas-pc2.apiit.edu.my> Hi all, Anyone can direct me on Linux connectivity with Motorola V360 phone? I have tried with USB and bluetooth with following results. USB: Can list the device as Bus 001 Device 013: ID 22b8:4902 Motorola PCS Bluetooth: Can ping and send pin I do not what file system to mount, if possible. p3nfs? anyone used it? Apart from detecting the phone I cannot do anything else. Examples on internet are very little. So how do I transfer data and synch with my V360 phone? If this is the wrong listing to post, please direct me to correct place. From peak at argo.troja.mff.cuni.cz Wed Mar 15 21:23:32 2006 From: peak at argo.troja.mff.cuni.cz (Pavel Kankovsky) Date: Wed, 15 Mar 2006 22:23:32 +0100 (CET) Subject: Bugzilla status whiteboard explanation needed In-Reply-To: Message-ID: <20060315212332.6704.qmail@paddy.troja.mff.cuni.cz> On Tue, 14 Mar 2006, Pekka Savola wrote: > > - rh73 and rh9 is used instead of rhl73 and rhl9 > This may have been typo in the wiki, and these should be rh73 and > rh90 (or rh9), at least that's what all current packages use. 171 bugs with rh90 12 bugs with rh9 8 bugs with rhl "rh73" and "rh90" are our winners Can anyone privileged enough fix it in the wiki? (Or grant me the privs to do it? ) > > - impact=xxx is not documented at all > It has no impact on FL ;-/ There is a handful of FL entries using it, e.g. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181014 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184074 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184098 --Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ] "Resistance is futile. Open your source code and prepare for assimilation." From marcdeslauriers at videotron.ca Thu Mar 16 01:30:24 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 15 Mar 2006 20:30:24 -0500 Subject: Fedora Legacy Test Update Notification: mod_python Message-ID: <4418BFB0.2070402@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-152896 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152896 2006-03-15 --------------------------------------------------------------------- Name : mod_python Versions : rh73: mod_python-2.7.8-1.7.3.3.legacy Versions : rh9: mod_python-3.0.1-4.1.legacy Versions : fc1: mod_python-3.0.4-0.1.1.legacy Summary : An embedded Python interpreter for the Apache Web server. Description : Mod_python is a module that embeds the Python language interpreter within the server, allowing Apache handlers to be written in Python. --------------------------------------------------------------------- Update Information: An Updated mod_python package that fixes a security issue in the publisher handler is now available. Mod_python is a module that embeds the Python language interpreter within the Apache web server, allowing handlers to be written in Python. Graham Dumpleton discovered a flaw affecting the publisher handler of mod_python, used to make objects inside modules callable via URL. A remote user could visit a carefully crafted URL that would gain access to objects that should not be visible, leading to an information leak. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0088 to this issue. Users of mod_python are advised to upgrade to this updated package, which contains a backported patch to correct this issue. --------------------------------------------------------------------- Changelogs rh73: * Sat Mar 11 2006 Jeff Sheltren 2.7.8-1.7.3.3.legacy - Patch for CAN-2005-0088 (#152896) - Patch config file to remove ieee linking which was causing build to fail rh9: * Sat Mar 11 2006 Jeff Sheltren 3.0.1-4.1.legacy - Patch for CAN-2005-0088 (#152896) - Patch configure script not to link with ieee lib fc1: * Sat Mar 11 2006 Jeff Sheltren 3.0.4-0.1.1.legacy - Patch for CAN-2005-0088 (#152896) - Patch configure script not to link to ieee lib --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: f936f1ddb29779efae651ff90a19fa17d4edb9f8 redhat/7.3/updates-testing/i386/mod_python-2.7.8-1.7.3.3.legacy.i386.rpm d7792718f71006a00d5e932009dff9b8688330a5 redhat/7.3/updates-testing/SRPMS/mod_python-2.7.8-1.7.3.3.legacy.src.rpm rh9: 6b1e637878a7af1f58f1127d07b7614334b71136 redhat/9/updates-testing/i386/mod_python-3.0.1-4.1.legacy.i386.rpm 5ef5e32ac4d17f77c602d99299baab7f7c00c52d redhat/9/updates-testing/SRPMS/mod_python-3.0.1-4.1.legacy.src.rpm fc1: d3959d23e0718b15a4a0b4fc4126b3198e7e98f8 fedora/1/updates-testing/i386/mod_python-3.0.4-0.1.1.legacy.i386.rpm 20c04acf2eadcb2d99cf6c076a6d1ea34537ed24 fedora/1/updates-testing/SRPMS/mod_python-3.0.4-0.1.1.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Thu Mar 16 01:30:52 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 15 Mar 2006 20:30:52 -0500 Subject: Fedora Legacy Test Update Notification: xine Message-ID: <4418BFCC.9070700@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-152873 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152873 2006-03-15 --------------------------------------------------------------------- Name : xine Versions : rh73: xine-0.9.8-4.2.legacy Summary : A free video player. Description : xine is a free gpl-licensed video player for unix-like systems. --------------------------------------------------------------------- Update Information: An updated xine package that fixes security bugs is now available. xine is a free gpl-licensed video player for unix-like systems. A vulnerability has been reported in the way xine handles a bug report email. A local user could create a specially crafted symlink which could result in xine overwriting a file which it has write access to. The Common Vulnerabilities and Exposures project has assigned the name CVE-2004-0372 to this issue. A heap overflow has been found in the DVD subpicture decoder of xine-lib. This can be used for a remote heap overflow exploit, which can, on some systems, lead to or help in executing malicious code with the permissions of the user running a xine-lib based media application. All users of xine should upgrade to this updated package, which includes backported patches to correct these issues. --------------------------------------------------------------------- Changelogs rh73: * Wed Mar 01 2006 Marc Deslauriers 1:0.9.8-4.2.legacy - Added missing arts-devel, audiofile-devel, esound-devel, libogg-devel, and libvorbis-devel to BuildRequires * Wed Jan 12 2005 Pekka Savola 1:0.9.8-4.1.legacy - fix CAN-2004-0372 and XSA-2004-5 (#2348) --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 297e2b6fb5bb2dad8629944e03dc8d7635f5c225 redhat/7.3/updates-testing/i386/xine-0.9.8-4.2.legacy.i386.rpm 465a4ea2a12017a0cee76883e9263ece27c31a6d redhat/7.3/updates-testing/i386/xine-devel-0.9.8-4.2.legacy.i386.rpm 7336c58504919c05a6ccd5caac1c4a41bb7b7c12 redhat/7.3/updates-testing/SRPMS/xine-0.9.8-4.2.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Thu Mar 16 01:31:10 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 15 Mar 2006 20:31:10 -0500 Subject: Fedora Legacy Test Update Notification: tcpdump Message-ID: <4418BFDE.2010804@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-156139 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156139 2006-03-15 --------------------------------------------------------------------- Name : tcpdump Versions : rh9: tcpdump-3.7.2-7.9.4.legacy Versions : fc1: tcpdump-3.7.2-8.fc1.3.legacy Versions : fc2: tcpdump-3.8.2-6.FC2.3.legacy Summary : A network traffic monitoring tool. Description : Tcpdump is a command-line tool for monitoring network traffic. Tcpdump can capture and display the packet headers on a particular network interface or on all interfaces. Tcpdump can display all of the packet headers, or just the ones that match particular criteria. --------------------------------------------------------------------- Update Information: Updated tcpdump packages that fix several security issues are now available. Tcpdump is a command-line tool for monitoring network traffic. Several denial of service bugs were found in the way tcpdump processes certain network packets. It is possible for an attacker to inject a carefully crafted packet onto the network, crashing a running tcpdump session. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CVE-2005-1267, CVE-2005-1278, CVE-2005-1279, and CVE-2005-1280 to these issues. Users of tcpdump are advised to upgrade to these erratum packages, which contain backported security patches and are not vulnerable to these issues. --------------------------------------------------------------------- Changelogs rh9: * Sat Jun 11 2005 Marc Deslauriers 14:3.7.2-7.9.4.legacy - fix for Multiple DoS issues in tcpdump (CAN-2005-1280, CAN-2005-1279, CAN-2005-1278) fc1: * Sat Jun 11 2005 Marc Deslauriers - 14:3.7.2-8.fc1.3.legacy - fix for Multiple DoS issues in tcpdump (CAN-2005-1280, CAN-2005-1279, CAN-2005-1278) fc2: * Sat Mar 11 2006 Jeff Sheltren - 14:3.8.2-6.FC2.3.legacy - Patch CAN-2005-1267 (#156139) * Sat Jun 11 2005 Marc Deslauriers - 14:3.8.2-6.FC2.2.legacy - fix for Multiple DoS issues in tcpdump (CAN-2005-1280, CAN-2005-1279, CAN-2005-1278) --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh9: 0beccb4a6dd929174bc2d70d680a2e3c4a094391 redhat/9/updates-testing/i386/tcpdump-3.7.2-7.9.4.legacy.i386.rpm 71e1ffc2c4dbf2a5c754630e198f17af94000e66 redhat/9/updates-testing/i386/libpcap-0.7.2-7.9.4.legacy.i386.rpm 843a832974f531413a8e406491f6c91d09bda24d redhat/9/updates-testing/i386/arpwatch-2.1a11-7.9.4.legacy.i386.rpm 192fa5bbebe8039f3c23b8aa26804d1c4b788412 redhat/9/updates-testing/SRPMS/tcpdump-3.7.2-7.9.4.legacy.src.rpm fc1: 1a426b6225718dbd325fbe0c6d54f8904b710103 fedora/1/updates-testing/i386/tcpdump-3.7.2-8.fc1.3.legacy.i386.rpm 45cffdb7d98c2eb03da004d89b776a7050ff5c40 fedora/1/updates-testing/i386/libpcap-0.7.2-8.fc1.3.legacy.i386.rpm 75e263aa296969c873d0475cc1c0785c30ea24d6 fedora/1/updates-testing/i386/arpwatch-2.1a11-8.fc1.3.legacy.i386.rpm 6e86c20a8af1fc607809c713d7ac00ab5e2f717c fedora/1/updates-testing/SRPMS/tcpdump-3.7.2-8.fc1.3.legacy.src.rpm fc2: 32d0dcf31fbe12225954cc32dad45dbcb6c5f5e4 fedora/2/updates-testing/i386/tcpdump-3.8.2-6.FC2.3.legacy.i386.rpm c84625e92600faa8566129c8229daa6c328dcee9 fedora/2/updates-testing/i386/libpcap-0.8.3-6.FC2.3.legacy.i386.rpm dbdcbed104a6d3985a0735aab55031a3be0e1a74 fedora/2/updates-testing/i386/arpwatch-2.1a13-6.FC2.3.legacy.i386.rpm bb98c4cd71507e4dec94da2c1c9f95ee9bbacde1 fedora/2/updates-testing/SRPMS/tcpdump-3.8.2-6.FC2.3.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Thu Mar 16 01:31:43 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 15 Mar 2006 20:31:43 -0500 Subject: Fedora Legacy Test Update Notification: cyrus-imapd Message-ID: <4418BFFF.3090703@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-156290 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156290 2006-03-15 --------------------------------------------------------------------- Name : cyrus-imapd Versions : fc2: cyrus-imapd-2.2.12-1.1.fc2.1.legacy Summary : A high-performance mail server with IMAP, POP3, NNTP and SIEVE support. Description : The cyrus-imapd package contains the core of the Cyrus IMAP server. It is a scaleable enterprise mail system designed for use from small to large enterprise environments using standards-based internet mail technologies. --------------------------------------------------------------------- Update Information: Updated cyrus-imapd packages that fix several buffer overflow security issues are now available. The cyrus-imapd package contains the core of the Cyrus IMAP server. Several buffer overflow bugs were found in cyrus-imapd. It is possible that an authenticated malicious user could cause the imap server to crash. Additionally, a peer news admin could potentially execute arbitrary code on the imap server when news is received using the fetchnews command. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0546 to this issue. Users of cyrus-imapd are advised to upgrade to these updated packages, which contain cyrus-imapd version 2.2.12 to correct these issues. --------------------------------------------------------------------- Changelogs fc2: * Mon Mar 06 2006 Marc Deslauriers 2.2.12-1.1.fc2.1.legacy - Update to 2.2.12 to fix CVE-2005-0546. The only difference between 2.2.10 and 2.2.12 was the security fix, so upgrading is the equivalent of backporting the security fix. --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) fc2: 869a5d94e05156e2bdcff36242fd25b2c0e1c6d1 fedora/2/updates-testing/i386/cyrus-imapd-2.2.12-1.1.fc2.1.legacy.i386.rpm b3bfaca68420697544395c17dbf2cefb5eabcf8f fedora/2/updates-testing/i386/cyrus-imapd-devel-2.2.12-1.1.fc2.1.legacy.i386.rpm 0a8652c25f5d608811b64c634191845b6dcd672a fedora/2/updates-testing/i386/cyrus-imapd-murder-2.2.12-1.1.fc2.1.legacy.i386.rpm d7cfe6d91b0aa23b189949bf516e94479eefd8ef fedora/2/updates-testing/i386/cyrus-imapd-nntp-2.2.12-1.1.fc2.1.legacy.i386.rpm 03b23f099fd26fa8421bf90f4542ff4e56226d36 fedora/2/updates-testing/i386/cyrus-imapd-utils-2.2.12-1.1.fc2.1.legacy.i386.rpm 1d1f935c0d88f209321ebb9ae679af9a0ff23e42 fedora/2/updates-testing/i386/perl-Cyrus-2.2.12-1.1.fc2.1.legacy.i386.rpm de27bfdc5d7e2a2c5268d769ef0842aba85bfed5 fedora/2/updates-testing/SRPMS/cyrus-imapd-2.2.12-1.1.fc2.1.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Thu Mar 16 01:32:03 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 15 Mar 2006 20:32:03 -0500 Subject: Fedora Legacy Test Update Notification: imap Message-ID: <4418C013.1020406@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-170411 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170411 2006-03-15 --------------------------------------------------------------------- Name : imap Versions : rh7.3: imap-2001a-10.3.legacy Versions : rh9: imap-2001a-18.2.legacy Versions : fc1: imap-2002d-3.2.legacy Summary : Server daemons for IMAP and POP network mail protocols. Description : The imap package provides server daemons for both the IMAP (Internet Message Access Protocol) and POP (Post Office Protocol) mail access protocols. The POP protocol uses a "post office" machine to collect mail for users and allows users to download their mail to their local machine for reading. The IMAP protocol allows a user to read mail on a remote machine without downloading it to their local machine. --------------------------------------------------------------------- Update Information: An updated imap package that fixes a buffer overflow issue is now available. The imap package provides server daemons for both the IMAP (Internet Message Access Protocol) and POP (Post Office Protocol) mail access protocols. A buffer overflow flaw was discovered in the way the c-client library parses user supplied mailboxes. If an authenticated user requests a specially crafted mailbox name, it may be possible to execute arbitrary code on a server that uses the library. The Common Vulnerabilities and Exposures project has assigned the name CVE-2005-2933 to this issue. All users of imap should upgrade to these updated packages, which contain a backported patch and are not vulnerable to this issue. --------------------------------------------------------------------- Changelogs rh73: * Mon Mar 06 2006 Marc Deslauriers 2001a-10.3.legacy - Replaced CVE-2005-2933 patch with the one from RHEL21 for consistency's sake * Wed Oct 12 2005 Ville Herva 2001a-10.2.legacy - Added security patch for CAN-2005-2933 rh9: * Mon Mar 06 2006 Marc Deslauriers 2001a-18.2.legacy - Added security patch for CVE-2005-2933 fc1: * Mon Mar 06 2006 Marc Deslauriers 1:2002d-3.2.legacy - Added patch for CVE-2005-2933 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh7.3: a516bdac39c9b3946a51e2aa1b2c525418405097 redhat/7.3/updates-testing/i386/imap-2001a-10.3.legacy.i386.rpm 7492a4f5a96f61a50bc1d486004a991407fb8a93 redhat/7.3/updates-testing/i386/imap-devel-2001a-10.3.legacy.i386.rpm eb6df42d990be3bbf408b9c9cfe759d4ac31d82f redhat/7.3/updates-testing/SRPMS/imap-2001a-10.3.legacy.src.rpm rh9: dd3d1a3bac748d1db5643a76a86c02568abec7d2 redhat/9/updates-testing/i386/imap-2001a-18.2.legacy.i386.rpm d7986d8efea12260ebb0613bb6cd486d72ef4ac1 redhat/9/updates-testing/i386/imap-devel-2001a-18.2.legacy.i386.rpm aef5ef7d054ff02b594bcb2ba564bfbb4778f00b redhat/9/updates-testing/SRPMS/imap-2001a-18.2.legacy.src.rpm fc1: 369fb568801a2d2865a55b2ceabab87e496d8705 fedora/1/updates-testing/i386/imap-2002d-3.2.legacy.i386.rpm 967a77fbc8a4d2dcc3fdfac8b715d7a84537c0c0 fedora/1/updates-testing/i386/imap-devel-2002d-3.2.legacy.i386.rpm 43b5221927cbeb9c2f3387f6a4b8f46f66d4d77d fedora/1/updates-testing/SRPMS/imap-2002d-3.2.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Thu Mar 16 01:32:20 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 15 Mar 2006 20:32:20 -0500 Subject: Fedora Legacy Test Update Notification: unzip Message-ID: <4418C024.90502@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-180159 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180159 2006-03-15 --------------------------------------------------------------------- Name : unzip Versions : rh73: unzip-5.50-31.1.legacy Versions : rh9: unzip-5.50-33.1.legacy Versions : fc1: unzip-5.50-35.1.legacy Versions : fc2: unzip-5.50-37.1.legacy Versions : fc3: unzip-5.51-4.fc3.1.legacy Summary : A utility for unpacking zip files. Description : The unzip utility is used to list, test, or extract files from a zip archive. Zip archives are commonly found on MS-DOS systems. The zip utility, included in the zip package, creates zip archives. Zip and unzip are both compatible with archives created by PKWARE(R)'s PKZIP for MS-DOS, but the programs' options and default behaviors do differ in some respects. --------------------------------------------------------------------- Update Information: An updated unzip package that fixes a buffer overflow vulnerability is now available. The unzip utility is used to list, test, or extract files from a zip archive. A buffer overflow bug has been discovered in unzip when handling long file names. An attacker could create a specially crafted path which could cause unzip to crash or execute arbitrary instructions. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-4667 to this issue. Users of unzip should upgrade to this updated package, which contains backported patches and is not vulnerable to this issue. --------------------------------------------------------------------- Changelogs rh73: * Thu Mar 09 2006 Marc Deslauriers 5.50-31.1.legacy - Added a legacy release tag * Mon Feb 06 2006 Michal Jaegermann 5.50-31.hd - patch for bz 178961 - CVE-2005-4667 - unzip long file name buffer overflow rh9: * Thu Mar 09 2006 Marc Deslauriers 5.50-33.1.legacy - Added patch for CVE-2005-4667 fc1: * Thu Mar 09 2006 Marc Deslauriers 5.50-35.1.legacy - Added patch for CVE-2005-4667 fc2: * Thu Mar 09 2006 Marc Deslauriers 5.50-37.1.legacy - Added patch for CVE-2005-4667 fc3: * Thu Mar 09 2006 Marc Deslauriers 5.51-4.fc3.1.legacy - Added patch for CVE-2005-4667 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 5d341df449ddf2d22410bd37bfba7d124960c1ae redhat/7.3/updates-testing/i386/unzip-5.50-31.1.legacy.i386.rpm d76fb8e7acc75cfca6d419b461ded4176348e2a2 redhat/7.3/updates-testing/SRPMS/unzip-5.50-31.1.legacy.src.rpm rh9: 00b6b6b34e4229e9a2547418c83470752c9c9ff9 redhat/9/updates-testing/i386/unzip-5.50-33.1.legacy.i386.rpm 30aa7fdaf8aada1dbb30dab4e6058a846d6a1e34 redhat/9/updates-testing/SRPMS/unzip-5.50-33.1.legacy.src.rpm fc1: 473bf802cf9257684f534cb99e7813e4257bf189 fedora/1/updates-testing/i386/unzip-5.50-35.1.legacy.i386.rpm 5f5fba20950799ed5676fa1e65044f3b2a61c497 fedora/1/updates-testing/SRPMS/unzip-5.50-35.1.legacy.src.rpm fc2: 475ae5bed64d3273ccd986d5ee55bd5300b9b01f fedora/2/updates-testing/i386/unzip-5.50-37.1.legacy.i386.rpm 4d35e2bceeb45747e415b66deea0e955b258889e fedora/2/updates-testing/SRPMS/unzip-5.50-37.1.legacy.src.rpm fc3: 3fdea3917830be7fd801a2872ef2caa115592d13 fedora/3/updates-testing/i386/unzip-5.51-4.fc3.1.legacy.i386.rpm a55ddb890db2308be565ea22057624808afda1b3 fedora/3/updates-testing/x86_64/unzip-5.51-4.fc3.1.legacy.x86_64.rpm e1f9b432cec0100d9a50ad99d3b72c8b19aea8b4 fedora/3/updates-testing/SRPMS/unzip-5.51-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: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Thu Mar 16 01:32:52 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 15 Mar 2006 20:32:52 -0500 Subject: Fedora Legacy Test Update Notification: tar (rh73, rh9, fc1, fc2) Message-ID: <4418C044.3050701@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-183571-1 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183571 2006-03-15 --------------------------------------------------------------------- Name : tar Versions : rh73: tar-1.13.25-4.7.2.legacy Versions : rh9: tar-1.13.25-11.1.legacy Versions : fc1: tar-1.13.25-12.1.legacy Versions : fc2: tar-1.13.25-14.1.legacy Summary : A GNU file archiving program. Description : The GNU tar program saves many files together in one archive and can restore individual files (or all of the files) from that archive. Tar can also be used to add supplemental files to an archive and to update or list files in the archive. Tar includes multivolume support, automatic archive compression/decompression, the ability to perform remote archives, and the ability to perform incremental and full backups. --------------------------------------------------------------------- Update Information: An updated tar package that fixes a path traversal flaw is now available. The GNU tar program saves many files together in one archive and can restore individual files (or all of the files) from that archive. In 2002, a path traversal flaw was found in the way GNU tar extracted archives. A malicious user could create a tar archive that could write to arbitrary files to which the user running GNU tar has write access (CVE-2002-0399). A security advisory was released containing a backported patch. It was discovered that the backported security patch contained an incorrect optimization and therefore was not sufficient to completely correct this vulnerability. The Common Vulnerabilities and Exposures project (cve.mitre.org) assigned the name CVE-2005-1918 to this issue. Users of tar should upgrade to this updated package, which contains a replacement backported patch to correct this issue. --------------------------------------------------------------------- Changelogs rh73: * Tue Mar 07 2006 Marc Deslauriers 1.13.25-4.7.2.legacy - Updated security fix for CVE-2005-1918 rh9: * Tue Mar 07 2006 Marc Deslauriers 1.13.25-11.1.legacy - Updated security fix for CVE-2005-1918 fc1: * Tue Mar 07 2006 Marc Deslauriers 1.13.25-12.1.legacy - Updated security fix for CVE-2005-1918 fc2: * Wed Mar 08 2006 Marc Deslauriers 1.13.25-14.1.legacy - Updated security fix for CVE-2005-1918 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 57d5b198335bcb254ff49b26b60b2ded6fdc3c29 redhat/7.3/updates-testing/i386/tar-1.13.25-4.7.2.legacy.i386.rpm aec36c77c75a882b3c44a61fa61c23ff204ef4e5 redhat/7.3/updates-testing/SRPMS/tar-1.13.25-4.7.2.legacy.src.rpm rh9: df30641462702e447ac80e5e71db048e039cc378 redhat/9/updates-testing/i386/tar-1.13.25-11.1.legacy.i386.rpm 27e7678d52f44d3872047c5b05c6dfd751c2a806 redhat/9/updates-testing/SRPMS/tar-1.13.25-11.1.legacy.src.rpm fc1: 0caee4057c9325f93ac327e1a4d067fee8b1a744 fedora/1/updates-testing/i386/tar-1.13.25-12.1.legacy.i386.rpm 458a1d96fdf8f580b5702a7243f7653d8c581ac6 fedora/1/updates-testing/SRPMS/tar-1.13.25-12.1.legacy.src.rpm fc2: 5565230fd52a82671b69a9310883a25f7844b8a6 fedora/2/updates-testing/i386/tar-1.13.25-14.1.legacy.i386.rpm 864f986b64392dacaec2bde2c42339a4e6bd7e35 fedora/2/updates-testing/SRPMS/tar-1.13.25-14.1.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Thu Mar 16 01:33:13 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 15 Mar 2006 20:33:13 -0500 Subject: Fedora Legacy Test Update Notification: tar (fc3) Message-ID: <4418C059.6090803@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-183571-2 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183571 2006-03-15 --------------------------------------------------------------------- Name : tar Versions : fc3: tar-1.14-5.FC3.1.legacy Summary : A GNU file archiving program. Description : The GNU tar program saves many files together in one archive and can restore individual files (or all of the files) from that archive. Tar can also be used to add supplemental files to an archive and to update or list files in the archive. Tar includes multivolume support, automatic archive compression/decompression, the ability to perform remote archives, and the ability to perform incremental and full backups. --------------------------------------------------------------------- Update Information: An updated tar package that fixes a buffer overflow bug is now available. The GNU tar program saves many files together in one archive and can restore individual files (or all of the files) from that archive. Jim Meyering discovered a buffer overflow bug in the way GNU tar extracts malformed archives. By tricking a user into extracting a malicious tar archive, it is possible to execute arbitrary code as the user running tar. The Common Vulnerabilities and Exposures project (cve.mitre.org) assigned the name CVE-2006-0300 to this issue. Users of tar should upgrade to this updated package, which contains a backported patch to correct this issue. --------------------------------------------------------------------- Changelogs fc3: * Wed Mar 08 2006 Marc Deslauriers 1.14-5.FC3.1.legacy - fix heap overlfow bug CVE-2006-0300 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) fc3: 4f6bcb8de3d063812be162a217aeea29f2fc5963 fedora/3/updates-testing/i386/tar-1.14-5.FC3.1.legacy.i386.rpm 42eec5a437fb2d1205684c224d10efde0ff8c65e fedora/3/updates-testing/x86_64/tar-1.14-5.FC3.1.legacy.x86_64.rpm 244730a9296048ff02b1700ca982bc10cef7fec0 fedora/3/updates-testing/SRPMS/tar-1.14-5.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: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Thu Mar 16 01:33:30 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 15 Mar 2006 20:33:30 -0500 Subject: Fedora Legacy Test Update Notification: pine Message-ID: <4418C06A.4050601@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-184074 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184074 2006-03-15 --------------------------------------------------------------------- Name : pine Versions : rh73: pine-4.44-19.73.1.legacy Versions : rh9: pine-4.44-19.90.1.legacy Summary : A commonly used, MIME compliant mail and news reader. Description : Pine is a very popular, easy to use, full-featured email user agent that includes a simple text editor called pico. Pine supports MIME extensions and can also be used to read news. Pine also supports IMAP, mail, and MH style folders. --------------------------------------------------------------------- Update Information: An updated Pine package is now available to fix a denial of service attack. Pine is an email user agent. The c-client IMAP client library, as used in Pine 4.44 contains an integer overflow and integer signedness flaw. An attacker could create a malicious IMAP server in such a way that it would cause Pine to crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2003-0297 to this issue. Users of Pine are advised to upgrade to these erratum packages which contain a backported patch to correct this issue. --------------------------------------------------------------------- Changelogs rh73: * Wed Mar 08 2006 Marc Deslauriers 4.44-19.73.1.legacy - Added patch for CVE-2003-0297 rh9: * Wed Mar 08 2006 Marc Deslauriers 4.44-19.90.1.legacy - Added patch for CVE-2003-0297 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 2f5de5f092e8d5c2d821e3715fcc6656b19e1b54 redhat/7.3/updates-testing/i386/pine-4.44-19.73.1.legacy.i386.rpm 4fc304469e6dad1025ac0eb1c428bbc84a9ed76f redhat/7.3/updates-testing/SRPMS/pine-4.44-19.73.1.legacy.src.rpm rh9: 043112c55f52e5454ab01e52f7a50968016ac6a1 redhat/9/updates-testing/i386/pine-4.44-19.90.1.legacy.i386.rpm d84320a9dbe9b1b1917e2acb8c6306c005711075 redhat/9/updates-testing/SRPMS/pine-4.44-19.90.1.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Thu Mar 16 01:33:49 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 15 Mar 2006 20:33:49 -0500 Subject: Fedora Legacy Test Update Notification: libc-client Message-ID: <4418C07D.4030200@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-184098 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184098 2006-03-15 --------------------------------------------------------------------- Name : libc-client Versions : fc2: libc-client-2002e-5.1.legacy Summary : C-client mail access routines for IMAP and POP protocols Description : C-client is a common API for accessing mailboxes. It is used internally by the popular PINE mail reader, the University of Washington's IMAP server and PHP. --------------------------------------------------------------------- Update Information: Updated libc-client packages that fix a buffer overflow issue are now available. C-client is a common API for accessing mailboxes. A buffer overflow flaw was discovered in the way C-client parses user supplied mailboxes. If an authenticated user requests a specially crafted mailbox name, it may be possible to execute arbitrary code on a server that uses C-client to access mailboxes. The Common Vulnerabilities and Exposures project has assigned the name CVE-2005-2933 to this issue. All users of libc-client should upgrade to these updated packages, which contain a backported patch that resolves this issue. --------------------------------------------------------------------- Changelogs fc2: * Tue Mar 07 2006 Marc Deslauriers 2002e-5.1.legacy - apply fix for CVE-2005-2933: buffer overflow --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) fc2: 5232f6a722f64fac4c5e09ca3d34a8e5d33192ed fedora/2/updates-testing/i386/libc-client-2002e-5.1.legacy.i386.rpm 5e03f3725e30f607708e8da1e9c1537d6e929a29 fedora/2/updates-testing/i386/libc-client-devel-2002e-5.1.legacy.i386.rpm 489cbea579ce3fece1527c68df20f24e8c9bfe75 fedora/2/updates-testing/SRPMS/libc-client-2002e-5.1.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From d.terweij at nettuning.net Wed Mar 15 22:04:32 2006 From: d.terweij at nettuning.net (Danny Terweij - Net Tuning | Net) Date: Wed, 15 Mar 2006 23:04:32 +0100 Subject: klogd and syslogd high load usage Message-ID: <0e6d01c6487c$71f11f50$1e00a8c0@prvd321> On a system (FC3) the load usage on klogd and syslogd are very high and running all the time. I have reniced them to 19 and system loads gets back to below 1.00 and stays stable. The box was last week 1 hour not reachable because those 2 produced a (last known) load of minimal 600. The logfiles at /var/log are not big. and most ones are weekly rotated. I guess syslogd is doing things for /var/log. But what is klogd doing? The only big logfiles i know in this system are logfiles from apache (a lot virtual hosting domain names). These apache domain-logfiles rotates also every week. So do I need some tweaking/tuning somewhere? 20913 root 34 19 1552 476 408 R 0.7 0.0 35:25.76 klogd 20909 root 34 19 1604 636 524 R 0.3 0.1 26:47.30 syslogd Danny. From oliver at samera.com.py Thu Mar 16 05:43:41 2006 From: oliver at samera.com.py (Oliver Schulze L.) Date: Thu, 16 Mar 2006 01:43:41 -0400 Subject: RedHat 7.3 or RHEL 2.1 Message-ID: <4418FB0D.5020204@samera.com.py> Hi, I have a server that have an aplication that runs on RH7.3 or RHEL 2.1 Currently, it runs RH7.3 with yum updates from fedora-legacy My question is, should I update to RHEL 2.1 or stay in RH7.3? What are my advantages of migrating to RHEL2.1? Many thanks Oliver -- Oliver Schulze L. From cz at unicityllc.com Thu Mar 16 10:40:27 2006 From: cz at unicityllc.com (Cyril Zlachevsky) Date: Thu, 16 Mar 2006 12:40:27 +0200 Subject: upgrade from RHL 7.2 to 7.3 Message-ID: <4419409B.2020306@unicityllc.com> Hello! I have server runs Red Hat Linux 7.2 Unfortunately version 7.2 support suspended. I'm use apt-get for system updates. My question is - it is safe to upgrade 7.2 to 7.3 by apt-get like this way? ---cut--- # apt-get update Get:1 http://download.fedoralegacy.org redhat/7.3/i386 release [1606B] Fetched 1606B in 0s (10.2kB/s) Get:1 http://download.fedoralegacy.org redhat/7.3/i386/os pkglist [1229kB] Get:2 http://download.fedoralegacy.org redhat/7.3/i386/os release [125B] Get:3 http://download.fedoralegacy.org redhat/7.3/i386/updates pkglist [949kB] Get:4 http://download.fedoralegacy.org redhat/7.3/i386/updates release [130B] Get:5 http://download.fedoralegacy.org redhat/7.3/i386/legacy-utils pkglist [110 0B] Get:6 http://download.fedoralegacy.org redhat/7.3/i386/legacy-utils release [135 B] Get:7 http://download.fedoralegacy.org redhat/7.3/i386/os srclist [149kB] Get:8 http://download.fedoralegacy.org redhat/7.3/i386/updates srclist [55.4kB] Get:9 http://download.fedoralegacy.org redhat/7.3/i386/legacy-utils srclist [571 B] Fetched 2385kB in 12s (188kB/s) Reading Package Lists... Done Collecting File Provides... Done # apt-get dist-upgrade Reading Package Lists... Done Collecting File Provides... Done Building Dependency Tree... Done Calculating Upgrade... Done The following packages will be upgraded 4Suite Omni Omni-foomatic PyXML SysVinit XFree86-libs a2ps alchemist apmd aspell authconfig autoconf autofs automake bash bc binutils bison cdecl chkconfig cipe console-tools cpio cpp cracklib cracklib-dicts ctags cyrus-sasl cyrus-sasl-devel cyrus-sasl-md5 cyrus-sasl-plain db1 db2 db3 db3-devel db3-utils diffutils docbook-style-dsssl dos2unix dosfstools e2fsprogs ed eject expat findutils flex foomatic freetype ftp gawk gcc gcc-c++ gcc-g77 gd gdbm glibc glibc-common glibc-devel gmp gperf gpm grep groff groff-perl grub gzip hdparm hotplug htmlview imap indent indexhtml info initscripts ipchains iproute iptables iputils joe kbdconfig krb5-libs krbafs ksymoops kudzu less libcap libjpeg libpng libstdc++ libstdc++-devel libtiff libtool libtool-libs libxslt lockdev logrotate logwatch lokkit losetup lynx m4 mailcap man-pages mc mingetty mkbootdisk mkinitrd mktemp mod_perl mount mouseconfig mpage mrtg mysql mysql-devel mysql-server ncftp ncompress ncurses ncurses-devel net-tools newt nmap ntp ntsysv openjade pam pam_krb5 parted passwd patch pciutils pcre pcre-devel perl perl-CGI perl-CPAN perl-DBD-MySQL perl-DBI perl-DB_File perl-DateManip perl-Digest-MD5 perl-HTML-Parser perl-HTML-Tagset perl-MIME-Base64 perl-NDBM_File perl-Parse-Yapp perl-Storable perl-URI perl-XML-Dumper perl-XML-Encoding perl-XML-Grove perl-XML-Parser perl-XML-Twig perl-libnet perl-libwww-perl perl-libxml-enno perl-libxml-perl perl-suidperl pidentd pine pkgconfig popt portmap procmail procps psmisc pspell pwdb python python-devel raidtools rdate readline readline-devel redhat-release reiserfs-utils rhn_register rmt screen sed setserial setup sgml-common sh-utils sharutils slang slang-devel slrn strace swig sysklogd sysstat tcl telnet telnet-server tetex tetex-dvilj tetex-dvips tetex-fonts tetex-latex texinfo textutils time timeconfig tk tmpwatch traceroute tripwire ucd-snmp ucd-snmp-utils util-linux vim-common vim-minimal vixie-cron wget which whois words xdelta zip The following packages will be REPLACED: db31 (by db3x) docbook-dtd30-sgml (by docbook-dtds) docbook-dtd31-sgml (by docbook-dtds) docbook-dtd40-sgml (by docbook-dtds) kernel-headers (by glibc-kernheaders) lclint (by splint) links (by elinks) sgml-tools (by linuxdoc-tools) The following NEW packages will be installed: Distutils db3x docbook-dtds elinks glib2 glibc-kernheaders hesiod hwdata libuser linuxdoc-tools splint usbutils usermode xml-common 221 packages upgraded, 14 newly installed, 8 replaced, 0 removed and 0 not upgra ded. Need to get 163MB of archives. After unpacking 14.0MB disk space will be freed. Do you want to continue? [Y/n] ---cut--- From deisenst at gtw.net Thu Mar 16 12:29:39 2006 From: deisenst at gtw.net (David Eisenstein) Date: Thu, 16 Mar 2006 06:29:39 -0600 (CST) Subject: Bugzilla status whiteboard explanation needed In-Reply-To: <20060315212332.6704.qmail@paddy.troja.mff.cuni.cz> Message-ID: On Wed, 15 Mar 2006, Pavel Kankovsky wrote: > On Tue, 14 Mar 2006, Pekka Savola wrote: > > > > - rh73 and rh9 is used instead of rhl73 and rhl9 > > This may have been typo in the wiki, and these should be rh73 and > > rh90 (or rh9), at least that's what all current packages use. > > > "rh73" and "rh90" are our winners > > Can anyone privileged enough fix it in the wiki? > (Or grant me the privs to do it? ) Fixed. Oh, and you can grant yourself the privileges to do it. See . > > > > - impact=xxx is not documented at all > > It has no impact on FL ;-/ I have placed a definition of the impact=xxx tag also in the wiki. Its use may help inform the reader, worker, developer of the relative security importance of the bug. See , and . -David From rdieter at math.unl.edu Thu Mar 16 12:35:33 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 16 Mar 2006 06:35:33 -0600 Subject: upgrade from RHL 7.2 to 7.3 In-Reply-To: <4419409B.2020306@unicityllc.com> References: <4419409B.2020306@unicityllc.com> Message-ID: Cyril Zlachevsky wrote: > I have server runs Red Hat Linux 7.2 > Unfortunately version 7.2 support suspended. > I'm use apt-get for system updates. > My question is - it is safe to upgrade 7.2 to 7.3 by apt-get like this way? Should be. I recall myself doing exactly that many moons ago... (-: -- Rex From pekkas at netcore.fi Thu Mar 16 12:46:00 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 16 Mar 2006 14:46:00 +0200 (EET) Subject: upgrade from RHL 7.2 to 7.3 In-Reply-To: <4419409B.2020306@unicityllc.com> References: <4419409B.2020306@unicityllc.com> Message-ID: On Thu, 16 Mar 2006, Cyril Zlachevsky wrote: > My question is - it is safe to upgrade 7.2 to 7.3 by apt-get like this way? The list below doesn't seem to include a kernel update.. you should make sure you'll be updating it too... I made some 7.2 -> 7.3 updates many years ago using "autoupdate". It went smoothly for servers. Additionally, I converted ext2 partitions to ext3 if they weren't already, and went through the rpmnew/rpmsave files that resulted from the update. -- 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 dreamer at chen-online.net Thu Mar 16 16:18:25 2006 From: dreamer at chen-online.net (Lawrence 'The Dreamer' Chen) Date: Thu, 16 Mar 2006 11:18:25 -0500 Subject: upgrade from RHL 7.2 to 7.3 In-Reply-To: <4419409B.2020306@unicityllc.com> Message-ID: <018901c64915$410eaee0$02fea8c0@lhaven.homeip.net> When I did my upgrades from RHL 7.2 to 7.3 (first involving a pair of 'important' servers at work, and later my server at home....the difference being that work machines are regularly backed up, and my Linux server at home has never been backed up ;) I used 'yum'. Some of my tale is here: http://lawrence.chen-online.net/index.php?title=yum_upgrade_of_redhat_7_2_to_7_ 3&more=1&c=1&tb=1&pb=1 http://lawrence.chen-online.net/index.php?title=home_server_upgrade&more=1&c=1& tb=1&pb=1 http://lawrence.chen-online.net/index.php?title=home_redhat_7_2_server_upgrade_ to_7_3&more=1&c=1&tb=1&pb=1 -- 1. First installed yum and had my RHL 7.2 updating correctly from Fedora Legacy http://www.fedoralegacy.org/docs/yum-rh7x.php 2. Download and install the redhat-release package for 7.3 IE: rpm -Uvh ftp://linux21.fnal.gov/linux/legacy/redhat/7.3/os/i386/redhat-release-7.3-1.noa rch.rpm 3. changed exactarch=1 to exactarch=0 in /etc/yum.conf I didn't need to do this for the machines at work, but had assorted conflicts during the upgrade of my home server. 4. Upgrade to RHL 7.3 yum upgrade 5. changed exactarch=0 back to exactarch=1 in /etc/yum.conf. -- Lawrence > -----Original Message----- > From: fedora-legacy-list-bounces at redhat.com > [mailto:fedora-legacy-list-bounces at redhat.com] On Behalf Of > Cyril Zlachevsky > Sent: Thursday, March 16, 2006 05:40 > To: fedora-legacy-list at redhat.com > Subject: upgrade from RHL 7.2 to 7.3 > > Hello! > I have server runs Red Hat Linux 7.2 > Unfortunately version 7.2 support suspended. > I'm use apt-get for system updates. > My question is - it is safe to upgrade 7.2 to 7.3 by apt-get > like this way? > From harri.haataja at smilehouse.com Thu Mar 16 18:10:41 2006 From: harri.haataja at smilehouse.com (Harri Haataja) Date: Thu, 16 Mar 2006 20:10:41 +0200 Subject: upgrade from RHL 7.2 to 7.3 In-Reply-To: References: <4419409B.2020306@unicityllc.com> Message-ID: <20060316181041.GH17716@XTL.antioffline.net> On Thu, Mar 16, 2006 at 06:35:33AM -0600, Rex Dieter wrote: > Cyril Zlachevsky wrote: > > I have server runs Red Hat Linux 7.2 > > Unfortunately version 7.2 support suspended. > > I'm use apt-get for system updates. > > My question is - it is safe to upgrade 7.2 to 7.3 by apt-get like this way? > Should be. I recall myself doing exactly that many moons ago... (-: I also recall doing this. Possibly 7.1 -> 7.2 -> 7.3 -> 8.0 -> 9.0 more or less. There will be snags as more major things and package names etc change. You have to see that kernels change, initrds and whatnot get set right, booting works etc. I also tend to do larger upgrades in phases if possible. First taking "easy" targets like small applications and non-critical libraries etc and cutting down the size of the possibly difficult chunk instead of breaking everything at once. Then again, RH wasn't probably quite meant to do this and there's probably lots of combinations to find that don't quite work. I'm especially wary of libc upgrades. This was all a long ago, though. -- A doctor can bury his mistakes but an architect can only advise his clients to plant vines. -- Frank Lloyd Wright From harri.haataja at smilehouse.com Thu Mar 16 18:10:41 2006 From: harri.haataja at smilehouse.com (Harri Haataja) Date: Thu, 16 Mar 2006 20:10:41 +0200 Subject: upgrade from RHL 7.2 to 7.3 In-Reply-To: References: <4419409B.2020306@unicityllc.com> Message-ID: <20060316181041.GH17716@XTL.antioffline.net> On Thu, Mar 16, 2006 at 06:35:33AM -0600, Rex Dieter wrote: > Cyril Zlachevsky wrote: > > I have server runs Red Hat Linux 7.2 > > Unfortunately version 7.2 support suspended. > > I'm use apt-get for system updates. > > My question is - it is safe to upgrade 7.2 to 7.3 by apt-get like this way? > Should be. I recall myself doing exactly that many moons ago... (-: I also recall doing this. Possibly 7.1 -> 7.2 -> 7.3 -> 8.0 -> 9.0 more or less. There will be snags as more major things and package names etc change. You have to see that kernels change, initrds and whatnot get set right, booting works etc. I also tend to do larger upgrades in phases if possible. First taking "easy" targets like small applications and non-critical libraries etc and cutting down the size of the possibly difficult chunk instead of breaking everything at once. Then again, RH wasn't probably quite meant to do this and there's probably lots of combinations to find that don't quite work. I'm especially wary of libc upgrades. This was all a long ago, though. -- A doctor can bury his mistakes but an architect can only advise his clients to plant vines. -- Frank Lloyd Wright From mikes at kuentos.guam.net Thu Mar 16 19:04:53 2006 From: mikes at kuentos.guam.net (Michael D. Setzer II) Date: Fri, 17 Mar 2006 05:04:53 +1000 Subject: Setting up system for use of multiple access paths Message-ID: <441A4375.17471.1273E58@mikes.kuentos.guam.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 My College has a T-1 connection that has been having some major problems, being down for 7 hours and 20 minuts the other day. I have had a bridge to a DSL line that provided a backup for Internet access thru a Fedora machine with a squid server. Just got a Cable line with a 4.2Mb connection that is now also connected to this machine, but now it uses the Cable as the devault path. Ideally, I would like to setup a system in what all the various internet bandwidth could be used. The best option that I can currently think of is setting up a squid server with each of the access points (T-1, DSL, and Cable) and have them in a round robin configuration, but that requres 3 machines. The one system does have access to all the networks, but currently only the default route is used by a machine. Perhaps there are others that might have a similar situation with two of more access routes. Thanks. +----------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor Guam Community College Computer Center mailto:mikes at kuentos.guam.net mailto:msetzerii at gmail.com http://www.guam.net/home/mikes Guam - Where America's Day Begins +----------------------------------------------------------+ http://setiathome.berkeley.edu Number of Seti Units Returned: 19,471 Processing time: 32 years, 290 days, 12 hours, 58 minutes (Total Hours: 287,489) BOINC Seti at Home Total Credits 552135.158300 -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 -- QDPGP 2.61c Comment: http://community.wow.net/grt/qdpgp.html iQA/AwUBRBkqNizGQcr/2AKZEQKjFQCgtcXOOKzTvNS/XfANHt4HV04puYcAoIEC Md2hPiD084YpDCDZIGMKdasq =9y5Y -----END PGP SIGNATURE----- From drees76 at gmail.com Thu Mar 16 19:44:56 2006 From: drees76 at gmail.com (David Rees) Date: Thu, 16 Mar 2006 11:44:56 -0800 Subject: Setting up system for use of multiple access paths In-Reply-To: <441A4375.17471.1273E58@mikes.kuentos.guam.net> References: <441A4375.17471.1273E58@mikes.kuentos.guam.net> Message-ID: <72dbd3150603161144m30ddd992r7b1226e21601e2bd@mail.gmail.com> On 3/16/06, Michael D. Setzer II wrote: > Ideally, I would like to setup a system in what all the various internet bandwidth could > be used. While you've got an interesting problem, I think you've posted to the wrong mailing list for this type of discussion... -Dave From marcdeslauriers at videotron.ca Fri Mar 17 00:52:22 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 16 Mar 2006 19:52:22 -0500 Subject: [FLSA-2006:157459-1] Updated kernel packages fix security issues Message-ID: <441A0846.7050004@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated kernel packages fix security issues Advisory ID: FLSA:157459-1 Issue date: 2006-03-16 Product: Red Hat Linux Keywords: Bugfix CVE Names: CVE-2002-2185 CVE-2004-0791 CVE-2005-0124 CVE-2005-1263 CVE-2005-2458 CVE-2005-2490 CVE-2005-2708 CVE-2005-2709 CVE-2005-2973 CVE-2005-3180 CVE-2005-3273 CVE-2005-3275 CVE-2005-3276 CVE-2005-3806 CVE-2005-3857 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated kernel packages that fix several security issues are now available. The Linux kernel handles the basic functions of the operating system. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 3. Problem description: These new kernel packages contain fixes for the security issues described below: - a flaw in network IGMP processing that a allowed a remote user on the local network to cause a denial of service (disabling of multicast reports) if the system is running multicast applications (CVE-2002-2185) - a recent Internet Draft by Fernando Gont recommended that ICMP Source Quench messages be ignored by hosts. A patch to ignore these messages is included. (CVE-2004-0791) - flaws in the coda module that allowed denial-of-service attacks (crashes) or local privilege escalations (CVE-2005-0124) - a flaw between execve() syscall handling and core dumping of ELF-format executables allowed local unprivileged users to cause a denial of service (system crash) or possibly gain privileges (CVE-2005-1263) - a flaw in gzip/zlib handling internal to the kernel that may allow a local user to cause a denial of service (crash) (CVE-2005-2458) - a flaw in sendmsg() syscall handling on 64-bit systems that allowed a local user to cause a denial of service or potentially gain privileges (CVE-2005-2490) - a flaw in exec() handling on some 64-bit architectures that allowed a local user to cause a denial of service (crash) (CVE-2005-2708) - a flaw in procfs handling during unloading of modules that allowed a local user to cause a denial of service or potentially gain privileges (CVE-2005-2709) - a flaw in IPv6 network UDP port hash table lookups that allowed a local user to cause a denial of service (hang) (CVE-2005-2973) - a network buffer info leak using the orinoco driver that allowed a remote user to possibly view uninitialized data (CVE-2005-3180) - a flaw in the packet radio ROSE protocol that allowed a user to trigger out-of-bounds errors. (CVE-2005-3273) - a flaw in IPv4 network TCP and UDP netfilter handling that allowed a local user to cause a denial of service (crash) (CVE-2005-3275) - a minor info leak with the get_thread_area() syscall that allowed a local user to view uninitialized kernel stack data (CVE-2005-3276) - a flaw in the IPv6 flowlabel code that allowed a local user to cause a denial of service (crash) (CVE-2005-3806) - a flaw in file lease time-out handling that allowed a local user to cause a denial of service (log file overflow) (CVE-2005-3857) All users are advised to upgrade their kernels to the packages associated with their machine architectures and configurations as listed in this erratum. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To install kernel packages manually, use "rpm -ivh " and modify system settings to boot the kernel you have installed. To do this, edit /boot/grub/grub.conf and change the default entry to "default=0" (or, if you have chosen to use LILO as your boot loader, edit /etc/lilo.conf and run lilo) 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. Note that this may not automatically pull the new kernel in if you have configured apt/yum to ignore kernels. If so, follow the manual instructions above. 5. Bug IDs fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157459 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/kernel-2.4.20-46.7.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-2.4.20-46.7.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-BOOT-2.4.20-46.7.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-doc-2.4.20-46.7.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-source-2.4.20-46.7.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-2.4.20-46.7.legacy.i586.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-smp-2.4.20-46.7.legacy.i586.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-2.4.20-46.7.legacy.i686.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-bigmem-2.4.20-46.7.legacy.i686.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-smp-2.4.20-46.7.legacy.i686.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-2.4.20-46.7.legacy.athlon.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-smp-2.4.20-46.7.legacy.athlon.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/kernel-2.4.20-46.9.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-2.4.20-46.9.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-BOOT-2.4.20-46.9.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-doc-2.4.20-46.9.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-source-2.4.20-46.9.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-2.4.20-46.9.legacy.i586.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-smp-2.4.20-46.9.legacy.i586.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-2.4.20-46.9.legacy.i686.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-bigmem-2.4.20-46.9.legacy.i686.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-smp-2.4.20-46.9.legacy.i686.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-2.4.20-46.9.legacy.athlon.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-smp-2.4.20-46.9.legacy.athlon.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 13d96ec3b350e2fe08a0b2daea0fbc903b55dba6 redhat/7.3/updates/i386/kernel-2.4.20-46.7.legacy.athlon.rpm dd2a0de51955f130914b97e54002999398594e78 redhat/7.3/updates/i386/kernel-2.4.20-46.7.legacy.i386.rpm c2a33858f1863b5aa8fc61812620bd538416eec1 redhat/7.3/updates/i386/kernel-2.4.20-46.7.legacy.i586.rpm 82f9abe5137fe60c379e54ed4c30102e77a3d7ce redhat/7.3/updates/i386/kernel-2.4.20-46.7.legacy.i686.rpm 2b7d00492c0bdd1c42f8e1fd60c69aa06d2af5b2 redhat/7.3/updates/i386/kernel-bigmem-2.4.20-46.7.legacy.i686.rpm 18b774d3bbe7bc2c3b1326b31cf653fc4ec3dd02 redhat/7.3/updates/i386/kernel-BOOT-2.4.20-46.7.legacy.i386.rpm 53e150d66bcd19881e6d3375b3921cbdcc19f9da redhat/7.3/updates/i386/kernel-doc-2.4.20-46.7.legacy.i386.rpm 8451d90ea0f882cc95635eac07ad794fe3a80b73 redhat/7.3/updates/i386/kernel-smp-2.4.20-46.7.legacy.athlon.rpm 70cbb1233156b94cb7adf05a9a60932bdebd01a7 redhat/7.3/updates/i386/kernel-smp-2.4.20-46.7.legacy.i586.rpm df9078043ff5fb7a46de6c664c6009d1a17591d3 redhat/7.3/updates/i386/kernel-smp-2.4.20-46.7.legacy.i686.rpm d41ae5e41700ea15838560c1ab4cff28b405ebc6 redhat/7.3/updates/i386/kernel-source-2.4.20-46.7.legacy.i386.rpm 21f35ccaf8e57e440c3019b34feb9d9505400b35 redhat/7.3/updates/SRPMS/kernel-2.4.20-46.7.legacy.src.rpm 109e959e391c02665c2683714476641b512b1d2a redhat/9/updates/i386/kernel-2.4.20-46.9.legacy.athlon.rpm bf329aff38c0cc9c6976994ba8b4fecf23f9a842 redhat/9/updates/i386/kernel-2.4.20-46.9.legacy.i386.rpm c805fe8f45b96104ad70e1886bd46de107dee452 redhat/9/updates/i386/kernel-2.4.20-46.9.legacy.i586.rpm 8bd381c660a26da151afbd1e3fc732b83c2becc4 redhat/9/updates/i386/kernel-2.4.20-46.9.legacy.i686.rpm 70e9a8644eee9902c0d19ebf6b73b382909f178b redhat/9/updates/i386/kernel-bigmem-2.4.20-46.9.legacy.i686.rpm d6f9e20636ac96af35f9c001b51b0be121aed44f redhat/9/updates/i386/kernel-BOOT-2.4.20-46.9.legacy.i386.rpm f6c3109670d2cea5c47f78f1852ad28764ac5f4f redhat/9/updates/i386/kernel-doc-2.4.20-46.9.legacy.i386.rpm 4c6803f8075e975ce898fabd55cc1534db98e0e8 redhat/9/updates/i386/kernel-smp-2.4.20-46.9.legacy.athlon.rpm 79c7bda4bfe36807fdd4144146e728ffe20e1a9a redhat/9/updates/i386/kernel-smp-2.4.20-46.9.legacy.i586.rpm 833c41272f7836354359194344de076e566c7eb4 redhat/9/updates/i386/kernel-smp-2.4.20-46.9.legacy.i686.rpm f56721c762dcf68d1021213cae598765d53b710f redhat/9/updates/i386/kernel-source-2.4.20-46.9.legacy.i386.rpm 665d140e5dacf04a703408634be6619e6878112a redhat/9/updates/SRPMS/kernel-2.4.20-46.9.legacy.src.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-2185 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0791 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0124 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1263 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2458 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2490 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2708 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2709 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2973 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3180 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3273 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3275 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3276 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3806 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3857 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Fri Mar 17 00:53:07 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 16 Mar 2006 19:53:07 -0500 Subject: [FLSA-2006:157459-2] Updated kernel packages fix security issues Message-ID: <441A0873.4050305@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated kernel packages fix security issues Advisory ID: FLSA:157459-2 Issue date: 2006-03-16 Product: Fedora Core Keywords: Bugfix CVE Names: CVE-2002-2185 CVE-2004-0791 CVE-2005-0756 CVE-2005-1762 CVE-2005-2553 CVE-2005-1263 CVE-2005-2458 CVE-2005-2490 CVE-2005-2708 CVE-2005-2709 CVE-2005-2973 CVE-2005-3044 CVE-2005-3180 CVE-2005-3275 CVE-2005-3276 CVE-2005-3806 CVE-2005-3857 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated kernel packages that fix several security issues are now available. The Linux kernel handles the basic functions of the operating system. 2. Relevant releases/architectures: Fedora Core 1 - i386 3. Problem description: These new kernel packages contain fixes for the security issues described below: - a flaw in network IGMP processing that a allowed a remote user on the local network to cause a denial of service (disabling of multicast reports) if the system is running multicast applications (CVE-2002-2185) - a recent Internet Draft by Fernando Gont recommended that ICMP Source Quench messages be ignored by hosts. A patch to ignore these messages is included. (CVE-2004-0791) - flaws in ptrace() syscall handling on AMD64 and Intel EM64T systems that allowed a local user to cause a denial of service (crash) (CVE-2005-0756, CVE-2005-1762, CVE-2005-2553) - a flaw between execve() syscall handling and core dumping of ELF-format executables allowed local unprivileged users to cause a denial of service (system crash) or possibly gain privileges (CVE-2005-1263) - a flaw in gzip/zlib handling internal to the kernel that may allow a local user to cause a denial of service (crash) (CVE-2005-2458) - a flaw in sendmsg() syscall handling on 64-bit systems that allowed a local user to cause a denial of service or potentially gain privileges (CVE-2005-2490) - a flaw in exec() handling on some 64-bit architectures that allowed a local user to cause a denial of service (crash) (CVE-2005-2708) - a flaw in procfs handling during unloading of modules that allowed a local user to cause a denial of service or potentially gain privileges (CVE-2005-2709) - a flaw in IPv6 network UDP port hash table lookups that allowed a local user to cause a denial of service (hang) (CVE-2005-2973) - a flaw in 32-bit-compat handling of the TIOCGDEV ioctl that allowed a local user to cause a denial of service (crash) (CVE-2005-3044) - a network buffer info leak using the orinoco driver that allowed a remote user to possibly view uninitialized data (CVE-2005-3180) - a flaw in IPv4 network TCP and UDP netfilter handling that allowed a local user to cause a denial of service (crash) (CVE-2005-3275) - a minor info leak with the get_thread_area() syscall that allowed a local user to view uninitialized kernel stack data (CVE-2005-3276) - a flaw in the IPv6 flowlabel code that allowed a local user to cause a denial of service (crash) (CVE-2005-3806) - a flaw in file lease time-out handling that allowed a local user to cause a denial of service (log file overflow) (CVE-2005-3857) All users are advised to upgrade their kernels to the packages associated with their machine architectures and configurations as listed in this erratum. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To install kernel packages manually, use "rpm -ivh " and modify system settings to boot the kernel you have installed. To do this, edit /boot/grub/grub.conf and change the default entry to "default=0" (or, if you have chosen to use LILO as your boot loader, edit /etc/lilo.conf and run lilo) 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. Note that this may not automatically pull the new kernel in if you have configured apt/yum to ignore kernels. If so, follow the manual instructions above. 5. Bug IDs fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157459 6. RPMs required: Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/kernel-2.4.22-1.2199.8.legacy.nptl.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/kernel-BOOT-2.4.22-1.2199.8.legacy.nptl.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/kernel-doc-2.4.22-1.2199.8.legacy.nptl.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/kernel-source-2.4.22-1.2199.8.legacy.nptl.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2199.8.legacy.nptl.i586.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2199.8.legacy.nptl.i586.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2199.8.legacy.nptl.i686.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2199.8.legacy.nptl.i686.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2199.8.legacy.nptl.athlon.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2199.8.legacy.nptl.athlon.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 5ec641496db89906ce3e587bda826b38f0e2b2b4 fedora/1/updates/i386/kernel-2.4.22-1.2199.8.legacy.nptl.athlon.rpm 70e345e1ff5427a4aa41fb4b72155e6ba73fcc38 fedora/1/updates/i386/kernel-2.4.22-1.2199.8.legacy.nptl.i586.rpm a8b7fe13256306a237f7bbbcbabd9f20223d4ed9 fedora/1/updates/i386/kernel-2.4.22-1.2199.8.legacy.nptl.i686.rpm 3917adb45e830432e875092aca7c7447eb2c8363 fedora/1/updates/i386/kernel-BOOT-2.4.22-1.2199.8.legacy.nptl.i386.rpm 337feb3c89f824fe1191cdf9332497e84effe122 fedora/1/updates/i386/kernel-doc-2.4.22-1.2199.8.legacy.nptl.i386.rpm e015d687b7cb7ce56396d0199686e9ea182adb1e fedora/1/updates/i386/kernel-smp-2.4.22-1.2199.8.legacy.nptl.athlon.rpm 157b2e6c26d187f9706d201e60ee1ea025cbec1c fedora/1/updates/i386/kernel-smp-2.4.22-1.2199.8.legacy.nptl.i586.rpm 987d9826216bdeadfdc364aaa1a8272a11a5c478 fedora/1/updates/i386/kernel-smp-2.4.22-1.2199.8.legacy.nptl.i686.rpm 4d4b7eae72326f73abb03a6833b767ab1170e3e9 fedora/1/updates/i386/kernel-source-2.4.22-1.2199.8.legacy.nptl.i386.rpm 973e0e5c1916951e9fac3dcf02999969e6da102d fedora/1/updates/SRPMS/kernel-2.4.22-1.2199.8.legacy.nptl.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-2002-2185 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0791 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0756 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1762 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2553 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1263 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2458 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2490 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2708 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2709 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2973 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3044 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3180 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3275 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3276 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3806 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3857 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Fri Mar 17 00:53:36 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 16 Mar 2006 19:53:36 -0500 Subject: [FLSA-2006:157459-3] Updated kernel packages fix security issues Message-ID: <441A0890.6080903@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated kernel packages fix security issues Advisory ID: FLSA:157459-3 Issue date: 2006-03-16 Product: Fedora Core Keywords: Bugfix CVE Names: CVE-2002-2185 CVE-2005-0756 CVE-2005-1761 CVE-2005-1762 CVE-2005-1763 CVE-2005-0839 CVE-2005-0867 CVE-2005-0937 CVE-2005-0977 CVE-2005-1041 CVE-2005-1263 CVE-2005-1264 CVE-2005-1265 CVE-2005-1368 CVE-2005-1369 CVE-2005-2098 CVE-2005-2099 CVE-2005-2456 CVE-2005-2555 CVE-2005-2458 CVE-2005-2490 CVE-2005-2492 CVE-2005-2709 CVE-2005-2800 CVE-2005-2801 CVE-2005-2872 CVE-2005-2973 CVE-2005-3044 CVE-2005-3053 CVE-2005-3106 CVE-2005-3109 CVE-2005-3110 CVE-2005-3180 CVE-2005-3181 CVE-2005-3274 CVE-2005-3275 CVE-2005-3276 CVE-2005-3356 CVE-2005-3358 CVE-2005-3784 CVE-2005-3805 CVE-2005-3806 CVE-2005-3807 CVE-2005-3848 CVE-2005-3857 CVE-2005-3858 CVE-2005-4605 CVE-2006-0095 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated kernel packages that fix several security issues are now available. The Linux kernel handles the basic functions of the operating system. 2. Relevant releases/architectures: Fedora Core 2 - i386 3. Problem description: These new kernel packages contain fixes for the security issues described below: - a flaw in network IGMP processing that a allowed a remote user on the local network to cause a denial of service (disabling of multicast reports) if the system is running multicast applications (CVE-2002-2185) - flaws in ptrace() syscall handling on 64-bit systems that allowed a local user to cause a denial of service (crash) (CVE-2005-0756, CVE-2005-1761, CVE-2005-1762, CVE-2005-1763) - a flaw when setting the line discipline on a serial tty that allowed a local user to inject mouse movements or keystrokes when another user is logged in. (CVE-2005-0839) - an integer overflow flaw when writing to a sysfs file that allowed a local user to overwrite kernel memory, causing a denial of service (system crash) or arbitrary code execution. (CVE-2005-0867) - a flaw in the futex functions that allowed a local user to cause a denial of service (system crash). (CVE-2005-0937) - a flaw in the tmpfs file system that allowed a local user to cause a denial of service (system crash). (CVE-2005-0977) - a flaw in the fib_seq_start function that allowed a local user to cause a denial of service (system crash) via /proc/net/route. (CVE-2005-1041) - a flaw between execve() syscall handling and core dumping of ELF-format executables allowed local unprivileged users to cause a denial of service (system crash) or possibly gain privileges (CVE-2005-1263) - a flaw in the servicing of a raw device ioctl that allowed a local user who has access to raw devices to write to kernel memory and cause a denial of service or potentially gain privileges (CVE-2005-1264) - a flaw that prevented the topdown allocator from allocating mmap areas all the way down to address zero (CVE-2005-1265) - a flaw in the key_user_lookup function in security/keys/key.c that allowed a user to cause a denial of service (crash) (CVE-2005-1368) - a flaw in the it87 and via686a drivers in I2C that allowed a locl user to cause a denial of service (crash) (CVE-2005-1369) - flaws dealing with keyrings that could cause a local denial of service (CVE-2005-2098, CVE-2005-2099) - flaws in IPSEC network handling that allowed a local user to cause a denial of service or potentially gain privileges (CVE-2005-2456, CVE-2005-2555) - a flaw in gzip/zlib handling internal to the kernel that may allow a local user to cause a denial of service (crash) (CVE-2005-2458) - a flaw in sendmsg() syscall handling on 64-bit systems that allowed a local user to cause a denial of service or potentially gain privileges (CVE-2005-2490) - a flaw in sendmsg() syscall handling that allowed a local user to cause a denial of service by altering hardware state (CVE-2005-2492) - a flaw in procfs handling during unloading of modules that allowed a local user to cause a denial of service or potentially gain privileges (CVE-2005-2709) - a flaw in the SCSI procfs interface that allowed a local user to cause a denial of service (crash) (CVE-2005-2800) - a xattr sharing bug in the ext2 and ext3 file systems that could cause default ACLs to disappear (CVE-2005-2801) - a flaw in the ipt_recent module on 64-bit architectures which could allow a remote denial of service (CVE-2005-2872) - a flaw in IPv6 network UDP port hash table lookups that allowed a local user to cause a denial of service (hang) (CVE-2005-2973) - a flaw in 32-bit-compat handling of the TIOCGDEV ioctl that allowed a local user to cause a denial of service (crash) (CVE-2005-3044) - a flaw in the set_mempolicy system call that allowed a local user to cause a denial of service (system panic). (CVE-2005-3053) - a race condition when threads share memory mapping that allowed local users to cause a denial of service (deadlock) (CVE-2005-3106) - a flaw when trying to mount a non-hfsplus filesystem using hfsplus that allowed local users to cause a denial of service (crash) (CVE-2005-3109) - a race condition in the ebtables netfilter module that may allow remote attackers to cause a denial of service (crash) on a SMP system that is operating under a heavy load (CVE-2005-3110) - a network buffer info leak using the orinoco driver that allowed a remote user to possibly view uninitialized data (CVE-2005-3180) - a memory leak was found in the audit system that allowed an unprivileged local user to cause a denial of service. (CVE-2005-3181) - a race condition in ip_vs_conn_flush that allowed a local user to cause a denial of service (CVE-2005-3274) - a flaw in IPv4 network TCP and UDP netfilter handling that allowed a local user to cause a denial of service (crash) (CVE-2005-3275) - a minor info leak with the get_thread_area() syscall that allowed a local user to view uninitialized kernel stack data (CVE-2005-3276) - a flaw in mq_open system call that allowed a local user to cause a denial of service (crash) (CVE-2005-3356) - a flaw in set_mempolicy that allowed a local user on some 64-bit architectures to cause a denial of service (crash) (CVE-2005-3358) - a flaw in the auto-reap of child processes that allowed a local user to cause a denial of service (crash) (CVE-2005-3784) - a flaw in the POSIX timer cleanup handling that allowed a local user to cause a denial of service (crash) (CVE-2005-3805) - a flaw in the IPv6 flowlabel code that allowed a local user to cause a denial of service (crash) (CVE-2005-3806) - a memory leak in the VFS file lease handling that allowed a local user to cause a denial of service (CVE-2005-3807) - a flaw in network ICMP processing that allowed a local user to cause a denial of service (memory exhaustion) (CVE-2005-3848) - a flaw in file lease time-out handling that allowed a local user to cause a denial of service (log file overflow) (CVE-2005-3857) - a flaw in network IPv6 xfrm handling that allowed a local user to cause a denial of service (memory exhaustion) (CVE-2005-3858) - a flaw in procfs handling that allowed a local user to read kernel memory (CVE-2005-4605) - a memory disclosure flaw in dm-crypt that allowed a local user to obtain sensitive information about a cryptographic key (CVE-2006-0095) All users are advised to upgrade their kernels to the packages associated with their machine architectures and configurations as listed in this erratum. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To install kernel packages manually, use "rpm -ivh " and modify system settings to boot the kernel you have installed. To do this, edit /boot/grub/grub.conf and change the default entry to "default=0" (or, if you have chosen to use LILO as your boot loader, edit /etc/lilo.conf and run lilo) 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. Note that this may not automatically pull the new kernel in if you have configured apt/yum to ignore kernels. If so, follow the manual instructions above. 5. Bug IDs fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157459 6. RPMs required: Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/kernel-2.6.10-2.3.legacy_FC2.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/kernel-doc-2.6.10-2.3.legacy_FC2.noarch.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/kernel-sourcecode-2.6.10-2.3.legacy_FC2.noarch.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/kernel-2.6.10-2.3.legacy_FC2.i586.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/kernel-smp-2.6.10-2.3.legacy_FC2.i586.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/kernel-2.6.10-2.3.legacy_FC2.i686.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/kernel-smp-2.6.10-2.3.legacy_FC2.i686.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 68999cdecf0bb3c6cda09edbe2cedd57fff709ad fedora/2/updates/i386/kernel-2.6.10-2.3.legacy_FC2.i586.rpm 85de0ac6c22acb127c7bfae0c8b6e8067fd60442 fedora/2/updates/i386/kernel-2.6.10-2.3.legacy_FC2.i686.rpm 631a71b16611758af3db18da17205422deb41c30 fedora/2/updates/i386/kernel-doc-2.6.10-2.3.legacy_FC2.noarch.rpm 6f5010188ca24a79d5fb6323a687c5cdc9611d24 fedora/2/updates/i386/kernel-smp-2.6.10-2.3.legacy_FC2.i586.rpm 4beec907750088ff917855a7e5ec8a31bb752358 fedora/2/updates/i386/kernel-smp-2.6.10-2.3.legacy_FC2.i686.rpm 1a33e38fa69b09fb80e6a5d334aad72e963820eb fedora/2/updates/i386/kernel-sourcecode-2.6.10-2.3.legacy_FC2.noarch.rpm 85eee44769a3a0ca55221b93d9386563798961a7 fedora/2/updates/SRPMS/kernel-2.6.10-2.3.legacy_FC2.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-2002-2185 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0756 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1761 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1762 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1763 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0839 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0867 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0937 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0977 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1041 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1263 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1264 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1265 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1368 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1369 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2098 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2099 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2456 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2555 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2458 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2490 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2492 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2709 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2800 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2801 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2872 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2973 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3044 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3053 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3106 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3109 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3110 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3180 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3181 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3274 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3275 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3276 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3356 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3358 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3784 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3805 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3806 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3807 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3848 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3857 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3858 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4605 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0095 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Fri Mar 17 00:54:07 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 16 Mar 2006 19:54:07 -0500 Subject: [FLSA-2006:157459-4] Updated kernel packages fix security issues Message-ID: <441A08AF.1020203@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated kernel packages fix security issues Advisory ID: FLSA:157459-4 Issue date: 2006-03-16 Product: Fedora Core Keywords: Bugfix CVE Names: CVE-2002-2185 CVE-2005-2709 CVE-2005-3044 CVE-2005-3274 CVE-2005-3356 CVE-2005-3358 CVE-2005-3527 CVE-2005-3784 CVE-2005-3805 CVE-2005-3806 CVE-2005-3807 CVE-2005-3857 CVE-2005-4605 CVE-2006-0095 CVE-2006-0454 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated kernel packages that fix several security issues are now available. The Linux kernel handles the basic functions of the operating system. 2. Relevant releases/architectures: Fedora Core 3 - i386, x86_64 3. Problem description: These new kernel packages contain fixes for the security issues described below: - a flaw in network IGMP processing that a allowed a remote user on the local network to cause a denial of service (disabling of multicast reports) if the system is running multicast applications (CVE-2002-2185) - a flaw in procfs handling during unloading of modules that allowed a local user to cause a denial of service or potentially gain privileges (CVE-2005-2709) - a flaw in 32-bit-compat handling of the TIOCGDEV ioctl that allowed a local user to cause a denial of service (crash) (CVE-2005-3044) - a race condition in ip_vs_conn_flush that allowed a local user to cause a denial of service (CVE-2005-3274) - a flaw in mq_open system call that allowed a local user to cause a denial of service (crash) (CVE-2005-3356) - a flaw in set_mempolicy that allowed a local user on some 64-bit architectures to cause a denial of service (crash) (CVE-2005-3358) - a race condition in do_coredump in signal.c that allowed a local user to cause a denial of service (crash) (CVE-2005-3527) - a flaw in the auto-reap of child processes that allowed a local user to cause a denial of service (crash) (CVE-2005-3784) - a flaw in the POSIX timer cleanup handling that allowed a local user to cause a denial of service (crash) (CVE-2005-3805) - a flaw in the IPv6 flowlabel code that allowed a local user to cause a denial of service (crash) (CVE-2005-3806) - a memory leak in the VFS file lease handling that allowed a local user to cause a denial of service (CVE-2005-3807) - a flaw in file lease time-out handling that allowed a local user to cause a denial of service (log file overflow) (CVE-2005-3857) - a flaw in procfs handling that allowed a local user to read kernel memory (CVE-2005-4605) - a memory disclosure flaw in dm-crypt that allowed a local user to obtain sensitive information about a cryptographic key (CVE-2006-0095) - a flaw while constructing an ICMP response that allowed remote users to cause a denial of service (crash) (CVE-2006-0454) All users are advised to upgrade their kernels to the packages associated with their machine architectures and configurations as listed in this erratum. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To install kernel packages manually, use "rpm -ivh " and modify system settings to boot the kernel you have installed. To do this, edit /boot/grub/grub.conf and change the default entry to "default=0" (or, if you have chosen to use LILO as your boot loader, edit /etc/lilo.conf and run lilo) 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. Note that this may not automatically pull the new kernel in if you have configured apt/yum to ignore kernels. If so, follow the manual instructions above. 5. Bug IDs fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157459 6. RPMs required: Fedora Core 3: SRPM: http://download.fedoralegacy.org/fedora/3/updates/SRPMS/kernel-2.6.12-2.3.legacy_FC3.src.rpm i386: http://download.fedoralegacy.org/fedora/3/updates/i386/kernel-2.6.12-2.3.legacy_FC3.i586.rpm http://download.fedoralegacy.org/fedora/3/updates/i386/kernel-2.6.12-2.3.legacy_FC3.i686.rpm http://download.fedoralegacy.org/fedora/3/updates/i386/kernel-doc-2.6.12-2.3.legacy_FC3.noarch.rpm http://download.fedoralegacy.org/fedora/3/updates/i386/kernel-smp-2.6.12-2.3.legacy_FC3.i586.rpm http://download.fedoralegacy.org/fedora/3/updates/i386/kernel-smp-2.6.12-2.3.legacy_FC3.i686.rpm x86_64: http://download.fedoralegacy.org/fedora/3/updates/x86_64/kernel-2.6.12-2.3.legacy_FC3.x86_64.rpm http://download.fedoralegacy.org/fedora/3/updates/x86_64/kernel-doc-2.6.12-2.3.legacy_FC3.noarch.rpm http://download.fedoralegacy.org/fedora/3/updates/x86_64/kernel-smp-2.6.12-2.3.legacy_FC3.x86_64.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- b9e37d94319ce74e98aa053d9da798437b979a5e fedora/3/updates/i386/kernel-2.6.12-2.3.legacy_FC3.i586.rpm e8698e932795b5a8c9ecc97e95fab42f55d71ac9 fedora/3/updates/i386/kernel-2.6.12-2.3.legacy_FC3.i686.rpm 58e7014a387ef6e17bf9f68d26eb1242a9dab3f2 fedora/3/updates/i386/kernel-doc-2.6.12-2.3.legacy_FC3.noarch.rpm d09fb6f194558505d8d52fb22a60420cd35a06f1 fedora/3/updates/i386/kernel-smp-2.6.12-2.3.legacy_FC3.i586.rpm 640077c447f1ac5edf5e21000c916bb750006f84 fedora/3/updates/i386/kernel-smp-2.6.12-2.3.legacy_FC3.i686.rpm 3341ee0cc5e61d464a9982a5f96ec802d9121965 fedora/3/updates/x86_64/kernel-2.6.12-2.3.legacy_FC3.x86_64.rpm 58e7014a387ef6e17bf9f68d26eb1242a9dab3f2 fedora/3/updates/x86_64/kernel-doc-2.6.12-2.3.legacy_FC3.noarch.rpm ab4a29a3ec0bceda378319476b6ce46613805f90 fedora/3/updates/x86_64/kernel-smp-2.6.12-2.3.legacy_FC3.x86_64.rpm 725204fe5e8fb35b54083be1a6757cc8be43cf9d fedora/3/updates/SRPMS/kernel-2.6.12-2.3.legacy_FC3.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-2002-2185 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2709 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3044 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3274 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3356 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3358 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3527 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3784 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3805 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3806 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3807 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3857 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4605 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0095 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0454 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Fri Mar 17 00:54:55 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 16 Mar 2006 19:54:55 -0500 Subject: [FLSA-2006:173274] Updated gdk-pixbuf packages fix security issues Message-ID: <441A08DF.3060809@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated gdk-pixbuf packages fix security issues Advisory ID: FLSA:173274 Issue date: 2006-03-16 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2005-2975 CVE-2005-2976 CVE-2005-3186 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated gdk-pixbuf packages that fix several security issues are now available. The gdk-pixbuf package contains an image loading library used with the GNOME GUI desktop environment. 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 gdk-pixbuf processes XPM images. An attacker could create a carefully crafted XPM file in such a way that it could cause an application linked with gdk-pixbuf to execute arbitrary code when the file was opened by a victim. The Common Vulnerabilities and Exposures project has assigned the name CVE-2005-3186 to this issue. Ludwig Nussel discovered an integer overflow bug in the way gdk-pixbuf processes XPM images. An attacker could create a carefully crafted XPM file in such a way that it could cause an application linked with gdk-pixbuf to execute arbitrary code or crash when the file was opened by a victim. The Common Vulnerabilities and Exposures project has assigned the name CVE-2005-2976 to this issue. Ludwig Nussel also discovered an infinite-loop denial of service bug in the way gdk-pixbuf processes XPM images. An attacker could create a carefully crafted XPM file in such a way that it could cause an application linked with gdk-pixbuf to stop responding when the file was opened by a victim. The Common Vulnerabilities and Exposures project has assigned the name CVE-2005-2975 to this issue. Users of gdk-pixbuf are advised to upgrade to these updated packages, which contain backported patches and are not vulnerable to these issues. 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=173274 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/gdk-pixbuf-0.22.0-7.73.4.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/gdk-pixbuf-0.22.0-7.73.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/gdk-pixbuf-devel-0.22.0-7.73.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/gdk-pixbuf-gnome-0.22.0-7.73.4.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/gdk-pixbuf-0.22.0-7.90.4.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/gdk-pixbuf-0.22.0-7.90.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/gdk-pixbuf-devel-0.22.0-7.90.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/gdk-pixbuf-gnome-0.22.0-7.90.4.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/gdk-pixbuf-0.22.0-11.3.4.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/gdk-pixbuf-0.22.0-11.3.4.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/gdk-pixbuf-devel-0.22.0-11.3.4.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/gdk-pixbuf-gnome-0.22.0-11.3.4.2.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/gdk-pixbuf-0.22.0-12.fc2.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/gdk-pixbuf-0.22.0-12.fc2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/gdk-pixbuf-devel-0.22.0-12.fc2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/gdk-pixbuf-gnome-0.22.0-12.fc2.1.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 68920e1aa48821ef2712597cfbb738a308fed989 redhat/7.3/updates/i386/gdk-pixbuf-0.22.0-7.73.4.legacy.i386.rpm bed67c95aeba203d572601c03f61f4a87738577e redhat/7.3/updates/i386/gdk-pixbuf-devel-0.22.0-7.73.4.legacy.i386.rpm 83b2d6fa22c90b3335c80e8516bbf7c013f3e0ce redhat/7.3/updates/i386/gdk-pixbuf-gnome-0.22.0-7.73.4.legacy.i386.rpm 72d3a78c075cbd1108551c0f003d1d546474f345 redhat/7.3/updates/SRPMS/gdk-pixbuf-0.22.0-7.73.4.legacy.src.rpm d2f5f242b378c44caa4b05ff2d157732b4f50896 redhat/9/updates/i386/gdk-pixbuf-0.22.0-7.90.4.legacy.i386.rpm 5a4b0b7566fb195e3ae9ac9df3a1d0d85f86d53d redhat/9/updates/i386/gdk-pixbuf-devel-0.22.0-7.90.4.legacy.i386.rpm 99deb34f608c31c177acc48aae2a5a22dbef5e27 redhat/9/updates/i386/gdk-pixbuf-gnome-0.22.0-7.90.4.legacy.i386.rpm 34b8e79dfcfabfbd375636077a606f4c7193aabb redhat/9/updates/SRPMS/gdk-pixbuf-0.22.0-7.90.4.legacy.src.rpm 0c08e3ec62a3ffc2cf4bf020f56dbce6c6abe55e fedora/1/updates/i386/gdk-pixbuf-0.22.0-11.3.4.2.legacy.i386.rpm b51c2c8928ef71b22375ef359262f5ab0467ede1 fedora/1/updates/i386/gdk-pixbuf-devel-0.22.0-11.3.4.2.legacy.i386.rpm c36d9f5d78ddb75cfade93741fac76b692159fc0 fedora/1/updates/i386/gdk-pixbuf-gnome-0.22.0-11.3.4.2.legacy.i386.rpm a33a275c1c2ff62a4256cd360aa2377989db4fd9 fedora/1/updates/SRPMS/gdk-pixbuf-0.22.0-11.3.4.2.legacy.src.rpm 6b55923c343d97bd131685a02cb36aba60be94a2 fedora/2/updates/i386/gdk-pixbuf-0.22.0-12.fc2.1.legacy.i386.rpm a391b3b8ee9c42bf0f4fed872bfa5aea61cd34a7 fedora/2/updates/i386/gdk-pixbuf-devel-0.22.0-12.fc2.1.legacy.i386.rpm a76c91bbdb0ff8fc1a30bf7c46a7392fbecf412b fedora/2/updates/i386/gdk-pixbuf-gnome-0.22.0-12.fc2.1.legacy.i386.rpm 1ee0fd9996c89480305d4831e77406696030ec3f fedora/2/updates/SRPMS/gdk-pixbuf-0.22.0-12.fc2.1.legacy.src.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2975 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2976 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3186 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Fri Mar 17 00:55:34 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 16 Mar 2006 19:55:34 -0500 Subject: [FLSA-2006:174479] Updated libungif packages fix security issues Message-ID: <441A0906.8080003@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated libungif packages fix security issues Advisory ID: FLSA:174479 Issue date: 2006-03-16 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2005-2974 CVE-2005-3350 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated libungif packages that fix two security issues are now available. The libungif package contains a shared library of functions for loading and saving GIF format image files. 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: Several bugs in the way libungif decodes GIF images were discovered. An attacker could create a carefully crafted GIF image file in such a way that it could cause an application linked with libungif to crash or execute arbitrary code when the file is opened by a victim. The Common Vulnerabilities and Exposures project has assigned the names CVE-2005-2974 and CVE-2005-3350 to these issues. All users of libungif are advised to upgrade to these updated packages, which contain backported patches that resolve these issues. 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=174479 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/libungif-4.1.0-10.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/libungif-4.1.0-10.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/libungif-devel-4.1.0-10.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/libungif-progs-4.1.0-10.2.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/libungif-4.1.0-15.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/libungif-4.1.0-15.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/libungif-devel-4.1.0-15.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/libungif-progs-4.1.0-15.2.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/libungif-4.1.0-16.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/libungif-4.1.0-16.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/libungif-devel-4.1.0-16.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/libungif-progs-4.1.0-16.2.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/libungif-4.1.0-17.3.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/libungif-4.1.0-17.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/libungif-devel-4.1.0-17.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/libungif-progs-4.1.0-17.3.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 540bf946dff308b065de73d7ce6ab9eb8d8c504a redhat/7.3/updates/i386/libungif-4.1.0-10.2.legacy.i386.rpm 840791ef661042f779275b7c835760ab521a8d80 redhat/7.3/updates/i386/libungif-devel-4.1.0-10.2.legacy.i386.rpm 81f2ed8f2bae2785ec2820234875b870f583c7ce redhat/7.3/updates/i386/libungif-progs-4.1.0-10.2.legacy.i386.rpm 8e039159be2bf479bf2bdb84ebadc2a364b3bd06 redhat/7.3/updates/SRPMS/libungif-4.1.0-10.2.legacy.src.rpm c78cfe7b9a7e46d45865fcebad0956efb8962970 redhat/9/updates/i386/libungif-4.1.0-15.2.legacy.i386.rpm 1b8a2ff811fca4b56850adfc5fc602bd140876d8 redhat/9/updates/i386/libungif-devel-4.1.0-15.2.legacy.i386.rpm 35f6365684cec0da676b5c5fea9bdf2e9863d1ff redhat/9/updates/i386/libungif-progs-4.1.0-15.2.legacy.i386.rpm cb023ca008db9d81ad6d730cb714cb1f51ea97f3 redhat/9/updates/SRPMS/libungif-4.1.0-15.2.legacy.src.rpm 351c84419dfff38690db6f343fa91a41e6b2af1e fedora/1/updates/i386/libungif-4.1.0-16.2.legacy.i386.rpm 72af8bc46a9deb31ede1fc773866e67f20f0da0b fedora/1/updates/i386/libungif-devel-4.1.0-16.2.legacy.i386.rpm 3d36816c8ec4479647419402be97568fade3088e fedora/1/updates/i386/libungif-progs-4.1.0-16.2.legacy.i386.rpm 92a4859d10e58f5abc85e7e22c89e4cf4911fbf0 fedora/1/updates/SRPMS/libungif-4.1.0-16.2.legacy.src.rpm 3a87b57220b6b788150d240977774dc54f6732fe fedora/2/updates/i386/libungif-4.1.0-17.3.legacy.i386.rpm c2d7e51e31ecb48546712d0c6f9998601af6daec fedora/2/updates/i386/libungif-devel-4.1.0-17.3.legacy.i386.rpm fbde1aceba27f12aacb41c8acbe2cf58a59cc121 fedora/2/updates/i386/libungif-progs-4.1.0-17.3.legacy.i386.rpm 609e3081132c7dca0da32f631e5ec4117df51265 fedora/2/updates/SRPMS/libungif-4.1.0-17.3.legacy.src.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2974 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3350 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Fri Mar 17 00:56:17 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 16 Mar 2006 19:56:17 -0500 Subject: [FLSA-2006:175404] Updated xpdf package fixes security issues Message-ID: <441A0931.5050905@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated xpdf package fixes security issues Advisory ID: FLSA:175404 Issue date: 2006-03-16 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2005-2097 CVE-2005-3191 CVE-2005-3192 CVE-2005-3193 CVE-2005-3624 CVE-2005-3625 CVE-2005-3626 CVE-2005-3627 CVE-2005-3628 CVE-2006-0301 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: An updated xpdf package that fixes several security issues is now available. The xpdf package is an X Window System-based viewer for Portable Document Format (PDF) files. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 Fedora Core 3 - i386, x86_64 3. Problem description: A flaw was discovered in Xpdf in that an attacker could construct a carefully crafted PDF file that would cause Xpdf to consume all available disk space in /tmp when opened. The Common Vulnerabilities and Exposures project assigned the name CVE-2005-2097 to this issue. Several flaws were discovered in Xpdf. An attacker could construct a carefully crafted PDF file that could cause Xpdf to crash or possibly execute arbitrary code when opened. The Common Vulnerabilities and Exposures project assigned the names CVE-2005-3191, CVE-2005-3192, CVE-2005-3193, CVE-2005-3624, CVE-2005-3625, CVE-2005-3626, CVE-2005-3627 and CVE-2005-3628 to these issues. A heap based buffer overflow bug was discovered in Xpdf. An attacker could construct a carefully crafted PDF file that could cause Xpdf to crash or possibly execute arbitrary code when opened. The Common Vulnerabilities and Exposures project assigned the name CVE-2006-0301 to this issue. Users of Xpdf should upgrade to this updated package, which contains backported patches to resolve these issues. 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=175404 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/xpdf-1.00-7.6.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/xpdf-1.00-7.6.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/xpdf-chinese-simplified-1.00-7.6.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/xpdf-chinese-traditional-1.00-7.6.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/xpdf-japanese-1.00-7.6.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/xpdf-korean-1.00-7.6.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/xpdf-2.01-11.4.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/xpdf-2.01-11.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/xpdf-chinese-simplified-2.01-11.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/xpdf-chinese-traditional-2.01-11.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/xpdf-japanese-2.01-11.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/xpdf-korean-2.01-11.4.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/xpdf-2.03-1.4.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/xpdf-2.03-1.4.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/xpdf-3.00-3.8.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/xpdf-3.00-3.8.1.legacy.i386.rpm Fedora Core 3: SRPM: http://download.fedoralegacy.org/fedora/3/updates/SRPMS/xpdf-3.01-0.FC3.5.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/3/updates/i386/xpdf-3.01-0.FC3.5.legacy.i386.rpm x86_64: http://download.fedoralegacy.org/fedora/3/updates/x86_64/xpdf-3.01-0.FC3.5.legacy.x86_64.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 6096aa2b487e635ae3003cf246ec66d53dc81d41 redhat/7.3/updates/i386/xpdf-1.00-7.6.legacy.i386.rpm e670899dd04a31d466d0ba2cc213763157a3b101 redhat/7.3/updates/i386/xpdf-chinese-simplified-1.00-7.6.legacy.i386.rpm c636a2b79eb22afe35993466675e9fdd086a84f2 redhat/7.3/updates/i386/xpdf-chinese-traditional-1.00-7.6.legacy.i386.rpm 9a2bfe9e373cd20422a862f48d3d6ad787b7f0f1 redhat/7.3/updates/i386/xpdf-japanese-1.00-7.6.legacy.i386.rpm bc47f11dea342606e74aff1a55cf74bd52783b60 redhat/7.3/updates/i386/xpdf-korean-1.00-7.6.legacy.i386.rpm ace7a51b625269d9f5bd3355b07a842f0e1426f4 redhat/7.3/updates/SRPMS/xpdf-1.00-7.6.legacy.src.rpm 4fe0714cdf2194cf0426e15210cbe509d77b2788 redhat/9/updates/i386/xpdf-2.01-11.4.legacy.i386.rpm c54fad904f475d693c781632dbadfae9434e4c87 redhat/9/updates/i386/xpdf-chinese-simplified-2.01-11.4.legacy.i386.rpm 1b6f0cf3f309515fd60b88576a1168f9d9bc7fe0 redhat/9/updates/i386/xpdf-chinese-traditional-2.01-11.4.legacy.i386.rpm accef6df9ed9b1cee0e05fffa7e7dde085ae3f35 redhat/9/updates/i386/xpdf-japanese-2.01-11.4.legacy.i386.rpm 69a7ae59cb1ddb5b422eccdec53711f459939c3f redhat/9/updates/i386/xpdf-korean-2.01-11.4.legacy.i386.rpm 090ddacf36dc0180c16cef8526aedc9bb9c5225c redhat/9/updates/SRPMS/xpdf-2.01-11.4.legacy.src.rpm 0349626a79f659adc0590938b99a6097f6898f10 fedora/1/updates/i386/xpdf-2.03-1.4.legacy.i386.rpm 8612ba60a89cfb0ef195450d1c927487b868deec fedora/1/updates/SRPMS/xpdf-2.03-1.4.legacy.src.rpm f60fc20854386ef91f6769aabd29f3a77e29084d fedora/2/updates/i386/xpdf-3.00-3.8.1.legacy.i386.rpm 64139c039afc0af67eadcc8c87e03aed6c6254d0 fedora/2/updates/SRPMS/xpdf-3.00-3.8.1.legacy.src.rpm 268cba4fb5fd62699595cdeed78375f324c874f6 fedora/3/updates/i386/xpdf-3.01-0.FC3.5.legacy.i386.rpm 021ec4bb4d86192a519261b3073a3d348e4fa14a fedora/3/updates/x86_64/xpdf-3.01-0.FC3.5.legacy.x86_64.rpm 3e139055107af9057062154add60191331765e43 fedora/3/updates/SRPMS/xpdf-3.01-0.FC3.5.legacy.src.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2097 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 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0301 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Fri Mar 17 00:56:56 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 16 Mar 2006 19:56:56 -0500 Subject: [FLSA-2006:178606] Updated kdelibs packages fix security issues Message-ID: <441A0958.4040805@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated kdelibs packages fix security issues Advisory ID: FLSA:178606 Issue date: 2006-03-16 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2005-0237 CVE-2005-0396 CVE-2005-1046 CVE-2005-1920 CVE-2006-0019 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated kdelibs packages that fix several security issues are now available. The kdelibs package provides libraries for the K Desktop Environment. 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: The International Domain Name (IDN) support in the Konqueror browser allowed remote attackers to spoof domain names using punycode encoded domain names. Such domain names are decoded in URLs and SSL certificates in a way that uses homograph characters from other character sets, which facilitates phishing attacks. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0237 to this issue. Sebastian Krahmer discovered a flaw in dcopserver, the KDE Desktop Communication Protocol (DCOP) daemon. A local user could use this flaw to stall the DCOP authentication process, affecting any local desktop users and causing a reduction in their desktop functionality. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0396 to this issue. A buffer overflow was found in the kimgio library for KDE 3.4.0. An attacker could create a carefully crafted PCX image in such a way that it would cause kimgio to execute arbitrary code when processing the image. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-1046 to this issue. A flaw was discovered affecting Kate, the KDE advanced text editor, and Kwrite. Depending on system settings, it may be possible for a local user to read the backup files created by Kate or Kwrite. The Common Vulnerabilities and Exposures project assigned the name CVE-2005-1920 to this issue. A heap overflow flaw was discovered affecting kjs, the JavaScript interpreter engine used by Konqueror and other parts of KDE. An attacker could create a malicious web site containing carefully crafted JavaScript code that would trigger this flaw and possibly lead to arbitrary code execution. The Common Vulnerabilities and Exposures project assigned the name CVE-2006-0019 to this issue. Users of KDE should upgrade to these erratum packages, which contain backported patches to correct these issues. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178606 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/kdelibs-3.0.5a-0.73.7.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/kdelibs-3.0.5a-0.73.7.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/kdelibs-devel-3.0.5a-0.73.7.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/kdelibs-3.1-17.1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/kdelibs-3.1-17.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/kdelibs-devel-3.1-17.1.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/kdelibs-3.1.4-9.FC1.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/kdelibs-3.1.4-9.FC1.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/kdelibs-devel-3.1.4-9.FC1.1.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/kdelibs-3.2.2-14.FC2.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/kdelibs-3.2.2-14.FC2.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/kdelibs-devel-3.2.2-14.FC2.2.legacy.i386.rpm Fedora Core 3: SRPM: http://download.fedoralegacy.org/fedora/3/updates/SRPMS/kdelibs-3.4.2-1.fc3.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/3/updates/i386/kdelibs-3.4.2-1.fc3.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/3/updates/i386/kdelibs-devel-3.4.2-1.fc3.1.legacy.i386.rpm x86_64: http://download.fedoralegacy.org/fedora/3/updates/x86_64/kdelibs-3.4.2-1.fc3.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/3/updates/x86_64/kdelibs-3.4.2-1.fc3.1.legacy.x86_64.rpm http://download.fedoralegacy.org/fedora/3/updates/x86_64/kdelibs-devel-3.4.2-1.fc3.1.legacy.x86_64.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 2f2d25474d7f6c68b77e376684f3835cd61123e4 redhat/7.3/updates/i386/kdelibs-3.0.5a-0.73.7.legacy.i386.rpm c153c581d132fc5ae882167d3319f103652043dd redhat/7.3/updates/i386/kdelibs-devel-3.0.5a-0.73.7.legacy.i386.rpm 7ad24efea3cd775ad8bc649128d64875eec1554e redhat/7.3/updates/SRPMS/kdelibs-3.0.5a-0.73.7.legacy.src.rpm f527dda13ccda9cd86542014e749587548b82a32 redhat/9/updates/i386/kdelibs-3.1-17.1.legacy.i386.rpm 6e22f76a8310051d285d60817066659f4429b633 redhat/9/updates/i386/kdelibs-devel-3.1-17.1.legacy.i386.rpm 7d8b9b30352004864252d7f2a72a877f062adf0f redhat/9/updates/SRPMS/kdelibs-3.1-17.1.legacy.src.rpm 3de25dd41842099dca0cf142adef2c4fe35bcfce fedora/1/updates/i386/kdelibs-3.1.4-9.FC1.1.legacy.i386.rpm 5d48525f08c39c3f73ca1d547be6aa0335c02a02 fedora/1/updates/i386/kdelibs-devel-3.1.4-9.FC1.1.legacy.i386.rpm 14c5cab3afedd32f05324ced28cd9abda3349ff1 fedora/1/updates/SRPMS/kdelibs-3.1.4-9.FC1.1.legacy.src.rpm 944bbc21e569bc63544f540783eedf4ecf430d2f fedora/2/updates/i386/kdelibs-3.2.2-14.FC2.2.legacy.i386.rpm 6d15fbaa66fbadf6fa19ce3feb04e4c71ef18dfe fedora/2/updates/i386/kdelibs-devel-3.2.2-14.FC2.2.legacy.i386.rpm 1b2a47dcae3e180dc2b0ccecdff5dca12b914393 fedora/2/updates/SRPMS/kdelibs-3.2.2-14.FC2.2.legacy.src.rpm 4d217b3e16c4624ff14b9615ab7720efbaaff7e8 fedora/3/updates/i386/kdelibs-3.4.2-1.fc3.1.legacy.i386.rpm c861158a8f3734f0ae633fc46cd8705c6d5fc0ad fedora/3/updates/i386/kdelibs-devel-3.4.2-1.fc3.1.legacy.i386.rpm 4d217b3e16c4624ff14b9615ab7720efbaaff7e8 fedora/3/updates/x86_64/kdelibs-3.4.2-1.fc3.1.legacy.i386.rpm 8d37c651ebe27beb56c34383972128a18e8e3c4d fedora/3/updates/x86_64/kdelibs-3.4.2-1.fc3.1.legacy.x86_64.rpm 10cabc626d4c0570999ccd70aa8e248f31b49f8f fedora/3/updates/x86_64/kdelibs-devel-3.4.2-1.fc3.1.legacy.x86_64.rpm bb0dc7875106e2b71d30a5a8f2df6737aee4a80a fedora/3/updates/SRPMS/kdelibs-3.4.2-1.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-2005-0237 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0396 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1046 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1920 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0019 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Fri Mar 17 04:24:48 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 16 Mar 2006 23:24:48 -0500 Subject: Fedora Legacy Server Outage Message-ID: <441A3A10.5070302@videotron.ca> As we sent out today's security advisories, one of our servers experienced an outage before completely syncing to the mirrors. As a result, the updates repository contains missing packages. This situation should be corrected shortly. I apologize for any problems this may cause. Marc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From ben at schoolpathways.com Fri Mar 17 07:14:51 2006 From: ben at schoolpathways.com (Benjamin Smith) Date: Thu, 16 Mar 2006 23:14:51 -0800 Subject: X-Chat 2.4.0 to 2.6 In-Reply-To: <017101c64458$9c7482d0$1e00a8c0@prvd321> References: <00a101c642cd$6e970e00$1e00a8c0@prvd321> <440FBE2B.7010705@NOSPAMsbcglobal.net> <017101c64458$9c7482d0$1e00a8c0@prvd321> Message-ID: <200603162314.51836.ben@schoolpathways.com> On Friday 10 March 2006 07:37, Danny Terweij - Net Tuning | Net wrote: > > That's the mission. You *did* read the mission statement, didn't you? > > Nope. I dont like reading :P If you don't read the sign that says "Caution: Sharks" then expect to be bit occasionally. > > Isn't that what FC4 is supposed to be? > > Where it ends? FC is not a good choice for production. Linux is stable, > linux dont have to reboot much. Linux can run for years without a reboot. If you run a Linux system for years without a reboot on a public network, then your system is likely compromised, and is probably a launching point for crackers, spam relays, DOS attacks, and the like. To securely admin any Linux system all but requires a reboot to start using an updated kernel at the very least every few months or so, and frequently more often than that. > I > do not want to upgrade my production machines every 6 months because FC has > a new version. Then use CentOS if you like RedHat, or try Debian, Gentoo, or something else. > Those new versions holds new versions of software. Why cant they build one > FC and update/upgrade just the installed versions? Because, then, it wouldn't be the same release anymore? Perhaps I'm mistaken, but questions like these indicate (to me) that you just want others to solve your problems for free. > You think every "user" reading that? > Here a practical "user" example: > - Hmm no more updates when i do yum update > - lets google > - hey a new repo called legacy.. > - Ah here i found how to add it to my yum > - Nice i get updates again > But actualy it are not updates, but fixes/patches. But they *are* updates. They are *security* updates, so that systems that are otherwise stable don't have to be retired or "messed with" to keep working. New versions would destabilize such systems. If you want *new* versions, then get a *new* operating system version. > -After some time, he finds out that newer versions are not delivered. > -Finds alternate repos like atrpms dag dries livna etc... > -doing yum update, "oh look again new versions :)" > > This is a real example how most of the linux users are doing without read > any statement text. Because its not intresting to read :) sed -e s/'most of the linux users'/'me'/g; But you wouldn't read up to find out what that does either, would you? -Ben -- "I kept looking around for somebody to solve the problem. Then I realized I am somebody" -Anonymous From lists at benjamindsmith.com Fri Mar 17 07:15:38 2006 From: lists at benjamindsmith.com (Benjamin Smith) Date: Thu, 16 Mar 2006 23:15:38 -0800 Subject: X-Chat 2.4.0 to 2.6 In-Reply-To: <017101c64458$9c7482d0$1e00a8c0@prvd321> References: <00a101c642cd$6e970e00$1e00a8c0@prvd321> <440FBE2B.7010705@NOSPAMsbcglobal.net> <017101c64458$9c7482d0$1e00a8c0@prvd321> Message-ID: <200603162315.38391.lists@benjamindsmith.com> On Friday 10 March 2006 07:37, Danny Terweij - Net Tuning | Net wrote: > > That's the mission. You *did* read the mission statement, didn't you? > > Nope. I dont like reading :P If you don't read the sign that says "Caution: Sharks" then expect to be bit occasionally. > > Isn't that what FC4 is supposed to be? > > Where it ends? FC is not a good choice for production. Linux is stable, > linux dont have to reboot much. Linux can run for years without a reboot. If you run a Linux system for years without a reboot on a public network, then your system is likely compromised, and is probably a launching point for crackers, spam relays, DOS attacks, and the like. To securely admin any Linux system all but requires a reboot to start using an updated kernel at the very least every few months or so, and frequently more often than that. > I > do not want to upgrade my production machines every 6 months because FC has > a new version. Then use CentOS if you like RedHat, or try Debian, Gentoo, or something else. > Those new versions holds new versions of software. Why cant they build one > FC and update/upgrade just the installed versions? Because, then, it wouldn't be the same release anymore? Perhaps I'm mistaken, but questions like these indicate (to me) that you just want others to solve your problems for free. > You think every "user" reading that? > Here a practical "user" example: > - Hmm no more updates when i do yum update > - lets google > - hey a new repo called legacy.. > - Ah here i found how to add it to my yum > - Nice i get updates again > But actualy it are not updates, but fixes/patches. But they *are* updates. They are *security* updates, so that systems that are otherwise stable don't have to be retired or "messed with" to keep working. New versions would destabilize such systems. If you want *new* versions, then get a *new* operating system version. > -After some time, he finds out that newer versions are not delivered. > -Finds alternate repos like atrpms dag dries livna etc... > -doing yum update, "oh look again new versions :)" > > This is a real example how most of the linux users are doing without read > any statement text. Because its not intresting to read :) sed -e s/'most of the linux users'/'me'/g; But you wouldn't read up to find out what that does either, would you? -Ben -- "I kept looking around for somebody to solve the problem. Then I realized I am somebody" -Anonymous -- "The best way to predict the future is to invent it." - XEROX PARC slogan, circa 1978 From deisenst at gtw.net Sun Mar 19 05:40:51 2006 From: deisenst at gtw.net (David Eisenstein) Date: Sat, 18 Mar 2006 23:40:51 -0600 (CST) Subject: FW: US-CERT Technical Cyber Security Alert TA06-075A -- Adobe Macromedia Flash Products Multiple Vulnerabilities Message-ID: Hi folks, "There are critical vulnerabilities in Macromedia Flash player and related software. Exploitation of these vulnerabilities could allow a remote, unauthenticated attacker to execute arbitrary code or cause a denial of service on a vulnerable system." For more detailed info, please see the forwarded message from CERT, below. Although I don't believe that Fedora or Fedora Legacy provides any version of Macromedia's Flash Player to our end users (as it's proprietary), end users may still decide to download and install this free plugin ... so it is good to know about this. I believe Flash is able to be used both with Firefox and Mozilla. Perhaps KDE's Konqueror also can use Flash. Someone who knows for sure about Konqueror, can you respond on the list and let us know? One workaround one can do to not be vulnerable is to disable Flash, at least until a secure version can be installed. I use Mozilla-1.7.12. What I do to disable flash (and I rarely have it enabled ;)) is: 1) Shut down your browser and (Mozilla-based) email program, if open. 2) Do a '$ find /usr/lib -iname 'libflash*.so'. 3) It may find the flash player (possibly named 'libflashplayer.so') under any of these directories: /usr/lib/mozilla/plugins/ /usr/lib/mozilla-(version)/plugins /usr/lib/firefox-(version)/plugins 4) Wherever it finds the plugin .so (shared-object) file, then (as root) either delete the file, or rename it to something your browser will not find to load. I rename it to 'no_libflashplayer.so.txt'. 5) At this point, the flash player should be disabled, so when you next start Mozilla and/or Firefox you should be safe from this vulnerability. I make no warrantee that the above suggestions for disabling the flash player will work for you. You take the above steps AT YOUR OWN RISK! If anyone has a better way to suggest disabling the Macromedia Flash player, will you please respond to this message with your suggestion(s)? Thanks. For those of you already aware of this, my apologies for the duplication. Regards, David Eisenstein ---------- Forwarded message ---------- From: US-CERT Technical Alerts To: technical-alerts at us-cert.gov Date: Thu, 16 Mar 2006 18:13:56 -0500 Subject: US-CERT Technical Cyber Security Alert TA06-075A -- Adobe Macromedia Flash Products Multiple Vulnerabilities -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 National Cyber Alert System Technical Cyber Security Alert TA06-075A Adobe Macromedia Flash Products Contain Vulnerabilities Original release date: March 16, 2006 Last revised: -- Source: US-CERT Systems Affected Microsoft Windows, Apple Mac OS X, Linux, Solaris, or other operating systems with any of the following Adobe Macromedia products installed: * Flash Player 8.0.22.0 and earlier * Flash Professional 8 * Flash Basic * Flash MX 2004 * Flash Debug Player 7.0.14.0 and earlier * Flex 1.5 * Breeze Meeting Add-In 5.1 and earlier * Adobe Macromedia Shockwave Player 10.1.0.11 and earlier For more complete information, refer to Adobe Security Bulletin APSB06-03. Overview There are critical vulnerabilities in Macromedia Flash player and related software. Exploitation of these vulnerabilities could allow a remote, unauthenticated attacker to execute arbitrary code or cause a denial of service on a vulnerable system. I. Description Adobe Security Bulletin APSB06-03 addresses vulnerabilities in Macromedia Flash Player and related software. Further information is available in the following US-CERT Vulnerability Note: VU#945060 - Adobe Macromedia Flash products contain multiple vulnerabilities Several vulnerabilities in Adobe Macromedia Flash products may allow a remote attacker to execute arbitrary code on a vulnerable system. (CVE-2006-0024) Several operating systems, including Microsoft Windows (see Microsoft Security Advisory 916208), have vulnerable versions of Flash installed by default. Systems with Flash-enabled web browsers are vulnerable. An attacker could host a specially crafted Flash file on a web site and convince a user to visit the site. II. Impact A remote, unauthenticated attacker could execute arbitrary code with the privileges of the user. If the user is logged on with administrative privileges, the attacker could take complete control of an affected system. An attacker may also be able to cause a denial of service. III. Solution Apply Updates Adobe has provided the updates for these vulnerabilities in APBS06-03. Disable Flash Please see Microsoft Security Advisory 916208 for instructions on how to disable Flash on Microsoft Windows. For other operating systems and web browsers, please contact the appropriate vendor. Appendix A. References * Macromedia - APSB06-03: Flash Player Update to Address Security Vulnerabilities - * US-CERT Vulnerability Note VU#945060 - * CVE-2006-0024 - * Microsoft Security Advisory (916208) - ____________________________________________________________________ The most recent version of this document can be found at: ____________________________________________________________________ Feedback can be directed to US-CERT Technical Staff. Please send email to with "TA06-075A Feedback VU#945060" in the subject. ____________________________________________________________________ For instructions on subscribing to or unsubscribing from this mailing list, visit . ____________________________________________________________________ Produced 2006 by US-CERT, a government organization. Terms of use: ____________________________________________________________________ Revision History Mar 16, 2006: Initial release -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iQEVAwUBRBnrc30pj593lg50AQJh0Af/WnwWF6RIXfF6zpDCXMzkEjdaiWUSDa+g utKrN8ZwUqKsPVw/uKR9vLwqWrWRYbTAsVjnFd1TBiBcasxAPIM4Y0u8sYCnXldB NmpotYhMPiuIIh7t/2bGxaAwOB8yBZvN4GNGDarsiK243/nf0m8Y7e6t+XN5FY6V nDp+q8mxiPN0T7Bh+ofeEX7m7SOEAza7kBwzsGgRSZzIkVmwH1+pBjPznmM1Zylh UzpTPhmvKkQtuDJ3iG3P0J6hrNZqTukEcOh5VB9gRhfvzpavSa6sXoiI7+/zTADa IJ8ZZZ6crFYmP/DTPeA9nbeCtQg/HAu+ty6ME/leVsHah3a16NWm4w== =XJw+ -----END PGP SIGNATURE----- From m.a.young at durham.ac.uk Sun Mar 19 17:48:52 2006 From: m.a.young at durham.ac.uk (M A Young) Date: Sun, 19 Mar 2006 17:48:52 +0000 (GMT) Subject: FW: US-CERT Technical Cyber Security Alert TA06-075A -- Adobe Macromedia Flash Products Multiple Vulnerabilities In-Reply-To: References: Message-ID: On Sat, 18 Mar 2006, David Eisenstein wrote: > Although I don't believe that Fedora or Fedora Legacy provides any version > of Macromedia's Flash Player to our end users (as it's proprietary), end > users may still decide to download and install this free plugin ... so it > is good to know about this. I believe Flash is able to be used both with > Firefox and Mozilla. Perhaps KDE's Konqueror also can use Flash. > Someone who knows for sure about Konqueror, can you respond on the list > and let us know? Yes, if you are using flash in mozilla or firefox, probably KDS Konqueror as well, you almost certainly need to upgrade. For mozilla or firefox, just type about:plugins in the title bar to see if you have flash installed - 7.0 r63 is the fixed version. Michael Young From pyz at brama.com Sun Mar 19 19:36:11 2006 From: pyz at brama.com (Max Pyziur) Date: Sun, 19 Mar 2006 14:36:11 -0500 (EST) Subject: FW: US-CERT Technical Cyber Security Alert TA06-075A -- Adobe Macromedia Flash Products Multiple Vulnerabilities In-Reply-To: References: Message-ID: On Sun, 19 Mar 2006, M A Young wrote: > On Sat, 18 Mar 2006, David Eisenstein wrote: > >> Although I don't believe that Fedora or Fedora Legacy provides any version >> of Macromedia's Flash Player to our end users (as it's proprietary), end >> users may still decide to download and install this free plugin ... so it >> is good to know about this. I believe Flash is able to be used both with >> Firefox and Mozilla. Perhaps KDE's Konqueror also can use Flash. >> Someone who knows for sure about Konqueror, can you respond on the list >> and let us know? > Yes, if you are using flash in mozilla or firefox, probably KDS Konqueror > as well, you almost certainly need to upgrade. For mozilla or firefox, > just type about:plugins in the title bar to see if you have flash > installed - 7.0 r63 is the fixed version. Latest rpms major distros can be found here: http://macromedia.mplug.org/site_uh.html Max Pyziur pyz at brama.com > Michael Young From jancio_wodnik at wp.pl Sun Mar 19 21:01:20 2006 From: jancio_wodnik at wp.pl (Jancio Wodnik) Date: Sun, 19 Mar 2006 22:01:20 +0100 Subject: FW: US-CERT Technical Cyber Security Alert TA06-075A -- Adobe Macromedia Flash Products Multiple Vulnerabilities In-Reply-To: References: Message-ID: <441DC6A0.4040102@wp.pl> Max Pyziur napisa?(a): > On Sun, 19 Mar 2006, M A Young wrote: > >> On Sat, 18 Mar 2006, David Eisenstein wrote: >> >>> Although I don't believe that Fedora or Fedora Legacy provides any >>> version >>> of Macromedia's Flash Player to our end users (as it's proprietary), >>> end >>> users may still decide to download and install this free plugin ... >>> so it >>> is good to know about this. I believe Flash is able to be used both >>> with >>> Firefox and Mozilla. Perhaps KDE's Konqueror also can use Flash. >>> Someone who knows for sure about Konqueror, can you respond on the list >>> and let us know? >> Yes, if you are using flash in mozilla or firefox, probably KDS >> Konqueror >> as well, you almost certainly need to upgrade. For mozilla or firefox, >> just type about:plugins in the title bar to see if you have flash >> installed - 7.0 r63 is the fixed version. > > Latest rpms major distros can be found here: > http://macromedia.mplug.org/site_uh.html yeah, the Latest. Files in this rpm for fedora are from 9 december so that is ver 7.61 of macromedia player :/ But he name this rpm is: flash-plugin-7.0.63-1.i386.rpm (inside ver 7.61) Eh, i have download it from macromedia and i have version 7.63 thanks a lot for this repo ! Irens > > Max Pyziur > pyz at brama.com > >> Michael Young > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > > From tmz at pobox.com Sun Mar 19 21:33:41 2006 From: tmz at pobox.com (Todd Zullinger) Date: Sun, 19 Mar 2006 16:33:41 -0500 Subject: FW: US-CERT Technical Cyber Security Alert TA06-075A -- Adobe Macromedia Flash Products Multiple Vulnerabilities In-Reply-To: <441DC6A0.4040102@wp.pl> References: <441DC6A0.4040102@wp.pl> Message-ID: <20060319213341.GA32376@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jancio Wodnik wrote: >>Latest rpms major distros can be found here: >>http://macromedia.mplug.org/site_uh.html > yeah, the Latest. Files in this rpm for fedora are from 9 december so > that is ver 7.61 of macromedia player :/ Why do you say that? The files inside the 7.0.63 tar archive available from Macromedia's website[1] are dated December 8, 2005. > But he name this rpm is: flash-plugin-7.0.63-1.i386.rpm (inside ver 7.61) Did you restart your browser after updating the rpm? Firefox 1.0.7 here shows 7.0 r63. [1] http://fpdownload.macromedia.com/get/flashplayer/current/install_flash_player_7_linux.tar.gz - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== A good programmer is one who looks both ways before crossing a one-way street. -- Doug Linder -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iG0EARECAC0FAkQdzjUmGGh0dHA6Ly93d3cucG9ib3guY29tL350bXovcGdwL3Rt ei5hc2MACgkQuv+09NZUB1qwZQCgrv97xFnYaaBOoKL1VHpPhUsvovYAn1hYW88e 0/MbCL6b3ZupruHBzs5a =K9X1 -----END PGP SIGNATURE----- From jancio_wodnik at wp.pl Sun Mar 19 23:18:35 2006 From: jancio_wodnik at wp.pl (Jancio Wodnik) Date: Mon, 20 Mar 2006 00:18:35 +0100 Subject: FW: US-CERT Technical Cyber Security Alert TA06-075A -- Adobe Macromedia Flash Products Multiple Vulnerabilities In-Reply-To: <20060319213341.GA32376@psilocybe.teonanacatl.org> References: <441DC6A0.4040102@wp.pl> <20060319213341.GA32376@psilocybe.teonanacatl.org> Message-ID: <441DE6CB.2030704@wp.pl> Todd Zullinger napisa?(a): > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jancio Wodnik wrote: > >>> Latest rpms major distros can be found here: >>> http://macromedia.mplug.org/site_uh.html >>> >> yeah, the Latest. Files in this rpm for fedora are from 9 december so >> that is ver 7.61 of macromedia player :/ >> > > Why do you say that? The files inside the 7.0.63 tar archive > available from Macromedia's website[1] are dated December 8, 2005. > > >> But he name this rpm is: flash-plugin-7.0.63-1.i386.rpm (inside ver 7.61) >> > > Did you restart your browser after updating the rpm? Firefox 1.0.7 > here shows 7.0 r63. > > Ok, I restarted twice, but i saw always 7.61, so installed again rpm with flash-plugin and now it is ok. My faul, sorry. Regards, Irens > [1] http://fpdownload.macromedia.com/get/flashplayer/current/install_flash_player_7_linux.tar.gz > > - -- > Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp > ====================================================================== > A good programmer is one who looks both ways before crossing a one-way > street. > -- Doug Linder > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (GNU/Linux) > Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. > > iG0EARECAC0FAkQdzjUmGGh0dHA6Ly93d3cucG9ib3guY29tL350bXovcGdwL3Rt > ei5hc2MACgkQuv+09NZUB1qwZQCgrv97xFnYaaBOoKL1VHpPhUsvovYAn1hYW88e > 0/MbCL6b3ZupruHBzs5a > =K9X1 > -----END PGP SIGNATURE----- > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > > > From gene.heskett at verizon.net Mon Mar 20 01:28:46 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Sun, 19 Mar 2006 20:28:46 -0500 Subject: FW: US-CERT Technical Cyber Security Alert TA06-075A -- Adobe Macromedia Flash Products Multiple Vulnerabilities In-Reply-To: <20060319213341.GA32376@psilocybe.teonanacatl.org> References: <441DC6A0.4040102@wp.pl> <20060319213341.GA32376@psilocybe.teonanacatl.org> Message-ID: <200603192028.47043.gene.heskett@verizon.net> On Sunday 19 March 2006 16:33, Todd Zullinger wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Jancio Wodnik wrote: >>>Latest rpms major distros can be found here: >>>http://macromedia.mplug.org/site_uh.html >> >> yeah, the Latest. Files in this rpm for fedora are from 9 december >> so that is ver 7.61 of macromedia player :/ > >Why do you say that? The files inside the 7.0.63 tar archive >available from Macromedia's website[1] are dated December 8, 2005. > >> But he name this rpm is: flash-plugin-7.0.63-1.i386.rpm (inside ver >> 7.61) > >Did you restart your browser after updating the rpm? Firefox 1.0.7 >here shows 7.0 r63. > >[1] > http://fpdownload.macromedia.com/get/flashplayer/current/install_flas >h_player_7_linux.tar.gz I have that same problem. First, this advisory is a wee bit old, and second the files in that rpm are as you say, obviously dated to well before this vulnerability was published. Like Dec 8, 2005. If this is indeed a vulnerability fix, I think we have a reasonable expectation of finding the executable code at least as new as the show-license file. Something doesn't quite smell edible here methinks. -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From tmz at pobox.com Mon Mar 20 02:18:47 2006 From: tmz at pobox.com (Todd Zullinger) Date: Sun, 19 Mar 2006 21:18:47 -0500 Subject: [OT] Re: FW: US-CERT Technical Cyber Security Alert TA06-075A -- Adobe Macromedia Flash Products Multiple Vulnerabilities In-Reply-To: <200603192028.47043.gene.heskett@verizon.net> References: <441DC6A0.4040102@wp.pl> <20060319213341.GA32376@psilocybe.teonanacatl.org> <200603192028.47043.gene.heskett@verizon.net> Message-ID: <20060320021847.GB32376@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gene Heskett wrote: > I have that same problem. First, this advisory is a wee bit old, > and second the files in that rpm are as you say, obviously dated to > well before this vulnerability was published. Like Dec 8, 2005. Well, we're far off topic here, but in the hopes of adding useful knowledge to the pool, here are a few comments. Looking at the CVE[1], it appears that this issue was assigned on 2005/11/30. So it's very possible that Macromedia had a chance to update their legacy 7x flash code by the 8th. Sure, the files from the Macromedia archive are dated Dec 8 and they didn't issue the advisory until Mar 14. This could be due to any number of factors. Maybe developing a fix for the newer 8x flash player (for windows and mac, not *nix) took longer. Or it could be that some of Macromedia's partners needed/wanted more time to get patches integrated before the security hole was released. It's also quite possible that Macromedia just isn't as fast to push out patches as many of us in the free software world are used to. > If this is indeed a vulnerability fix, I think we have a reasonable > expectation of finding the executable code at least as new as the > show-license file. Why? The show-license file is something added in packaging the rpm, not a part of the tarball that Macromedia provides. > Something doesn't quite smell edible here methinks. But then the question is, what steps have you taken to verify your suspicions? :) Here's a few minutes worth of investigation (yeah, I should have probably spent this time on one of the many packages in Legacy queue). The changelog for the rpm states: * Wed Mar 15 2006 Warren Togami 7.0.63-1 - CVE-2006-0024 The rpm is signed with the security at fedora.us key. The md5sum of the tarball from Macromedia's site matches that of the tarball in the flash-plugin SRPM. The Macromedia tarball's Readme.txt says: "Users should only install Players that have been downloaded from trusted sources, such as http://www.macromedia.com/ or http://macromedia.mplug.org/" (So Macromedia is showing their trust in the mplug distribution site, for what that's worth. I figure if you trust them enough to run their [closed source] code on your box, that you might also trust them if they point you to a download site.) Unless there's been a breach of the fedora.us key that I don't know about, I take the above as plenty of evidence that there isn't anything suspicious about the flash-plugin rpm. [1] http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0024 - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== ...more people are driven insane through religious hysteria than by drinking alcohol. -- W.C. Fields -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iG0EARECAC0FAkQeEQcmGGh0dHA6Ly93d3cucG9ib3guY29tL350bXovcGdwL3Rt ei5hc2MACgkQuv+09NZUB1rbCQCgzVrV/2sgVstp4drHB3937vp3BxcAoMSn3QRL zq5BZWdTYabiqzyZWFKl =j96R -----END PGP SIGNATURE----- From gene.heskett at verizon.net Mon Mar 20 03:47:33 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Sun, 19 Mar 2006 22:47:33 -0500 Subject: [OT] Re: FW: US-CERT Technical Cyber Security Alert TA06-075A -- Adobe Macromedia Flash Products Multiple Vulnerabilities In-Reply-To: <20060320021847.GB32376@psilocybe.teonanacatl.org> References: <200603192028.47043.gene.heskett@verizon.net> <20060320021847.GB32376@psilocybe.teonanacatl.org> Message-ID: <200603192247.33751.gene.heskett@verizon.net> On Sunday 19 March 2006 21:18, Todd Zullinger wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Gene Heskett wrote: >> I have that same problem. First, this advisory is a wee bit old, >> and second the files in that rpm are as you say, obviously dated to >> well before this vulnerability was published. Like Dec 8, 2005. > >Well, we're far off topic here, but in the hopes of adding >useful knowledge to the pool, here are a few comments. I wouldn't say we were THAT far off topic. :) >Looking at the CVE[1], it appears that this issue was assigned on >2005/11/30. So it's very possible that Macromedia had a chance to >update their legacy 7x flash code by the 8th. > >Sure, the files from the Macromedia archive are dated Dec 8 and they >didn't issue the advisory until Mar 14. This could be due to any >number of factors. Maybe developing a fix for the newer 8x flash >player (for windows and mac, not *nix) took longer. Or it could be >that some of Macromedia's partners needed/wanted more time to get >patches integrated before the security hole was released. > >It's also quite possible that Macromedia just isn't as fast to push >out patches as many of us in the free software world are used to. > The point is that when I went to install it, it had already, previously been installed by yum, several nights ago. But just for grins, let me check the date of that rpm in the yum cache. Yes that was on the 16th of March. Not quite as old in fact as it was in my well aged wet ram. Having seen the advisory on another site, I did that by hand, and automaticly assumed this was a brand new vulnerability. My bad. I should have looked in my own cache, but took the easy way out of makeing some obviously useless noise... My apologies. [...] -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From gene.heskett at verizon.net Mon Mar 20 03:53:16 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Sun, 19 Mar 2006 22:53:16 -0500 Subject: docbook format Q Message-ID: <200603192253.16200.gene.heskett@verizon.net> Greetings all; I just installed kleansweep from the tarball, but have found that its docs are in a compressed docbook format. I asked once before how does one go about viewing such files, and was chide for not reading the fine manual. Well, thats fine, but as far as I know, there isn't a manpage for docbook. My /usr/bin does contain a no doubt usefull collection of docbook2whatever file formaters but not a recognizable reader in the image of the simple 'man filename'. So how does one go about actually viewing a *.docbook file? -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From nils at lemonbit.nl Mon Mar 20 11:32:40 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Mon, 20 Mar 2006 12:32:40 +0100 Subject: docbook format Q In-Reply-To: <200603192253.16200.gene.heskett@verizon.net> References: <200603192253.16200.gene.heskett@verizon.net> Message-ID: Op 20-mrt-2006, om 4:53 heeft Gene Heskett het volgende geschreven: > I just installed kleansweep from the tarball, but have found that its > docs are in a compressed docbook format. > > I asked once before how does one go about viewing such files, and was > chide for not reading the fine manual. Well, thats fine, but as > far as > I know, there isn't a manpage for docbook. > > My /usr/bin does contain a no doubt usefull collection of > docbook2whatever file formaters but not a recognizable reader in the > image of the simple 'man filename'. > > So how does one go about actually viewing a *.docbook file? Docbook (as I understand it, I've never used it) is not a viewable format. It's a format from which you can generate viewable formats (HTML, PDF, txt, etc.). You'd have to dig around to find the right command to convert a docbook file into the format of your choice. Or maybe ask the kleansweep people why they don't ship viewable documentation. Or maybe they can tell you what to do. Nils Breunese. P.S. This is probably not the right list for this question. From dag at wieers.com Mon Mar 20 11:19:11 2006 From: dag at wieers.com (Dag Wieers) Date: Mon, 20 Mar 2006 12:19:11 +0100 (CET) Subject: apt sources.list In-Reply-To: <441E7947.7030801@imag.fr> References: <441E7947.7030801@imag.fr> Message-ID: On Mon, 20 Mar 2006, Nicolas Thierry-Mieg wrote: > I was actually looking for the sources.list entry for fedora legacy (for FC3), > I know there's a mirror on freshrpms > in fact shouldn't the apt fc3 package be updated to include the legacy mirror, > since the sources.list stuff is in that package (for fc3)? > That way people would transparently shift from core to legacy if they just > upgraded their freshrpms and rpmforge stuff > (my apt package is apt-0.5.15cnc6-4.1.fc3.rf, so this second point probably > concerns rpmforge rather than freshrpms, but I know Dag reads this list so I > won't crosspost) I guess it should. But it requires the fedora legacy project to create empty repositories in advance as I'm not interested in updating the apt package whenever a fedora release is phased out. I'm including the fedora legacy project in this mail to see if they can provide empty repositories in advance so they can be included at all times. Thanks for the feedback, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From jkeating at j2solutions.net Mon Mar 20 15:22:55 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 20 Mar 2006 07:22:55 -0800 Subject: apt sources.list In-Reply-To: References: <441E7947.7030801@imag.fr> Message-ID: <200603200722.55643.jkeating@j2solutions.net> On Monday 20 March 2006 03:19, Dag Wieers wrote: > I'm including the fedora legacy project in this mail to see if they can > provide empty repositories in advance so they can be included at all > times. I'm toying w/ the idea of dropping apt support as of FC3. With the start of multiple arches and with apt not being included in Fedora (but yum is), I'd rather not deal with the long long metadata generation time, the hassle of providing apt packages for each release and the nasty symlink tree I have to create to be able to support it. Apt metadata creation will continue to happen for the older RHL releases, and Fedoras up to 2 I do believe, but from 3 on, I'd rather use the native updating tools provided with Fedora. That said, I did create empty repos for FC4 and FC5, and will create one for FC6 once that gets going. Hopefully by the time FC6 comes out, we'll be moved over to using download.fedora.redhat.com as our master mirror and thus all the rest of the Fedora mirror system. -- 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: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From jkeating at redhat.com Mon Mar 20 15:15:26 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 20 Mar 2006 07:15:26 -0800 Subject: apt sources.list In-Reply-To: References: <441E7947.7030801@imag.fr> Message-ID: <200603200715.26950.jkeating@redhat.com> On Monday 20 March 2006 03:19, Dag Wieers wrote: > I guess it should. But it requires the fedora legacy project to create > empty repositories in advance as I'm not interested in updating the apt > package whenever a fedora release is phased out. > > I'm including the fedora legacy project in this mail to see if they can > provide empty repositories in advance so they can be included at all > times. I'm toying w/ the idea of dropping apt support as of FC3. With the start of multiple arches and with apt not being included in Fedora (but yum is), I'd rather not deal with the long long metadata generation time, the hassle of providing apt packages for each release and the nasty symlink tree I have to create to be able to support it. Apt metadata creation will continue to happen for the older RHL releases, and Fedoras up to 2 I do believe, but from 3 on, I'd rather use the native updating tools provided with Fedora. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From rdieter at math.unl.edu Mon Mar 20 15:39:48 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 20 Mar 2006 09:39:48 -0600 Subject: apt sources.list In-Reply-To: <200603200722.55643.jkeating@j2solutions.net> References: <441E7947.7030801@imag.fr> <200603200722.55643.jkeating@j2solutions.net> Message-ID: <441ECCC4.9030508@math.unl.edu> Jesse Keating wrote: > On Monday 20 March 2006 03:19, Dag Wieers wrote: >> I'm including the fedora legacy project in this mail to see if they can >> provide empty repositories in advance so they can be included at all >> times. > > I'm toying w/ the idea of dropping apt support as of FC3. With the start of > multiple arches and with apt not being included in Fedora (but yum is), AFAIK, apt development has been taken up again to address these issues. Not much point in dropping support, just to add it back later. OTOH, part of apt's improvements is to use repodata... (-: -- Rex From gerry at pathtech.org Mon Mar 20 16:48:15 2006 From: gerry at pathtech.org (G. Roderick Singleton) Date: Mon, 20 Mar 2006 11:48:15 -0500 Subject: apt sources.list In-Reply-To: <200603200722.55643.jkeating@j2solutions.net> References: <441E7947.7030801@imag.fr> <200603200722.55643.jkeating@j2solutions.net> Message-ID: <1142873295.14066.321.camel@www.pathtech.org> On Mon, 2006-03-20 at 07:22 -0800, Jesse Keating wrote: > On Monday 20 March 2006 03:19, Dag Wieers wrote: > > I'm including the fedora legacy project in this mail to see if they can > > provide empty repositories in advance so they can be included at all > > times. > > I'm toying w/ the idea of dropping apt support as of FC3. With the start of > multiple arches and with apt not being included in Fedora (but yum is), I'd > rather not deal with the long long metadata generation time, the hassle of > providing apt packages for each release and the nasty symlink tree I have to > create to be able to support it. Apt metadata creation will continue to > happen for the older RHL releases, and Fedoras up to 2 I do believe, but from > 3 on, I'd rather use the native updating tools provided with Fedora. Please do _NOT_ drop apt. I have found it is superior to yum with keeping my 7.3 box up-to-date. What I would like to see is to have certain tools, such as sendmail, included as the newer releases have security fixes and are often better than whatever was/is available with the distros. just my 2 cents worth. > > That said, I did create empty repos for FC4 and FC5, and will create one for > FC6 once that gets going. Hopefully by the time FC6 comes out, we'll be > moved over to using download.fedora.redhat.com as our master mirror and thus > all the rest of the Fedora mirror system. > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list -- G. Roderick Singleton PATH tech -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 1956 bytes Desc: not available URL: From jkeating at j2solutions.net Mon Mar 20 17:18:28 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 20 Mar 2006 09:18:28 -0800 Subject: apt sources.list In-Reply-To: <1142873295.14066.321.camel@www.pathtech.org> References: <441E7947.7030801@imag.fr> <200603200722.55643.jkeating@j2solutions.net> <1142873295.14066.321.camel@www.pathtech.org> Message-ID: <200603200918.28670.jkeating@j2solutions.net> On Monday 20 March 2006 08:48, G. Roderick Singleton wrote: > Please do _NOT_ drop apt. I have found it is superior to yum with > keeping my 7.3 box up-to-date. > > What I would like to see is to have certain tools, such as sendmail, > included as the newer releases have security fixes and are often better > than whatever was/is available with the distros. > > just my 2 cents worth. Apt support will not be removed for RHL7.3. However in later Fedora releases, yum performance is quite a lot better. If apt starts using the common repodata, then apt support will reappear for those releases too. As for new versions, that isn't something we'll do in the RHL space. Within Fedora there is an upstream (Fedora Project) tendency to use new releases, so we may follow suite when low impact. However something like sendmail is pretty high impact IMHO. -- 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: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From gerry at pathtech.org Mon Mar 20 17:52:13 2006 From: gerry at pathtech.org (G. Roderick Singleton) Date: Mon, 20 Mar 2006 12:52:13 -0500 Subject: apt sources.list In-Reply-To: <200603200918.28670.jkeating@j2solutions.net> References: <441E7947.7030801@imag.fr> <200603200722.55643.jkeating@j2solutions.net> <1142873295.14066.321.camel@www.pathtech.org> <200603200918.28670.jkeating@j2solutions.net> Message-ID: <1142877133.24818.2.camel@www.pathtech.org> On Mon, 2006-03-20 at 09:18 -0800, Jesse Keating wrote: > On Monday 20 March 2006 08:48, G. Roderick Singleton wrote: > > Please do _NOT_ drop apt. I have found it is superior to yum with > > keeping my 7.3 box up-to-date. > > > > What I would like to see is to have certain tools, such as sendmail, > > included as the newer releases have security fixes and are often better > > than whatever was/is available with the distros. > > > > just my 2 cents worth. > > Apt support will not be removed for RHL7.3. However in later Fedora releases, > yum performance is quite a lot better. If apt starts using the common > repodata, then apt support will reappear for those releases too. > > As for new versions, that isn't something we'll do in the RHL space. Within > Fedora there is an upstream (Fedora Project) tendency to use new releases, so > we may follow suite when low impact. However something like sendmail is > pretty high impact IMHO. > Yes. I have been building my own rpms but have no decent repository where they could be offered. Have 8.13.4 currently running and 8.13.5 in the queue. If FL and/or FP could offer space, I would be willing to share. -- G. Roderick Singleton PATH tech -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 1956 bytes Desc: not available URL: From donjr at maner.org Mon Mar 20 19:01:04 2006 From: donjr at maner.org (Donald Maner) Date: Mon, 20 Mar 2006 13:01:04 -0600 Subject: 1-2-3 out, time for FC2? Message-ID: <9CD490EAC0F62A40A780878421D4A730DE07@amun.home.maner.org> With the release of FC5, I figured I'd start the discussion to gauge the amount of support for keeping FC2 updates going. As specified in the FAQ, Fedora Legacy will pick it up and maintain it for two additional Fedora Core release cycles. I believe FC1 still has the following to warrant continued work, what about FC2? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gene.heskett at verizon.net Mon Mar 20 19:46:02 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Mon, 20 Mar 2006 14:46:02 -0500 Subject: 1-2-3 out, time for FC2? In-Reply-To: <9CD490EAC0F62A40A780878421D4A730DE07@amun.home.maner.org> References: <9CD490EAC0F62A40A780878421D4A730DE07@amun.home.maner.org> Message-ID: <200603201446.02912.gene.heskett@verizon.net> On Monday 20 March 2006 14:01, Donald Maner wrote: >With the release of FC5, I figured I'd start the discussion to gauge > the amount of support for keeping FC2 updates going. > >As specified in the FAQ, Fedora Legacy will pick it up and maintain it > for two additional Fedora Core release cycles. > >I believe FC1 still has the following to warrant continued work, what > about FC2? We're still out here, so count me in. -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From pekkas at netcore.fi Mon Mar 20 19:49:18 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 20 Mar 2006 21:49:18 +0200 (EET) Subject: 1-2-3 out, time for FC2? In-Reply-To: <200603201446.02912.gene.heskett@verizon.net> References: <9CD490EAC0F62A40A780878421D4A730DE07@amun.home.maner.org> <200603201446.02912.gene.heskett@verizon.net> Message-ID: On Mon, 20 Mar 2006, Gene Heskett wrote: >> I believe FC1 still has the following to warrant continued work, what >> about FC2? > > We're still out here, so count me in. Do you have a bugzilla account? Just wondering. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From jkeating at j2solutions.net Mon Mar 20 19:47:11 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 20 Mar 2006 11:47:11 -0800 Subject: 1-2-3 out, time for FC2? In-Reply-To: <9CD490EAC0F62A40A780878421D4A730DE07@amun.home.maner.org> References: <9CD490EAC0F62A40A780878421D4A730DE07@amun.home.maner.org> Message-ID: <200603201147.11754.jkeating@j2solutions.net> On Monday 20 March 2006 11:01, Donald Maner wrote: > With the release of FC5, I figured I'd start the discussion to gauge the > amount of support for keeping FC2 updates going. > As specified in the FAQ, Fedora Legacy will pick it up and maintain it for > two additional Fedora Core release cycles. > I believe FC1 still has the following to warrant continued work, what about > FC2? FC6 Test 2 would be the time in which FC2 would be eligible for the chopping block. Personally I'd like to see it go unless I get STRONG compelling arguments to keep it. Legacy is an extender, but not an indefinite one. Longer life span needs ought to be using RHEL or one of the free rebuilds. I'd also entertain pasturing FC1 at the same time. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From gene.heskett at verizon.net Mon Mar 20 19:57:39 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Mon, 20 Mar 2006 14:57:39 -0500 Subject: 1-2-3 out, time for FC2? In-Reply-To: References: <9CD490EAC0F62A40A780878421D4A730DE07@amun.home.maner.org> <200603201446.02912.gene.heskett@verizon.net> Message-ID: <200603201457.39189.gene.heskett@verizon.net> On Monday 20 March 2006 14:49, Pekka Savola wrote: >On Mon, 20 Mar 2006, Gene Heskett wrote: >>> I believe FC1 still has the following to warrant continued work, >>> what about FC2? >> >> We're still out here, so count me in. > >Do you have a bugzilla account? > >Just wondering. account? No, but I have made a couple of entries to HellZilla. That broke me of that wannabe bad habit. :( -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From donjr at maner.org Mon Mar 20 20:02:47 2006 From: donjr at maner.org (Donald Maner) Date: Mon, 20 Mar 2006 14:02:47 -0600 Subject: 1-2-3 out, time for FC2? References: <9CD490EAC0F62A40A780878421D4A730DE07@amun.home.maner.org> <200603201147.11754.jkeating@j2solutions.net> Message-ID: <9CD490EAC0F62A40A780878421D4A730DE08@amun.home.maner.org> Ah, so I'm jumping the gun a little bit :) That's fine, I just wanted to see which way the wind was blowing. ________________________________ On Monday 20 March 2006 11:01, Donald Maner wrote: > With the release of FC5, I figured I'd start the discussion to gauge the > amount of support for keeping FC2 updates going. > As specified in the FAQ, Fedora Legacy will pick it up and maintain it for > two additional Fedora Core release cycles. > I believe FC1 still has the following to warrant continued work, what about > FC2? FC6 Test 2 would be the time in which FC2 would be eligible for the chopping block. Personally I'd like to see it go unless I get STRONG compelling arguments to keep it. Legacy is an extender, but not an indefinite one. Longer life span needs ought to be using RHEL or one of the free rebuilds. -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 3817 bytes Desc: not available URL: From mic at npgx.com.au Mon Mar 20 20:44:04 2006 From: mic at npgx.com.au (Michael Mansour) Date: Tue, 21 Mar 2006 06:44:04 +1000 Subject: 1-2-3 out, time for FC2? In-Reply-To: <200603201446.02912.gene.heskett@verizon.net> References: <9CD490EAC0F62A40A780878421D4A730DE07@amun.home.maner.org> <200603201446.02912.gene.heskett@verizon.net> Message-ID: <20060320204252.M57697@npgx.com.au> > >With the release of FC5, I figured I'd start the discussion to gauge > > the amount of support for keeping FC2 updates going. > > > >As specified in the FAQ, Fedora Legacy will pick it up and maintain it > > for two additional Fedora Core release cycles. > > > >I believe FC1 still has the following to warrant continued work, what > > about FC2? > > We're still out here, so count me in. I still have one FC2 machine, but am decommissioning it over the next few weeks. Michael. From mic at npgx.com.au Mon Mar 20 21:22:34 2006 From: mic at npgx.com.au (Michael Mansour) Date: Tue, 21 Mar 2006 07:22:34 +1000 Subject: Updated tzdata packages? Message-ID: <20060320211633.M90352@npgx.com.au> Hi, I'm just wondering has anyone considered updating the tzdata package for FC1/2? In Australia for example, our Daylight savings time changed due to the Commonwealth games. Red Hat have released updates for their distributions, but looking at FC1/2: FC1# tzdata-2004b-1.fc1 FC2# tzdata-2005f-1.fc2 # zdump -v Australia/NSW |grep 2006 Australia/NSW Sat Mar 25 15:59:59 2006 UTC = Sun Mar 26 02:59:59 2006 EST isdst=1 gmtoff=39600 Australia/NSW Sat Mar 25 16:00:00 2006 UTC = Sun Mar 26 02:00:00 2006 EST isdst=0 gmtoff=36000 Australia/NSW Sat Oct 28 15:59:59 2006 UTC = Sun Oct 29 01:59:59 2006 EST isdst=0 gmtoff=36000 Australia/NSW Sat Oct 28 16:00:00 2006 UTC = Sun Oct 29 03:00:00 2006 EST isdst=1 gmtoff=39600 while FC3 (and above): # zdump -v Australia/NSW |grep 2006 Australia/NSW Sat Apr 1 15:59:59 2006 UTC = Sun Apr 2 02:59:59 2006 EST isdst=1 gmtoff=39600 Australia/NSW Sat Apr 1 16:00:00 2006 UTC = Sun Apr 2 02:00:00 2006 EST isdst=0 gmtoff=36000 Australia/NSW Sat Oct 28 15:59:59 2006 UTC = Sun Oct 29 01:59:59 2006 EST isdst=0 gmtoff=36000 Australia/NSW Sat Oct 28 16:00:00 2006 UTC = Sun Oct 29 03:00:00 2006 EST isdst=1 gmtoff=39600 Obviously this affects the way in which the clock will adjust itself this coming Saturday (3am goes back to 2am), instead of adjusting itself on April 1. I realise this isn't a security fix, but why hasn't FL taken the issue on board? Michael. From mattdm at mattdm.org Mon Mar 20 21:42:18 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 20 Mar 2006 16:42:18 -0500 Subject: 1-2-3 out, time for FC2? In-Reply-To: <9CD490EAC0F62A40A780878421D4A730DE07@amun.home.maner.org> References: <9CD490EAC0F62A40A780878421D4A730DE07@amun.home.maner.org> Message-ID: <20060320214218.GA11006@jadzia.bu.edu> On Mon, Mar 20, 2006 at 01:01:04PM -0600, Donald Maner wrote: > I believe FC1 still has the following to warrant continued work, what > about FC2? Sadly, my time has been thin so I haven't been able to contribute what I'd liked [*], and although I _do_ plan to help, this comment should most fairly be viewed as coming from Just an End User. That said, I hope to phase out all FC2-based systems here by the end of this summer, but would really appreciate updates until then. [*] I have an excuse! -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Mon Mar 20 21:44:12 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 20 Mar 2006 16:44:12 -0500 Subject: Updated tzdata packages? In-Reply-To: <20060320211633.M90352@npgx.com.au> References: <20060320211633.M90352@npgx.com.au> Message-ID: <20060320214412.GB11006@jadzia.bu.edu> On Tue, Mar 21, 2006 at 07:22:34AM +1000, Michael Mansour wrote: > I'm just wondering has anyone considered updating the tzdata package for FC1/2? > In Australia for example, our Daylight savings time changed due to the > Commonwealth games. Red Hat have released updates for their distributions, but > looking at FC1/2: > FC1# tzdata-2004b-1.fc1 > FC2# tzdata-2005f-1.fc2 And the Indiana change will bite people in the US, too. (2006a) > I realise this isn't a security fix, but why hasn't FL taken the issue on > board? I think you answered your own question. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From nils at lemonbit.nl Mon Mar 20 23:08:04 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Tue, 21 Mar 2006 00:08:04 +0100 Subject: 1-2-3 out, time for FC2? In-Reply-To: <200603201446.02912.gene.heskett@verizon.net> References: <9CD490EAC0F62A40A780878421D4A730DE07@amun.home.maner.org> <200603201446.02912.gene.heskett@verizon.net> Message-ID: <9ABA99A1-8ABA-4884-970E-8EE382017AD4@lemonbit.nl> Gene Heskett wrote: > On Monday 20 March 2006 14:01, Donald Maner wrote: >> With the release of FC5, I figured I'd start the discussion to gauge >> the amount of support for keeping FC2 updates going. >> >> As specified in the FAQ, Fedora Legacy will pick it up and >> maintain it >> for two additional Fedora Core release cycles. >> >> I believe FC1 still has the following to warrant continued work, what >> about FC2? > > We're still out here, so count me in. I have one production server that's still on FC2. If FL would stop releasing updates for FC2 I will have it reinstalled with a newer OS (probably CentOS). Alas, as it's my only FC2 machine I can't help with QA. Nils. From pekkas at netcore.fi Mon Mar 20 23:49:43 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 21 Mar 2006 01:49:43 +0200 (EET) Subject: Updated tzdata packages? In-Reply-To: <20060320214412.GB11006@jadzia.bu.edu> References: <20060320211633.M90352@npgx.com.au> <20060320214412.GB11006@jadzia.bu.edu> Message-ID: On Mon, 20 Mar 2006, Matthew Miller wrote: > On Tue, Mar 21, 2006 at 07:22:34AM +1000, Michael Mansour wrote: >> I'm just wondering has anyone considered updating the tzdata package for FC1/2? >> In Australia for example, our Daylight savings time changed due to the >> Commonwealth games. Red Hat have released updates for their distributions, but >> looking at FC1/2: >> FC1# tzdata-2004b-1.fc1 >> FC2# tzdata-2005f-1.fc2 > > And the Indiana change will bite people in the US, too. (2006a) Even though this is not a security issue, these have been fixed in any case. The tzdata/glibc packages should have been released a couple of weeks ago, but you can get them from updates-testing. RHL73/RHL9 (glibc) packages are based on tzdata 2006a; FC (tzdata) packages are based on 2005r. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From gene.heskett at verizon.net Tue Mar 21 03:11:31 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Mon, 20 Mar 2006 22:11:31 -0500 Subject: 1-2-3 out, time for FC2? In-Reply-To: <9ABA99A1-8ABA-4884-970E-8EE382017AD4@lemonbit.nl> References: <9CD490EAC0F62A40A780878421D4A730DE07@amun.home.maner.org> <200603201446.02912.gene.heskett@verizon.net> <9ABA99A1-8ABA-4884-970E-8EE382017AD4@lemonbit.nl> Message-ID: <200603202211.31166.gene.heskett@verizon.net> On Monday 20 March 2006 18:08, Nils Breunese (Lemonbit Internet) wrote: >Gene Heskett wrote: >> On Monday 20 March 2006 14:01, Donald Maner wrote: >>> With the release of FC5, I figured I'd start the discussion to >>> gauge the amount of support for keeping FC2 updates going. >>> >>> As specified in the FAQ, Fedora Legacy will pick it up and >>> maintain it >>> for two additional Fedora Core release cycles. >>> >>> I believe FC1 still has the following to warrant continued work, >>> what about FC2? >> >> We're still out here, so count me in. > >I have one production server that's still on FC2. If FL would stop >releasing updates for FC2 I will have it reinstalled with a newer OS >(probably CentOS). Alas, as it's my only FC2 machine I can't help >with QA. > >Nils. I'm in the same boat, the only FC2 box I have is this one, and I do not really consider it expendable. I'd feel much different if I had another box to drop onto the end of the ethernet cable & plug this 19" monitor into. But I don't. Lots of folks would call this considerably hacked up FC2 install thoroughly broken, but guess what? EVERYTHING I use everyday, for several hours of that day, Just Works(TM). >-- >fedora-legacy-list mailing list >fedora-legacy-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-legacy-list -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From cave.dnb at tiscali.fr Tue Mar 21 00:47:25 2006 From: cave.dnb at tiscali.fr (Nigel Henry) Date: Tue, 21 Mar 2006 01:47:25 +0100 Subject: FW: US-CERT Technical Cyber Security Alert TA06-075A -- Adobe Macromedia Flash Products Multiple Vulnerabilities In-Reply-To: References: Message-ID: <200603210147.25409.cave.dnb@tiscali.fr> On Sunday 19 March 2006 06:40, David Eisenstein wrote: > Hi folks, > > "There are critical vulnerabilities in Macromedia Flash player and > related software. Exploitation of these vulnerabilities could allow a > remote, unauthenticated attacker to execute arbitrary code or cause a > denial of service on a vulnerable system." > > For more detailed info, please see the forwarded message from CERT, > below. > > Although I don't believe that Fedora or Fedora Legacy provides any version > of Macromedia's Flash Player to our end users (as it's proprietary), end > users may still decide to download and install this free plugin ... so it > is good to know about this. I believe Flash is able to be used both with > Firefox and Mozilla. Perhaps KDE's Konqueror also can use Flash. > Someone who knows for sure about Konqueror, can you respond on the list > and let us know? Hi David. Just to let you know that the latest version of Flashplayer does work ok in Konqueror, on FC2. I tried it out on Jamie Cameron's Webmin site.http://www.webmin.com , and the link to his sister Lara Cameron's site, which requires Flash. Nigel. > > One workaround one can do to not be vulnerable is to disable Flash, at > least until a secure version can be installed. I use Mozilla-1.7.12. > What I do to disable flash (and I rarely have it enabled ;)) is: > > 1) Shut down your browser and (Mozilla-based) email program, if open. > 2) Do a '$ find /usr/lib -iname 'libflash*.so'. > 3) It may find the flash player (possibly named 'libflashplayer.so') > under any of these directories: > /usr/lib/mozilla/plugins/ > /usr/lib/mozilla-(version)/plugins > /usr/lib/firefox-(version)/plugins > 4) Wherever it finds the plugin .so (shared-object) file, then (as > root) either delete the file, or rename it to something your > browser will not find to load. I rename it to > 'no_libflashplayer.so.txt'. > 5) At this point, the flash player should be disabled, so when you > next start Mozilla and/or Firefox you should be safe from this > vulnerability. > > I make no warrantee that the above suggestions for disabling the flash > player will work for you. You take the above steps AT YOUR OWN RISK! > > If anyone has a better way to suggest disabling the Macromedia Flash > player, will you please respond to this message with your suggestion(s)? > Thanks. > > For those of you already aware of this, my apologies for the duplication. > > Regards, > David Eisenstein > > ---------- Forwarded message ---------- > From: US-CERT Technical Alerts > To: technical-alerts at us-cert.gov > Date: Thu, 16 Mar 2006 18:13:56 -0500 > Subject: US-CERT Technical Cyber Security Alert TA06-075A -- Adobe > Macromedia Flash Products Multiple Vulnerabilities > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > National Cyber Alert System > > Technical Cyber Security Alert TA06-075A > > > Adobe Macromedia Flash Products Contain Vulnerabilities > > Original release date: March 16, 2006 > Last revised: -- > Source: US-CERT > > > Systems Affected > > Microsoft Windows, Apple Mac OS X, Linux, Solaris, or other operating > systems with any of the following Adobe Macromedia products installed: > * Flash Player 8.0.22.0 and earlier > * Flash Professional 8 > * Flash Basic > * Flash MX 2004 > * Flash Debug Player 7.0.14.0 and earlier > * Flex 1.5 > * Breeze Meeting Add-In 5.1 and earlier > * Adobe Macromedia Shockwave Player 10.1.0.11 and earlier > > For more complete information, refer to Adobe Security Bulletin > APSB06-03. > > > Overview > > There are critical vulnerabilities in Macromedia Flash player and > related software. Exploitation of these vulnerabilities could allow a > remote, unauthenticated attacker to execute arbitrary code or cause a > denial of service on a vulnerable system. > > > I. Description > > Adobe Security Bulletin APSB06-03 addresses vulnerabilities in > Macromedia Flash Player and related software. Further information is > available in the following US-CERT Vulnerability Note: > > VU#945060 - Adobe Macromedia Flash products contain multiple > vulnerabilities > > Several vulnerabilities in Adobe Macromedia Flash products may allow a > remote attacker to execute arbitrary code on a vulnerable system. > (CVE-2006-0024) > > Several operating systems, including Microsoft Windows (see Microsoft > Security Advisory 916208), have vulnerable versions of Flash installed > by default. Systems with Flash-enabled web browsers are vulnerable. An > attacker could host a specially crafted Flash file on a web site and > convince a user to visit the site. > > > II. Impact > > A remote, unauthenticated attacker could execute arbitrary code with > the privileges of the user. If the user is logged on with > administrative privileges, the attacker could take complete control of > an affected system. An attacker may also be able to cause a denial of > service. > > > III. Solution > > Apply Updates > > Adobe has provided the updates for these vulnerabilities in APBS06-03. > > Disable Flash > > Please see Microsoft Security Advisory 916208 for instructions on how > to disable Flash on Microsoft Windows. For other operating systems and > web browsers, please contact the appropriate vendor. > > > Appendix A. References > > * Macromedia - APSB06-03: Flash Player Update to Address Security > Vulnerabilities - > .html> > > * US-CERT Vulnerability Note VU#945060 - > > > * CVE-2006-0024 - > > > * Microsoft Security Advisory (916208) - > > > > ____________________________________________________________________ > > The most recent version of this document can be found at: > > > ____________________________________________________________________ > > Feedback can be directed to US-CERT Technical Staff. Please send > email to with "TA06-075A Feedback VU#945060" in the > subject. > ____________________________________________________________________ > > For instructions on subscribing to or unsubscribing from this > mailing list, visit . > ____________________________________________________________________ > > Produced 2006 by US-CERT, a government organization. > > Terms of use: > > > ____________________________________________________________________ > > > Revision History > > Mar 16, 2006: Initial release > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.1 (GNU/Linux) > > iQEVAwUBRBnrc30pj593lg50AQJh0Af/WnwWF6RIXfF6zpDCXMzkEjdaiWUSDa+g > utKrN8ZwUqKsPVw/uKR9vLwqWrWRYbTAsVjnFd1TBiBcasxAPIM4Y0u8sYCnXldB > NmpotYhMPiuIIh7t/2bGxaAwOB8yBZvN4GNGDarsiK243/nf0m8Y7e6t+XN5FY6V > nDp+q8mxiPN0T7Bh+ofeEX7m7SOEAza7kBwzsGgRSZzIkVmwH1+pBjPznmM1Zylh > UzpTPhmvKkQtuDJ3iG3P0J6hrNZqTukEcOh5VB9gRhfvzpavSa6sXoiI7+/zTADa > IJ8ZZZ6crFYmP/DTPeA9nbeCtQg/HAu+ty6ME/leVsHah3a16NWm4w== > =XJw+ > -----END PGP SIGNATURE----- From mattdm at mattdm.org Tue Mar 21 11:41:19 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 21 Mar 2006 06:41:19 -0500 Subject: Updated tzdata packages? In-Reply-To: References: <20060320211633.M90352@npgx.com.au> <20060320214412.GB11006@jadzia.bu.edu> Message-ID: <20060321114119.GA16467@jadzia.bu.edu> On Tue, Mar 21, 2006 at 01:49:43AM +0200, Pekka Savola wrote: > >And the Indiana change will bite people in the US, too. (2006a) > Even though this is not a security issue, these have been fixed in any > case. Thanks Pekka! -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From philip at datafoundry.com Tue Mar 21 13:30:47 2006 From: philip at datafoundry.com (Philip Molter) Date: Tue, 21 Mar 2006 07:30:47 -0600 Subject: 1-2-3 out, time for FC2? In-Reply-To: <200603202211.31166.gene.heskett@verizon.net> References: <9CD490EAC0F62A40A780878421D4A730DE07@amun.home.maner.org> <200603201446.02912.gene.heskett@verizon.net> <9ABA99A1-8ABA-4884-970E-8EE382017AD4@lemonbit.nl> <200603202211.31166.gene.heskett@verizon.net> Message-ID: <44200007.7090605@datafoundry.com> > I'm in the same boat, the only FC2 box I have is this one, and I do not > really consider it expendable. I'd feel much different if I had > another box to drop onto the end of the ethernet cable & plug this 19" > monitor into. But I don't. > > Lots of folks would call this considerably hacked up FC2 install > thoroughly broken, but guess what? EVERYTHING I use everyday, for > several hours of that day, Just Works(TM). I have several FC2 boxes that I'd like to upgrade but haven't gotten around to hitting yet (they'll probably go to FC4 when I get around to it). FC2 is a great milestone distribution because it was the first FC distribution with the 2.6 kernel and that kernel was pushed all the way to 2.6.10, a really nice stable FC kernel, before being legacied. Philip From tseaver at palladion.com Tue Mar 21 13:38:28 2006 From: tseaver at palladion.com (Tres Seaver) Date: Tue, 21 Mar 2006 08:38:28 -0500 Subject: 1-2-3 out, time for FC2? In-Reply-To: <200603201147.11754.jkeating@j2solutions.net> References: <9CD490EAC0F62A40A780878421D4A730DE07@amun.home.maner.org> <200603201147.11754.jkeating@j2solutions.net> Message-ID: <442001D4.9060706@palladion.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: > On Monday 20 March 2006 11:01, Donald Maner wrote: > >>With the release of FC5, I figured I'd start the discussion to gauge the >>amount of support for keeping FC2 updates going. >>As specified in the FAQ, Fedora Legacy will pick it up and maintain it for >>two additional Fedora Core release cycles. >>I believe FC1 still has the following to warrant continued work, what about >>FC2? > > > FC6 Test 2 would be the time in which FC2 would be eligible for the chopping > block. Personally I'd like to see it go unless I get STRONG compelling > arguments to keep it. Legacy is an extender, but not an indefinite one. > Longer life span needs ought to be using RHEL or one of the free rebuilds. > > I'd also entertain pasturing FC1 at the same time. - -1 from me (and I actually do some package QA for FC1). No threat involved, but if FC1 is dropped, I will have no further incentive not to upgrade the only remaining Fedora box I have deployed to Centos. 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 iD8DBQFEIAHU+gerLs4ltQ4RAg/rAJ91Mdm7GTgulFdmu4s06l2ZMrq0HQCfXzeS IEWEc//tqiiChlTYZuO9XkA= =/OCS -----END PGP SIGNATURE----- From donjr at maner.org Tue Mar 21 16:09:18 2006 From: donjr at maner.org (Donald Maner) Date: Tue, 21 Mar 2006 10:09:18 -0600 Subject: 1-2-3 out, time for FC2? Message-ID: <9CD490EAC0F62A40A780878421D4A730520B@amun.home.maner.org> > - -1 from me (and I actually do some package QA for FC1). No > threat involved, but if FC1 is dropped, I will have no > further incentive not to upgrade the only remaining Fedora > box I have deployed to Centos. I think that's the point. FC isn't supposed to be never-ending for the FC releases. I think that if you're not going to upgrade an early FC release to a later release, you probably SHOULD switch to RHEL or a RHEL rebuild. It just makes sense: you KNOW that fixes will be available for 5 years or whatever it is. From Mike.McCarty at sbcglobal.net Tue Mar 21 18:08:16 2006 From: Mike.McCarty at sbcglobal.net (Mike McCarty) Date: Tue, 21 Mar 2006 12:08:16 -0600 Subject: 1-2-3 out, time for FC2? In-Reply-To: <9CD490EAC0F62A40A780878421D4A730DE07@amun.home.maner.org> References: <9CD490EAC0F62A40A780878421D4A730DE07@amun.home.maner.org> Message-ID: <44204110.40309@sbcglobal.net> Donald Maner wrote: > With the release of FC5, I figured I'd start the discussion to gauge the amount of support for keeping FC2 updates going. > > As specified in the FAQ, Fedora Legacy will pick it up and maintain it for two additional Fedora Core release cycles. > > I believe FC1 still has the following to warrant continued work, what about FC2? I have an FC2 machine which is my main machine. I don't have another, and no finances to get another, so I don't help with testing. OTOH, due to recent discussion regarding changes to QA policy, I'm not pulling from FL at the moment, so that may negate couting my machine. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From deisenst at gtw.net Tue Mar 21 18:33:10 2006 From: deisenst at gtw.net (David Eisenstein) Date: Tue, 21 Mar 2006 12:33:10 -0600 (CST) Subject: Updated tzdata packages? In-Reply-To: <20060320214412.GB11006@jadzia.bu.edu> Message-ID: On Mon, 20 Mar 2006, Matthew Miller wrote: > On Tue, Mar 21, 2006 at 07:22:34AM +1000, Michael Mansour wrote: > > I'm just wondering has anyone considered updating the tzdata package for FC1/2? > > In Australia for example, our Daylight savings time changed due to the > > Commonwealth games. Red Hat have released updates for their distributions, but > > looking at FC1/2: > > FC1# tzdata-2004b-1.fc1 > > FC2# tzdata-2005f-1.fc2 > > And the Indiana change will bite people in the US, too. (2006a) > > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (From ): == Comment #23 From David Eisenstein on 2006-02-28 09:49 EST == Just in case anyone is interested, I have built 2006a-based tzdata packages for Fedora Core 1. I've installed them on my FC1 machine, and it hasn't started smoking yet! :^) Built the package based on the devel tree in CVS, tag "tzdata-2006a-2". Note: These are *NOT* official Legacy packages. Source package: ebce830d475513202d17e1877cd652731b987108 tzdata-2006a-2.fc1.1.src.rpm Noarch binary package: 7b621b3da5f80223681becfc40bc6166fbc75d10 tzdata-2006a-2.fc1.1.noarch.rpm Downloadable at: http://fedoralegacy.org/contrib/tzdata/ Hope this is helpful. -David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFEIEaZxou1V/j9XZwRAsJEAJ9Ci4diKpF1q+huTTyv4Ub9+i9ZIwCgyA3c dtuQ+nmuJ1C7YvLbzJNOJ3o= =5MLP -----END PGP SIGNATURE----- From deisenst at gtw.net Tue Mar 21 19:24:27 2006 From: deisenst at gtw.net (David Eisenstein) Date: Tue, 21 Mar 2006 13:24:27 -0600 Subject: FW: Re: Secunia pages ... (from fedora-security-list) Message-ID: <442052EB.1070909@gtw.net> Hi Legacy Folks, I thought you all might find the following post by Josh Bressers to the new Fedora-security-list to be of interest. It gives some information about the methodology that the Security Response Team at Red Hat uses in discerning and triaging security-related bugs. Do we in Legacy have any security-audit CVE tracking files like Josh mentions below in Fedora's CVS? -David ---------- Forwarded message ---------- From: Josh Bressers To: David Eisenstein Cc: fedora-security-list at redhat.com, Filip Tsachev , Rahul Sundaram Date: Sat, 04 Mar 2006 07:35:53 -0500 Subject: Re: Secunia pages -- publishing wrong and misleading infor- mation about security status of Fedora distros?? RE: [Fedora Project Wiki] Update of "Security" by JoshBressers (fwd) > Was noticing one of Josh Bresser's edits to wiki/Security today... (see > the forward below). > > If Secunia's information is incorrect and misleading, misrepresenting the > true security status of Fedora distributions, oughtn't we get in touch > with Secunia to help coordinate updating their information to make it > correct and informative? I would dare to say it's not worth the effort. The problem becomes who do you decide to feed information to and who don't you? There are many organizations like secunia that try to represent security information to the public at large. I think the best way to show describe security issues to the Fedora community would be to write a script or two to parse these files: http://cvs.fedora.redhat.com/viewcvs/fedora-security/audit/fc4?root=fedora&view=markup http://cvs.fedora.redhat.com/viewcvs/fedora-security/audit/fc5?root=fedora&view=markup These are where the security response team tracks every public issue we're aware of that affects Core. I'm open to suggests and ideas from anyone who wants to parse this file. One of the problem is how to display this information in a sensible manner that doesn't overload a normal person. These files do have a lack of bugzilla ID, as almost 100% of the issues in FC4 should have a bugzilla entry. There are certain things we do with bugzilla to help capture information. The things in FC5 don't always as the version upgrade as part of distribution creation fixes many issues. Let's look at bug 182416 The first thing you will probably notice is the CVE id is in the summary. This makes it very easy to see which issues are which when we do a bug listing. This also means you can view the CVE information here: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0528 The severity is of course "security". The "Status Whiteboard" is possibly the most interesting thing we keep in a bug. This is also a field one would want to parse with a security reporting tool. source=cve,reported=20060202,impact=important,public=20060128 This tells us we found out about this issue when MITRE made not of it in their database (cve.mitre.org/cve). It's one of the many many things we spy on to stay ahead of the wave. We found the issue on 2006-02-02 (reported). We have classified the issue as "Important": http://www.redhat.com/security/updates/classification/ And the issue was known to the public at large on 2006-01-28. Let me know if there are any questions. I should probably find some time to put all this into a wiki page. From debbiet at arlut.utexas.edu Tue Mar 21 20:17:06 2006 From: debbiet at arlut.utexas.edu (Debbie Tropiano) Date: Tue, 21 Mar 2006 14:17:06 -0600 Subject: 1-2-3 out, time for FC2? In-Reply-To: <44200007.7090605@datafoundry.com> References: <9CD490EAC0F62A40A780878421D4A730DE07@amun.home.maner.org> <200603201446.02912.gene.heskett@verizon.net> <9ABA99A1-8ABA-4884-970E-8EE382017AD4@lemonbit.nl> <200603202211.31166.gene.heskett@verizon.net> <44200007.7090605@datafoundry.com> Message-ID: <20060321201706.GA22022@arlut.utexas.edu> On Tue, Mar 21, 2006 at 07:30:47AM -0600, Philip Molter wrote: > I have several FC2 boxes that I'd like to upgrade but haven't gotten > around to hitting yet (they'll probably go to FC4 ... As yet just another user (with no time or ability to help out at this time), this is our situation as well. We have several FC2 production systems that we're not ready to upgrade yet. We need SNARE and until we can use that with the kernel auditing in FC4, we can't upgrade (and yes, we are working on that issue). OTOH since they're pretty stable, we pretty much leave them alone (they're on a private network so fewer security issues). Debbie -- | Debbie Tropiano | debbiet at arlut.utexas.edu | | Environmental Sciences Laboratory | +1 512 835 3367 w | | Applied Research Laboratories of UT Austin | +1 512 835 3544 fax | | P.O. Box 8029, Austin, TX 78713-8029 | home email: debbie at icus.com | From nils at lemonbit.nl Tue Mar 21 22:34:41 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Tue, 21 Mar 2006 23:34:41 +0100 Subject: 1-2-3 out, time for FC2? In-Reply-To: <44204110.40309@sbcglobal.net> References: <9CD490EAC0F62A40A780878421D4A730DE07@amun.home.maner.org> <44204110.40309@sbcglobal.net> Message-ID: <54582786-7C0D-45EE-9EF9-0F891E397DFD@lemonbit.nl> Mike McCarty wrote: > I have an FC2 machine which is my main machine. I don't have > another, and no finances to get another, so I don't help > with testing. OTOH, due to recent discussion regarding changes > to QA policy, I'm not pulling from FL at the moment, so that > may negate couting my machine. Why don't you update to a newer Fedora Core release? Nils. From cave.dnb at tiscali.fr Wed Mar 22 00:23:51 2006 From: cave.dnb at tiscali.fr (Nigel Henry) Date: Wed, 22 Mar 2006 01:23:51 +0100 Subject: 1-2-3 out, time for FC2? In-Reply-To: <54582786-7C0D-45EE-9EF9-0F891E397DFD@lemonbit.nl> References: <9CD490EAC0F62A40A780878421D4A730DE07@amun.home.maner.org> <44204110.40309@sbcglobal.net> <54582786-7C0D-45EE-9EF9-0F891E397DFD@lemonbit.nl> Message-ID: <200603220123.51946.cave.dnb@tiscali.fr> On Tuesday 21 March 2006 23:34, Nils Breunese (Lemonbit Internet) wrote: > Mike McCarty wrote: > > I have an FC2 machine which is my main machine. I don't have > > another, and no finances to get another, so I don't help > > with testing. OTOH, due to recent discussion regarding changes > > to QA policy, I'm not pulling from FL at the moment, so that > > may negate couting my machine. > > Why don't you update to a newer Fedora Core release? > > Nils. Hi Nils. Personally I take offense at someone telling me to get a better distro. I see this a lot on forums. Someone asking a question to solve a problem, and some idiot replying back with, "upgrade" why don't you "upgrade". I've been using FC1, and FC2 for quite some time and am quite happy with them. In more recent times FC3, which on one machine continually crashes kicker (the panel) when logging out. FC4 was an absolute nightmare to install, as my cyberbladei1 card with the trident driver didn't appear to be supported. Had to change the driver to vesa to get X going. Only after doing the upgrades was I able to change the driver back to trident, so I'm not too impressed with either FC3, or FC4. I appreciate that there is a limit to how many RH, and Fedora versions that Fedora Legacy can cope with. If they drop FC1, and FC2, I will still continue to use them. It will be sad not having security support for them, and am not clued up enough to sort this out for myself, but so be it. Fernando at planetccrma has similar problems, dealing with music apps for RH9, FC1,2,3,and now 4, plus x86_64 on some of those. Logically the maintainers have to call a halt somewhere, but I will continue to use FC1, and FC2, supported or not. Incidentally there are still folks out there using MS DOS, and Win95, even though that is no longer supported. They are happy with it, and I hope have sufficient 3rd party security in place, but it's their choice, and no one should be forcing them to change. I'm only a home user, so perhaps am not so concerned as someone using FC1, FC2 in the corporate environment, but am sure that there are a certain number of Linux IT guys and gals out there who are quite capable of sorting out security fixes for FC1, and 2 if and when they are dropped by Fedora Legacy. Nigel. > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list From cave.dnb at tiscali.fr Tue Mar 21 23:49:50 2006 From: cave.dnb at tiscali.fr (Nigel Henry) Date: Wed, 22 Mar 2006 00:49:50 +0100 Subject: 1-2-3 out, time for FC2? In-Reply-To: <54582786-7C0D-45EE-9EF9-0F891E397DFD@lemonbit.nl> References: <9CD490EAC0F62A40A780878421D4A730DE07@amun.home.maner.org> <44204110.40309@sbcglobal.net> <54582786-7C0D-45EE-9EF9-0F891E397DFD@lemonbit.nl> Message-ID: <200603220049.50312.cave.dnb@tiscali.fr> On Tuesday 21 March 2006 23:34, Nils Breunese (Lemonbit Internet) wrote: > Mike McCarty wrote: > > I have an FC2 machine which is my main machine. I don't have > > another, and no finances to get another, so I don't help > > with testing. OTOH, due to recent discussion regarding changes > > to QA policy, I'm not pulling from FL at the moment, so that > > may negate couting my machine. > > Why don't you update to a newer Fedora Core release? > > Nils. Hi Nils. Personally I take offense at someone telling me to get a better distro. I see this a lot on forums. Someone asking a question to solve a problem, and some idiot replying back with, "upgrade" why don't you "upgrade". I've been using FC1, and FC2 for quite some time and am quite happy with them. In more recent times FC3, which on one machine continually crashes kicker (the panel) when logging out. FC4 was an absolute nightmare to install, as my cyberbladei1 card with the trident driver didn't appear to be supported. Had to change the driver to vesa to get X going. Only after doing the upgrades was I able to change the driver back to trident, so I'm not too impressed with either FC3, or FC4. I appreciate that there is a limit to how many RH, and Fedora versions that Fedora Legacy can cope with. If they drop FC1, and FC2, I will still continue to use them. It will be sad not having security support for them, and am not clued up enough to sort this out for myself, but so be it. Fernando at planetccrma has similar problems, dealing with music apps for RH9, FC1,2,3,and now 4, plus x86_64 on some of those. Logically the maintainers have to call a halt somewhere, but I will continue to use FC1, and FC2, supported or not. Incidentally there are still folks out there using MS DOS, and Win95, even though that is no longer supported. They are happy with it, and I hope have sufficient 3rd party security in place, but it's their choice, and no one should be forcing them to change. I'm only a home user, so perhaps am not so concerned as someone using FC1, FC2 in the corporate environment, but am sure that there are a certain number of Linux IT guys and gals out there who are quite capable of sorting out security fixes for FC1, and 2 if and when they are dropped by Fedora Legacy. Nigel. > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list From nils at lemonbit.nl Wed Mar 22 07:32:44 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Wed, 22 Mar 2006 08:32:44 +0100 Subject: 1-2-3 out, time for FC2? In-Reply-To: <200603220049.50312.cave.dnb@tiscali.fr> References: <9CD490EAC0F62A40A780878421D4A730DE07@amun.home.maner.org> <44204110.40309@sbcglobal.net> <54582786-7C0D-45EE-9EF9-0F891E397DFD@lemonbit.nl> <200603220049.50312.cave.dnb@tiscali.fr> Message-ID: <4FE6F39D-666C-4778-AB8E-CE23834B5C95@lemonbit.nl> Nigel Henry wrote: > On Tuesday 21 March 2006 23:34, Nils Breunese (Lemonbit Internet) > wrote: >> Why don't you update to a newer Fedora Core release? > > Hi Nils. Personally I take offense at someone telling me to get a > better > distro. I see this a lot on forums. Someone asking a question to > solve a > problem, and some idiot replying back with, "upgrade" why don't you > "upgrade". I'm not telling you to get a 'better distro' or to upgrade. I was just asking myself why you don't upgrade. There can be good reasons for that. On the other hand I wish people would stop complaining about not getting any upgrades anymore (I'm talking about people in general) when Fedora clearly states it has a short lifecycle. Fedora is for running the latest and greatest and Fedora Legacy is here to help people out a little longer after Red Hat stops releasing updates. > Incidentally there are still folks out there using MS DOS, and > Win95, even > though that is no longer supported. They are happy with it, and I > hope have > sufficient 3rd party security in place, but it's their choice, and > no one > should be forcing them to change. Nobody is forcing them or FC1/FC2 users to change their OS. > I'm only a home user, so perhaps am not so concerned as someone > using FC1, FC2 > in the corporate environment, but am sure that there are a certain > number of > Linux IT guys and gals out there who are quite capable of sorting out > security fixes for FC1, and 2 if and when they are dropped by > Fedora Legacy. Sure. But why don't they step in and join Fedora Legacy now? If there would a lot of community involvement maybe FL could support releases longer. Nils. From mic at npgx.com.au Wed Mar 22 08:15:46 2006 From: mic at npgx.com.au (Michael Mansour) Date: Wed, 22 Mar 2006 18:15:46 +1000 Subject: Updated tzdata packages? In-Reply-To: References: <20060320214412.GB11006@jadzia.bu.edu> Message-ID: <20060322081220.M90107@npgx.com.au> Hi, > On Mon, 20 Mar 2006, Matthew Miller wrote: > > > On Tue, Mar 21, 2006 at 07:22:34AM +1000, Michael Mansour wrote: > > > I'm just wondering has anyone considered updating the tzdata package for FC1/2? > > > In Australia for example, our Daylight savings time changed due to the > > > Commonwealth games. Red Hat have released updates for their distributions, but > > > looking at FC1/2: > > > FC1# tzdata-2004b-1.fc1 > > > FC2# tzdata-2005f-1.fc2 > > > > And the Indiana change will bite people in the US, too. (2006a) > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > (From > ): > == Comment #23 From David Eisenstein on 2006-02-28 09:49 EST == > > Just in case anyone is interested, I have built 2006a-based tzdata packages > for Fedora Core 1. I've installed them on my FC1 machine, and it hasn't > started smoking yet! :^) > > Built the package based on the devel tree in CVS, tag "tzdata-2006a-2". > > Note: These are *NOT* official Legacy packages. > > Source package: > ebce830d475513202d17e1877cd652731b987108 tzdata-2006a-2.fc1.1.src.rpm > > Noarch binary package: > 7b621b3da5f80223681becfc40bc6166fbc75d10 tzdata-2006a-2.fc1.1.noarch.rpm > > Downloadable at: http://fedoralegacy.org/contrib/tzdata/ > > Hope this is helpful. -David I just wanted to say thanks alot for all your help here. From the first email response I received I thought no one would have cared much about this update, even though it is a "critical" update as it causes problems system-wide, but then realised many had cared about it and updates were available. I've applied the updates and rebooted the affected machines and things in the world are fine again. Michael. From papier at sdv.fr Wed Mar 22 08:48:48 2006 From: papier at sdv.fr (Laurent Papier) Date: Wed, 22 Mar 2006 09:48:48 +0100 Subject: 1-2-3 out, time for FC2? In-Reply-To: <20060321201706.GA22022@arlut.utexas.edu> References: <9CD490EAC0F62A40A780878421D4A730DE07@amun.home.maner.org> <200603201446.02912.gene.heskett@verizon.net> <9ABA99A1-8ABA-4884-970E-8EE382017AD4@lemonbit.nl> <200603202211.31166.gene.heskett@verizon.net> <44200007.7090605@datafoundry.com> <20060321201706.GA22022@arlut.utexas.edu> Message-ID: <20060322094848.041ebbbe.papier@sdv.fr> Le Tue, 21 Mar 2006 14:17:06 -0600 Debbie Tropiano ?crit: > > On Tue, Mar 21, 2006 at 07:30:47AM -0600, Philip Molter wrote: > > I have several FC2 boxes that I'd like to upgrade but haven't gotten > > around to hitting yet (they'll probably go to FC4 ... > > As yet just another user (with no time or ability to help out at > this time), this is our situation as well. We have several FC2 > production systems that we're not ready to upgrade yet. We need > SNARE and until we can use that with the kernel auditing in FC4, > we can't upgrade (and yes, we are working on that issue). OTOH > since they're pretty stable, we pretty much leave them alone > (they're on a private network so fewer security issues). We also have a lot of FC2 servers in production. FC2 was the first distribution with kernel 2.6. In our environment (LAMP or mail servers without X11), newer FC release provide no real improvement. So we still use FC2 as it is much easier to manage only a few different distro (we still have RedHat 9 servers). -- Laurent Papier - 03 88 75 80 50 Admin. syst?me - SdV Plurimedia - From jkosin at beta.intcomgrp.com Wed Mar 22 13:31:20 2006 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Wed, 22 Mar 2006 08:31:20 -0500 Subject: 1-2-3 out, time for FC2? In-Reply-To: <4FE6F39D-666C-4778-AB8E-CE23834B5C95@lemonbit.nl> References: <9CD490EAC0F62A40A780878421D4A730DE07@amun.home.maner.org> <44204110.40309@sbcglobal.net> <54582786-7C0D-45EE-9EF9-0F891E397DFD@lemonbit.nl> <200603220049.50312.cave.dnb@tiscali.fr> <4FE6F39D-666C-4778-AB8E-CE23834B5C95@lemonbit.nl> Message-ID: <442151A8.6050108@beta.intcomgrp.com> Nils Breunese (Lemonbit Internet) wrote: > > I'm not telling you to get a 'better distro' or to upgrade. I was just > asking myself why you don't upgrade. There can be good reasons for > that. On the other hand I wish people would stop complaining about not > getting any upgrades anymore (I'm talking about people in general) > when Fedora clearly states it has a short lifecycle. Fedora is for > running the latest and greatest and Fedora Legacy is here to help > people out a little longer after Red Hat stops releasing updates. > My reasons: (1) Device driver for my Digi card is not supported by the newer kernels. (2) It took me weeks to setup everything originally, and I don't want to take weeks more if something goes wrong. (3) It actually works (FC1 that is)... I haven't had any problems with DNS, etc on the unit. Knock on wood. (4) I've learned a lot about RPM packages since the move to FL. That has to count for something.... If I stayed with the most current, I would have never learned how to build my own samba packages, httpd packages, install and maintain my own ClamAV packages. Actually learn a painful lesson why they don't update perl very often, etc. I could go on and on about this point. Just my 2-cents, James Kosin -- Scanned by ClamAV - http://www.clamav.net From nils at lemonbit.nl Wed Mar 22 16:02:35 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Wed, 22 Mar 2006 17:02:35 +0100 Subject: 1-2-3 out, time for FC2? In-Reply-To: <442151A8.6050108@beta.intcomgrp.com> References: <9CD490EAC0F62A40A780878421D4A730DE07@amun.home.maner.org> <44204110.40309@sbcglobal.net> <54582786-7C0D-45EE-9EF9-0F891E397DFD@lemonbit.nl> <200603220049.50312.cave.dnb@tiscali.fr> <4FE6F39D-666C-4778-AB8E-CE23834B5C95@lemonbit.nl> <442151A8.6050108@beta.intcomgrp.com> Message-ID: <3D8D2002-844C-4FDC-8502-A9942DD4F632@lemonbit.nl> James Kosin wrote: > My reasons: > (1) Device driver for my Digi card is not supported by the newer > kernels. > (2) It took me weeks to setup everything originally, and I don't > want to take weeks more if something goes wrong. > (3) It actually works (FC1 that is)... I haven't had any problems > with DNS, etc on the unit. Knock on wood. > (4) I've learned a lot about RPM packages since the move to FL. > That has to count for something.... If I stayed with the most > current, I would have never learned how to build my own samba > packages, httpd packages, install and maintain my own ClamAV > packages. Actually learn a painful lesson why they don't update > perl very often, etc. I could go on and on about this point. I upgraded my workstation from FC1 all the way to FC5 last monday every time a new release came out without a lot of problems (I think all my problems would've been non-existent if I had waited until the 3rd party repo's I use also built their stuff for FC5). It is nice that you learned about building rpms and that your machine just works. But apart from the driver for your card it really shouldn't be a problem for you to upgrade, right? Upgrading generally doesn't destroy your setup, so it shouldn't take weeks to be up and running again. Maybe a day. Of course, YMMV. I just think it would be interesting (for Fedora Legacy) to have some sort of idea of why people are running legacy versions of Red Hat and Fedora, so FL knows 'who they are doing it for'. My guess is that it's mostly people that have used Fedora Core for live servers that they don't want to upgrade (people that maybe should've gotten another distro, in my opinion) and there's people like James Kosin that won't upgrade because of things like driver/kernel issues. Now, I'm just on this list because I have a couple of FC2 and FC3 servers (yes, they shouldn't be running FC, but I didn't install them) and I want to keep myself updated on the status of the project that keeps those boxes safe on the internet. The minute FL is no longer able to deliver patched versions fast enough I will have my servers reinstalled with something like CentOS. And I'll just keep updating my workstation to the latest and greatest Fedora every release. :o) Nils. From Mike.McCarty at sbcglobal.net Wed Mar 22 17:27:57 2006 From: Mike.McCarty at sbcglobal.net (Mike McCarty) Date: Wed, 22 Mar 2006 11:27:57 -0600 Subject: 1-2-3 out, time for FC2? In-Reply-To: <3D8D2002-844C-4FDC-8502-A9942DD4F632@lemonbit.nl> References: <9CD490EAC0F62A40A780878421D4A730DE07@amun.home.maner.org> <44204110.40309@sbcglobal.net> <54582786-7C0D-45EE-9EF9-0F891E397DFD@lemonbit.nl> <200603220049.50312.cave.dnb@tiscali.fr> <4FE6F39D-666C-4778-AB8E-CE23834B5C95@lemonbit.nl> <442151A8.6050108@beta.intcomgrp.com> <3D8D2002-844C-4FDC-8502-A9942DD4F632@lemonbit.nl> Message-ID: <4421891D.6020803@sbcglobal.net> Nils Breunese (Lemonbit Internet) wrote: [snip] > I just think it would be interesting (for Fedora Legacy) to have some > sort of idea of why people are running legacy versions of Red Hat and > Fedora, so FL knows 'who they are doing it for'. My guess is that it's Oh, idle curiosity. Why would the people at FL be interested in any particular user's motivation? > mostly people that have used Fedora Core for live servers that they > don't want to upgrade (people that maybe should've gotten another > distro, in my opinion) and there's people like James Kosin that won't I do it because I should have used a different distribution. It came about like this (since you express idle curiosity)... I landed a contract programming job, and was requested to put Linux and WinXP both as dual boot on my machine. More specifically, I was requested to put FC2 on my machine. I worked on the software, which was intended to run under Windows, Linux, SCO Unix, and other OS. Now, the fellow who wanted me to run a Red Hat compatible Linux only knew about FCx as being a "good" one. He was ignorant. But that's what the boss wanted, so that's what I put on here. Probably a re-spin like CentOS or Scientific Linux would have been better. Now, the contract is over, but I have an FC2 box. I have zero motivation to change, so I leave it as it is. If I "upgrade" it will not be to any version of Fedora Core. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From shiva at sewingwitch.com Wed Mar 22 18:29:27 2006 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 22 Mar 2006 10:29:27 -0800 Subject: US-CERT Technical Cyber Security Alert TA06-081A -- Sendmail Race Condition Vulnerability (fwd) Message-ID: <38B44F665F3F012CD404C402@[10.169.6.226]> Main alert page: Fedora details: >From the summary: A race condition in Sendmail may allow a remote attacker to execute arbitrary code. For those of us accepting mail from outside on pre-FC4 Fedora, are any updates in the pipe to address this? From A.E.Lawrence at lboro.ac.uk Wed Mar 22 18:54:03 2006 From: A.E.Lawrence at lboro.ac.uk (A E Lawrence) Date: Wed, 22 Mar 2006 18:54:03 +0000 Subject: Fedora Legacy Update : kdelibs dependency problems Message-ID: <44219D4B.9090408@lboro.ac.uk> > Synopsis: Updated kdelibs packages fix security issues > Advisory ID: FLSA:178606 download.fedoralegacy.org/fedora/3/updates/x86_64/kdelibs-3.4.2-1.fc3.1.legacy.x86_64.rpm Trying to update (yum) the kdelibs and kdelibs-devel rpms fails on a AMD64 FC3 legacy system because all the other kde packages appear to require kdebase-3.3.1-4.3.FC3. I can't see anyone else reporting this problem in the archives of this list, so I am mystified. I suspect that I can force the upgrade without breaking anything by a manual "rpm -Fhv --nodeps ...", but I shouldn't need to do this, should I? ael ----------------------------------------------------------------- Snippets from failed yum update:- Dependencies Resolved Transaction Listing: Update: kdelibs.i386 6:3.4.2-1.fc3.1.legacy - updates Update: kdelibs.x86_64 6:3.4.2-1.fc3.1.legacy - updates Update: kdelibs-devel.x86_64 6:3.4.2-1.fc3.1.legacy - updates Total download size: 54 M Is this ok [y/N]: y Downloading Packages: Running Transaction Test Finished Transaction Test Transaction Check Error: file /usr/bin/kcmshell from install of kdelibs-3.4.2-1.fc3.1.legacy conflicts with file from package kdebase-3.3.1-4.3.FC3 file /usr/lib/kde3/kcmshell.la from install of kdelibs-3.4.2-1.fc3.1.legacy conflicts with file from package kdebase-3.3.1-4.3.FC3 ... file /usr/share/apps/kstyle/themes/plastik.themerc from install of kdelibs-3.4.2-1.fc3.1.legacy conflicts with file from package kdeartwork-3.3.1-1 ----------------------------------------------------------------------------- From agibson at ptm.com Wed Mar 22 20:42:47 2006 From: agibson at ptm.com (Adam Gibson) Date: Wed, 22 Mar 2006 15:42:47 -0500 Subject: Security issue with sendmail < 8.13.6 (released today) Message-ID: <4421B6C7.5030200@ptm.com> http://www.sendmail.com/company/advisory/index.shtml "Sendmail, Inc. has recently become aware of a security vulnerability in certain versions of sendmail Mail Transfer Agent (MTA) and UNIX and Linux products that contain it. Sendmail was notified by security researchers at ISS that, under some specific timing conditions, this vulnerability may permit a specifically crafted attack to take over the sendmail MTA process, allowing remote attackers to execute commands and run arbitrary programs on the system running the MTA, affecting email delivery, or tampering with other programs and data on this system." From hholzer at may.co.at Wed Mar 22 21:36:34 2006 From: hholzer at may.co.at (Harald Holzer) Date: Wed, 22 Mar 2006 22:36:34 +0100 (CET) Subject: squid problems on fc1 since last update ? Message-ID: <54334.62.40.166.69.1143063394.squirrel@62.40.166.69> can someone else confirm that the new squid rpm has some problems ? (squid-2.5.STABLE3-2.fc1.6.legacy) i have to sites, where squid randomly quits, and one where the access to some urls isnt possible. all problems are solved with downgrading to "squid-2.5.STABLE3-2.fc1". From nils at lemonbit.nl Wed Mar 22 21:50:53 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Wed, 22 Mar 2006 22:50:53 +0100 Subject: 1-2-3 out, time for FC2? In-Reply-To: <4421891D.6020803@sbcglobal.net> References: <9CD490EAC0F62A40A780878421D4A730DE07@amun.home.maner.org> <44204110.40309@sbcglobal.net> <54582786-7C0D-45EE-9EF9-0F891E397DFD@lemonbit.nl> <200603220049.50312.cave.dnb@tiscali.fr> <4FE6F39D-666C-4778-AB8E-CE23834B5C95@lemonbit.nl> <442151A8.6050108@beta.intcomgrp.com> <3D8D2002-844C-4FDC-8502-A9942DD4F632@lemonbit.nl> <4421891D.6020803@sbcglobal.net> Message-ID: <0734BF4C-31FE-4EA4-A8DC-F568082FA601@lemonbit.nl> Mike McCarty wrote: >> just think it would be interesting (for Fedora Legacy) to have >> some sort of idea of why people are running legacy versions of >> Red Hat and Fedora, so FL knows 'who they are doing it for'. My >> guess is that it's > > Oh, idle curiosity. Why would the people at FL be interested in any > particular user's motivation? Not any particular user's motivation, but the main motivations would be interesting I think. Well, I don't know if the FL developers care, but personally I think it would be interesting. Nils. From jkeating at j2solutions.net Wed Mar 22 22:43:08 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 22 Mar 2006 14:43:08 -0800 Subject: US-CERT Technical Cyber Security Alert TA06-081A -- Sendmail Race Condition Vulnerability (fwd) In-Reply-To: <38B44F665F3F012CD404C402@[10.169.6.226]> References: <38B44F665F3F012CD404C402@[10.169.6.226]> Message-ID: <200603221443.08373.jkeating@j2solutions.net> On Wednesday 22 March 2006 10:29, Kenneth Porter wrote: > For those of us accepting mail from outside on pre-FC4 Fedora, are any > updates in the pipe to address this? We are working on some fixed packages. -- 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: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From nils at lemonbit.nl Wed Mar 22 23:09:10 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Thu, 23 Mar 2006 00:09:10 +0100 Subject: Fedora Legacy Update : kdelibs dependency problems In-Reply-To: <44219D4B.9090408@lboro.ac.uk> References: <44219D4B.9090408@lboro.ac.uk> Message-ID: <3B4047C1-4271-4C18-AF36-650795DBDE94@lemonbit.nl> A E Lawrence wrote: > Trying to update (yum) the kdelibs and kdelibs-devel rpms fails on > a AMD64 FC3 legacy system because all the other kde packages appear > to require kdebase-3.3.1-4.3.FC3. > > I can't see anyone else reporting this problem in the archives of > this list, so I am mystified. I suspect that I can force the > upgrade without breaking anything by a manual "rpm -Fhv -- > nodeps ...", but I shouldn't need to do this, should I? -F doesn't do a forced install, it is the 'freshen' option (only updates packages if they're already installed). It looks like the packaging is a bit funky. A file that is part of kdebase-3.3.1 is now found in kdelibs-3.4.2 and a file that was in kdeartwork is now found in kdelibs. It looks to me the old layout was correct and the new kdelibs incorporates files it shouldn't. Note: I don't run 64 bit Fedora and I don't use KDE either. Nils. From michal at harddata.com Wed Mar 22 23:21:38 2006 From: michal at harddata.com (Michal Jaegermann) Date: Wed, 22 Mar 2006 16:21:38 -0700 Subject: Fedora Legacy Update : kdelibs dependency problems In-Reply-To: <44219D4B.9090408@lboro.ac.uk> References: <44219D4B.9090408@lboro.ac.uk> Message-ID: <20060322232138.GA12446@mail.harddata.com> On Wed, Mar 22, 2006 at 06:54:03PM +0000, A E Lawrence wrote: > > Synopsis: Updated kdelibs packages fix security issues > > Advisory ID: FLSA:178606 > > download.fedoralegacy.org/fedora/3/updates/x86_64/kdelibs-3.4.2-1.fc3.1.legacy.x86_64.rpm > > Trying to update (yum) the kdelibs and kdelibs-devel rpms fails on a > AMD64 FC3 legacy system because all the other kde packages appear to > require kdebase-3.3.1-4.3.FC3. There is something not kosher with your system as in August 2005 there was an FC3 update of various things KDE and this included kdelibs-3.4.2-0.fc3.2; on x86_64 too. > I suspect that I can force the upgrade without > breaking anything by a manual "rpm -Fhv --nodeps ...", Don't do that. Quite likely something will break. I guess that you should first run all available updates from "pre-legacy" servers and only after that apply what was provided later. There is an assumption here that all earlier updates were already applied. Michal From smooge at gmail.com Wed Mar 22 23:37:16 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Wed, 22 Mar 2006 16:37:16 -0700 Subject: US-CERT Technical Cyber Security Alert TA06-081A -- Sendmail Race Condition Vulnerability (fwd) In-Reply-To: <38B44F665F3F012CD404C402@10.169.6.226> References: <38B44F665F3F012CD404C402@10.169.6.226> Message-ID: <80d7e4090603221537s44874a3j41831d4ab18ac228@mail.gmail.com> On 3/22/06, Kenneth Porter wrote: > Main alert page: > > Fedora details: > > >From the summary: > > A race condition in Sendmail may allow a remote attacker to execute > arbitrary code. > > For those of us accepting mail from outside on pre-FC4 Fedora, are any > updates in the pipe to address this? > The patches are being looked at and evaluated. > -- > 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 sheltren at cs.ucsb.edu Wed Mar 22 23:40:30 2006 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Wed, 22 Mar 2006 19:40:30 -0400 Subject: US-CERT Technical Cyber Security Alert TA06-081A -- Sendmail Race Condition Vulnerability (fwd) In-Reply-To: <38B44F665F3F012CD404C402@[10.169.6.226]> References: <38B44F665F3F012CD404C402@[10.169.6.226]> Message-ID: On Mar 22, 2006, at 2:29 PM, Kenneth Porter wrote: > Main alert page: > > Fedora details: > >> From the summary: > > A race condition in Sendmail may allow a remote attacker to execute > arbitrary code. > > For those of us accepting mail from outside on pre-FC4 Fedora, are > any updates in the pipe to address this? > Hi, yes, Jesse is working on updated packages right now. If you're interested, the bugzilla ticket is here: https://bugzilla.redhat.com/ bugzilla/show_bug.cgi?id=186277 -Jeff From michal at harddata.com Wed Mar 22 23:47:27 2006 From: michal at harddata.com (Michal Jaegermann) Date: Wed, 22 Mar 2006 16:47:27 -0700 Subject: US-CERT Technical Cyber Security Alert TA06-081A -- Sendmail Race Condition Vulnerability (fwd) In-Reply-To: <38B44F665F3F012CD404C402@[10.169.6.226]> References: <38B44F665F3F012CD404C402@[10.169.6.226]> Message-ID: <20060322234727.GA12997@mail.harddata.com> On Wed, Mar 22, 2006 at 10:29:27AM -0800, Kenneth Porter wrote: > Main alert page: > > Fedora details: > > >From the summary: > > A race condition in Sendmail may allow a remote attacker to execute > arbitrary code. > > For those of us accepting mail from outside on pre-FC4 Fedora, are any > updates in the pipe to address this? It sounds like this is an issue with some urgency. FC3 is using sendmail-8.13.1-2 and a patch sendmail-8.13.1-VU#834865.patch, which you can find in sendmail-8.13.1-3.RHEL4.3.src.rpm, applies to this source without any modificiations. Not a very big surprise. So it is enough to rebuild a corresponding rpm with this patch and you should be fine. How this works for earlier versions I do not know. There is also sendmail-8.12.11-4.RHEL3.4.src.rpm in RHEL updates and it should be possible to "recycle" that patch as well. Michal From pekkas at netcore.fi Thu Mar 23 00:34:12 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 23 Mar 2006 02:34:12 +0200 (EET) Subject: sendmail remote vulnerability Message-ID: Hi, I hope FL core has had preliminary warning of the just-released sendmail remote vulnerability.... and if something has already been done about it, even better.. -- 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 tseaver at palladion.com Thu Mar 23 01:30:17 2006 From: tseaver at palladion.com (Tres Seaver) Date: Wed, 22 Mar 2006 20:30:17 -0500 Subject: US-CERT Technical Cyber Security Alert TA06-081A -- Sendmail Race Condition Vulnerability (fwd) In-Reply-To: <38B44F665F3F012CD404C402@[10.169.6.226]> References: <38B44F665F3F012CD404C402@[10.169.6.226]> Message-ID: <4421FA29.7010902@palladion.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kenneth Porter wrote: > Main alert page: > > Fedora details: > >> From the summary: > > > A race condition in Sendmail may allow a remote attacker to execute > arbitrary code. > > For those of us accepting mail from outside on pre-FC4 Fedora, are any > updates in the pipe to address this? How about this: $ sudo yum install postfix 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 iD8DBQFEIfop+gerLs4ltQ4RAnY5AKC1fekZzdc1duYWXol7zcXcOYozowCdG9NV LCrFO0RAZHHwByoTABf29qQ= =75OE -----END PGP SIGNATURE----- From deisenst at gtw.net Thu Mar 23 01:37:17 2006 From: deisenst at gtw.net (David Eisenstein) Date: Wed, 22 Mar 2006 19:37:17 -0600 Subject: Fedora Legacy Update : kdelibs dependency problems In-Reply-To: <44219D4B.9090408@lboro.ac.uk> References: <44219D4B.9090408@lboro.ac.uk> Message-ID: <4421FBCD.9070302@gtw.net> A E Lawrence wrote: >> Synopsis: Updated kdelibs packages fix security issues >> Advisory ID: FLSA:178606 > > download.fedoralegacy.org/fedora/3/updates/x86_64/kdelibs-3.4.2-1.fc3.1.legacy.x86_64.rpm > > > Trying to update (yum) the kdelibs and kdelibs-devel rpms fails on a > AMD64 FC3 legacy system because all the other kde packages appear to > require kdebase-3.3.1-4.3.FC3. > > I can't see anyone else reporting this problem in the archives of this > list, so I am mystified. I suspect that I can force the upgrade without > breaking anything by a manual "rpm -Fhv --nodeps ...", but I shouldn't > need to do this, should I? > > ael > > ----------------------------------------------------------------- > Snippets from failed yum update:- > > Dependencies Resolved > Transaction Listing: > Update: kdelibs.i386 6:3.4.2-1.fc3.1.legacy - updates > Update: kdelibs.x86_64 6:3.4.2-1.fc3.1.legacy - updates > Update: kdelibs-devel.x86_64 6:3.4.2-1.fc3.1.legacy - updates > Total download size: 54 M > Is this ok [y/N]: y > Downloading Packages: > Running Transaction Test > Finished Transaction Test > Transaction Check Error: file /usr/bin/kcmshell from install of > kdelibs-3.4.2-1.fc3.1.legacy conflicts with file from package > kdebase-3.3.1-4.3.FC3 > file /usr/lib/kde3/kcmshell.la from install of > kdelibs-3.4.2-1.fc3.1.legacy conflicts with file from package > kdebase-3.3.1-4.3.FC3 > ... > file /usr/share/apps/kstyle/themes/plastik.themerc from install of > kdelibs-3.4.2-1.fc3.1.legacy conflicts with file from package > kdeartwork-3.3.1-1 > ----------------------------------------------------------------------------- This is strange. The latest version of KDE for FC3 in updates is 3.4.2. Yum is supposed to take care of figuring out all of the dependencies, so I would have thought that it would also have downloaded the other kde___-3.4.2 packages as well, instead of giving you this error. What version of yum do you have installed? What does your yum.conf look like? What was the command you gave on the command line to update kdelibs? What happens when you do '# yum check-update'? As a workaround, you might try this: # yum update `rpm -qa kde* --qf '%{name} '` and see if that works for you. From tseaver at palladion.com Thu Mar 23 01:30:17 2006 From: tseaver at palladion.com (Tres Seaver) Date: Wed, 22 Mar 2006 20:30:17 -0500 Subject: US-CERT Technical Cyber Security Alert TA06-081A -- Sendmail Race Condition Vulnerability (fwd) In-Reply-To: <38B44F665F3F012CD404C402@[10.169.6.226]> References: <38B44F665F3F012CD404C402@[10.169.6.226]> Message-ID: <4421FA29.7010902@palladion.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kenneth Porter wrote: > Main alert page: > > Fedora details: > >> From the summary: > > > A race condition in Sendmail may allow a remote attacker to execute > arbitrary code. > > For those of us accepting mail from outside on pre-FC4 Fedora, are any > updates in the pipe to address this? How about this: $ sudo yum install postfix 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 iD8DBQFEIfop+gerLs4ltQ4RAnY5AKC1fekZzdc1duYWXol7zcXcOYozowCdG9NV LCrFO0RAZHHwByoTABf29qQ= =75OE -----END PGP SIGNATURE----- From rostetter at mail.utexas.edu Thu Mar 23 01:44:48 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 22 Mar 2006 19:44:48 -0600 Subject: 1-2-3 out, time for FC2? In-Reply-To: <3D8D2002-844C-4FDC-8502-A9942DD4F632@lemonbit.nl> References: <9CD490EAC0F62A40A780878421D4A730DE07@amun.home.maner.org> <44204110.40309@sbcglobal.net> <54582786-7C0D-45EE-9EF9-0F891E397DFD@lemonbit.nl> <200603220049.50312.cave.dnb@tiscali.fr> <4FE6F39D-666C-4778-AB8E-CE23834B5C95@lemonbit.nl> <442151A8.6050108@beta.intcomgrp.com> <3D8D2002-844C-4FDC-8502-A9942DD4F632@lemonbit.nl> Message-ID: <20060322194448.c6ei6wnk4fwc8kw8@mail.ph.utexas.edu> Quoting "Nils Breunese (Lemonbit Internet)" : > I just think it would be interesting (for Fedora Legacy) to have some > sort of idea of why people are running legacy versions of Red Hat and > Fedora, so FL knows 'who they are doing it for'. I'm doing it for the classic reason: I can't upgrade my servers just anytime; I need to upgrade them on a strict schedule. In other words, I have "windows of opportunity" within which to upgrade. As you might guess, the upgrade schedule for FC releases does not usually match my windows of opportunity... So I need something to keep my going for up to a year, until I can upgrade the machines... > My guess is that it's > mostly people that have used Fedora Core for live servers that they > don't want to upgrade (people that maybe should've gotten another > distro, in my opinion) and there's people like James Kosin that won't > upgrade because of things like driver/kernel issues. Very rarely I hit a driver issue or other issue. But mostly it is a matter of timing and available time. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From michal at harddata.com Thu Mar 23 01:46:53 2006 From: michal at harddata.com (Michal Jaegermann) Date: Wed, 22 Mar 2006 18:46:53 -0700 Subject: US-CERT Technical Cyber Security Alert TA06-081A -- Sendmail Race Condition Vulnerability (fwd) In-Reply-To: <38B44F665F3F012CD404C402@[10.169.6.226]> References: <38B44F665F3F012CD404C402@[10.169.6.226]> Message-ID: <20060323014653.GB4994@mail.harddata.com> On Wed, Mar 22, 2006 at 10:29:27AM -0800, Kenneth Porter wrote: > > For those of us accepting mail from outside on pre-FC4 Fedora, are any > updates in the pipe to address this? I should add that in sendmail.org annoucement, http://lwn.net/Articles/176595/, there is the following: "However, note that those patches may not (cleanly) apply to versions other than 8.13.5 and 8.12.11, respectively. There are no patches for versions before 8.12 because those outdated versions use a different I/O layer and hence it would require a major effort to rewrite that layer." So, it is clear that those with older distros will have to do, if required, a sendmail version bump. If Sendmail, Inc. is refusing to patch that back then surely I am not going to try. I think that this seriously affects only RH7.3 but it is possible to reuse there sendmail-8.12.11-4.RHEL3.4 - likely with configuration changes in a spec file. Michal From marcdeslauriers at videotron.ca Thu Mar 23 05:22:49 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 23 Mar 2006 00:22:49 -0500 Subject: [FLEA-2006:173091-1] Updated glibc packages add daylight savings rule enhancements Message-ID: <442230A9.7050405@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated glibc packages add daylight savings rule enhancements Advisory ID: FLEA:173091-1 Issue date: 2006-03-23 Product: Red Hat Linux Keywords: Enhancement --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated glibc packages that add daylight savings rule enhancements for various countries are now available. The GNU libc packages (known as glibc) contain the standard C libraries used by applications. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 3. Problem description: This update adjusts timezone files for countries where daylight savings rules have recently changed or are going to change in the near future. Users in those countries should upgrade to these updated packages and rerun redhat-config-date to update the local timezone in /etc/localtime. 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=173091 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/glibc-2.2.5-44.legacy.8.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/glibc-2.2.5-44.legacy.8.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/glibc-2.2.5-44.legacy.8.i686.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/glibc-common-2.2.5-44.legacy.8.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/glibc-debug-2.2.5-44.legacy.8.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/glibc-debug-2.2.5-44.legacy.8.i686.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/glibc-debug-static-2.2.5-44.legacy.8.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/glibc-devel-2.2.5-44.legacy.8.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/glibc-profile-2.2.5-44.legacy.8.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/glibc-utils-2.2.5-44.legacy.8.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/nscd-2.2.5-44.legacy.8.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/glibc-2.3.2-27.9.7.4.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/glibc-2.3.2-27.9.7.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/glibc-2.3.2-27.9.7.4.legacy.i686.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/glibc-common-2.3.2-27.9.7.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/glibc-debug-2.3.2-27.9.7.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/glibc-devel-2.3.2-27.9.7.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/glibc-profile-2.3.2-27.9.7.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/glibc-utils-2.3.2-27.9.7.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/nptl-devel-2.3.2-27.9.7.4.legacy.i686.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/nscd-2.3.2-27.9.7.4.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 8977060010fc16bbaf2aba545c3b958e4a953ec8 redhat/7.3/updates/i386/glibc-2.2.5-44.legacy.8.i386.rpm 4e4fce10ff1cfbdda21dbd0ca19132ffa3b34a15 redhat/7.3/updates/i386/glibc-2.2.5-44.legacy.8.i686.rpm ccc856a5f596cffca0d76f124ffff2df7cecd413 redhat/7.3/updates/i386/glibc-common-2.2.5-44.legacy.8.i386.rpm f301116e857b0d3d63c39af5003dcbab897b4af2 redhat/7.3/updates/i386/glibc-debug-2.2.5-44.legacy.8.i386.rpm c7f784964cff0af15108e981fb0eed5f5b49b8b4 redhat/7.3/updates/i386/glibc-debug-2.2.5-44.legacy.8.i686.rpm 2f59c12525a171646595f56126f882a656107fb7 redhat/7.3/updates/i386/glibc-debug-static-2.2.5-44.legacy.8.i386.rpm fbc27b34ed90759a4a8572c11b714e42bd2e3bda redhat/7.3/updates/i386/glibc-devel-2.2.5-44.legacy.8.i386.rpm 1a53624c0e7ee609a57d60740769fcb8e661244f redhat/7.3/updates/i386/glibc-profile-2.2.5-44.legacy.8.i386.rpm f316b55111db5e4e6afb6e7defdf04b4a5505867 redhat/7.3/updates/i386/glibc-utils-2.2.5-44.legacy.8.i386.rpm 18bb566cbc5b0e8abb1f7d72db364601584efb92 redhat/7.3/updates/i386/nscd-2.2.5-44.legacy.8.i386.rpm 3e8f11366500b362ef7040173912e0f07607b51c redhat/7.3/updates/SRPMS/glibc-2.2.5-44.legacy.8.src.rpm 91117fc583591c8bcc04939cc2c02af012356fb3 redhat/9/updates/i386/glibc-2.3.2-27.9.7.4.legacy.i386.rpm 18a13ba104fd958e1abcbe42cdf2ae31c9b0cb30 redhat/9/updates/i386/glibc-2.3.2-27.9.7.4.legacy.i686.rpm cb5501a39b03cacda052757f8265bc6f02c92883 redhat/9/updates/i386/glibc-common-2.3.2-27.9.7.4.legacy.i386.rpm bbf1af111006a214efde3da5b734372ec98c75d9 redhat/9/updates/i386/glibc-debug-2.3.2-27.9.7.4.legacy.i386.rpm 753ea0d554610c4dd35cc54764def86269c2c148 redhat/9/updates/i386/glibc-devel-2.3.2-27.9.7.4.legacy.i386.rpm 1ccda9c9ca1b424d5714016fad7b49280d981e3a redhat/9/updates/i386/glibc-profile-2.3.2-27.9.7.4.legacy.i386.rpm 112788df6619fb9fc39282ab0eeaf7718d34f8b5 redhat/9/updates/i386/glibc-utils-2.3.2-27.9.7.4.legacy.i386.rpm 6a8728560054bce9a0e4ddc8de897085fa54a8c6 redhat/9/updates/i386/nscd-2.3.2-27.9.7.4.legacy.i386.rpm 326be845c248a3d35e66550b54fbcd3a9556cae7 redhat/9/updates/i386/nptl-devel-2.3.2-27.9.7.4.legacy.i686.rpm 1cdcc8fa2428568fb571a6428b80217c17ec8183 redhat/9/updates/SRPMS/glibc-2.3.2-27.9.7.4.legacy.src.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Thu Mar 23 05:23:25 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 23 Mar 2006 00:23:25 -0500 Subject: [FLEA-2006:173091-2] Updated tzdata package adds daylight savings rule enhancements Message-ID: <442230CD.7090508@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated tzdata package adds daylight savings rule enhancements Advisory ID: FLEA:173091-2 Issue date: 2006-03-23 Product: Fedora Core Keywords: Enhancement --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: An updated tzdata package that adds daylight savings rule enhancements for various countries is now available. The tzdata package contains data files with rules for various timezones around the world. 2. Relevant releases/architectures: Fedora Core 1 - i386 Fedora Core 2 - i386 Fedora Core 3 - i386, x86_64 3. Problem description: This update adjusts timezone files for countries where daylight savings rules have recently changed or are going to change in the near future. Users in those countries should upgrade to these updated packages and rerun redhat-config-date (or system-config-date in FC2) to update the local timezone in /etc/localtime. 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=173091 6. RPMs required: Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/tzdata-2006a-2.fc1.1.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/tzdata-2006a-2.fc1.1.noarch.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/tzdata-2006a-2.fc2.1.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/tzdata-2006a-2.fc2.1.noarch.rpm Fedora Core 3: SRPM: http://download.fedoralegacy.org/fedora/3/updates/SRPMS/tzdata-2006a-2.fc3.1.src.rpm i386: http://download.fedoralegacy.org/fedora/3/updates/i386/tzdata-2006a-2.fc3.1.noarch.rpm x86_64: http://download.fedoralegacy.org/fedora/3/updates/x86_64/tzdata-2006a-2.fc3.1.noarch.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- e2ded77aca0a2b9f5dfb2ace0344ee59634f5776 fedora/1/updates/i386/tzdata-2006a-2.fc1.1.noarch.rpm 303892ebacb9b1f35612d7dade0cbb52c6c5cc3a fedora/1/updates/SRPMS/tzdata-2006a-2.fc1.1.src.rpm fcb96a5975ffe9e1b1acb183a97b6bb19ec51d51 fedora/2/updates/i386/tzdata-2006a-2.fc2.1.noarch.rpm 61e89be1e7373113c80f5fcda11a75a278f9b3ab fedora/2/updates/SRPMS/tzdata-2006a-2.fc2.1.src.rpm e8781a60ab8686bd4e1af2a70e233b292d41625a fedora/3/updates/i386/tzdata-2006a-2.fc3.1.noarch.rpm e8781a60ab8686bd4e1af2a70e233b292d41625a fedora/3/updates/x86_64/tzdata-2006a-2.fc3.1.noarch.rpm ad359bb43953718456cb876f6f06cf3eab08b69a fedora/3/updates/SRPMS/tzdata-2006a-2.fc3.1.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. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From jkeating at j2solutions.net Thu Mar 23 07:50:47 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 22 Mar 2006 23:50:47 -0800 Subject: Fedora Legacy Test Update Notification: sendmail Message-ID: <200603222350.52013.jkeating@j2solutions.net> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-186277 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186277 2006-03-22 --------------------------------------------------------------------- Name : sendmail Versions : rh73: sendmail-8.12.11-4.22.9.legacy Versions : rh9: sendmail-8.12.11-4.24.1.legacy Versions : fc1: sendmail-8.12.11-4.25.1.legacy Versions : fc2: sendmail-8.12.11-4.26.legacy Versions : fc3: sendmail-8.13.1-3.legacy Summary : A widely used Mail Transport Agent (MTA). Description : The Sendmail program is a very widely used Mail Transport Agent (MTA). MTAs send mail from one machine to another. Sendmail is not a client program, which you use to read your email. Sendmail is a behind-the-scenes program which actually moves your email over networks or the Internet to where you want it to go. If you ever need to reconfigure Sendmail, you will also need to have the sendmail.cf package installed. If you need documentation on Sendmail, you can install the sendmail-doc package. --------------------------------------------------------------------- Update Information: An updated tar package that fixes a flaw in the handling of asynchronous signals. A flaw in the handling of asynchronous signals was discovered in Sendmail. A remote attacker may be able to exploit a race condition to execute arbitrary code as root. The Common Vulnerabilities and Exposures project assigned the name CVE-2006-0058 to this issue. By default on Red Hat Enterprise Linux 2.1 and later, Sendmail is configured to only accept connections from the local host. Therefore only users who have configured Sendmail to listen to remote hosts would be able to be remotely exploited by this vulnerability. In order to correct this issue for RHL 7.3 users, it was necessary to upgrade the version of Sendmail from 8.11 as originally shipped to Sendmail 8.12.11 with the addition of the security patch supplied by Sendmail Inc. This erratum provides updated packages based on Sendmail 8.12 with a compatibility mode enabled as provided by Red Hat for RHEL 2.1. After updating to these packages, users should pay close attention to their sendmail logs to ensure that the upgrade completed sucessfully. In order to correct this issue for RHL 9 and FC1 users, it was necessary to upgrade the version of Sendmail from 8.12.8 and 8.12.10 respectively to 8.12.11 with the addition of the security patch supplied by Sendmail Inc. After updating to these packages, users should pay close attention to their sendmail logs to ensure that the upgrade completed sucessfully. For Fedora Core 3 users, the patch supplied by Sendmail Inc. applies cleanly to the latest sendmail package previously released for Fedora Core 3. Users of Sendmail should upgrade to this updated package, which contains a replacement backported patch to correct this issue. --------------------------------------------------------------------- Changelogs rh73: * Wed Mar 22 2006 Jesse Keating 8.12.11-4.22.9.legacy - Sourced in for RHL7.3 - Added groff buildreq rh9: * Wed Mar 22 2006 Jesse Keating - 8.12.11-4.24.1.legacy - fixed VU#834865 (#186277) - disable -fpie - enable old_setup - Add BuildReq gdbm-devel - Use sasl1 fc1: * Wed Mar 22 2006 Jesse Keating - 8.12.11-4.25.1.legacy - fixed VU#834865 (#186277) - enable old_setup fc2: * Wed Mar 22 2006 Jesse Keating - 8.12.11-4.26.legacy - fixed VU#834865 (#186277) fc3: * Wed Mar 22 2006 Jesse Keating 8.13.1-3.legacy - fixed VU#834865 (#186277) --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: d9c001d8a34f11f528ff6be2a9f8dd15818caf40 redhat/7.3/updates-testing/SRPMS/sendmail-8.12.11-4.22.9.legacy.src.rpm 80f02c886b020e6d6ef17389c22c8b530fb05a48 redhat/7.3/updates-testing/i386/sendmail-8.12.11-4.22.9.legacy.i386.rpm 285816881a55fe4b8a74fee48205c8ceedaee5e5 redhat/7.3/updates-testing/i386/sendmail-cf-8.12.11-4.22.9.legacy.i386.rpm b4154a342e7747d980b7acaf352649ddc1dcc40d redhat/7.3/updates-testing/i386/sendmail-devel-8.12.11-4.22.9.legacy.i386.rpm 81a36048a12cc5c08a8e93490dde6817c402ae54 redhat/7.3/updates-testing/i386/sendmail-doc-8.12.11-4.22.9.legacy.i386.rpm rh9: 272bbff91a52692991f6f0fd434a27fda1c92057 redhat/9/updates-testing/SRPMS/sendmail-8.12.11-4.24.1.legacy.src.rpm 683d48df1c5aabb1e9768d4bfb37036d0d7ff7c6 redhat/9/updates-testing/i386/sendmail-8.12.11-4.24.1.legacy.i386.rpm a6e967294f6cbe9f623e5626e20e33fbbc410f68 redhat/9/updates-testing/i386/sendmail-cf-8.12.11-4.24.1.legacy.i386.rpm da996e582bb27144c7c26050e0ba51ce7cb727d7 redhat/9/updates-testing/i386/sendmail-devel-8.12.11-4.24.1.legacy.i386.rpm 8d03dc1dd178543cb9d9050198774b599967bfcd redhat/9/updates-testing/i386/sendmail-doc-8.12.11-4.24.1.legacy.i386.rpm fc1: c33698f4e499d477d9712de3d6061825348a294f fedora/1/updates-testing/SRPMS/sendmail-8.12.11-4.25.1.legacy.src.rpm df880ab03eaeb2f82be81bee96c28392984a4b86 fedora/1/updates-testing/i386/sendmail-8.12.11-4.25.1.legacy.i386.rpm 729bcaeb1269b65728f014bbbedb5c1a54a5158e fedora/1/updates-testing/i386/sendmail-cf-8.12.11-4.25.1.legacy.i386.rpm 256ff91b67ecc7680a5f2fb97b3b32142bb80d18 fedora/1/updates-testing/i386/sendmail-devel-8.12.11-4.25.1.legacy.i386.rpm 65725c811c4c7eede9f88c006a13c15e458d353f fedora/1/updates-testing/i386/sendmail-doc-8.12.11-4.25.1.legacy.i386.rpm fc2: 65086d18cb29e02b57ce07b6abf79ba378ae1c3c fedora/2/updates-testing/SRPMS/sendmail-8.12.11-4.26.legacy.src.rpm 7e44b02696338832e2dfc0057aeb58c98511d0d2 fedora/2/updates-testing/i386/sendmail-8.12.11-4.26.legacy.i386.rpm d159f0c92bd530799b75341d18b5b2cbe5aa5a0a fedora/2/updates-testing/i386/sendmail-cf-8.12.11-4.26.legacy.i386.rpm 8421bfb2eb2f2b3fddb35e905fdcfecd0fb8088c fedora/2/updates-testing/i386/sendmail-devel-8.12.11-4.26.legacy.i386.rpm b659d2733afa3d6f4df840a395c6eae3a5c07d50 fedora/2/updates-testing/i386/sendmail-doc-8.12.11-4.26.legacy.i386.rpm fc3: fbfba64eac81e57ae098f967b7d3bf4e47e04c87 fedora/3/updates-testing/SRPMS/sendmail-8.13.1-3.legacy.src.rpm 6cc0f44ad32c0eb62801331bf8bfa41625b61031 fedora/3/updates-testing/i386/sendmail-8.13.1-3.legacy.i386.rpm 04bd02d3f731eb985d6e8b9fde7ee3ddc5bdccfe fedora/3/updates-testing/i386/sendmail-cf-8.13.1-3.legacy.i386.rpm 97f173fa48f847feb5051bc2cb4686f53e3895ac fedora/3/updates-testing/i386/sendmail-devel-8.13.1-3.legacy.i386.rpm 298c0908052efdbc671dda1f22f025f96a10d770 fedora/3/updates-testing/i386/sendmail-doc-8.13.1-3.legacy.i386.rpm 162a1e21ac33e5a9072f7cb9934d17523d8160f6 fedora/3/updates-testing/x86_64/sendmail-8.13.1-3.legacy.x86_64.rpm 939de41400340905ec0b378b501e5d1b8b41e545 fedora/3/updates-testing/x86_64/sendmail-cf-8.13.1-3.legacy.x86_64.rpm c09947143c351f575737036599c23c542404d82e fedora/3/updates-testing/x86_64/sendmail-devel-8.13.1-3.legacy.x86_64.rpm bd1b9553b49e5c2631a40f68461472b1671f9beb fedora/3/updates-testing/x86_64/sendmail-doc-8.13.1-3.legacy.x86_64.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From marcdeslauriers at videotron.ca Thu Mar 23 05:13:27 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 23 Mar 2006 00:13:27 -0500 Subject: [FLEA-2006:173091-1] Updated glibc packages add daylight savings rule enhancements Message-ID: <44222E77.20900@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated glibc packages add daylight savings rule enhancements Advisory ID: FLEA:173091-1 Issue date: 2006-03-23 Product: Red Hat Linux Keywords: Enhancement --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated glibc packages that add daylight savings rule enhancements for various countries are now available. The GNU libc packages (known as glibc) contain the standard C libraries used by applications. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 3. Problem description: This update adjusts timezone files for countries where daylight savings rules have recently changed or are going to change in the near future. Users in those countries should upgrade to these updated packages and rerun redhat-config-date to update the local timezone in /etc/localtime. 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=173091 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/glibc-2.2.5-44.legacy.8.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/glibc-2.2.5-44.legacy.8.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/glibc-2.2.5-44.legacy.8.i686.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/glibc-common-2.2.5-44.legacy.8.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/glibc-debug-2.2.5-44.legacy.8.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/glibc-debug-2.2.5-44.legacy.8.i686.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/glibc-debug-static-2.2.5-44.legacy.8.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/glibc-devel-2.2.5-44.legacy.8.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/glibc-profile-2.2.5-44.legacy.8.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/glibc-utils-2.2.5-44.legacy.8.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/nscd-2.2.5-44.legacy.8.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/glibc-2.3.2-27.9.7.4.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/glibc-2.3.2-27.9.7.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/glibc-2.3.2-27.9.7.4.legacy.i686.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/glibc-common-2.3.2-27.9.7.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/glibc-debug-2.3.2-27.9.7.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/glibc-devel-2.3.2-27.9.7.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/glibc-profile-2.3.2-27.9.7.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/glibc-utils-2.3.2-27.9.7.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/nptl-devel-2.3.2-27.9.7.4.legacy.i686.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/nscd-2.3.2-27.9.7.4.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 8977060010fc16bbaf2aba545c3b958e4a953ec8 redhat/7.3/updates/i386/glibc-2.2.5-44.legacy.8.i386.rpm 4e4fce10ff1cfbdda21dbd0ca19132ffa3b34a15 redhat/7.3/updates/i386/glibc-2.2.5-44.legacy.8.i686.rpm ccc856a5f596cffca0d76f124ffff2df7cecd413 redhat/7.3/updates/i386/glibc-common-2.2.5-44.legacy.8.i386.rpm f301116e857b0d3d63c39af5003dcbab897b4af2 redhat/7.3/updates/i386/glibc-debug-2.2.5-44.legacy.8.i386.rpm c7f784964cff0af15108e981fb0eed5f5b49b8b4 redhat/7.3/updates/i386/glibc-debug-2.2.5-44.legacy.8.i686.rpm 2f59c12525a171646595f56126f882a656107fb7 redhat/7.3/updates/i386/glibc-debug-static-2.2.5-44.legacy.8.i386.rpm fbc27b34ed90759a4a8572c11b714e42bd2e3bda redhat/7.3/updates/i386/glibc-devel-2.2.5-44.legacy.8.i386.rpm 1a53624c0e7ee609a57d60740769fcb8e661244f redhat/7.3/updates/i386/glibc-profile-2.2.5-44.legacy.8.i386.rpm f316b55111db5e4e6afb6e7defdf04b4a5505867 redhat/7.3/updates/i386/glibc-utils-2.2.5-44.legacy.8.i386.rpm 18bb566cbc5b0e8abb1f7d72db364601584efb92 redhat/7.3/updates/i386/nscd-2.2.5-44.legacy.8.i386.rpm 3e8f11366500b362ef7040173912e0f07607b51c redhat/7.3/updates/SRPMS/glibc-2.2.5-44.legacy.8.src.rpm 91117fc583591c8bcc04939cc2c02af012356fb3 redhat/9/updates/i386/glibc-2.3.2-27.9.7.4.legacy.i386.rpm 18a13ba104fd958e1abcbe42cdf2ae31c9b0cb30 redhat/9/updates/i386/glibc-2.3.2-27.9.7.4.legacy.i686.rpm cb5501a39b03cacda052757f8265bc6f02c92883 redhat/9/updates/i386/glibc-common-2.3.2-27.9.7.4.legacy.i386.rpm bbf1af111006a214efde3da5b734372ec98c75d9 redhat/9/updates/i386/glibc-debug-2.3.2-27.9.7.4.legacy.i386.rpm 753ea0d554610c4dd35cc54764def86269c2c148 redhat/9/updates/i386/glibc-devel-2.3.2-27.9.7.4.legacy.i386.rpm 1ccda9c9ca1b424d5714016fad7b49280d981e3a redhat/9/updates/i386/glibc-profile-2.3.2-27.9.7.4.legacy.i386.rpm 112788df6619fb9fc39282ab0eeaf7718d34f8b5 redhat/9/updates/i386/glibc-utils-2.3.2-27.9.7.4.legacy.i386.rpm 6a8728560054bce9a0e4ddc8de897085fa54a8c6 redhat/9/updates/i386/nscd-2.3.2-27.9.7.4.legacy.i386.rpm 326be845c248a3d35e66550b54fbcd3a9556cae7 redhat/9/updates/i386/nptl-devel-2.3.2-27.9.7.4.legacy.i686.rpm 1cdcc8fa2428568fb571a6428b80217c17ec8183 redhat/9/updates/SRPMS/glibc-2.3.2-27.9.7.4.legacy.src.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Thu Mar 23 05:14:26 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 23 Mar 2006 00:14:26 -0500 Subject: [FLEA-2006:173091-2] Updated tzdata package adds daylight savings rule enhancements Message-ID: <44222EB2.7040803@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated tzdata package adds daylight savings rule enhancements Advisory ID: FLEA:173091-2 Issue date: 2006-03-23 Product: Fedora Core Keywords: Enhancement --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: An updated tzdata package that adds daylight savings rule enhancements for various countries is now available. The tzdata package contains data files with rules for various timezones around the world. 2. Relevant releases/architectures: Fedora Core 1 - i386 Fedora Core 2 - i386 Fedora Core 3 - i386, x86_64 3. Problem description: This update adjusts timezone files for countries where daylight savings rules have recently changed or are going to change in the near future. Users in those countries should upgrade to these updated packages and rerun redhat-config-date (or system-config-date in FC2) to update the local timezone in /etc/localtime. 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=173091 6. RPMs required: Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/tzdata-2006a-2.fc1.1.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/tzdata-2006a-2.fc1.1.noarch.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/tzdata-2006a-2.fc2.1.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/tzdata-2006a-2.fc2.1.noarch.rpm Fedora Core 3: SRPM: http://download.fedoralegacy.org/fedora/3/updates/SRPMS/tzdata-2006a-2.fc3.1.src.rpm i386: http://download.fedoralegacy.org/fedora/3/updates/i386/tzdata-2006a-2.fc3.1.noarch.rpm x86_64: http://download.fedoralegacy.org/fedora/3/updates/x86_64/tzdata-2006a-2.fc3.1.noarch.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- e2ded77aca0a2b9f5dfb2ace0344ee59634f5776 fedora/1/updates/i386/tzdata-2006a-2.fc1.1.noarch.rpm 303892ebacb9b1f35612d7dade0cbb52c6c5cc3a fedora/1/updates/SRPMS/tzdata-2006a-2.fc1.1.src.rpm fcb96a5975ffe9e1b1acb183a97b6bb19ec51d51 fedora/2/updates/i386/tzdata-2006a-2.fc2.1.noarch.rpm 61e89be1e7373113c80f5fcda11a75a278f9b3ab fedora/2/updates/SRPMS/tzdata-2006a-2.fc2.1.src.rpm e8781a60ab8686bd4e1af2a70e233b292d41625a fedora/3/updates/i386/tzdata-2006a-2.fc3.1.noarch.rpm e8781a60ab8686bd4e1af2a70e233b292d41625a fedora/3/updates/x86_64/tzdata-2006a-2.fc3.1.noarch.rpm ad359bb43953718456cb876f6f06cf3eab08b69a fedora/3/updates/SRPMS/tzdata-2006a-2.fc3.1.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. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Thu Mar 23 12:10:01 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 23 Mar 2006 07:10:01 -0500 Subject: US-CERT Technical Cyber Security Alert TA06-081A -- Sendmail Race Condition Vulnerability (fwd) In-Reply-To: <38B44F665F3F012CD404C402@[10.169.6.226]> References: <38B44F665F3F012CD404C402@[10.169.6.226]> Message-ID: <1143115802.6809.1.camel@mdlinux> On Wed, 2006-03-22 at 10:29 -0800, Kenneth Porter wrote: > For those of us accepting mail from outside on pre-FC4 Fedora, are any > updates in the pipe to address this? Packages have been created and QA'd. They will be pushed to updates-testing soon. You may follow progress here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186277 Marc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From gerry at pathtech.org Thu Mar 23 12:33:15 2006 From: gerry at pathtech.org (G. Roderick Singleton) Date: Thu, 23 Mar 2006 07:33:15 -0500 Subject: US-CERT Technical Cyber Security Alert TA06-081A -- Sendmail Race Condition Vulnerability (fwd) In-Reply-To: <200603221443.08373.jkeating@j2solutions.net> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <200603221443.08373.jkeating@j2solutions.net> Message-ID: <1143117195.21738.160.camel@www.pathtech.org> On Wed, 2006-03-22 at 14:43 -0800, Jesse Keating wrote: > On Wednesday 22 March 2006 10:29, Kenneth Porter wrote: > > For those of us accepting mail from outside on pre-FC4 Fedora, are any > > updates in the pipe to address this? > > We are working on some fixed packages. > Patch? Why patch when one can build the new release using a spec file? It works for me. -- G. Roderick Singleton PATH tech -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 1956 bytes Desc: not available URL: From gene.heskett at verizon.net Thu Mar 23 12:37:15 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Thu, 23 Mar 2006 07:37:15 -0500 Subject: Question about yum.conf for fc2 Message-ID: <200603230737.15910.gene.heskett@verizon.net> Greetings; Yum is rather continuously erroring out on fedora extras, both branches recently. Do I need to edit that line and send it someplace else now? -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From agibson at ptm.com Thu Mar 23 15:02:14 2006 From: agibson at ptm.com (Adam Gibson) Date: Thu, 23 Mar 2006 10:02:14 -0500 Subject: My personal patch for sendmail 8.12.8 on RedHat 9 In-Reply-To: <4422B022.80808@ptm.com> References: <4422B022.80808@ptm.com> Message-ID: <4422B876.9080409@ptm.com> Adam Gibson wrote: ... > This has been working since yesterday around 4pm EST on a medium load > server without issues. > > The offical 8.12.11 patch which does not apply properly on 8.12.8 is on > the main sendmail.org site for reference. > > Anyone here any new news about an official legacy patch? Ignore this patch since legacy already has a test update available that upgrades sendmail to 8.12.11 (Much better solution instead of worrying about the ramifications of back-porting the changes). BTW... legacy email list takes 7+ hours for list emails to get to me so I didn't see the announcement before I sent my original email. I have noticed this for the past few days(before my patch :)... anyone else seeing a major lag in list emails? From shiva at sewingwitch.com Thu Mar 23 15:06:09 2006 From: shiva at sewingwitch.com (Kenneth Porter) Date: Thu, 23 Mar 2006 07:06:09 -0800 Subject: US-CERT Technical Cyber Security Alert TA06-081A -- Sendmail Race Condition Vulnerability (fwd) In-Reply-To: <20060323014653.GB4994@mail.harddata.com> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <20060323014653.GB4994@mail.harddata.com> Message-ID: <97931CA26513E52B677587E8@[10.0.0.14]> --On Wednesday, March 22, 2006 6:46 PM -0700 Michal Jaegermann wrote: > So, it is clear that those with older distros will have to do, if > required, a sendmail version bump. I don't mind pulling the latest rawhide version, if the dependencies aren't too bad. Has anyone built that on FC2? Did you run into any hard-to-satisfy dependencies, like selinux and udev? (I got stuck updating mailman due to that problem.) From jkeating at j2solutions.net Thu Mar 23 18:02:28 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 23 Mar 2006 10:02:28 -0800 Subject: US-CERT Technical Cyber Security Alert TA06-081A -- Sendmail Race Condition Vulnerability (fwd) In-Reply-To: <1143117195.21738.160.camel@www.pathtech.org> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <200603221443.08373.jkeating@j2solutions.net> <1143117195.21738.160.camel@www.pathtech.org> Message-ID: <1143136948.23491.29.camel@yoda.loki.me> On Thu, 2006-03-23 at 07:33 -0500, G. Roderick Singleton wrote: > Patch? Why patch when one can build the new release using a spec file? > It works for me. Because we want to impact how the system works as little as possible. Usually this means backporting patches into existing packages as to not change functionality. Unfortunately that wasn't possible with this release, so we had to use the RHEL2.1 packages, and modified FC2 packages. See the test announcement for details. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From skvidal at linux.duke.edu Thu Mar 23 19:00:03 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 23 Mar 2006 14:00:03 -0500 Subject: Question about yum.conf for fc2 In-Reply-To: <200603230737.15910.gene.heskett@verizon.net> References: <200603230737.15910.gene.heskett@verizon.net> Message-ID: <1143140403.32685.1.camel@cutter> On Thu, 2006-03-23 at 07:37 -0500, Gene Heskett wrote: > Greetings; > > Yum is rather continuously erroring out on fedora extras, both branches > recently. Do I need to edit that line and send it someplace else now? you need to tell us what the error is. -sv From gene.heskett at verizon.net Thu Mar 23 19:21:52 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Thu, 23 Mar 2006 14:21:52 -0500 Subject: Fedora Legacy Test Update Notification: sendmail In-Reply-To: <200603222350.52013.jkeating@j2solutions.net> References: <200603222350.52013.jkeating@j2solutions.net> Message-ID: <200603231421.52976.gene.heskett@verizon.net> On Thursday 23 March 2006 02:50, Jesse Keating wrote: >--------------------------------------------------------------------- >Fedora Legacy Test Update Notification >FEDORALEGACY-2006-186277 >Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186277 >2006-03-22 >--------------------------------------------------------------------- > >Name : sendmail >Versions : rh73: sendmail-8.12.11-4.22.9.legacy What line in the /etc/yum.conf on my rh7.3 firewall box do I need to access this fix, yum is telling me its installed and current. But rpm says its sendmail-8.11.6-27.73, a bit long in the tooth don't you think? >Versions : rh9: sendmail-8.12.11-4.24.1.legacy >Versions : fc1: sendmail-8.12.11-4.25.1.legacy >Versions : fc2: sendmail-8.12.11-4.26.legacy >Versions : fc3: sendmail-8.13.1-3.legacy >Summary : A widely used Mail Transport Agent (MTA). >Description : >The Sendmail program is a very widely used Mail Transport Agent (MTA). >MTAs send mail from one machine to another. Sendmail is not a client >program, which you use to read your email. Sendmail is a >behind-the-scenes program which actually moves your email over >networks or the Internet to where you want it to go. > >If you ever need to reconfigure Sendmail, you will also need to have >the sendmail.cf package installed. If you need documentation on >Sendmail, you can install the sendmail-doc package. > >--------------------------------------------------------------------- >Update Information: > >An updated tar package that fixes a flaw in the handling of > asynchronous signals. > >A flaw in the handling of asynchronous signals was discovered in > Sendmail. A remote attacker may be able to exploit a race condition > to execute arbitrary code as root. The Common Vulnerabilities and > Exposures project assigned the name CVE-2006-0058 to this issue. > >By default on Red Hat Enterprise Linux 2.1 and later, Sendmail is > configured to only accept connections from the local host. Therefore > only users who have configured Sendmail to listen to remote hosts > would be able to be remotely exploited by this vulnerability. > >In order to correct this issue for RHL 7.3 users, it was necessary to > upgrade the version of Sendmail from 8.11 as originally shipped to > Sendmail 8.12.11 with the addition of the security patch supplied by > Sendmail Inc. This erratum provides updated packages based on > Sendmail 8.12 with a compatibility mode enabled as provided by Red > Hat for RHEL 2.1. After updating to these packages, users should pay > close attention to their sendmail logs to ensure that the upgrade > completed sucessfully. > >In order to correct this issue for RHL 9 and FC1 users, it was > necessary to upgrade the version of Sendmail from 8.12.8 and 8.12.10 > respectively to 8.12.11 with the addition of the security patch > supplied by Sendmail Inc. After updating to these packages, users > should pay close attention to their sendmail logs to ensure that the > upgrade completed sucessfully. > >For Fedora Core 3 users, the patch supplied by Sendmail Inc. applies > cleanly to the latest sendmail package previously released for Fedora > Core 3. > >Users of Sendmail should upgrade to this updated package, which > contains a replacement backported patch to correct this issue. > >--------------------------------------------------------------------- >Changelogs > >rh73: >* Wed Mar 22 2006 Jesse Keating >8.12.11-4.22.9.legacy >- Sourced in for RHL7.3 >- Added groff buildreq > > >rh9: >* Wed Mar 22 2006 Jesse Keating - > 8.12.11-4.24.1.legacy - fixed VU#834865 (#186277) >- disable -fpie >- enable old_setup >- Add BuildReq gdbm-devel >- Use sasl1 > > >fc1: >* Wed Mar 22 2006 Jesse Keating - > 8.12.11-4.25.1.legacy - fixed VU#834865 (#186277) >- enable old_setup > >fc2: >* Wed Mar 22 2006 Jesse Keating - > 8.12.11-4.26.legacy - fixed VU#834865 (#186277) > >fc3: >* Wed Mar 22 2006 Jesse Keating > 8.13.1-3.legacy - fixed VU#834865 (#186277) > >--------------------------------------------------------------------- >This update can be downloaded from: > http://download.fedoralegacy.org/ >(sha1sums) > >rh73: >d9c001d8a34f11f528ff6be2a9f8dd15818caf40 >redhat/7.3/updates-testing/SRPMS/sendmail-8.12.11-4.22.9.legacy.src.rp >m 80f02c886b020e6d6ef17389c22c8b530fb05a48 >redhat/7.3/updates-testing/i386/sendmail-8.12.11-4.22.9.legacy.i386.rp >m 285816881a55fe4b8a74fee48205c8ceedaee5e5 >redhat/7.3/updates-testing/i386/sendmail-cf-8.12.11-4.22.9.legacy.i386 >.rpm b4154a342e7747d980b7acaf352649ddc1dcc40d >redhat/7.3/updates-testing/i386/sendmail-devel-8.12.11-4.22.9.legacy.i >386.rpm 81a36048a12cc5c08a8e93490dde6817c402ae54 >redhat/7.3/updates-testing/i386/sendmail-doc-8.12.11-4.22.9.legacy.i38 >6.rpm > > >rh9: >272bbff91a52692991f6f0fd434a27fda1c92057 >redhat/9/updates-testing/SRPMS/sendmail-8.12.11-4.24.1.legacy.src.rpm >683d48df1c5aabb1e9768d4bfb37036d0d7ff7c6 >redhat/9/updates-testing/i386/sendmail-8.12.11-4.24.1.legacy.i386.rpm >a6e967294f6cbe9f623e5626e20e33fbbc410f68 >redhat/9/updates-testing/i386/sendmail-cf-8.12.11-4.24.1.legacy.i386.r >pm da996e582bb27144c7c26050e0ba51ce7cb727d7 >redhat/9/updates-testing/i386/sendmail-devel-8.12.11-4.24.1.legacy.i38 >6.rpm 8d03dc1dd178543cb9d9050198774b599967bfcd >redhat/9/updates-testing/i386/sendmail-doc-8.12.11-4.24.1.legacy.i386. >rpm > > >fc1: >c33698f4e499d477d9712de3d6061825348a294f >fedora/1/updates-testing/SRPMS/sendmail-8.12.11-4.25.1.legacy.src.rpm >df880ab03eaeb2f82be81bee96c28392984a4b86 >fedora/1/updates-testing/i386/sendmail-8.12.11-4.25.1.legacy.i386.rpm >729bcaeb1269b65728f014bbbedb5c1a54a5158e >fedora/1/updates-testing/i386/sendmail-cf-8.12.11-4.25.1.legacy.i386.r >pm 256ff91b67ecc7680a5f2fb97b3b32142bb80d18 >fedora/1/updates-testing/i386/sendmail-devel-8.12.11-4.25.1.legacy.i38 >6.rpm 65725c811c4c7eede9f88c006a13c15e458d353f >fedora/1/updates-testing/i386/sendmail-doc-8.12.11-4.25.1.legacy.i386. >rpm > > >fc2: >65086d18cb29e02b57ce07b6abf79ba378ae1c3c >fedora/2/updates-testing/SRPMS/sendmail-8.12.11-4.26.legacy.src.rpm >7e44b02696338832e2dfc0057aeb58c98511d0d2 >fedora/2/updates-testing/i386/sendmail-8.12.11-4.26.legacy.i386.rpm >d159f0c92bd530799b75341d18b5b2cbe5aa5a0a >fedora/2/updates-testing/i386/sendmail-cf-8.12.11-4.26.legacy.i386.rpm >8421bfb2eb2f2b3fddb35e905fdcfecd0fb8088c >fedora/2/updates-testing/i386/sendmail-devel-8.12.11-4.26.legacy.i386. >rpm b659d2733afa3d6f4df840a395c6eae3a5c07d50 >fedora/2/updates-testing/i386/sendmail-doc-8.12.11-4.26.legacy.i386.rp >m > >fc3: >fbfba64eac81e57ae098f967b7d3bf4e47e04c87 >fedora/3/updates-testing/SRPMS/sendmail-8.13.1-3.legacy.src.rpm >6cc0f44ad32c0eb62801331bf8bfa41625b61031 >fedora/3/updates-testing/i386/sendmail-8.13.1-3.legacy.i386.rpm >04bd02d3f731eb985d6e8b9fde7ee3ddc5bdccfe >fedora/3/updates-testing/i386/sendmail-cf-8.13.1-3.legacy.i386.rpm >97f173fa48f847feb5051bc2cb4686f53e3895ac >fedora/3/updates-testing/i386/sendmail-devel-8.13.1-3.legacy.i386.rpm >298c0908052efdbc671dda1f22f025f96a10d770 >fedora/3/updates-testing/i386/sendmail-doc-8.13.1-3.legacy.i386.rpm >162a1e21ac33e5a9072f7cb9934d17523d8160f6 >fedora/3/updates-testing/x86_64/sendmail-8.13.1-3.legacy.x86_64.rpm >939de41400340905ec0b378b501e5d1b8b41e545 >fedora/3/updates-testing/x86_64/sendmail-cf-8.13.1-3.legacy.x86_64.rpm >c09947143c351f575737036599c23c542404d82e >fedora/3/updates-testing/x86_64/sendmail-devel-8.13.1-3.legacy.x86_64. >rpm bd1b9553b49e5c2631a40f68461472b1671f9beb >fedora/3/updates-testing/x86_64/sendmail-doc-8.13.1-3.legacy.x86_64.rp >m > >--------------------------------------------------------------------- > >Please test and comment in bugzilla. -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From sheltren at cs.ucsb.edu Thu Mar 23 21:20:11 2006 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Thu, 23 Mar 2006 17:20:11 -0400 Subject: Question about yum.conf for fc2 In-Reply-To: <200603230737.15910.gene.heskett@verizon.net> References: <200603230737.15910.gene.heskett@verizon.net> Message-ID: <4455EAC7-8974-48D9-8665-6ED87CC3E98F@cs.ucsb.edu> On Mar 23, 2006, at 8:37 AM, Gene Heskett wrote: > Greetings; > > Yum is rather continuously erroring out on fedora extras, both > branches > recently. Do I need to edit that line and send it someplace else now? > > Gene, as far as I know Fedora Extras has only ever been FC3 and up. What URL(s) are you referring to? -Jeff From deisenst at gtw.net Thu Mar 23 22:09:51 2006 From: deisenst at gtw.net (David Eisenstein) Date: Thu, 23 Mar 2006 16:09:51 -0600 (CST) Subject: My personal patch for sendmail 8.12.8 on RedHat 9 In-Reply-To: <4422B876.9080409@ptm.com> Message-ID: On Thu, 23 Mar 2006, Adam Gibson wrote: > Adam Gibson wrote: > ... > > This has been working since yesterday around 4pm EST on a medium load > > server without issues. > > > > The offical 8.12.11 patch which does not apply properly on 8.12.8 is on > > the main sendmail.org site for reference. > > > > Anyone here any new news about an official legacy patch? > > Ignore this patch since legacy already has a test update available that > upgrades sendmail to 8.12.11 (Much better solution instead of worrying > about the ramifications of back-porting the changes). > > BTW... legacy email list takes 7+ hours for list emails to get to me so > I didn't see the announcement before I sent my original email. I have > noticed this for the past few days(before my patch :)... anyone else > seeing a major lag in list emails? Hi Adam, One of the reasons your original post with the patch didn't make it out on the list yet is that it was around 70 kiB in size, and the list software is set up to allow only 40kiB without moderation. So it is being held for moderation. We can either release that note to the list or reject/discard that post. It's not like it's 1 MB post or anything. :) What would you prefer that we do? Regards, David Eisenstein From oliver at samera.com.py Fri Mar 24 00:53:55 2006 From: oliver at samera.com.py (Oliver Schulze L.) Date: Thu, 23 Mar 2006 20:53:55 -0400 Subject: sendmail remote vulnerability In-Reply-To: References: Message-ID: <44234323.4010901@samera.com.py> I agree, it would be nice to have an update ;) I keep running: yum -y update sendmail ;) Cheers Oliver Pekka Savola wrote: > Hi, > > I hope FL core has had preliminary warning of the just-released > sendmail remote vulnerability.... and if something has already been > done about it, even better.. > -- Oliver Schulze L. From gene.heskett at verizon.net Fri Mar 24 04:49:53 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Thu, 23 Mar 2006 23:49:53 -0500 Subject: Question about yum.conf for fc2 In-Reply-To: <1143140403.32685.1.camel@cutter> References: <200603230737.15910.gene.heskett@verizon.net> <1143140403.32685.1.camel@cutter> Message-ID: <200603232349.53873.gene.heskett@verizon.net> On Thursday 23 March 2006 14:00, seth vidal wrote: >On Thu, 2006-03-23 at 07:37 -0500, Gene Heskett wrote: >> Greetings; >> >> Yum is rather continuously erroring out on fedora extras, both >> branches recently. Do I need to edit that line and send it >> someplace else now? > >you need to tell us what the error is. Humm, this is the second copy, to the list, posted at 14:00 your time, just now walked in the door Seth, its 23:48 here now. ???? -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From nils at lemonbit.nl Fri Mar 24 11:10:47 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Fri, 24 Mar 2006 12:10:47 +0100 Subject: Question about yum.conf for fc2 In-Reply-To: <4455EAC7-8974-48D9-8665-6ED87CC3E98F@cs.ucsb.edu> References: <200603230737.15910.gene.heskett@verizon.net> <4455EAC7-8974-48D9-8665-6ED87CC3E98F@cs.ucsb.edu> Message-ID: <82C5B680-2C9F-4559-A7A1-F7980CB1CD46@lemonbit.nl> Jeff Sheltren wrote: > On Mar 23, 2006, at 8:37 AM, Gene Heskett wrote: >> >> Yum is rather continuously erroring out on fedora extras, both >> branches >> recently. Do I need to edit that line and send it someplace else >> now? > > Gene, as far as I know Fedora Extras has only ever been FC3 and > up. What URL(s) are you referring to? Maybe he's talking about the fedora.us days? Nils. From agibson at ptm.com Fri Mar 24 13:34:51 2006 From: agibson at ptm.com (Adam Gibson) Date: Fri, 24 Mar 2006 08:34:51 -0500 Subject: My personal patch for sendmail 8.12.8 on RedHat 9 In-Reply-To: References: Message-ID: <4423F57B.4040608@ptm.com> David Eisenstein wrote: > Hi Adam, > > One of the reasons your original post with the patch didn't make it out on > the list yet is that it was around 70 kiB in size, and the list software > is set up to allow only 40kiB without moderation. So it is being held for > moderation. We can either release that note to the list or reject/discard > that post. It's not like it's 1 MB post or anything. :) > > What would you prefer that we do? > > My intent was to let others that might have been scrambling to backport the patch to 8.12.8 make use of the backported patch for sendmail 8.12.8 that I was successful in doing. The patch only applies without conflicts on RH9's sendmail I am pretty sure. Considering that legacy is just upgrading sendmail to 8.12.11 and it is available in updates-testing there is probably no need for it. The only use I would think anyone would have out of it is if someone has some bizarre reason that they need to stick with 8.12.8 on RH9. I know I will be ditching my patched 8.12.8 and going with the official update from legacy. Hopefully the updated sendmail will fix a milter problem I have where you can not send a SIGINT, SIGHUP, SIGTERM to any milter process(they are filtered with rt_sigsetmask or something like that). You have to send a SIGKILL to terminate a milter on RH9. That is however unlikely. I did not see anything in the changelog for sendmail that would hint at that but I am hopeful anyway :). I really have no preference if you want to kill the post or not. Unless someone speaks up that they want to see a patch that applies to sendmail 8.12.8 (updated spec was included too) I don't know if it is worth the (70kbit * number of list users) bandwidth unless just to archive it. Ditch it if nobody responds would be fine with me. From sheltren at cs.ucsb.edu Fri Mar 24 16:35:18 2006 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Fri, 24 Mar 2006 12:35:18 -0400 (AST) Subject: My personal patch for sendmail 8.12.8 on RedHat 9 In-Reply-To: References: <4422B876.9080409@ptm.com> Message-ID: <9938.209.88.66.94.1143218118.squirrel@letters.cs.ucsb.edu> On Thu, March 23, 2006 6:09 pm, David Eisenstein wrote: > On Thu, 23 Mar 2006, Adam Gibson wrote: >> BTW... legacy email list takes 7+ hours for list emails to get to me so >> I didn't see the announcement before I sent my original email. I have >> noticed this for the past few days(before my patch :)... anyone else >> seeing a major lag in list emails? > > Hi Adam, > > One of the reasons your original post with the patch didn't make it out on > the list yet is that it was around 70 kiB in size, and the list software > is set up to allow only 40kiB without moderation. So it is being held for > moderation. We can either release that note to the list or reject/discard > that post. It's not like it's 1 MB post or anything. :) > > What would you prefer that we do? > > Regards, > David Eisenstein I've also noticed quite a delay in messages to this list. For example, looking at the full headers from your (David's) message, you can see it sat on listman.util.phx.redhat.com for ~14(!) hours. ---------- Received: from listman.util.phx.redhat.com (listman.util.phx.redhat.com [10.8.4.110]) by hormel.redhat.com (Postfix) with ESMTP id 86CB473173; Fri, 24 Mar 2006 07:23:24 -0500 (EST) Received: from listman.util.phx.redhat.com (localhost.localdomain [127.0.0.1]) by listman.util.phx.redhat.com (8.13.1/8.13.1) with ESMTP id k2OCNMPs005411; Fri, 24 Mar 2006 07:23:22 -0500 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by listman.util.phx.redhat.com (8.13.1/8.13.1) with ESMTP id k2NM9vMj022587; Thu, 23 Mar 2006 17:09:57 -0500 ---------- -Jeff From hjp+fedora-legacy at wsr.ac.at Fri Mar 24 17:39:11 2006 From: hjp+fedora-legacy at wsr.ac.at (Peter J. Holzer) Date: Fri, 24 Mar 2006 18:39:11 +0100 Subject: Long RTT on fedora-legacy-list (was: Question about yum.conf for fc2) In-Reply-To: <200603232349.53873.gene.heskett@verizon.net> References: <200603230737.15910.gene.heskett@verizon.net> <1143140403.32685.1.camel@cutter> <200603232349.53873.gene.heskett@verizon.net> Message-ID: <20060324173911.GN27495@wsr.ac.at> On 2006-03-23 23:49:53 -0500, Gene Heskett wrote: > Received: from listman.util.phx.redhat.com (localhost.localdomain [127.0.0.1]) > by listman.util.phx.redhat.com (8.13.1/8.13.1) with ESMTP id k2OH5hkP031529; > Fri, 24 Mar 2006 12:06:05 -0500 ^^^^^ > Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com > [172.16.52.254]) > by listman.util.phx.redhat.com (8.13.1/8.13.1) with ESMTP id > k2O4o2sH012586 for ; > Thu, 23 Mar 2006 23:50:02 -0500 ^^^^^ [...] > Humm, this is the second copy, to the list, posted at 14:00 your time, > just now walked in the door Seth, its 23:48 here now. As somebody else already noted, the fedora-legacy-list sometimes has extremely long round-trip times. This mail seems to have been more than 12 hours on listman.util.phx.redhat.com, before it was sent on. hp -- _ | Peter J. Holzer | If I wanted to be "academically correct", |_|_) | Sysadmin WSR | I'd be programming in Java. | | | hjp at wsr.ac.at | I don't, and I'm not. __/ | http://www.hjp.at/ | -- Jesse Erlbaum on dbi-users -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 388 bytes Desc: not available URL: From cave.dnb at tiscali.fr Fri Mar 24 17:43:22 2006 From: cave.dnb at tiscali.fr (Nigel Henry) Date: Fri, 24 Mar 2006 18:43:22 +0100 Subject: Question about yum.conf for fc2 In-Reply-To: <200603232349.53873.gene.heskett@verizon.net> References: <200603230737.15910.gene.heskett@verizon.net> <1143140403.32685.1.camel@cutter> <200603232349.53873.gene.heskett@verizon.net> Message-ID: <200603241843.22241.cave.dnb@tiscali.fr> On Friday 24 March 2006 05:49, Gene Heskett wrote: > On Thursday 23 March 2006 14:00, seth vidal wrote: > >On Thu, 2006-03-23 at 07:37 -0500, Gene Heskett wrote: > >> Greetings; > >> > >> Yum is rather continuously erroring out on fedora extras, both > >> branches recently. Do I need to edit that line and send it > >> someplace else now? > > > >you need to tell us what the error is. > > Humm, this is the second copy, to the list, posted at 14:00 your time, > just now walked in the door Seth, its 23:48 here now. > > ???? Gene. I've just received this post at 18:30 CET, and it shows 05:49:53 CET. Man that's one hell of a round trip. A latency problem somewhere, I presume. Nigel. From cradle at umd.edu Fri Mar 24 18:54:18 2006 From: cradle at umd.edu (David Eisner) Date: Fri, 24 Mar 2006 13:54:18 -0500 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <1143115802.6809.1.camel@mdlinux> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> Message-ID: <4424405A.1060303@umd.edu> Just a heads up: after installing the sendmail-8.12.11-4.24.1.legacy package on a RH9 machine today, I noticed /usr/lib/sendmail was gone. This will break anything that's expecting it to be there. In my case, symlinking /usr/lib/sendmail --> /usr/sbin/sendmail fixed the problem. -David Marc Deslauriers wrote: > On Wed, 2006-03-22 at 10:29 -0800, Kenneth Porter wrote: > >> For those of us accepting mail from outside on pre-FC4 Fedora, are any >> updates in the pipe to address this? >> > > Packages have been created and QA'd. They will be pushed to > updates-testing soon. > > You may follow progress here: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186277 > > Marc. > > ------------------------------------------------------------------------ > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list From gene.heskett at verizon.net Fri Mar 24 21:11:18 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Fri, 24 Mar 2006 16:11:18 -0500 Subject: BT RANT, Was Re: Question about yum.conf for fc2 In-Reply-To: <82C5B680-2C9F-4559-A7A1-F7980CB1CD46@lemonbit.nl> References: <200603230737.15910.gene.heskett@verizon.net> <4455EAC7-8974-48D9-8665-6ED87CC3E98F@cs.ucsb.edu> <82C5B680-2C9F-4559-A7A1-F7980CB1CD46@lemonbit.nl> Message-ID: <200603241611.18546.gene.heskett@verizon.net> On Friday 24 March 2006 06:10, Nils Breunese (Lemonbit Internet) wrote: >Jeff Sheltren wrote: >> On Mar 23, 2006, at 8:37 AM, Gene Heskett wrote: >>> Yum is rather continuously erroring out on fedora extras, both >>> branches >>> recently. Do I need to edit that line and send it someplace else >>> now? >> >> Gene, as far as I know Fedora Extras has only ever been FC3 and >> up. What URL(s) are you referring to? > >Maybe he's talking about the fedora.us days? > >Nils. At this point its all moot, I've manage to find and install the newer sendmail on both machines. And trying to carry on a meaningfull conversation about a problem if to be frank, is fscking nuts when the lag is approaching 36 hrs to get a message, its reply, and this reply back into the mailboxes of everyone concerned. Don't take me wrong, I have appreciated attempts to help, but the mailserver lags have rendered its usefullness to somewhere in the range of that of tits on a boar hog since FC5 was released. If its shareing a pipeline with the FC5 downloads, that's just more evidence that there should be more people using torrents AND leaving it seeding when they are done. I'm seeding both the cd and the dvd right now, so I don't feel like I'm contributing to the problem. FWIW, azureus says I'm the ONLY ONE seeding the dvd right now, and the ratio is now well above 1.1, so I AM doing my part. And I note that the seed count for the cd's where the ratio is now at 1.2 something is bouncing between 0 and 1. If I'm the only one seeding then of course all you are going to hear is bitches about the poor BT bandwidth. What the hecks the matter with you folks? Take Take Take, but never give back in kind. I just raised the speed limit to about 90% of my bandwidth, but thats still not enough to feed other hungry torrents. So if you have it, give it back. Fire up that client and share! -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From jkeating at j2solutions.net Fri Mar 24 22:14:59 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 24 Mar 2006 14:14:59 -0800 Subject: BT RANT, Was Re: Question about yum.conf for fc2 In-Reply-To: <200603241611.18546.gene.heskett@verizon.net> References: <200603230737.15910.gene.heskett@verizon.net> <4455EAC7-8974-48D9-8665-6ED87CC3E98F@cs.ucsb.edu> <82C5B680-2C9F-4559-A7A1-F7980CB1CD46@lemonbit.nl> <200603241611.18546.gene.heskett@verizon.net> Message-ID: <1143238499.23491.114.camel@yoda.loki.me> On Fri, 2006-03-24 at 16:11 -0500, Gene Heskett wrote: > Don't take me wrong, I have appreciated attempts to help, but the > mailserver lags have rendered its usefullness to somewhere in the range > of that of tits on a boar hog since FC5 was released. Red Hat upgraded the mailman software over the weekend, and must have forgotten to enable some performance tweaks. All should be better now, as evident by the flood of mail coming out of Red Hat. Other than really poor timing, it had nothing to do w/ FC5 traffic. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From lsomike at futzin.com Fri Mar 24 22:17:14 2006 From: lsomike at futzin.com (Mike Klinke) Date: Fri, 24 Mar 2006 16:17:14 -0600 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <4424405A.1060303@umd.edu> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> Message-ID: <200603241617.14987.lsomike@futzin.com> On Friday 24 March 2006 12:54, David Eisner wrote: > Just a heads up: after installing the > sendmail-8.12.11-4.24.1.legacy package on a RH9 machine today, I > noticed /usr/lib/sendmail was gone. This will break anything > that's expecting it to be there. > > In my case, symlinking /usr/lib/sendmail --> /usr/sbin/sendmail > fixed the problem. > > -David > There is instead an entry in /usr/lib; "sendmail.sendmail" which is linked to /usr/sbin/sendmail. Also the man pages no longer work if you type; "man sendmail" You have to use "man sendmail.sendmail". Regards, Mike Klinke From mic at npgx.com.au Fri Mar 24 22:21:15 2006 From: mic at npgx.com.au (Michael Mansour) Date: Sat, 25 Mar 2006 08:21:15 +1000 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <200603241617.14987.lsomike@futzin.com> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> Message-ID: <20060324221859.M34444@npgx.com.au> Hi, > On Friday 24 March 2006 12:54, David Eisner wrote: > > > Just a heads up: after installing the > > sendmail-8.12.11-4.24.1.legacy package on a RH9 machine today, I > > noticed /usr/lib/sendmail was gone. This will break anything > > that's expecting it to be there. > > > > In my case, symlinking /usr/lib/sendmail --> /usr/sbin/sendmail > > fixed the problem. > > > > -David > > > > There is instead an entry in /usr/lib; "sendmail.sendmail" which > is linked to /usr/sbin/sendmail. Also the man pages no longer work > if you type; "man sendmail" You have to use "man > sendmail.sendmail". That goes for FC1 also. "man sendmail" doesn't work, "man sendmail.sendmail" works. The first time I re-ran it also (I use MailScanner with sendmail in queue mode): # service MailScanner restart Shutting down MailScanner daemons: MailScanner: [ OK ] incoming sendmail: [ OK ] outgoing sendmail: [ OK ] Starting MailScanner daemons: incoming sendmail: m4: m4: No such file or directory *** ERROR: FEATURE() should be before MAILER() *** ERROR: FEATURE() should be before MAILER() *** ERROR: FEATURE() should be before MAILER() *** ERROR: MAILER(local) already included *** ERROR: MAILER(smtp) already included [ OK ] outgoing sendmail: [ OK ] MailScanner: [ OK ] The next and consecutive times I re-ran it, this error went away. Regards, Michael. From gene.heskett at verizon.net Fri Mar 24 22:37:21 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Fri, 24 Mar 2006 17:37:21 -0500 Subject: BT RANT, Was Re: Question about yum.conf for fc2 In-Reply-To: <1143238499.23491.114.camel@yoda.loki.me> References: <200603230737.15910.gene.heskett@verizon.net> <200603241611.18546.gene.heskett@verizon.net> <1143238499.23491.114.camel@yoda.loki.me> Message-ID: <200603241737.21895.gene.heskett@verizon.net> On Friday 24 March 2006 17:14, Jesse Keating wrote: >On Fri, 2006-03-24 at 16:11 -0500, Gene Heskett wrote: >> Don't take me wrong, I have appreciated attempts to help, but the >> mailserver lags have rendered its usefullness to somewhere in the >> range of that of tits on a boar hog since FC5 was released. > >Red Hat upgraded the mailman software over the weekend, and must have >forgotten to enable some performance tweaks. All should be better > now, as evident by the flood of mail coming out of Red Hat. > >Other than really poor timing, it had nothing to do w/ FC5 traffic. Well, this round trip is down to about 1:25. considerably better than the 14-18 hours it was earlier. -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From jkeating at j2solutions.net Fri Mar 24 22:41:36 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 24 Mar 2006 14:41:36 -0800 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <200603241617.14987.lsomike@futzin.com> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> Message-ID: <1143240096.23491.116.camel@yoda.loki.me> On Fri, 2006-03-24 at 16:17 -0600, Mike Klinke wrote: > There is instead an entry in /usr/lib; "sendmail.sendmail" which > is linked to /usr/sbin/sendmail. Also the man pages no longer work > if you type; "man sendmail" You have to use "man > sendmail.sendmail". This sounds like the Alternatives system got confused and wasn't making the links that it was supposed to, as stated in the spec file. Hrm. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From jimpop at yahoo.com Fri Mar 24 22:47:00 2006 From: jimpop at yahoo.com (Jim Popovitch) Date: Fri, 24 Mar 2006 17:47:00 -0500 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <200603241617.14987.lsomike@futzin.com> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> Message-ID: <442476E4.8010309@yahoo.com> Mike Klinke wrote: > On Friday 24 March 2006 12:54, David Eisner wrote: > >> Just a heads up: after installing the >> sendmail-8.12.11-4.24.1.legacy package on a RH9 machine today, I >> noticed /usr/lib/sendmail was gone. This will break anything >> that's expecting it to be there. >> >> In my case, symlinking /usr/lib/sendmail --> /usr/sbin/sendmail >> fixed the problem. >> >> -David >> > > There is instead an entry in /usr/lib; "sendmail.sendmail" which > is linked to /usr/sbin/sendmail. Also the man pages no longer work > if you type; "man sendmail" You have to use "man > sendmail.sendmail". Do you have postfix installed on the same host? sendmail.sendmail is an indication that postfix.sendmail possibly exists and that an alias or softlink is used to define the current one. -Jim P. From michal at harddata.com Fri Mar 24 22:48:56 2006 From: michal at harddata.com (Michal Jaegermann) Date: Fri, 24 Mar 2006 15:48:56 -0700 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <20060324221859.M34444@npgx.com.au> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> <20060324221859.M34444@npgx.com.au> Message-ID: <20060324224856.GA19117@mail.harddata.com> On Sat, Mar 25, 2006 at 08:21:15AM +1000, Michael Mansour wrote: > > On Friday 24 March 2006 12:54, David Eisner wrote: > > > > There is instead an entry in /usr/lib; "sendmail.sendmail" which > > is linked to /usr/sbin/sendmail. Also the man pages no longer work > > if you type; "man sendmail" You have to use "man > > sendmail.sendmail". > > That goes for FC1 also. "man sendmail" doesn't work, "man sendmail.sendmail" > works. /usr/sbin/alternatives was supposed to take care of that. If you will do 'rpm -q --scripts sendmail' then you should see, among other things, something of that sort: /usr/sbin/alternatives --install /usr/sbin/sendmail mta \ /usr/sbin/sendmail.sendmail 90 \ --slave /usr/bin/mailq mta-mailq /usr/bin/mailq.sendmail \ --slave ( ... and so on, and so on ....) Apparently something is not right here. Check with what you ended up in /etc/alternatives/ (should be a bunch of symlinks there and things like /usr/lib/sendmail, or correspoding manpages, are links to these). As a workaround you can add for now missing symlinks by yourself; or you can try to rerun that part of an installation script and see if this will create all links you need. I am not sure in which distro /usr/sbin/alternatives showed up for the first time. > *** ERROR: FEATURE() should be before MAILER() > *** ERROR: FEATURE() should be before MAILER() > *** ERROR: FEATURE() should be before MAILER() > *** ERROR: MAILER(local) already included > *** ERROR: MAILER(smtp) already included > [ OK ] > outgoing sendmail: [ OK ] > MailScanner: [ OK ] > > The next and consecutive times I re-ran it, this error went away. It smells like corresponding config files were not yet rebuilt the first time but later were present. Michal From nils at lemonbit.nl Fri Mar 24 22:50:44 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Fri, 24 Mar 2006 23:50:44 +0100 Subject: BT RANT, Was Re: Question about yum.conf for fc2 In-Reply-To: <200603241611.18546.gene.heskett@verizon.net> References: <200603230737.15910.gene.heskett@verizon.net> <4455EAC7-8974-48D9-8665-6ED87CC3E98F@cs.ucsb.edu> <82C5B680-2C9F-4559-A7A1-F7980CB1CD46@lemonbit.nl> <200603241611.18546.gene.heskett@verizon.net> Message-ID: Gene Heskett wrote: > What the hecks the matter with you folks? Take Take Take, but never > give back in kind. I just raised the speed limit to about 90% of my > bandwidth, but thats still not enough to feed other hungry torrents. > So if you have it, give it back. Fire up that client and share! When I was downloading FC5 there were like 50 seeds and over 80 peers. And that was before the official release! Oh well, I never used those .isos anyway, just upgraded by installing FC5's fedora-release package and running yum update ('only' 1.3 GB of updates, instead of burning 5 CD's). Nils. From gene.heskett at verizon.net Fri Mar 24 23:14:58 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Fri, 24 Mar 2006 18:14:58 -0500 Subject: Nother silly Q: When switching from samba to cifs Message-ID: <200603241814.58682.gene.heskett@verizon.net> Greetings; Do I have to switch all machines on the net at the same time? I was under the impresssion that cifs was backwards compatible with samba for most of its features. I tried to switch just this one to cifs and I'm getting perms problems I believe. The other box that was the target I was trying to mount -t cifs etc etc, was still setup as samba share on that end. -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From lsomike at futzin.com Fri Mar 24 23:35:41 2006 From: lsomike at futzin.com (Mike Klinke) Date: Fri, 24 Mar 2006 17:35:41 -0600 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <20060324224856.GA19117@mail.harddata.com> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <20060324221859.M34444@npgx.com.au> <20060324224856.GA19117@mail.harddata.com> Message-ID: <200603241735.42020.lsomike@futzin.com> On Friday 24 March 2006 16:48, Michal Jaegermann wrote: > > /usr/sbin/alternatives was supposed to take care of that. If you > will do 'rpm -q --scripts sendmail' then you should see, among > other things, something of that sort: > > /usr/sbin/alternatives --install /usr/sbin/sendmail mta \ > /usr/sbin/sendmail.sendmail 90 \ > --slave /usr/bin/mailq mta-mailq /usr/bin/mailq.sendmail > \ --slave ( ... and so on, and so on ....) That all seems to be there and I didn't notice anything wrong. > > Apparently something is not right here. Check with what you > ended up in /etc/alternatives/ (should be a bunch of symlinks > there and things like /usr/lib/sendmail, or correspoding > manpages, are links to these). As a workaround you can add for > now missing symlinks by yourself; or you can try to rerun that > part of an installation script and see if this will create all > links you need. > Those also appear to be there, but .... there appears to be a missing link in the /usr/share/man/man8 directory: sendmail.8.gz -> /etc/alternatives/mta-sendmailman if my FC3 structure is anything to go by. Manually adding it allows the "man sendmail" syntax to work. Regards, Mike Klinke From drees76 at gmail.com Fri Mar 24 23:44:28 2006 From: drees76 at gmail.com (David Rees) Date: Fri, 24 Mar 2006 15:44:28 -0800 Subject: BT RANT, Was Re: Question about yum.conf for fc2 In-Reply-To: <200603241611.18546.gene.heskett@verizon.net> References: <200603230737.15910.gene.heskett@verizon.net> <4455EAC7-8974-48D9-8665-6ED87CC3E98F@cs.ucsb.edu> <82C5B680-2C9F-4559-A7A1-F7980CB1CD46@lemonbit.nl> <200603241611.18546.gene.heskett@verizon.net> Message-ID: <72dbd3150603241544i5efa87f2u96fa420225584055@mail.gmail.com> On 3/24/06, Gene Heskett wrote: > > What the hecks the matter with you folks? Take Take Take, but never > give back in kind. I just raised the speed limit to about 90% of my > bandwidth, but thats still not enough to feed other hungry torrents. > So if you have it, give it back. Fire up that client and share! Heh, I run bittorrent on one of my machines, you should see how much data I've uploaded (over 80GB with the currently active torrents), and that's with limiting the upstream bandwidth to 25KBps and 2 connections per torrent. I don't dare uncap the bandwidth limits, it'll totally consume my T1, even if I disabled all the torrents except the FC5 torrent. -Dave From gene.heskett at verizon.net Sat Mar 25 02:58:20 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Fri, 24 Mar 2006 21:58:20 -0500 Subject: BT RANT, Was Re: Question about yum.conf for fc2 In-Reply-To: <72dbd3150603241544i5efa87f2u96fa420225584055@mail.gmail.com> References: <200603230737.15910.gene.heskett@verizon.net> <200603241611.18546.gene.heskett@verizon.net> <72dbd3150603241544i5efa87f2u96fa420225584055@mail.gmail.com> Message-ID: <200603242158.20869.gene.heskett@verizon.net> On Friday 24 March 2006 18:44, David Rees wrote: >On 3/24/06, Gene Heskett wrote: >> What the hecks the matter with you folks? Take Take Take, but never >> give back in kind. I just raised the speed limit to about 90% of my >> bandwidth, but thats still not enough to feed other hungry torrents. >> So if you have it, give it back. Fire up that client and share! > >Heh, I run bittorrent on one of my machines, you should see how much >data I've uploaded (over 80GB with the currently active torrents), and >that's with limiting the upstream bandwidth to 25KBps and 2 >connections per torrent. I don't dare uncap the bandwidth limits, >it'll totally consume my T1, even if I disabled all the torrents >except the FC5 torrent. > I've now upped about 8.1GB of FC5, not much, but it all helps. >-Dave > >-- >fedora-legacy-list mailing list >fedora-legacy-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-legacy-list -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From lsomike at futzin.com Sat Mar 25 03:52:34 2006 From: lsomike at futzin.com (Mike Klinke) Date: Fri, 24 Mar 2006 21:52:34 -0600 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <1143240096.23491.116.camel@yoda.loki.me> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <200603241617.14987.lsomike@futzin.com> <1143240096.23491.116.camel@yoda.loki.me> Message-ID: <200603242152.34895.lsomike@futzin.com> On Friday 24 March 2006 16:41, Jesse Keating wrote: > > This sounds like the Alternatives system got confused and wasn't > making the links that it was supposed to, as stated in the spec > file. Hrm. I see three missing links on RH9 and FC1; /usr/lib/sendmail /usr/share/man/man8/sendmail.8.gz /etc/pam.d/smtp Regards, Mike Klinke From mkratz at internode.com.au Sat Mar 25 04:05:24 2006 From: mkratz at internode.com.au (Michael Kratz) Date: Sat, 25 Mar 2006 14:35:24 +1030 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <1143240096.23491.116.camel@yoda.loki.me> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> <1143240096.23491.116.camel@yoda.loki.me> Message-ID: <4424C184.5090000@internode.com.au> Jesse Keating wrote: > > This sounds like the Alternatives system got confused and wasn't making > the links that it was supposed to, as stated in the spec file. Hrm. > FYI: I just (yum) updated sendmail on a Redhat 7.3 box, and the RPM overwrote my sendmail.cf file and didn't create a .rpmnew or .rpmsave! Lucky I still had my custom .mc file and it didn't overwrite that. -- Michael From rostetter at mail.utexas.edu Sat Mar 25 04:09:13 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 24 Mar 2006 22:09:13 -0600 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <1143240096.23491.116.camel@yoda.loki.me> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> <1143240096.23491.116.camel@yoda.loki.me> Message-ID: <20060324220913.ro57s5usue8kg04w@mail.ph.utexas.edu> Quoting Jesse Keating : > On Fri, 2006-03-24 at 16:17 -0600, Mike Klinke wrote: >> There is instead an entry in /usr/lib; "sendmail.sendmail" which >> is linked to /usr/sbin/sendmail. Also the man pages no longer work >> if you type; "man sendmail" You have to use "man >> sendmail.sendmail". > > This sounds like the Alternatives system got confused and wasn't making > the links that it was supposed to, as stated in the spec file. Hrm. This sounds like what happens when we rush the QA processes... I've stopped trying to do QA because by the time I download the testing version, install it, and start testing it, and well before I can submit a report, the package gets released... Very frustrating. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From jkeating at j2solutions.net Sat Mar 25 05:05:08 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 24 Mar 2006 21:05:08 -0800 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <20060324220913.ro57s5usue8kg04w@mail.ph.utexas.edu> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> <1143240096.23491.116.camel@yoda.loki.me> <20060324220913.ro57s5usue8kg04w@mail.ph.utexas.edu> Message-ID: <1143263108.3242.2.camel@ender> On Fri, 2006-03-24 at 22:09 -0600, Eric Rostetter wrote: > > This sounds like what happens when we rush the QA processes... > > I've stopped trying to do QA because by the time I download the testing > version, install it, and start testing it, and well before I can submit > a report, the package gets released... Very frustrating. > I had verified votes for all the platforms. I also had LOTS of people asking when a release would come out, again and again. Unfortunately sendmail is one of those really crappy packages that does a ton of stuff in spec and deals w/ alternatives and gets used in so many different ways that it is hard to test every corner case. Admittedly the missing symlinks is a pretty glaring issue, but rpmdiff wouldn't find it as the links aren't provided by the package, nor does it prevent normal mail delivery, just things that look in /usr/lib/ for sendmail. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From rostetter at mail.utexas.edu Sat Mar 25 06:14:43 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Sat, 25 Mar 2006 00:14:43 -0600 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <1143263108.3242.2.camel@ender> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> <1143240096.23491.116.camel@yoda.loki.me> <20060324220913.ro57s5usue8kg04w@mail.ph.utexas.edu> <1143263108.3242.2.camel@ender> Message-ID: <20060325001443.vml6u17x9z8k8wwk@mail.ph.utexas.edu> Quoting Jesse Keating : > I had verified votes for all the platforms. True. > I also had LOTS of people > asking when a release would come out, again and again. Should not be relevent, especially if there is one in updates-testing. > Unfortunately > sendmail is one of those really crappy packages that does a ton of stuff > in spec and deals w/ alternatives and gets used in so many different > ways that it is hard to test every corner case. Very hard with only 4-5 people testing it. Yes. > Admittedly the missing > symlinks is a pretty glaring issue, but rpmdiff wouldn't find it as the > links aren't provided by the package, nor does it prevent normal mail > delivery, just things that look in /usr/lib/ for sendmail. I've had issues with it moving my sendmail.mc to sendmail.mc.rpmsave and either replacing it with a new sendmail.mc or leaving me with no sendmail.mc at all. In either case, unless I catch this and fix it, my mail _does not_ get delivered normally. Then of course reverting to the old sendmail.mc causes warnings (if the old versions still had AUTO_REBUILD enabled, or I added FEATURE lines after the MAILER lines, etc). So I had to fix these to make it work. I _think_ there may have been similar problems with sendmail.cf, but I can't be sure since I just got in the habit of rebuilding it from sendmail.mc after the upgrade, due to the above issues. I found several systems where sendmail was _not_ running after the upgrade. I simply made sure the configs were okay (and rebuilt if not) and started sendmail in those cases, without issue, but... By the way, I never saw any of the symlink issues myself for some reason. But I did have sendmail.{mc/cf} issues, and failures to run after the upgrade... -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From rostetter at mail.utexas.edu Sat Mar 25 06:49:55 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Sat, 25 Mar 2006 00:49:55 -0600 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <20060324224856.GA19117@mail.harddata.com> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> <20060324221859.M34444@npgx.com.au> <20060324224856.GA19117@mail.harddata.com> Message-ID: <20060325004955.dk8vx8m7aaf4wwwg@mail.ph.utexas.edu> Quoting Michal Jaegermann : > I am not sure in which distro /usr/sbin/alternatives showed up > for the first time. It first showed up in RHL 7.3 as far as RHL goes. It originated in debian though... >> *** ERROR: FEATURE() should be before MAILER() >> *** ERROR: FEATURE() should be before MAILER() >> *** ERROR: FEATURE() should be before MAILER() Yeah, I got that on a bunch of machines. Just updated my sendmail.mc to move the FEATURE macros up above the MAILER macros, as it suggests. I also got a few errors on AUTO_REBUILD on older configs... -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From rostetter at mail.utexas.edu Sat Mar 25 07:00:53 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Sat, 25 Mar 2006 01:00:53 -0600 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <4424C184.5090000@internode.com.au> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> <1143240096.23491.116.camel@yoda.loki.me> <4424C184.5090000@internode.com.au> Message-ID: <20060325010053.01odujbcsl6owwc8@mail.ph.utexas.edu> Quoting Michael Kratz : > I just (yum) updated sendmail on a Redhat 7.3 box, and the RPM > overwrote my sendmail.cf file and didn't create a .rpmnew or .rpmsave! > > Lucky I still had my custom .mc file and it didn't overwrite that. Can you tell what was different between the old .cf and the new one? I can see it tries to "update" the sendmail.cf to comment out any references to "AutoRebuildAliases". This "update" might look more sinister than it is, or might even be more sinister than it means to be (e.g. if you run a non-standard configuration). In any case, it deletes the original without saving it... I can see where this could hose your configuration in very rare edge cases (like running out of disk space on the device while writing a file, etc). > -- > Michael -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From mkratz at internode.com.au Sat Mar 25 07:19:27 2006 From: mkratz at internode.com.au (Michael Kratz) Date: Sat, 25 Mar 2006 17:49:27 +1030 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <20060325010053.01odujbcsl6owwc8@mail.ph.utexas.edu> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> <1143240096.23491.116.camel@yoda.loki.me> <4424C184.5090000@internode.com.au> <20060325010053.01odujbcsl6owwc8@mail.ph.utexas.edu> Message-ID: <4424EEFF.10106@internode.com.au> Eric Rostetter wrote: > Quoting Michael Kratz : > >> I just (yum) updated sendmail on a Redhat 7.3 box, and the RPM >> overwrote my sendmail.cf file and didn't create a .rpmnew or .rpmsave! >> >> Lucky I still had my custom .mc file and it didn't overwrite that. > > Can you tell what was different between the old .cf and the new one? The new cf appeared to be a 'fresh' default config file. i.e. only bound to localhost, all my amavis and rbl stuff was missing, etc. Heres the build info from the sendmail.cf post upgrade: ##### built by mockbuild at turbosphere.fedoralegacy.org on Wed Mar 22 23:27:38 EST 2006 ##### in /builddir/build/BUILD/sendmail-8.12.11/cf/cf ##### using ../ as configuration include directory It looks like it just completely overwrote my sendmail.cf with a bog standard config. It shouldn't do that. It should either create its own sendmail.cf as sendmail.cf.rpmnew, or move the existing one to sendmail.rpmsave and then replace it. > I can see it tries to "update" the sendmail.cf to comment out any > references to "AutoRebuildAliases". Thats not present in my sendmail.cf at all. > This "update" might look more sinister than it > is, or might even be more sinister than it means to be (e.g. if you run a > non-standard configuration). In any case, it deletes the original without > saving it... I can see where this could hose your configuration in very > rare edge cases (like running out of disk space on the device while > writing a file, etc). In this case, pretty much everyone is going to be running a non-standard configuration if they're running a mail server, because the standard configuration only binds Sendmail to 127.0.0.1. Cheers, Michael From d.terweij at nettuning.net Sat Mar 25 10:39:33 2006 From: d.terweij at nettuning.net (Danny Terweij - Net Tuning | Net) Date: Sat, 25 Mar 2006 11:39:33 +0100 Subject: New sendmail and missing /usr/lib/sendmail References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux><4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> <1143240096.23491.116.camel@yoda.loki.me> <4424C184.5090000@internode.com.au><20060325010053.01odujbcsl6owwc8@mail.ph.utexas.edu> <4424EEFF.10106@internode.com.au> Message-ID: <006701c64ff8$68a2c7e0$1e00a8c0@prvd321> From: "Michael Kratz" > >> overwrote my sendmail.cf file and didn't create a .rpmnew or .rpmsave! My sendmail on FC3 boxes also not working correctly. mailq was set as mailq.sendmail. newaliases was set as newaliases.sendmail And maybe more is very wrong with this package. Danny. From jkeating at j2solutions.net Fri Mar 24 03:08:21 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 23 Mar 2006 19:08:21 -0800 Subject: [FLSA-2006:186277] Updated sendmail packages fix security issues Message-ID: <1143169701.23491.99.camel@yoda.loki.me> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated sendmail packages fix security issues Advisory ID: FLSA:186277 Issue date: 2006-03-23 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2006-0058 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated sendmail packages that fix a security issue are now available. The sendmail package provides A widely used Mail Transport Agent (MTA). 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 Fedora Core 3 - i386, x86_64 3. Problem description: A flaw in the handling of asynchronous signals was discovered in Sendmail. A remote attacker may be able to exploit a race condition to execute arbitrary code as root. The Common Vulnerabilities and Exposures project assigned the name CVE-2006-0058 to this issue. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. In order to correct this issue for RHL 7.3 users, it was necessary to upgrade the version of Sendmail from 8.11 as originally shipped to Sendmail 8.12.11 with the addition of the security patch supplied by Sendmail Inc. This erratum provides updated packages based on Sendmail 8.12 with a compatibility mode enabled as provided by Red Hat for RHEL 2.1. After updating to these packages, users should pay close attention to their sendmail logs to ensure that the upgrade completed successfully. In order to correct this issue for RHL 9 and FC1 users, it was necessary to upgrade the version of Sendmail from 8.12.8 and 8.12.10 respectively to 8.12.11 with the addition of the security patch supplied by Sendmail Inc. After updating to these packages, users should pay close attention to their sendmail logs to ensure that the upgrade completed successfully. For Fedora Core 3 users, the patch supplied by Sendmail Inc. applies cleanly to the latest sendmail package previously released for Fedora Core 3. Users updating to these packages are urged to review their sendmail.cf file after updating. 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=186277 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/sendmail-8.12.11-4.22.9.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/sendmail-8.12.11-4.22.9.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/sendmail-cf-8.12.11-4.22.9.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/sendmail-devel-8.12.11-4.22.9.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/sendmail-doc-8.12.11-4.22.9.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/sendmail-8.12.11-4.24.1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/sendmail-8.12.11-4.24.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/sendmail-cf-8.12.11-4.24.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/sendmail-devel-8.12.11-4.24.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/sendmail-doc-8.12.11-4.24.1.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/sendmail-8.12.11-4.25.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/sendmail-8.12.11-4.25.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/sendmail-cf-8.12.11-4.25.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/sendmail-devel-8.12.11-4.25.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/sendmail-doc-8.12.11-4.25.1.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/sendmail-8.12.11-4.26.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/sendmail-8.12.11-4.26.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/sendmail-cf-8.12.11-4.26.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/sendmail-devel-8.12.11-4.26.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/sendmail-doc-8.12.11-4.26.legacy.i386.rpm Fedora Core 3: SRPM: http://download.fedoralegacy.org/fedora/3/updates/SRPMS/sendmail-8.13.1-3.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/3/updates/i386/sendmail-8.13.1-3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/3/updates/i386/sendmail-cf-8.13.1-3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/3/updates/i386/sendmail-devel-8.13.1-3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/3/updates/i386/sendmail-doc-8.13.1-3.legacy.i386.rpm x86_64: http://download.fedoralegacy.org/fedora/3/updates/x86_64/sendmail-8.13.1-3.legacy.x86_64.rpm http://download.fedoralegacy.org/fedora/3/updates/x86_64/sendmail-cf-8.13.1-3.legacy.x86_64.rpm http://download.fedoralegacy.org/fedora/3/updates/x86_64/sendmail-devel-8.13.1-3.legacy.x86_64.rpm http://download.fedoralegacy.org/fedora/3/updates/x86_64/sendmail-doc-8.13.1-3.legacy.x86_64.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- d9c001d8a34f11f528ff6be2a9f8dd15818caf40 redhat/7.3/updates/SRPMS/sendmail-8.12.11-4.22.9.legacy.src.rpm 80f02c886b020e6d6ef17389c22c8b530fb05a48 redhat/7.3/updates/i386/sendmail-8.12.11-4.22.9.legacy.i386.rpm 285816881a55fe4b8a74fee48205c8ceedaee5e5 redhat/7.3/updates/i386/sendmail-cf-8.12.11-4.22.9.legacy.i386.rpm b4154a342e7747d980b7acaf352649ddc1dcc40d redhat/7.3/updates/i386/sendmail-devel-8.12.11-4.22.9.legacy.i386.rpm 81a36048a12cc5c08a8e93490dde6817c402ae54 redhat/7.3/updates/i386/sendmail-doc-8.12.11-4.22.9.legacy.i386.rpm 272bbff91a52692991f6f0fd434a27fda1c92057 redhat/9/updates/SRPMS/sendmail-8.12.11-4.24.1.legacy.src.rpm 683d48df1c5aabb1e9768d4bfb37036d0d7ff7c6 redhat/9/updates/i386/sendmail-8.12.11-4.24.1.legacy.i386.rpm a6e967294f6cbe9f623e5626e20e33fbbc410f68 redhat/9/updates/i386/sendmail-cf-8.12.11-4.24.1.legacy.i386.rpm da996e582bb27144c7c26050e0ba51ce7cb727d7 redhat/9/updates/i386/sendmail-devel-8.12.11-4.24.1.legacy.i386.rpm 8d03dc1dd178543cb9d9050198774b599967bfcd redhat/9/updates/i386/sendmail-doc-8.12.11-4.24.1.legacy.i386.rpm c33698f4e499d477d9712de3d6061825348a294f fedora/1/updates/SRPMS/sendmail-8.12.11-4.25.1.legacy.src.rpm df880ab03eaeb2f82be81bee96c28392984a4b86 fedora/1/updates/i386/sendmail-8.12.11-4.25.1.legacy.i386.rpm 729bcaeb1269b65728f014bbbedb5c1a54a5158e fedora/1/updates/i386/sendmail-cf-8.12.11-4.25.1.legacy.i386.rpm 256ff91b67ecc7680a5f2fb97b3b32142bb80d18 fedora/1/updates/i386/sendmail-devel-8.12.11-4.25.1.legacy.i386.rpm 65725c811c4c7eede9f88c006a13c15e458d353f fedora/1/updates/i386/sendmail-doc-8.12.11-4.25.1.legacy.i386.rpm 65086d18cb29e02b57ce07b6abf79ba378ae1c3c fedora/2/updates/SRPMS/sendmail-8.12.11-4.26.legacy.src.rpm 7e44b02696338832e2dfc0057aeb58c98511d0d2 fedora/2/updates/i386/sendmail-8.12.11-4.26.legacy.i386.rpm d159f0c92bd530799b75341d18b5b2cbe5aa5a0a fedora/2/updates/i386/sendmail-cf-8.12.11-4.26.legacy.i386.rpm 8421bfb2eb2f2b3fddb35e905fdcfecd0fb8088c fedora/2/updates/i386/sendmail-devel-8.12.11-4.26.legacy.i386.rpm b659d2733afa3d6f4df840a395c6eae3a5c07d50 fedora/2/updates/i386/sendmail-doc-8.12.11-4.26.legacy.i386.rpm fbfba64eac81e57ae098f967b7d3bf4e47e04c87 fedora/3/updates/SRPMS/sendmail-8.13.1-3.legacy.src.rpm 6cc0f44ad32c0eb62801331bf8bfa41625b61031 fedora/3/updates/i386/sendmail-8.13.1-3.legacy.i386.rpm 04bd02d3f731eb985d6e8b9fde7ee3ddc5bdccfe fedora/3/updates/i386/sendmail-cf-8.13.1-3.legacy.i386.rpm 97f173fa48f847feb5051bc2cb4686f53e3895ac fedora/3/updates/i386/sendmail-devel-8.13.1-3.legacy.i386.rpm 298c0908052efdbc671dda1f22f025f96a10d770 fedora/3/updates/i386/sendmail-doc-8.13.1-3.legacy.i386.rpm 162a1e21ac33e5a9072f7cb9934d17523d8160f6 fedora/3/updates/x86_64/sendmail-8.13.1-3.legacy.x86_64.rpm 939de41400340905ec0b378b501e5d1b8b41e545 fedora/3/updates/x86_64/sendmail-cf-8.13.1-3.legacy.x86_64.rpm c09947143c351f575737036599c23c542404d82e fedora/3/updates/x86_64/sendmail-devel-8.13.1-3.legacy.x86_64.rpm bd1b9553b49e5c2631a40f68461472b1671f9beb fedora/3/updates/x86_64/sendmail-doc-8.13.1-3.legacy.x86_64.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://www.kb.cert.org/vuls/id/834865 http://www.sendmail.com/company/advisory/ http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0058 http://rhn.redhat.com/errata/RHSA-2006-0265.html http://rhn.redhat.com/errata/RHSA-2006-0264.html 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From chris at fatorange.com Sat Mar 25 14:05:08 2006 From: chris at fatorange.com (Christian Becker) Date: Sat, 25 Mar 2006 15:05:08 +0100 Subject: RH 9.0: AUTH LOGIN issue with latest sendmail patch Message-ID: <004501c65015$208ffb40$0100000a@celsius> Hi all, Yesterday's sendmail update for RH9, going from 8.12.8 to 8.12.11, broke AUTH LOGIN for SMTP on our machine - all logins were rejected; logs were filled with "xyz did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA". For anybody else affected: The fix for me was to copy /etc/pam.d/smtp.sendmail to /etc/pam.d/smtp. The latter file seems to get deleted during the update. A similar issue is described at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109313 Christian Becker From marcdeslauriers at videotron.ca Sat Mar 25 14:36:13 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sat, 25 Mar 2006 09:36:13 -0500 Subject: RH 9.0: AUTH LOGIN issue with latest sendmail patch In-Reply-To: <004501c65015$208ffb40$0100000a@celsius> References: <004501c65015$208ffb40$0100000a@celsius> Message-ID: <1143297373.24060.40.camel@mdlinux> On Sat, 2006-03-25 at 15:05 +0100, Christian Becker wrote: > Hi all, > Yesterday's sendmail update for RH9, going from 8.12.8 to 8.12.11, broke > AUTH LOGIN for SMTP on our machine - all logins were rejected; logs were > filled with "xyz did not issue MAIL/EXPN/VRFY/ETRN during connection to > MTA". > For anybody else affected: The fix for me was to copy > /etc/pam.d/smtp.sendmail to /etc/pam.d/smtp. The latter file seems to get > deleted during the update. A similar issue is described at > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109313 That's pretty weird. It seems alternatives didn't create the link automatically. What is the output of "alternatives --display mta"? Marc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From lsomike at futzin.com Sat Mar 25 14:52:14 2006 From: lsomike at futzin.com (Mike Klinke) Date: Sat, 25 Mar 2006 08:52:14 -0600 Subject: RH 9.0: AUTH LOGIN issue with latest sendmail patch In-Reply-To: <1143297373.24060.40.camel@mdlinux> References: <004501c65015$208ffb40$0100000a@celsius> <1143297373.24060.40.camel@mdlinux> Message-ID: <200603250852.15101.lsomike@futzin.com> On Saturday 25 March 2006 08:36, Marc Deslauriers wrote: > That's pretty weird. It seems alternatives didn't create the link > automatically. There seem to be three missing links on RH9 and FC1: /usr/lib/sendmail -> /etc/alternatives/mta-sendmail /usr/share/man/man8/sendmail.8.gz -> /etc/alternatives/mta-sendmailman /etc/pam.d/smtp -> /etc/alternatives/mta-pam Regards, Mike Klinke From cradle at umd.edu Sat Mar 25 15:24:12 2006 From: cradle at umd.edu (David Eisner) Date: Sat, 25 Mar 2006 10:24:12 -0500 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <20060324220913.ro57s5usue8kg04w@mail.ph.utexas.edu> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> <1143240096.23491.116.camel@yoda.loki.me> <20060324220913.ro57s5usue8kg04w@mail.ph.utexas.edu> Message-ID: <4425609C.70506@umd.edu> Eric Rostetter wrote: > This sounds like what happens when we rush the QA processes... Other distros had advance warning about this vulnerability, and hence more time to apply patches and do testing. Is there a way Fedora Legacy could be added to the list of vendors that are notified in this type of situation? Who decides whom to notify in advance. Sendmail, Inc.? I imagine they want vendors to keep the information under wraps until the official announcement is made. (I could be wrong.) How would this work with Fedora Legacy? Is it possible? -David From michal at harddata.com Sat Mar 25 16:17:12 2006 From: michal at harddata.com (Michal Jaegermann) Date: Sat, 25 Mar 2006 09:17:12 -0700 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <4425609C.70506@umd.edu> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> <1143240096.23491.116.camel@yoda.loki.me> <20060324220913.ro57s5usue8kg04w@mail.ph.utexas.edu> <4425609C.70506@umd.edu> Message-ID: <20060325161712.GC1747@mail.harddata.com> On Sat, Mar 25, 2006 at 10:24:12AM -0500, David Eisner wrote: > Eric Rostetter wrote: > >This sounds like what happens when we rush the QA processes... > > Other distros had advance warning about this vulnerability, and hence > more time to apply patches and do testing. Personally I _hugely_ prefer fixed packages with minor packaging imperfections, which BTW can be trivially fixed by whomever is installing them by adding a link or two, then waiting for something which installs without a hitch and have a mail server "owned" in the meantime. Headaches in both cases do not even start to compare. I think that everybody should send Jesse big thanks for preparing new packages on such short notice. "New-and-improved", which create all needed links automatically on an installation, can be issued later. Of course it would help if people experiencing problems would try to identify what went wrong (older 'alternatives' do not work like they should?, some typos in %post scripts?, something else?). Again, look at what 'rpm -q --scripts sendmail' reports and check is something is amiss there, as the first step, if you have seen troubles. Michal From michal at harddata.com Sat Mar 25 16:29:03 2006 From: michal at harddata.com (Michal Jaegermann) Date: Sat, 25 Mar 2006 09:29:03 -0700 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <006701c64ff8$68a2c7e0$1e00a8c0@prvd321> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <200603241617.14987.lsomike@futzin.com> <1143240096.23491.116.camel@yoda.loki.me> <4424EEFF.10106@internode.com.au> <006701c64ff8$68a2c7e0$1e00a8c0@prvd321> Message-ID: <20060325162903.GD1747@mail.harddata.com> On Sat, Mar 25, 2006 at 11:39:33AM +0100, Danny Terweij - Net Tuning | Net wrote: > > My sendmail on FC3 boxes also not working correctly. Interesting. I actually did install an update on an FC3 box and it did not need any corrections after that. > mailq was set as mailq.sendmail. > newaliases was set as newaliases.sendmail They should be. That is exactly right. But also /usr/bin/mailq should be a link to /etc/alternatives/mta-mailq. Are you missing that link? Do you have any file systems mounted over NFS, for example. BTW - whatever is in /etc/alternatives/ is a symlink too. Yes, this "alternatives" system is somewhat baroque. In any case you can quickly save the day by creating few symlinks yourself. Michal From gene.heskett at verizon.net Sat Mar 25 16:45:51 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Sat, 25 Mar 2006 11:45:51 -0500 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <20060325162903.GD1747@mail.harddata.com> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <006701c64ff8$68a2c7e0$1e00a8c0@prvd321> <20060325162903.GD1747@mail.harddata.com> Message-ID: <200603251145.51226.gene.heskett@verizon.net> On Saturday 25 March 2006 11:29, Michal Jaegermann wrote: >On Sat, Mar 25, 2006 at 11:39:33AM +0100, Danny Terweij - Net Tuning | Net wrote: >> My sendmail on FC3 boxes also not working correctly. > >Interesting. I actually did install an update on an FC3 box and >it did not need any corrections after that. And I have likewise updated an rh7.3, and an FC2 box without detecting any problems. (yet, that is, I'm still getting locally generated emails on both boxes) -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From gene.heskett at verizon.net Sat Mar 25 16:49:18 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Sat, 25 Mar 2006 11:49:18 -0500 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <200603251145.51226.gene.heskett@verizon.net> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <20060325162903.GD1747@mail.harddata.com> <200603251145.51226.gene.heskett@verizon.net> Message-ID: <200603251149.18136.gene.heskett@verizon.net> On Saturday 25 March 2006 11:45, Gene Heskett wrote: >On Saturday 25 March 2006 11:29, Michal Jaegermann wrote: >>On Sat, Mar 25, 2006 at 11:39:33AM +0100, Danny Terweij - Net Tuning >> | > >Net wrote: >>> My sendmail on FC3 boxes also not working correctly. >> >>Interesting. I actually did install an update on an FC3 box and >>it did not need any corrections after that. > >And I have likewise updated an rh7.3, and an FC2 box without detecting >any problems. (yet, that is, I'm still getting locally generated > emails on both boxes) Hot damn, the server is fixed! Thanks to whomever had the magic hammer. -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From jkeating at j2solutions.net Sat Mar 25 16:49:53 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 25 Mar 2006 08:49:53 -0800 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <4425609C.70506@umd.edu> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> <1143240096.23491.116.camel@yoda.loki.me> <20060324220913.ro57s5usue8kg04w@mail.ph.utexas.edu> <4425609C.70506@umd.edu> Message-ID: <1143305393.3242.4.camel@ender> On Sat, 2006-03-25 at 10:24 -0500, David Eisner wrote: > > Other distros had advance warning about this vulnerability, and hence > more time to apply patches and do testing. Is there a way Fedora Legacy > could be added to the list of vendors that are notified in this type of > situation? > > Who decides whom to notify in advance. Sendmail, Inc.? I imagine they > want vendors to keep the information under wraps until the official > announcement is made. (I could be wrong.) How would this work with > Fedora Legacy? Is it possible? > This one was pushed by CERT, and they have individual agreements with various vendors. Fedora Legacy isn't one of those vendors. However after speaking with Red Hat security team, it turns out that CERT drives an issue like this once a year or so, very low volume. The majority of other issues are vetted through vendor-sec, which we are a part of. We are moving to a point in which we can prepare updates prior to the issue being public. Our new build software was a huge step, so look for faster response times in the future. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From marcdeslauriers at videotron.ca Sat Mar 25 16:54:10 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sat, 25 Mar 2006 11:54:10 -0500 Subject: RH 9.0: AUTH LOGIN issue with latest sendmail patch In-Reply-To: <200603250852.15101.lsomike@futzin.com> References: <004501c65015$208ffb40$0100000a@celsius> <1143297373.24060.40.camel@mdlinux> <200603250852.15101.lsomike@futzin.com> Message-ID: <1143305650.4461.3.camel@mdlinux> On Sat, 2006-03-25 at 08:52 -0600, Mike Klinke wrote: > There seem to be three missing links on RH9 and FC1: > > /usr/lib/sendmail -> > /etc/alternatives/mta-sendmail > > /usr/share/man/man8/sendmail.8.gz -> > /etc/alternatives/mta-sendmailman > > /etc/pam.d/smtp -> > /etc/alternatives/mta-pam > If you do a "alternatives --config mta" and re-select sendmail, do the links get created? Marc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From lsomike at futzin.com Sat Mar 25 20:34:32 2006 From: lsomike at futzin.com (Mike Klinke) Date: Sat, 25 Mar 2006 14:34:32 -0600 Subject: RH 9.0: AUTH LOGIN issue with latest sendmail patch In-Reply-To: <1143305650.4461.3.camel@mdlinux> References: <004501c65015$208ffb40$0100000a@celsius> <200603250852.15101.lsomike@futzin.com> <1143305650.4461.3.camel@mdlinux> Message-ID: <200603251434.32378.lsomike@futzin.com> On Saturday 25 March 2006 10:54, MD wrote: > On Sat, 2006-03-25 at 08:52 -0600, Mike Klinke wrote: > > There seem to be three missing links on RH9 and FC1: > If you do a "alternatives --config mta" and re-select sendmail, > do the links get created? Yes, they do ( on, at least, my RH9 test box ). Assuming that all that command does is create the necessary linkages for your desired mta, this looks like a good alternative to manually re-adding the links. Thanks!, Mike Klinke From chris at fatorange.com Sat Mar 25 20:42:11 2006 From: chris at fatorange.com (Christian Becker) Date: Sat, 25 Mar 2006 21:42:11 +0100 Subject: RH 9.0: AUTH LOGIN issue with latest sendmail patch In-Reply-To: <20060325203446.CC3C9735C8@hormel.redhat.com> Message-ID: <006101c6504c$9846a120$0400a8c0@chuck> >> There seem to be three missing links on RH9 and FC1: >> >> /usr/lib/sendmail -> >> /etc/alternatives/mta-sendmail >> > /usr/share/man/man8/sendmail.8.gz -> >> /etc/alternatives/mta-sendmailman >> >> /etc/pam.d/smtp -> >> /etc/alternatives/mta-pam >> > >If you do a "alternatives --config mta" and re-select sendmail, do the >links get created? > >Marc. Yes, re-selection creates the correct links. Here is the output of "alternatives --display mta" (after re-selection the status changes to "manual"): mta - status is auto. link currently points to /usr/sbin/sendmail.sendmail /usr/sbin/sendmail.sendmail - priority 90 slave mta-mailq: /usr/bin/mailq.sendmail slave mta-newaliases: /usr/bin/newaliases.sendmail slave mta-rmail: /usr/bin/rmail.sendmail slave mta-sendmail: /usr/lib/sendmail.sendmail slave mta-pam: /etc/pam.d/smtp.sendmail slave mta-sendmailman: /usr/share/man/man8/sendmail.sendmail.8.gz slave mta-mailqman: /usr/share/man/man1/mailq.sendmail.1.gz slave mta-newaliasesman: /usr/share/man/man1/newaliases.sendmail.1.gz slave mta-aliasesman: /usr/share/man/man5/aliases.sendmail.5.gz Current `best' version is /usr/sbin/sendmail.sendmail. Christian Becker From mic at npgx.com.au Sat Mar 25 22:46:08 2006 From: mic at npgx.com.au (Michael Mansour) Date: Sun, 26 Mar 2006 08:46:08 +1000 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <20060325004955.dk8vx8m7aaf4wwwg@mail.ph.utexas.edu> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> <20060324221859.M34444@npgx.com.au> <20060324224856.GA19117@mail.harddata.com> <20060325004955.dk8vx8m7aaf4wwwg@mail.ph.utexas.edu> Message-ID: <20060325224451.M3865@npgx.com.au> Hi Eric, > Quoting Michal Jaegermann : > > > I am not sure in which distro /usr/sbin/alternatives showed up > > for the first time. > > It first showed up in RHL 7.3 as far as RHL goes. It originated in > debian though... > > >> *** ERROR: FEATURE() should be before MAILER() > >> *** ERROR: FEATURE() should be before MAILER() > >> *** ERROR: FEATURE() should be before MAILER() > > Yeah, I got that on a bunch of machines. Just updated my sendmail.mc > to move the FEATURE macros up above the MAILER macros, as it suggests. Checking my FEATURE macros in the sendmail.mc, all of them are above the MAILER macros ie. the MAILER macros are the last two lines of the file. No sure why it produced those errors. Michael. From rostetter at mail.utexas.edu Sun Mar 26 03:43:42 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Sat, 25 Mar 2006 21:43:42 -0600 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <4424EEFF.10106@internode.com.au> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> <1143240096.23491.116.camel@yoda.loki.me> <4424C184.5090000@internode.com.au> <20060325010053.01odujbcsl6owwc8@mail.ph.utexas.edu> <4424EEFF.10106@internode.com.au> Message-ID: <20060325214342.vd2w1rnb55iv44kw@mail.ph.utexas.edu> Quoting Michael Kratz : >> Can you tell what was different between the old .cf and the new one? > > The new cf appeared to be a 'fresh' default config file. > > i.e. only bound to localhost, all my amavis and rbl stuff was missing, etc. I don't doubt this. I just wanted to make sure about it... I didn't pay much attention to the problems I had... I just got in the habit of recovering the sendmail.mc if needed, and rebuilding the sendmail.cf from the sendmail.mc whether it was needed or not... After all, I had to do this update on about 100 machines, and since the update was already QA'd, I just didn't bother taking notes on which machines failed and why, and which machines didn't fail and why... -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From rostetter at mail.utexas.edu Sun Mar 26 04:36:34 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Sat, 25 Mar 2006 22:36:34 -0600 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <4425609C.70506@umd.edu> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> <1143240096.23491.116.camel@yoda.loki.me> <20060324220913.ro57s5usue8kg04w@mail.ph.utexas.edu> <4425609C.70506@umd.edu> Message-ID: <20060325223634.zzexkaph63okkc4o@mail.ph.utexas.edu> Quoting David Eisner : > Eric Rostetter wrote: >> This sounds like what happens when we rush the QA processes... > > Other distros had advance warning about this vulnerability, So did FL technically. > and hence > more time to apply patches and do testing. They didn't have more time to apply patches. They did have more time to do testing, as they have professional (internal) QA testers. > Is there a way Fedora > Legacy could be added to the list of vendors that are notified in this > type of situation? It is. > Who decides whom to notify in advance. Sendmail, Inc.? I imagine they > want vendors to keep the information under wraps until the official > announcement is made. (I could be wrong.) How would this work with > Fedora Legacy? Is it possible? We were notified. We didn't act because it was "bad timing" for FL. But that isn't the issue IMHO. We had an update-testing version out fast. We just shouldn't have pushed it to updates so fast IMHO. > -David -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From rostetter at mail.utexas.edu Sun Mar 26 04:43:50 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Sat, 25 Mar 2006 22:43:50 -0600 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <20060325161712.GC1747@mail.harddata.com> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> <1143240096.23491.116.camel@yoda.loki.me> <20060324220913.ro57s5usue8kg04w@mail.ph.utexas.edu> <4425609C.70506@umd.edu> <20060325161712.GC1747@mail.harddata.com> Message-ID: <20060325224350.au1c0tssq5us0444@mail.ph.utexas.edu> Quoting Michal Jaegermann : > On Sat, Mar 25, 2006 at 10:24:12AM -0500, David Eisner wrote: >> Eric Rostetter wrote: >> >This sounds like what happens when we rush the QA processes... >> >> Other distros had advance warning about this vulnerability, and hence >> more time to apply patches and do testing. > > Personally I _hugely_ prefer fixed packages with minor packaging > imperfections, which BTW can be trivially fixed by whomever is > installing them by adding a link or two, then waiting for something > which installs without a hitch and have a mail server "owned" in the > meantime. Headaches in both cases do not even start to compare. Then you should install from updates-testing for your machines to accomplish that. Not everyone runing linux knows how to create the proper links, or perhaps even how to create a symlink at all. It actually amazes me that no one has suggested runing the proper alternatives command to fix this, and no one has researched if that fixes the problem, rather than suggesting that we manually create the links. > I think that everybody should send Jesse big thanks for preparing > new packages on such short notice. He didn't rush them, at his decision. So if anything you would ask why he didn't rush them, as he considered it not to be an important vulnerability. Why do I say this? Because that is what Jesse says in bugzilla about it. > "New-and-improved", which create > all needed links automatically on an installation, can be issued > later. That doesn't help those who had their mail disabled for hours or days in the meantime. > Of course it would help if people experiencing problems > would try to identify what went wrong (older 'alternatives' do not > work like they should?, some typos in %post scripts?, something > else?). Again, look at what 'rpm -q --scripts sendmail' reports > and check is something is amiss there, as the first step, if you > have seen troubles. I've looked into it, and can't find any reason for the missing symlinks. In fact, I've not had a system with missing symlinks yet. But, I did have some systems that lost their custom sendmail.{mc,cf} files, which is rather unrelated to the symlink issue. > Michal -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From rostetter at mail.utexas.edu Sun Mar 26 05:21:26 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Sat, 25 Mar 2006 23:21:26 -0600 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <20060325224451.M3865@npgx.com.au> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> <20060324221859.M34444@npgx.com.au> <20060324224856.GA19117@mail.harddata.com> <20060325004955.dk8vx8m7aaf4wwwg@mail.ph.utexas.edu> <20060325224451.M3865@npgx.com.au> Message-ID: <20060325232126.tk13tc86rxk0gcwk@mail.ph.utexas.edu> Quoting Michael Mansour : >> >> *** ERROR: FEATURE() should be before MAILER() >> >> *** ERROR: FEATURE() should be before MAILER() >> >> *** ERROR: FEATURE() should be before MAILER() >> >> Yeah, I got that on a bunch of machines. Just updated my sendmail.mc >> to move the FEATURE macros up above the MAILER macros, as it suggests. > > Checking my FEATURE macros in the sendmail.mc, all of them are above the > MAILER macros ie. the MAILER macros are the last two lines of the file. Strange. Anytime I saw this error/warning, it was because I really did have FEATURE after MAILER... Used to be okay I guess, and not it isn't. > No sure why it produced those errors. Only reason I can think of it is was processing some other file than the one you are refering to... > Michael. > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From rostetter at mail.utexas.edu Sun Mar 26 05:58:03 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Sat, 25 Mar 2006 23:58:03 -0600 Subject: sendmail upgrade issues Message-ID: <20060325235803.tnfw1139szwoco4o@mail.ph.utexas.edu> Okay, so I just upgraded a RHL 9 machine's sendmail from FL, and have my first case of missing symlinks. It left my sendmail.mc in place and created a new sendmail.mc.rpmnew. It then created a new sendmail.cf from sendmail.mc.rpmnew! If I do "m4 sendmail.mc.rpmnew sendmail.cf.from.rpmnew" and then if I do "diff sendmail.cf sendmail.cf.from.rpmnew" the only differences are the build time/date/user/etc. If I do a "m4 sendmail.mc sendmail.cf.local" and then if I do "diff sendmail.cf sendmail.cf.local" it has about 40+ changed lines. So, the funny thing is it somehow seems to have created the .cf file from the .rpmnew file... It did not save my old .cf file. I noticed this due to a log message: Mar 25 22:00:08 host sendmail[6927]: STARTTLS=client, error: load verify locs /etc/mail/certs, /etc/mail/certs/cacert.pem failed: 0 My sendmail.mc (and hence my sendmail.cf) has no definition for the certs, but the sendmail.mc.rpmnew does. The only way this could happen is if the sendmail.cf is made from the sendmail.mc.rpmnew IMHO. I also seems to have created a new /etc/rc.d/init.d/sendmail file, without saving the old version, AFAICT. And, as noted, I'm missing some symlinks also. All the symlinks in /etc/alternatives/ look fine. But I'm missing the link from /usr/lib/sendmail and "man sendmail" doesn't work. So, I don't know why any of the above happened, but it all seemed to have happended. Output from "alternatives --display mta" is: mta - status is manual. link currently points to /usr/sbin/sendmail.sendmail /usr/sbin/sendmail.sendmail - priority 90 slave mta-mailq: /usr/bin/mailq.sendmail slave mta-newaliases: /usr/bin/newaliases.sendmail slave mta-rmail: /usr/bin/rmail.sendmail slave mta-sendmail: /usr/lib/sendmail.sendmail slave mta-pam: /etc/pam.d/smtp.sendmail slave mta-sendmailman: /usr/share/man/man8/sendmail.sendmail.8.gz slave mta-mailqman: /usr/share/man/man1/mailq.sendmail.1.gz slave mta-newaliasesman: /usr/share/man/man1/newaliases.sendmail.1.gz slave mta-aliasesman: /usr/share/man/man5/aliases.sendmail.5.gz Current `best' version is /usr/sbin/sendmail.sendmail. For those who think "just create the symlinks and forget about it" it isn't so easy. The sendmail.cf is a default one, without my "smart host/mail hub/local relay" settings, and without my normal masquarading, etc. So this is a broken install now via the upgrade. Mail can be sent out perhaps (not tested) but no one can reply as the reply address won't be correct, etc. I'm leaving this machine broken so if anyone has any questions I can answer them. Note this machine was not rebooted after the upgrade. It is possible that things might change after a reboot. Any questions, let me know... I now have a "test" RHL 9 machine for the issue. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From marcdeslauriers at videotron.ca Sun Mar 26 06:46:15 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sun, 26 Mar 2006 01:46:15 -0500 Subject: sendmail upgrade issues In-Reply-To: <20060325235803.tnfw1139szwoco4o@mail.ph.utexas.edu> References: <20060325235803.tnfw1139szwoco4o@mail.ph.utexas.edu> Message-ID: <1143355575.13651.8.camel@mdlinux> On Sat, 2006-03-25 at 23:58 -0600, Eric Rostetter wrote: > Okay, so I just upgraded a RHL 9 machine's sendmail from FL, and have my > first case of missing symlinks. > The missing symlinks is a known issue. New packages are in bugzilla awaiting QA to fix the issue. > It left my sendmail.mc in place and created a new sendmail.mc.rpmnew. This is reasonable. > It then created a new sendmail.cf from sendmail.mc.rpmnew! > This is not. Did it leave a sendmail.cf.bak file? I have looked through the spec file, through the init file and through the Makefile to try and find some way for that to happen and I have come up empty. What's the date on the sendmail.cf file? What's the date on the sendmail.mc file? What version of the sendmail packages did you have installed beforehand? Could you have had a version that put it's sendmail.cf file in /etc? > If I do "m4 sendmail.mc.rpmnew sendmail.cf.from.rpmnew" and then > if I do "diff sendmail.cf sendmail.cf.from.rpmnew" the only > differences are the build time/date/user/etc. > > If I do a "m4 sendmail.mc sendmail.cf.local" and then > if I do "diff sendmail.cf sendmail.cf.local" it has about > 40+ changed lines. > That is pretty weird. > So, the funny thing is it somehow seems to have created the .cf > file from the .rpmnew file... It did not save my old .cf file. > I am guessing it didn't create the .cf file from the .rpmnew file. It probably just wrote out the sendmail.cf file from the rpm as it either didn't think the sendmail.cf file that was already there belonged to the previous sendmail package, or the sendmail.cf file from the previous package was in a different location. So you have another rh9 machine that still has an old sendmail package on it? > I also seems to have created a new /etc/rc.d/init.d/sendmail file, without > saving the old version, AFAICT. > It should have renamed the old one. > And, as noted, I'm missing some symlinks also. All the symlinks in > /etc/alternatives/ look fine. But I'm missing the link from /usr/lib/sendmail > and "man sendmail" doesn't work. > This is fixed in the package awaiting QA. > I'm leaving this machine broken so if anyone has any questions I can answer > them. > Thank you. Marc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From rostetter at mail.utexas.edu Sun Mar 26 07:38:54 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Sun, 26 Mar 2006 01:38:54 -0600 Subject: sendmail upgrade issues In-Reply-To: <1143355575.13651.8.camel@mdlinux> References: <20060325235803.tnfw1139szwoco4o@mail.ph.utexas.edu> <1143355575.13651.8.camel@mdlinux> Message-ID: <20060326013854.z69t8e3ocy88s0gs@mail.ph.utexas.edu> Quoting Marc Deslauriers : >> It then created a new sendmail.cf from sendmail.mc.rpmnew! >> > > This is not. > > Did it leave a sendmail.cf.bak file? I have looked through the spec > file, through the init file and through the Makefile to try and find > some way for that to happen and I have come up empty. What's the date on > the sendmail.cf file? What's the date on the sendmail.mc file? No, it did not leave a *.bak file. The files are: $ ls -l sendmail* -rw-r--r-- 1 root root 57671 Mar 25 19:54 sendmail.cf -rw-r--r-- 1 root root 57628 Mar 25 23:32 sendmail.cf.from.rpmnew -rw-r--r-- 1 root root 58337 Mar 25 23:33 sendmail.cf.local -rw-r--r-- 1 root root 5962 Apr 19 2004 sendmail.mc -rw-r--r-- 1 root root 6097 Mar 22 23:33 sendmail.mc.rpmnew $ ls -lc sendmail* -rw-r--r-- 1 root root 57671 Mar 25 19:54 sendmail.cf -rw-r--r-- 1 root root 57628 Mar 25 23:32 sendmail.cf.from.rpmnew -rw-r--r-- 1 root root 58337 Mar 25 23:33 sendmail.cf.local -rw-r--r-- 1 root root 5962 Apr 19 2004 sendmail.mc -rw-r--r-- 1 root root 6097 Mar 25 19:54 sendmail.mc.rpmnew $ As noted, I created the *.cf.from.rpmnew and *.cf.local for comparison purposes. The upgrade was obviously done around March 25 19:54. > What version of the sendmail packages did you have installed beforehand? > Could you have had a version that put it's sendmail.cf file in /etc? Not sure. There was a /etc/sendmail.cf file on the machine: -rw-r--r-- 1 root root 58223 Apr 19 2004 /etc/sendmail.cf So, at least at one time, it did have a sendmail that did put at least sendmail.cf in /etc/ rather than /etc/mail/. There is also a /etc/aliases on the machine: -rw-r--r-- 1 root root 1343 Mar 25 19:54 /etc/aliases But I think that is still normal? > I am guessing it didn't create the .cf file from the .rpmnew file. It > probably just wrote out the sendmail.cf file from the rpm as it either > didn't think the sendmail.cf file that was already there belonged to the > previous sendmail package, or the sendmail.cf file from the previous > package was in a different location. Probably it was the later. > So you have another rh9 machine that still has an old sendmail package > on it? I think I might have one for immediate access. I might also have another one but I won't have access to it until probably Wednesday. >> I also seems to have created a new /etc/rc.d/init.d/sendmail file, without >> saving the old version, AFAICT. >> > > It should have renamed the old one. I've seen it do it both ways (saving and not saving) and have no idea why... But then, I'm doing these on various systems running RHL 7.3, RHL 9, and RHEL 3.x, so the results vary... > This is fixed in the package awaiting QA. I never received an email about any such package... >> I'm leaving this machine broken so if anyone has any questions I can answer >> them. >> > > Thank you. > > Marc. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From rostetter at mail.utexas.edu Sun Mar 26 07:44:08 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Sun, 26 Mar 2006 01:44:08 -0600 Subject: sendmail upgrade issues In-Reply-To: <20060326013854.z69t8e3ocy88s0gs@mail.ph.utexas.edu> References: <20060325235803.tnfw1139szwoco4o@mail.ph.utexas.edu> <1143355575.13651.8.camel@mdlinux> <20060326013854.z69t8e3ocy88s0gs@mail.ph.utexas.edu> Message-ID: <20060326014408.2fbyhi6q4b4c8s00@mail.ph.utexas.edu> Quoting Eric Rostetter : >> So you have another rh9 machine that still has an old sendmail package >> on it? > > I think I might have one for immediate access. I might also have another > one but I won't have access to it until probably Wednesday. The one I had in mind is runing sendmail 8.12.8.9.90, but it does not have a /etc/sendmail.cf, so it probably won't act the same way as the one in this discussion, if indeed the problem is the location of sendmail.cf files. I'll have to get back to you on the other machine, but that may not be until Wednesday. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From rostetter at mail.utexas.edu Sun Mar 26 07:46:47 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Sun, 26 Mar 2006 01:46:47 -0600 Subject: sendmail upgrade issues In-Reply-To: <20060326013854.z69t8e3ocy88s0gs@mail.ph.utexas.edu> References: <20060325235803.tnfw1139szwoco4o@mail.ph.utexas.edu> <1143355575.13651.8.camel@mdlinux> <20060326013854.z69t8e3ocy88s0gs@mail.ph.utexas.edu> Message-ID: <20060326014647.69doi4cyc8qsgggk@mail.ph.utexas.edu> Quoting Eric Rostetter : >> What version of the sendmail packages did you have installed beforehand? >> Could you have had a version that put it's sendmail.cf file in /etc? Looks like it was _probably_ running sendmail 8.12.8-9.90.i386 before. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From marcdeslauriers at videotron.ca Sun Mar 26 15:05:01 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sun, 26 Mar 2006 10:05:01 -0500 Subject: sendmail upgrade issues In-Reply-To: <20060326014408.2fbyhi6q4b4c8s00@mail.ph.utexas.edu> References: <20060325235803.tnfw1139szwoco4o@mail.ph.utexas.edu> <1143355575.13651.8.camel@mdlinux> <20060326013854.z69t8e3ocy88s0gs@mail.ph.utexas.edu> <20060326014408.2fbyhi6q4b4c8s00@mail.ph.utexas.edu> Message-ID: <1143385502.4995.4.camel@mdlinux> On Sun, 2006-03-26 at 01:44 -0600, Eric Rostetter wrote: > Quoting Eric Rostetter : > > >> So you have another rh9 machine that still has an old sendmail package > >> on it? > > > > I think I might have one for immediate access. I might also have another > > one but I won't have access to it until probably Wednesday. Do you think you could do a "rpm -Uvvv" so we could get the output. If it goes wrong, we'll have something to look at. Marc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From marcdeslauriers at videotron.ca Sun Mar 26 15:24:42 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sun, 26 Mar 2006 10:24:42 -0500 Subject: sendmail upgrade issues In-Reply-To: <20060326013854.z69t8e3ocy88s0gs@mail.ph.utexas.edu> References: <20060325235803.tnfw1139szwoco4o@mail.ph.utexas.edu> <1143355575.13651.8.camel@mdlinux> <20060326013854.z69t8e3ocy88s0gs@mail.ph.utexas.edu> Message-ID: <1143386683.4995.6.camel@mdlinux> On Sun, 2006-03-26 at 01:38 -0600, Eric Rostetter wrote: > > This is fixed in the package awaiting QA. > > I never received an email about any such package... > I didn't know I had to send you one. :) Look here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186277 Marc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From rostetter at mail.utexas.edu Sun Mar 26 17:39:23 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Sun, 26 Mar 2006 11:39:23 -0600 Subject: sendmail upgrade issues In-Reply-To: <1143386683.4995.6.camel@mdlinux> References: <20060325235803.tnfw1139szwoco4o@mail.ph.utexas.edu> <1143355575.13651.8.camel@mdlinux> <20060326013854.z69t8e3ocy88s0gs@mail.ph.utexas.edu> <1143386683.4995.6.camel@mdlinux> Message-ID: <20060326113923.ishby8gycv0owccc@mail.ph.utexas.edu> Quoting Marc Deslauriers : > On Sun, 2006-03-26 at 01:38 -0600, Eric Rostetter wrote: > >> > This is fixed in the package awaiting QA. >> >> I never received an email about any such package... >> > > I didn't know I had to send you one. :) I guess it is confusing to say "awaiting QA" since we have two forms of QA. I kind of assumed you meant it was in updates-testing, in which case there is usually an e-mail sent out. I guess you mean it is in step one though, were no e-mail is sent out... > Look here: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186277 > > Marc. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From rostetter at mail.utexas.edu Sun Mar 26 18:03:16 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Sun, 26 Mar 2006 12:03:16 -0600 Subject: sendmail upgrade issues In-Reply-To: <1143385502.4995.4.camel@mdlinux> References: <20060325235803.tnfw1139szwoco4o@mail.ph.utexas.edu> <1143355575.13651.8.camel@mdlinux> <20060326013854.z69t8e3ocy88s0gs@mail.ph.utexas.edu> <20060326014408.2fbyhi6q4b4c8s00@mail.ph.utexas.edu> <1143385502.4995.4.camel@mdlinux> Message-ID: <20060326120316.fl0m87da31ckgg84@mail.ph.utexas.edu> Quoting Marc Deslauriers : > On Sun, 2006-03-26 at 01:44 -0600, Eric Rostetter wrote: >> Quoting Eric Rostetter : >> >> >> So you have another rh9 machine that still has an old sendmail package >> >> on it? >> > >> > I think I might have one for immediate access. I might also have another >> > one but I won't have access to it until probably Wednesday. > > Do you think you could do a "rpm -Uvvv" so we could get the output. If > it goes wrong, we'll have something to look at. > > Marc. Well, sorry, I messed it up. I did: "rpm -Fhvvv sendmail*.rpm | tee /tmp/sendmail.log" Which gave me almost nothing... I should have done: "rpm -Fhvvv sendmail*.rpm 2>&1 | tee /tmp/sendmail.log" instead. My scrollback buffer isn't big enough to catch the output completely. Later, I'll see if I can't reverse the changes and try again, but that won't be for a while... BTW, do you want me to do this with the released update or with the one proposed for QA? -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From cradle at umd.edu Sun Mar 26 18:56:27 2006 From: cradle at umd.edu (David Eisner) Date: Sun, 26 Mar 2006 13:56:27 -0500 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <20060325223634.zzexkaph63okkc4o@mail.ph.utexas.edu> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> <1143240096.23491.116.camel@yoda.loki.me> <20060324220913.ro57s5usue8kg04w@mail.ph.utexas.edu> <4425609C.70506@umd.edu> <20060325223634.zzexkaph63okkc4o@mail.ph.utexas.edu> Message-ID: <4426E3DB.7000005@umd.edu> Eric Rostetter wrote: > We were notified. We didn't act because it was "bad timing" for FL. On what day were you notified? -David From jkeating at j2solutions.net Sun Mar 26 19:03:21 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 26 Mar 2006 11:03:21 -0800 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <4426E3DB.7000005@umd.edu> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> <1143240096.23491.116.camel@yoda.loki.me> <20060324220913.ro57s5usue8kg04w@mail.ph.utexas.edu> <4425609C.70506@umd.edu> <20060325223634.zzexkaph63okkc4o@mail.ph.utexas.edu> <4426E3DB.7000005@umd.edu> Message-ID: <1143399802.3242.21.camel@ender> On Sun, 2006-03-26 at 13:56 -0500, David Eisner wrote: > On what day were you notified? We weren't. As I said before, this was a CERT driven announcement, and only those that have a pre-existing agreement w/ CERT got the notice before the embargo date. Fedora Legacy has no such agreement w/ CERT at this time, but I will be pursuing one. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From rostetter at mail.utexas.edu Mon Mar 27 04:16:45 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Sun, 26 Mar 2006 22:16:45 -0600 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <4426E3DB.7000005@umd.edu> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> <1143240096.23491.116.camel@yoda.loki.me> <20060324220913.ro57s5usue8kg04w@mail.ph.utexas.edu> <4425609C.70506@umd.edu> <20060325223634.zzexkaph63okkc4o@mail.ph.utexas.edu> <4426E3DB.7000005@umd.edu> Message-ID: <20060326221645.btfyqqnu4vsw8cc4@mail.ph.utexas.edu> Quoting David Eisner : > Eric Rostetter wrote: >> We were notified. We didn't act because it was "bad timing" for FL. > > On what day were you notified? > > -David All I know is that in bug 186277 it says: > Comment #13 From Jesse Keating on 2006-03-23 11:58 EST [reply] > I did have advance notice and I was on vendor-sec. However like > you said this > was a hard hole to exploit, and we were in the middle of upgrading our build > system. Had this been an easier hole to exploit, we would have had test > packages ready prior to the public announcement. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From Mike.McCarty at sbcglobal.net Mon Mar 27 05:48:15 2006 From: Mike.McCarty at sbcglobal.net (Mike McCarty) Date: Sun, 26 Mar 2006 23:48:15 -0600 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <20060324220913.ro57s5usue8kg04w@mail.ph.utexas.edu> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> <1143240096.23491.116.camel@yoda.loki.me> <20060324220913.ro57s5usue8kg04w@mail.ph.utexas.edu> Message-ID: <44277C9F.7070606@sbcglobal.net> Eric Rostetter wrote: > Quoting Jesse Keating : > >> On Fri, 2006-03-24 at 16:17 -0600, Mike Klinke wrote: >> >>> There is instead an entry in /usr/lib; "sendmail.sendmail" which >>> is linked to /usr/sbin/sendmail. Also the man pages no longer work >>> if you type; "man sendmail" You have to use "man >>> sendmail.sendmail". >> >> >> This sounds like the Alternatives system got confused and wasn't making >> the links that it was supposed to, as stated in the spec file. Hrm. > > > This sounds like what happens when we rush the QA processes... > > I've stopped trying to do QA because by the time I download the testing > version, install it, and start testing it, and well before I can submit > a report, the package gets released... Very frustrating. Ah, now we get down to the nitty gritty of the desire to hasten the process of going from a Test state to a Release state. Hopefully, those who in past have seen no need to maintain a policy of "no package can move from Test state to Release state unless it has actually gone through test to prove proper operation" and want to change to one of "if enough time has lapsed, then even if no verification of proper operation has taken place, we need to move from Test state to Release state" can see a little bit of the other side of the fence, now. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From Mike.McCarty at sbcglobal.net Mon Mar 27 05:51:34 2006 From: Mike.McCarty at sbcglobal.net (Mike McCarty) Date: Sun, 26 Mar 2006 23:51:34 -0600 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <20060325161712.GC1747@mail.harddata.com> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> <1143240096.23491.116.camel@yoda.loki.me> <20060324220913.ro57s5usue8kg04w@mail.ph.utexas.edu> <4425609C.70506@umd.edu> <20060325161712.GC1747@mail.harddata.com> Message-ID: <44277D66.1000107@sbcglobal.net> Michal Jaegermann wrote: > On Sat, Mar 25, 2006 at 10:24:12AM -0500, David Eisner wrote: > >>Eric Rostetter wrote: >> >>>This sounds like what happens when we rush the QA processes... >> >>Other distros had advance warning about this vulnerability, and hence >>more time to apply patches and do testing. > > > Personally I _hugely_ prefer fixed packages with minor packaging > imperfections, which BTW can be trivially fixed by whomever is But, next time it may not be "minor packaging imperfections which can be trivially fixed". > installing them by adding a link or two, then waiting for something > which installs without a hitch and have a mail server "owned" in the > meantime. Headaches in both cases do not even start to compare. > > I think that everybody should send Jesse big thanks for preparing I'll second that, as well. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From theyaga at gmail.com Mon Mar 27 13:04:38 2006 From: theyaga at gmail.com (S Theyagarajan ) Date: Mon, 27 Mar 2006 18:34:38 +0530 Subject: Hi all Message-ID: <19d5c040603270504t1379c23br2d4b2baf81e7a0e8@mail.gmail.com> Hi people, iam S.Theyagarajan, a sophomore at National Institute Of technology trichy India. Iam glad to join in here. and i have been in to many opensource projects. and i just found there are some vacancies. I love writing technical documentations and security management. I would be glad if i am given an opportunity to contribute . Thanks Taggy -- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS dpu s+:-- a--- C++++ UL+++ P+ L++++ E+++ W+++ N++ o+ K- w--- O+++ M- V- PS+ PE++ Y+++ PGP++ 5-- X-- R* tv b+++ DI+ D---- G++ e++ h* r++ y ------END GEEK CODE BLOCK------ TO DECODE THIS :go to http://www.ebb.org/ungeek/ and know more abt me ********************************************************************************** S.Theyagarajan Under Graduate Department Of Computer Science And Engineering National Institute Of Technology , Trichirapalli India 620015 Contact : Diamond Hostel room 24 NIT Trichy email : theyaga at gmail.com , Phone :+919245487992 ********************************************************************************** From marcdeslauriers at videotron.ca Mon Mar 27 13:07:58 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 27 Mar 2006 08:07:58 -0500 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <44277C9F.7070606@sbcglobal.net> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> <1143240096.23491.116.camel@yoda.loki.me> <20060324220913.ro57s5usue8kg04w@mail.ph.utexas.edu> <44277C9F.7070606@sbcglobal.net> Message-ID: <1143464878.7900.7.camel@mdlinux> On Sun, 2006-03-26 at 23:48 -0600, Mike McCarty wrote: > Ah, now we get down to the nitty gritty of the desire to hasten > the process of going from a Test state to a Release state. Hopefully, > those who in past have seen no need to maintain a policy of "no package > can move from Test state to Release state unless it has actually gone > through test to prove proper operation" and want to change to one of > "if enough time has lapsed, then even if no verification of proper > operation has taken place, we need to move from Test state to Release > state" can see a little bit of the other side of the fence, now. Curiously, sendmail actually DID get test votes for all platforms before it got moved to official updates. No part of the QA process was hastened. This has happened before. Most packages that got pushed out that had serious problems had been through QA and had people test them. One of the php updates is an example I know of. Marc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From guallar at easternrad.com Mon Mar 27 13:12:57 2006 From: guallar at easternrad.com (Josep L. Guallar-Esteve) Date: Mon, 27 Mar 2006 08:12:57 -0500 Subject: Hi all In-Reply-To: <19d5c040603270504t1379c23br2d4b2baf81e7a0e8@mail.gmail.com> References: <19d5c040603270504t1379c23br2d4b2baf81e7a0e8@mail.gmail.com> Message-ID: <200603270813.00087.guallar@easternrad.com> On Monday 27 March 2006 08:04, S Theyagarajan wrote: > Hi people, > iam S.Theyagarajan, a sophomore at National Institute > Of technology trichy India. > Iam glad to join in here. and i have been in to many opensource > projects. and i just found there are some vacancies. > > I love writing technical documentations and security management. > I would be glad if i am given an opportunity to contribute . > > Thanks > Taggy > -- Hi Taggy, Welcome on-board. Your documentation skills surely will be very useful to Fedora Legacy Project. Regards, Josep -- Josep L. Guallar-Esteve -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From rostetter at mail.utexas.edu Mon Mar 27 15:39:30 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 27 Mar 2006 09:39:30 -0600 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <44277D66.1000107@sbcglobal.net> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> <1143240096.23491.116.camel@yoda.loki.me> <20060324220913.ro57s5usue8kg04w@mail.ph.utexas.edu> <4425609C.70506@umd.edu> <20060325161712.GC1747@mail.harddata.com> <44277D66.1000107@sbcglobal.net> Message-ID: <20060327093930.vuwor2mdgpes8k4c@mail.ph.utexas.edu> Quoting Mike McCarty : >> I think that everybody should send Jesse big thanks for preparing > > I'll second that, as well. > > Mike Depsite any differences I have with the Fedora Legacy Project, I very much appreciate all that Jesse has done for the project. Without him there wouldn't be a FL Project. And I know he works very hard on the project, and spends a lot of time on the project, and at least until very recently when he joined Red Hat all he got for it was a bunch of hassles. So, thanks Jesse! I _do_ appreciate all you put into the project. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From jkeating at j2solutions.net Mon Mar 27 15:51:05 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 27 Mar 2006 07:51:05 -0800 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <20060326221645.btfyqqnu4vsw8cc4@mail.ph.utexas.edu> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> <1143240096.23491.116.camel@yoda.loki.me> <20060324220913.ro57s5usue8kg04w@mail.ph.utexas.edu> <4425609C.70506@umd.edu> <20060325223634.zzexkaph63okkc4o@mail.ph.utexas.edu> <4426E3DB.7000005@umd.edu> <20060326221645.btfyqqnu4vsw8cc4@mail.ph.utexas.edu> Message-ID: <1143474666.3242.29.camel@ender> On Sun, 2006-03-26 at 22:16 -0600, Eric Rostetter wrote: > All I know is that in bug 186277 it says: > > > Comment #13 From Jesse Keating on 2006-03-23 11:58 EST [reply] > > I did have advance notice and I was on vendor-sec. However like > > you said this > > was a hard hole to exploit, and we were in the middle of upgrading our build > > system. Had this been an easier hole to exploit, we would have had test > > packages ready prior to the public announcement. Thats my fault. I confused CVE issues. Some other things came through vendor-sec, this one didn't. My bad. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From rostetter at mail.utexas.edu Mon Mar 27 16:33:36 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 27 Mar 2006 10:33:36 -0600 Subject: Hi all In-Reply-To: <19d5c040603270504t1379c23br2d4b2baf81e7a0e8@mail.gmail.com> References: <19d5c040603270504t1379c23br2d4b2baf81e7a0e8@mail.gmail.com> Message-ID: <20060327103336.m95rmahwquck00w8@mail.ph.utexas.edu> Quoting S Theyagarajan : > Hi people, > iam S.Theyagarajan, a sophomore at National Institute > Of technology trichy India. > Iam glad to join in here. and i have been in to many opensource > projects. and i just found there are some vacancies. > > I love writing technical documentations and security management. > I would be glad if i am given an opportunity to contribute . We can use help with documentation. But you may also want to check out the Fedor Documentation Project (http://fedora.redhat.com/projects/docs/) if you want to do more... > Thanks > Taggy -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From rostetter at mail.utexas.edu Mon Mar 27 16:42:09 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 27 Mar 2006 10:42:09 -0600 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <1143464878.7900.7.camel@mdlinux> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> <1143240096.23491.116.camel@yoda.loki.me> <20060324220913.ro57s5usue8kg04w@mail.ph.utexas.edu> <44277C9F.7070606@sbcglobal.net> <1143464878.7900.7.camel@mdlinux> Message-ID: <20060327104209.iqbp1yrcx3i80swk@mail.ph.utexas.edu> Quoting Marc Deslauriers : > Curiously, sendmail actually DID get test votes for all platforms before > it got moved to official updates. No part of the QA process was > hastened. True, for the _current_ QA process. But not for the original QA process. The main problem I've had is that I've not had the required 4 days between the updates-testing e-mail notice and the released to updates e-mail notice. I don't know if this is because they are being released early, or because the mailing list was slow... > This has happened before. Most packages that got pushed out that had > serious problems had been through QA and had people test them. One of > the php updates is an example I know of. Yes, but they often have only a few people testing them, with only one vote per OS version... Not much QA really... > Marc. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From Mike.McCarty at sbcglobal.net Mon Mar 27 18:39:47 2006 From: Mike.McCarty at sbcglobal.net (Mike McCarty) Date: Mon, 27 Mar 2006 12:39:47 -0600 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <1143464878.7900.7.camel@mdlinux> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> <1143240096.23491.116.camel@yoda.loki.me> <20060324220913.ro57s5usue8kg04w@mail.ph.utexas.edu> <44277C9F.7070606@sbcglobal.net> <1143464878.7900.7.camel@mdlinux> Message-ID: <44283173.1090805@sbcglobal.net> Marc Deslauriers wrote: > On Sun, 2006-03-26 at 23:48 -0600, Mike McCarty wrote: > >>Ah, now we get down to the nitty gritty of the desire to hasten >>the process of going from a Test state to a Release state. Hopefully, >>those who in past have seen no need to maintain a policy of "no package >>can move from Test state to Release state unless it has actually gone >>through test to prove proper operation" and want to change to one of >>"if enough time has lapsed, then even if no verification of proper >>operation has taken place, we need to move from Test state to Release >>state" can see a little bit of the other side of the fence, now. > > > Curiously, sendmail actually DID get test votes for all platforms before > it got moved to official updates. No part of the QA process was > hastened. Yes, I saw that. But I worded my statement very carefully. I carefully used the wording "test to prove proper operation", not "normal test procedures". Looking back on it, I should not have used the word "maintain" in the exact context, since combining it with the word "change" has caused you to infer that I consider that current test procedure is one which verifies proper operation. I did not mean to imply that. > This has happened before. Most packages that got pushed out that had > serious problems had been through QA and had people test them. One of > the php updates is an example I know of. > > Marc. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From Mike.McCarty at sbcglobal.net Mon Mar 27 18:41:54 2006 From: Mike.McCarty at sbcglobal.net (Mike McCarty) Date: Mon, 27 Mar 2006 12:41:54 -0600 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <20060327104209.iqbp1yrcx3i80swk@mail.ph.utexas.edu> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> <1143240096.23491.116.camel@yoda.loki.me> <20060324220913.ro57s5usue8kg04w@mail.ph.utexas.edu> <44277C9F.7070606@sbcglobal.net> <1143464878.7900.7.camel@mdlinux> <20060327104209.iqbp1yrcx3i80swk@mail.ph.utexas.edu> Message-ID: <442831F2.2060602@sbcglobal.net> Eric Rostetter wrote: > Quoting Marc Deslauriers : > >> Curiously, sendmail actually DID get test votes for all platforms before >> it got moved to official updates. No part of the QA process was >> hastened. > > > True, for the _current_ QA process. But not for the original QA process. I don't know what that difference may have been. I do consider current QA process to be, umm, inadequate. [snip] >> This has happened before. Most packages that got pushed out that had >> serious problems had been through QA and had people test them. One of >> the php updates is an example I know of. > > > Yes, but they often have only a few people testing them, with only one > vote per OS version... Not much QA really... Amen, brother! Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From jkosin at beta.intcomgrp.com Mon Mar 27 18:43:27 2006 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Mon, 27 Mar 2006 13:43:27 -0500 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <1143240096.23491.116.camel@yoda.loki.me> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> <1143240096.23491.116.camel@yoda.loki.me> Message-ID: <4428324F.8010800@beta.intcomgrp.com> Jesse Keating wrote: > On Fri, 2006-03-24 at 16:17 -0600, Mike Klinke wrote: > >> There is instead an entry in /usr/lib; "sendmail.sendmail" which >> is linked to /usr/sbin/sendmail. Also the man pages no longer work >> if you type; "man sendmail" You have to use "man >> sendmail.sendmail". >> > > This sounds like the Alternatives system got confused and wasn't making > the links that it was supposed to, as stated in the spec file. Hrm. > > Jesse, BACK FROM HAVING A BABY! At least my wife did. Sounds like something didn't get built correctly. Was this a new release of sendmail or a patch? I believe my packages needed (or at least I let them build a -cf package) at one point. My version has been working for some time with no problems with man or other changes. Did the SPEC file change significantly? I guess I can download and compare to my packages. Thanks, James PS: I don't want everyone to start saying Congratulations. It isn't a good response on list. -- Scanned by ClamAV - http://www.clamav.net From jkeating at j2solutions.net Mon Mar 27 18:47:06 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 27 Mar 2006 10:47:06 -0800 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <4428324F.8010800@beta.intcomgrp.com> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> <1143240096.23491.116.camel@yoda.loki.me> <4428324F.8010800@beta.intcomgrp.com> Message-ID: <1143485227.3242.51.camel@ender> On Mon, 2006-03-27 at 13:43 -0500, James Kosin wrote: > Sounds like something didn't get built correctly. Was this a new > release of sendmail or a patch? > I believe my packages needed (or at least I let them build a -cf > package) at one point. My version has been working for some time with > no problems with man or other changes. > > Did the SPEC file change significantly? The patches supplied by Sendmail did not apply to older releases, so all releases had to be updated to 8.12.11. RHEL set a precedent on this when they updated the version on RHEL2.1. The spec did change in many ways, and unfortunately I didn't catch the significance of the changes w/regard to alternatives. These issues should be resolved in the newer packages in updates-testing. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From jkosin at beta.intcomgrp.com Mon Mar 27 19:13:13 2006 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Mon, 27 Mar 2006 14:13:13 -0500 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <1143485227.3242.51.camel@ender> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> <1143240096.23491.116.camel@yoda.loki.me> <4428324F.8010800@beta.intcomgrp.com> <1143485227.3242.51.camel@ender> Message-ID: <44283949.1070102@beta.intcomgrp.com> Jesse Keating wrote: > On Mon, 2006-03-27 at 13:43 -0500, James Kosin wrote: > >> Sounds like something didn't get built correctly. Was this a new >> release of sendmail or a patch? >> I believe my packages needed (or at least I let them build a -cf >> package) at one point. My version has been working for some time with >> no problems with man or other changes. >> >> Did the SPEC file change significantly? >> > > The patches supplied by Sendmail did not apply to older releases, so all > releases had to be updated to 8.12.11. RHEL set a precedent on this > when they updated the version on RHEL2.1. The spec did change in many > ways, and unfortunately I didn't catch the significance of the changes > w/regard to alternatives. > > These issues should be resolved in the newer packages in > updates-testing. > > Thanks, Glad to here you got it straighted out. I do have the original spec file for FC1 modified to work with 8.13.5 some time back... Of course, I added a patch now for the latest updates, got back and saw all the commotion about sendmail, which I use significantly. And didn't see any of the reported problems with my system. I just wanted to be sure I couldn't be of some help now that I'm back. James -- Scanned by ClamAV - http://www.clamav.net From paul at welshfamily.com Mon Mar 27 19:31:58 2006 From: paul at welshfamily.com (Paul Welsh) Date: Mon, 27 Mar 2006 20:31:58 +0100 Subject: Sendmail stuff-up In-Reply-To: Message-ID: <200603271932.k2RJWD4b002658@mx3.redhat.com> Well, I applied the latest patch to my Sendmail config and have managed to stuff it up well and truly. I am running RH9 and Sendmail 8.12.11.20060308/8.12.8. SMTP authentication stopped working first and in trying to fix it I managed to tie myself in knots. I ended up with errors like this: Mar 27 15:29:01 mail sendmail[16518]: NOQUEUE: SYSERR(root): /etc/mail/sendmail.cf: line 84: fileclass: cannot open 'ATURE(`access_db',`hash': No such file or directory In the end, I deleted sendmail.cf and sendmail.mc and forced rpm to install the new version again. This solved the above problem and Sendmail is now working to a degree, ie, those hosts in /etc/mail/access are able to relay mail, which is fine. Mail is delivered to pop3 accounts. However, I'm getting these errors: Mar 27 18:27:41 mail sendmail[641]: STARTTLS=server, error: SSL_CTX_check_private_key failed(/etc/mail/certs/key.pem): 0 I'm also getting this: Mar 27 18:07:07 mail sendmail[18011]: k2RH75f9018011: from=, size=1936, class=0, nrcpts=1, msgid=<000001c651c0$ca70ab30$5abfa8c0 at hwg48>, proto=ESMTP, daemon=MTA, relay=myrelay.net [193.111.201.133] Mar 27 18:07:07 mail sendmail[18011]: k2RH75f9018011: to=, delay=00:00:01, mailer=esmtp, pri=31936, stat=queued Mar 27 18:07:28 mail sendmail[18310]: k2RH75f9018011: SYSERR(root): mydomain.net. config error: mail loops back to me (MX problem?) Mar 27 18:07:28 mail sendmail[18310]: k2RH75f9018011: to=, delay=00:00:22, xdelay=00:00:00, mailer=esmtp, pri=121936, relay=mydomain.net. [84.234.16.235], dsn=5.3.5, stat=Local configuration error Mar 27 18:07:28 mail sendmail[18310]: k2RH75f9018011: k2RH7RE5018310: DSN: Local configuration error Where myrelay.net is my relay server and mydomain.net is the default domain on the server (Sendmail answers as mail.mydomain.net). The message is spam being sent to an invalid address. Other invalid addresses are treated better - I get "no such user here" in the log, but also "stat=Local configuration error". Any pointers much appreciated. Getting smtp auth with plain text to work would be great too! From lsomike at futzin.com Mon Mar 27 19:43:55 2006 From: lsomike at futzin.com (Mike Klinke) Date: Mon, 27 Mar 2006 13:43:55 -0600 Subject: Sendmail stuff-up In-Reply-To: <200603271932.k2RJWD4b002658@mx3.redhat.com> References: <200603271932.k2RJWD4b002658@mx3.redhat.com> Message-ID: <200603271343.55976.lsomike@futzin.com> On Monday 27 March 2006 13:31, Paul Welsh wrote: > Well, I applied the latest patch to my Sendmail config and have > managed to stuff it up well and truly. ?I am running RH9 and > Sendmail 8.12.11.20060308/8.12.8. The latest patch or the rpm? If the rpm that was released, you should see "sendmail-8.12.11-4.24.1.legacy". In either case you'll want to read through the bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186277 Regards, Mike Klinke From marcdeslauriers at videotron.ca Mon Mar 27 23:36:26 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 27 Mar 2006 18:36:26 -0500 Subject: New sendmail and missing /usr/lib/sendmail In-Reply-To: <1143485227.3242.51.camel@ender> References: <38B44F665F3F012CD404C402@[10.169.6.226]> <1143115802.6809.1.camel@mdlinux> <4424405A.1060303@umd.edu> <200603241617.14987.lsomike@futzin.com> <1143240096.23491.116.camel@yoda.loki.me> <4428324F.8010800@beta.intcomgrp.com> <1143485227.3242.51.camel@ender> Message-ID: <1143502586.10523.16.camel@mdlinux> On Mon, 2006-03-27 at 10:47 -0800, Jesse Keating wrote: > These issues should be resolved in the newer packages in > updates-testing. They're not in updates-testing yet. They're still awaiting PUBLISH votes in bugzilla. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186277 Marc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From rbearpark.nospam at gmail.com Tue Mar 28 12:13:08 2006 From: rbearpark.nospam at gmail.com (Ralph Bearpark) Date: Tue, 28 Mar 2006 14:13:08 +0200 Subject: Sendmail Patch Breaks Virtusertable Settings Message-ID: <1e81e0190603280413y187281a2k59dbea9184dfeae7@mail.gmail.com> So, I noticed that yesterday's sendmail patch on FC1 broke my virtusertable settings (catch-all addresses "@domain.tld" are not being forwarded to username as spec-ed but are bounced as "user unknown". Now, through looking at redhat bugzilla I see that there was some form a FU with sendmail config files for the sendmail patch. What I don't find is a clear statement on how I should remedy the FU. Do I get my config file from backup? Or re-do m4? Or await a new patch? Or what? A clear statement of advice - either here in the maillist or under advisories (http://www.fedoralegacy.org/updates/FC1/) would be very welcome/necessary. Thanks in anticipation. From pekkas at netcore.fi Tue Mar 28 12:21:38 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 28 Mar 2006 15:21:38 +0300 (EEST) Subject: Sendmail Patch Breaks Virtusertable Settings In-Reply-To: <1e81e0190603280413y187281a2k59dbea9184dfeae7@mail.gmail.com> References: <1e81e0190603280413y187281a2k59dbea9184dfeae7@mail.gmail.com> Message-ID: On Tue, 28 Mar 2006, Ralph Bearpark wrote: > Do I get my config file from backup? Or re-do m4? Or await a new > patch? Or what? > > A clear statement of advice - either here in the maillist or under > advisories (http://www.fedoralegacy.org/updates/FC1/) would be very > welcome/necessary. If you could test with the packages at: http://turbosphere.fedoralegacy.org/logs/fedora-1-core/69-sendmail-8.12.11-4.25.3.legacy/ , and report success/failure, it would be very helpful. If it doesn't help, you should probably do a bit of diffing to see what changed -- did .cf file change? Was it generated from Fedora Legacy or by you? What were the .mc file differences? -- 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 rbearpark.nospam at gmail.com Tue Mar 28 20:16:13 2006 From: rbearpark.nospam at gmail.com (Ralph Bearpark) Date: Tue, 28 Mar 2006 22:16:13 +0200 Subject: Sendmail Patch Breaks Virtusertable Settings In-Reply-To: References: <1e81e0190603280413y187281a2k59dbea9184dfeae7@mail.gmail.com> Message-ID: <1e81e0190603281216j4e70c1a9u1721f1dd7840441c@mail.gmail.com> On 3/28/06, Pekka Savola wrote: > On Tue, 28 Mar 2006, Ralph Bearpark wrote: > > Do I get my config file from backup? Or re-do m4? Or await a new > > patch? Or what? > > > > A clear statement of advice - either here in the maillist or under > > advisories (http://www.fedoralegacy.org/updates/FC1/) would be very > > welcome/necessary. > > If you could test with the packages at: > > http://turbosphere.fedoralegacy.org/logs/fedora-1-core/69-sendmail-8.12.11-4.25.3.legacy/ > > , and report success/failure, it would be very helpful. Sorry, but I was more concentrated on getting my system running again ASAP. I restored the sendmail.mc and sendmail.cf files from my backup and was surprised to find them unchanged post-patch. It seems the patch didn't actually change these config files (contrary to reports hereabouts). Then I looked into the virtusertable. I did a new makemap of the virtusertable.db and was surprised when the catch-all addresses started to work again. I am left wondering if this sendmail patch actually wiped virtusertable.db. But why would it do that? Regards, Ralph. From rbearpark.nospam at gmail.com Tue Mar 28 20:37:37 2006 From: rbearpark.nospam at gmail.com (Ralph Bearpark) Date: Tue, 28 Mar 2006 22:37:37 +0200 Subject: Sendmail Patch Breaks Virtusertable Settings In-Reply-To: <1e81e0190603281216j4e70c1a9u1721f1dd7840441c@mail.gmail.com> References: <1e81e0190603280413y187281a2k59dbea9184dfeae7@mail.gmail.com> <1e81e0190603281216j4e70c1a9u1721f1dd7840441c@mail.gmail.com> Message-ID: <1e81e0190603281237uc4932bey2ba8f67ecfcc76e2@mail.gmail.com> On 3/28/06, Ralph Bearpark wrote: > I am left wondering if this sendmail patch actually wiped virtusertable.db. I can now confirm that my virtusertable.db was somehow regenerated - erroneously - when the sendmail patch was installed. I restored the virtusertable.db from last night's backup (after the patch was installed) and I see it bears the approximate timestamp of the patch installation (see the _postpatch file below, mv-ed to make way for the new, correct virtusertable.db file). -rw-r----- 1 root root 24576 Mar 28 22:04 virtusertable.db -rw-r----- 1 root root 12288 Mar 27 19:07 virtusertable.db_postpatch So, why did this patch need to regenerate the virtusertable.db? And if it really did have to, then wtf did it have to do it incorrectly? As it is, I dread to think how many of my regular maillists are now halted due to the senders receiving "no such user" responses. Regards, Ralph. From jimpop at yahoo.com Wed Mar 29 00:03:33 2006 From: jimpop at yahoo.com (Jim Popovitch) Date: Tue, 28 Mar 2006 19:03:33 -0500 Subject: Sendmail Patch Breaks Virtusertable Settings In-Reply-To: <1e81e0190603281237uc4932bey2ba8f67ecfcc76e2@mail.gmail.com> References: <1e81e0190603280413y187281a2k59dbea9184dfeae7@mail.gmail.com> <1e81e0190603281216j4e70c1a9u1721f1dd7840441c@mail.gmail.com> <1e81e0190603281237uc4932bey2ba8f67ecfcc76e2@mail.gmail.com> Message-ID: <4429CED5.8090901@yahoo.com> Ralph Bearpark wrote: > So, why did this patch need to regenerate the virtusertable.db? And > if it really did have to, then wtf did it have to do it incorrectly? I can't recall ever doing a sendmail upgrade (diff hosts, diff distro's, manual builds, etc) that did not rebuild sendmail dbs via the Makefile in /etc/mail/. Are you sure that your /etc/mail/virtualusertable source was up-to-date before sendmail was upgraded? -Jim P. From marcdeslauriers at videotron.ca Wed Mar 29 00:38:10 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 28 Mar 2006 19:38:10 -0500 Subject: Fedora Legacy Test Update Notification: ncpfs Message-ID: <4429D6F2.3040101@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-152904 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152904 2006-03-28 --------------------------------------------------------------------- Name : ncpfs Versions : rh73: ncpfs-2.2.0.18-6.1.legacy Versions : rh9: ncpfs-2.2.1-1.1.legacy Versions : fc1: ncpfs-2.2.3-1.1.legacy Versions : fc2: ncpfs-2.2.4-1.1.legacy Versions : fc3: ncpfs-2.2.4-5.FC3.1.legacy Summary : Utilities for the ncpfs filesystem, a NetWare client. Description : Ncpfs is a filesystem which understands the Novell NetWare(TM) NCP protocol. Functionally, NCP is used for NetWare the way NFS is used in the TCP/IP world. For a Linux system to mount a NetWare filesystem, it needs a special mount program. The ncpfs package contains such a mount program plus other tools for configuring and using the ncpfs filesystem. --------------------------------------------------------------------- Update Information: An updated ncpfs package is now available. Ncpfs is a file system that understands the Novell NetWare(TM) NCP protocol. 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. --------------------------------------------------------------------- Changelogs rh73: * Fri Mar 10 2006 Marc Deslauriers 2.2.0.18-6.1.legacy - fixed getuid security bug CVE-2005-0013 rh9: * Fri Mar 10 2006 Marc Deslauriers 2.2.1-1.1.legacy - Added patches for CVE-2004-1079, CVE-2005-0013 and CVE-2005-0014 fc1: * Sat Mar 11 2006 Marc Deslauriers 2.2.3-1.1.legacy - Added patches for CVE-2004-1079, CVE-2005-0013 and CVE-2005-0014 fc2: * Sat Mar 11 2006 Marc Deslauriers 2.2.4-1.1.legacy - Added patches for CVE-2004-1079, CVE-2005-0013 and CVE-2005-0014 fc3: * Sat Mar 11 2006 Marc Deslauriers 2.2.4-5.FC3.1.legacy - Added missing part of CVE-2005-0013 fix --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 16740d3fa5e17a46429ad3586e4adf9a14a64f8d redhat/7.3/updates-testing/i386/ncpfs-2.2.0.18-6.1.legacy.i386.rpm 21f8520c8a2a3d60e55041c0db028e03549f8544 redhat/7.3/updates-testing/i386/ipxutils-2.2.0.18-6.1.legacy.i386.rpm 6704d55f1f43360b6ad4211e2ca0f92e9f2174c8 redhat/7.3/updates-testing/SRPMS/ncpfs-2.2.0.18-6.1.legacy.src.rpm rh9: 6acd3b7b7d09cb0e47769b43a888adf72a6278ac redhat/9/updates-testing/i386/ncpfs-2.2.1-1.1.legacy.i386.rpm c49d83f88b229ce57c689d313eccb4df7b89f36b redhat/9/updates-testing/i386/ipxutils-2.2.1-1.1.legacy.i386.rpm ac833c51fcf831bca3edef5d0275ccd1ae0a530f redhat/9/updates-testing/SRPMS/ncpfs-2.2.1-1.1.legacy.src.rpm fc1: 8379face8f68fe556d40bf32f72a5ab368e8eb6d fedora/1/updates-testing/i386/ncpfs-2.2.3-1.1.legacy.i386.rpm eefaa839a26179ca5d41897eacf7bbf3c49661e1 fedora/1/updates-testing/i386/ipxutils-2.2.3-1.1.legacy.i386.rpm ede00a8544200515b5e09a7a40836d8f558cac9d fedora/1/updates-testing/SRPMS/ncpfs-2.2.3-1.1.legacy.src.rpm fc2: 1d32d2f0c39475f98206d78f87c587d4f96ddb70 fedora/2/updates-testing/i386/ncpfs-2.2.4-1.1.legacy.i386.rpm c095ce2d66184b605516231609cddc30520c3eb5 fedora/2/updates-testing/i386/ipxutils-2.2.4-1.1.legacy.i386.rpm 874f8a48f85fef80615b5892a70d214f0935ed7a fedora/2/updates-testing/SRPMS/ncpfs-2.2.4-1.1.legacy.src.rpm fc3: dc329c8b3558f67350486358b01b6a62f6f467af fedora/3/updates-testing/i386/ncpfs-2.2.4-5.FC3.1.legacy.i386.rpm 1ddd6caafe4a693d4a69d341be69600df446de3b fedora/3/updates-testing/i386/ipxutils-2.2.4-5.FC3.1.legacy.i386.rpm db8660759a23570a6d06bda37c619e0931425ef8 fedora/3/updates-testing/x86_64/ncpfs-2.2.4-5.FC3.1.legacy.x86_64.rpm 1e8bc7d10995fde90688b424f5001c14f7d3e3bc fedora/3/updates-testing/x86_64/ipxutils-2.2.4-5.FC3.1.legacy.x86_64.rpm 7f29dd88dcf31f19970e22c8c3af7267c62a5508 fedora/3/updates-testing/SRPMS/ncpfs-2.2.4-5.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: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Wed Mar 29 00:38:38 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 28 Mar 2006 19:38:38 -0500 Subject: Fedora Legacy Test Update Notification: xloadimage Message-ID: <4429D70E.7090402@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-152923 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152923 2006-03-28 --------------------------------------------------------------------- Name : xloadimage Versions : rh73: xloadimage-4.1-21.2.legacy Versions : rh9: xloadimage-4.1-27.2.legacy Versions : fc1: xloadimage-4.1-29.2.legacy Versions : fc2: xloadimage-4.1-34.FC2.2.legacy Summary : An X Window System based image viewer. Description : 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). --------------------------------------------------------------------- Update Information: 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). 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. --------------------------------------------------------------------- Changelogs rh73: * Tue Mar 21 2006 Marc Deslauriers 4.1-21.2.legacy - Added missing XFree86-devel BuildPrereq * Thu Mar 16 2006 Donald Maner 4.1-21.1.legacy - Patches for CVE-2005-0638 and CVE-2005-3178 (#152923) rh9: * Tue Mar 21 2006 Marc Deslauriers 4.1-27.2.legacy - Added missing XFree86-devel to BuildPrereq * Thu Mar 16 2006 Donald Maner 4.1-27.1.legacy - Patches for CVE-2005-0638 and CVE-2005-3178 (#152923) fc1: * Tue Mar 21 2006 Marc Deslauriers 4.1-29.2.legacy - Added missing XFree86-devel to BuildPrereq * Thu Mar 16 2006 Donald Maner 4.1-29.1.legacy - Patches for CVE-2005-0638 and CVE-2005-3178 (#152923) fc2: * Tue Mar 21 2006 Marc Deslauriers 4.1-34.FC2.2.legacy - Added missing libjpeg-devel to BuildPrereq - Fix release tag * Fri Mar 17 2006 Donald Maner 4.1-34.1.legacy - Patch for CVE-2005-3178 (#152923) --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 88326ff1a0753287240180322b36f8174686e0cc redhat/7.3/updates-testing/i386/xloadimage-4.1-21.2.legacy.i386.rpm 663b64ed039000824bacd3475e807c29c835f388 redhat/7.3/updates-testing/SRPMS/xloadimage-4.1-21.2.legacy.src.rpm rh9: 7fef8d73737dfacb3d56f203bf31f3c8e2014925 redhat/9/updates-testing/i386/xloadimage-4.1-27.2.legacy.i386.rpm 2b4223a41ab2127ee3b173e0803635f3c441bb4f redhat/9/updates-testing/SRPMS/xloadimage-4.1-27.2.legacy.src.rpm fc1: c24c7a2ae4d703b00a3f84623cae24775674d5d7 fedora/1/updates-testing/i386/xloadimage-4.1-29.2.legacy.i386.rpm ec2c5a9b5049aeca3cd4d12e7b84c650fec1c295 fedora/1/updates-testing/SRPMS/xloadimage-4.1-29.2.legacy.src.rpm fc2: 2910727dcd74a462a2f137746592e53ba5fcdfac fedora/2/updates-testing/i386/xloadimage-4.1-34.FC2.2.legacy.i386.rpm 924f5e4ffc9ff7190dc1808def838e57377f5fd6 fedora/2/updates-testing/SRPMS/xloadimage-4.1-34.FC2.2.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Wed Mar 29 00:39:03 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 28 Mar 2006 19:39:03 -0500 Subject: Fedora Legacy Test Update Notification: fetchmail Message-ID: <4429D727.9090803@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-164512 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164512 2006-03-28 --------------------------------------------------------------------- Name : fetchmail Versions : rh73: fetchmail-5.9.0-21.7.3.2.legacy Versions : rh9: fetchmail-6.2.0-3.4.legacy Versions : fc1: fetchmail-6.2.0-8.2.legacy Versions : fc2: fetchmail-6.2.5-2.2.legacy Summary : A remote mail retrieval and forwarding utility. Description : Fetchmail is a remote mail retrieval and forwarding utility intended for use over on-demand TCP/IP links, like SLIP or PPP connections. Fetchmail supports every remote-mail protocol currently in use on the Internet (POP2, POP3, RPOP, APOP, KPOP, all IMAPs, ESMTP ETRN, IPv6, and IPSEC) for retrieval. Then Fetchmail forwards the mail through SMTP so you can read it through your favorite mail client. --------------------------------------------------------------------- Update Information: Updated fetchmail packages that fix security flaws are now available. Fetchmail is a remote mail retrieval and forwarding utility. 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 CAN-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. --------------------------------------------------------------------- Changelogs rh73: * Sat Mar 11 2006 Donald Maner 6.2.0-3.2.legacy - add patch for CAN-2003-0792 (#164512) - add patch for CAN-2005-4348 (#164512) - add patch for CAN-2005-3088 from RHEL 2.1 (#164512) * Thu Jul 28 2005 Jeff Sheltren 5.9.0-21.7.3.1.legacy - add patch for POP3 buffer overflow - CAN-2005-2355 (#164512) rh9: * Thu Mar 23 2006 Marc Deslauriers 6.2.0-3.4.legacy - Added missing e2fsprogs-devel to BuildPrereq * Sat Mar 11 2006 Donald Maner 6.2.0-3.2.legacy - add patch for CAN-2003-0792 (#164512) - add patch for CAN-2005-3088 (#164512) * Thu Jul 28 2005 Jeff Sheltren 6.2.0-3.1.legacy - add patch for POP3 buffer overflow - CAN-2005-2355 (#164512) fc1: * Sun Mar 12 2006 Donald Maner 6.2.0-8.2.legacy - add patch for CAN-2005-3088 (#164512) - add patch for CAN-2005-2355 (#164512) * Thu Jul 28 2005 Jeff Sheltren 6.2.0-8.1.legacy - add patch for POP3 buffer overflow - CAN-2005-2355 (#164512) fc2: * Sun Mar 12 2006 Donald Maner 6.2.5-2.2.legacy - add patch for crash on empty message - CVE-2005-4348 (#164512) - add patch for CAN-2005-3088 (#164512) * Thu Jul 28 2005 Jeff Sheltren 6.2.5-2.1.legacy - add patch for POP3 buffer overflow - CAN-2005-2355 (#164512) --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 8b49bca60dc8bcbba7634b8e0559c82fbeef3db5 redhat/7.3/updates-testing/i386/fetchmail-5.9.0-21.7.3.2.legacy.i386.rpm 9c9c861757b4b8b2866f1d0e91dbc16d5037d956 redhat/7.3/updates-testing/i386/fetchmailconf-5.9.0-21.7.3.2.legacy.i386.rpm 9cca4f274cb21928d459ed25883e5d3c1f758f10 redhat/7.3/updates-testing/SRPMS/fetchmail-5.9.0-21.7.3.2.legacy.src.rpm rh9: 0fd22e51f83aab97d8c1790ed95423882f01aa9b redhat/9/updates-testing/i386/fetchmail-6.2.0-3.4.legacy.i386.rpm 7d2eb582d0aba96e07710eb89cd8c4c41c4530d3 redhat/9/updates-testing/SRPMS/fetchmail-6.2.0-3.4.legacy.src.rpm fc1: 5df158a0ba6bb0c323a75464e04b11e246dd8f98 fedora/1/updates-testing/i386/fetchmail-6.2.0-8.2.legacy.i386.rpm 927ed2783b8b4a29d0669e7936c1d27fd05564eb fedora/1/updates-testing/SRPMS/fetchmail-6.2.0-8.2.legacy.src.rpm fc2: 418f533e86f4c04a5fc41235b0618db470a63471 fedora/2/updates-testing/i386/fetchmail-6.2.5-2.2.legacy.i386.rpm d5a948f76f51032c05ab44b0ca7e47e36f7e4042 fedora/2/updates-testing/SRPMS/fetchmail-6.2.5-2.2.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Wed Mar 29 00:39:24 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 28 Mar 2006 19:39:24 -0500 Subject: Fedora Legacy Test Update Notification: gnupg Message-ID: <4429D73C.5030507@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-185355 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185355 2006-03-28 --------------------------------------------------------------------- Name : gnupg Versions : rh73: gnupg-1.0.7-13.2.legacy Versions : rh9: gnupg-1.2.1-9.2.legacy Versions : fc1: gnupg-1.2.3-2.2.legacy Versions : fc2: gnupg-1.2.4-2.3.legacy Versions : fc3: gnupg-1.2.7-1.2.legacy Summary : A GNU utility for secure communication and data storage. Description : GnuPG (GNU Privacy Guard) is a GNU utility for encrypting data and creating digital signatures. GnuPG has advanced key management capabilities and is compliant with the proposed OpenPGP Internet standard described in RFC2440. Since GnuPG doesn't use any patented algorithm, it is not compatible with any version of PGP2 (PGP2.x uses only IDEA for symmetric-key encryption, which is patented worldwide). --------------------------------------------------------------------- Update Information: An updated GnuPG package that fixes signature verification flaws is now available. GnuPG is a utility for encrypting data and creating digital signatures. 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. This issue is mitigated in the GnuPG shipped with Red Hat Enterprise Linux as the --ignore-crc-error option must be passed to the gpg executable for this attack to be successful. 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. --------------------------------------------------------------------- Changelogs rh73: * Thu Mar 23 2006 Marc Deslauriers 1.0.7-13.2.legacy - Added missing openldap-devel and zlib-devel to BuildPrereq * Wed Mar 15 2006 Donald Maner 1.0.7-13.1.legacy - add patch from Werner Koch to error out on ambiguous armored signatures in message, with some more bits from Klaus Singvogel to handle argument parsing, backported (CVE-2006-0049, #185355) - add backport of patch from Werner Koch to fix the exit status when verifying signatures when no signature is provided (CVE-2006-0455, #185355) rh9: * Thu Mar 23 2006 Marc Deslauriers 1.2.1-9.2.legacy - Added missing openldap to BuildPrereq * Wed Mar 15 2006 Donald Maner 1.2.1-9.1.legacy - add patch from Werner Koch to error out on ambiguous armored signatures in message, with some more bits from Klaus Singvogel to handle argument parsing, backported (CVE-2006-0049, #185355) - add backport of patch from Werner Koch to fix the exit status when verifying signatures when no signature is provided (CVE-2006-0455, #185355) fc1: * Thu Mar 23 2006 Marc Deslauriers 1.2.3-2.2.legacy - Added missing openldap-devel and zlib-devel to BuildPrereq * Wed Mar 15 2006 Donald Maner 1.2.3-2.1.legacy - add patch from Werner Koch to error out on ambiguous armored signatures in message, with some more bits from Klaus Singvogel to handle argument parsing, backported (CVE-2006-0049, #185355) - add backport of patch from Werner Koch to fix the exit status when verifying signatures when no signature is provided (CVE-2006-0455, #185355) fc2: * Thu Mar 23 2006 Marc Deslauriers 1.2.3-2.3.legacy - Added missing openldap-devel, bzip2-devel and zlib-devel to BuildPrereq * Wed Mar 15 2006 Donald Maner 1.2.3-2.1.legacy - add patch from Werner Koch to error out on ambiguous armored signatures in message, with some more bits from Klaus Singvogel to handle argument parsing, backported (CVE-2006-0049, #185355) - add backport of patch from Werner Koch to fix the exit status when verifying signatures when no signature is provided (CVE-2006-0455, #185355) fc3: * Tue Mar 28 2006 Marc Deslauriers 1.2.7-1.2.legacy - Added missing openldap-devel, bzip2-devel and zlib-devel to BuildPrereq * Wed Mar 15 2006 Donald Maner 1.2.7-1.1.legacy - add patch from Werner Koch to error out on ambiguous armored signatures in message, with some more bits from Klaus Singvogel to handle argument parsing, backported (CVE-2006-0049, #185355) - add backport of patch from Werner Koch to fix the exit status when verifying signatures when no signature is provided (CVE-2006-0455, #185355) --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 86adcfed9761a1d962d9d941f580137ef9d9a2f2 redhat/7.3/updates-testing/i386/gnupg-1.0.7-13.2.legacy.i386.rpm f0dd605d899741889be374f7a23b1e1240462069 redhat/7.3/updates-testing/SRPMS/gnupg-1.0.7-13.2.legacy.src.rpm rh9: b551dcbc9739ca6af6ca175c61709d5a4209fee6 redhat/9/updates-testing/i386/gnupg-1.2.1-9.2.legacy.i386.rpm 937e799801ee740b3076aaf7bae40aedad8150bf redhat/9/updates-testing/SRPMS/gnupg-1.2.1-9.2.legacy.src.rpm fc1: 69c6c0d7cd4250e7e9ce1dc67ce4f3da3ee3b810 fedora/1/updates-testing/i386/gnupg-1.2.3-2.2.legacy.i386.rpm b0f065bc8326fdc3f842dbc368be479f5d6b27c0 fedora/1/updates-testing/SRPMS/gnupg-1.2.3-2.2.legacy.src.rpm fc2: 4c9c5887459282cf336cc18c161eb3a243ea4b6d fedora/2/updates-testing/i386/gnupg-1.2.4-2.3.legacy.i386.rpm ffdee44401e55625c991eb20a6fcf316f0fae7c9 fedora/2/updates-testing/SRPMS/gnupg-1.2.4-2.3.legacy.src.rpm fc3: 56347e77b9f310b8b9f13b5105f50720d114660f fedora/3/updates-testing/i386/gnupg-1.2.7-1.2.legacy.i386.rpm 42858f6256ed2aed3ebacaa1ea948ab245713ad6 fedora/3/updates-testing/x86_64/gnupg-1.2.7-1.2.legacy.x86_64.rpm 66087d787f7707eb181ceff7e37d3f2ca624201a fedora/3/updates-testing/SRPMS/gnupg-1.2.7-1.2.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Wed Mar 29 00:39:59 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 28 Mar 2006 19:39:59 -0500 Subject: [UPDATED] Fedora Legacy Test Update Notification: sendmail Message-ID: <4429D75F.5050809@videotron.ca> These updated test packages for rh73, rh9 and fc1 fix problems with the previous sendmail update. --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-186277 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186277 2006-03-28 --------------------------------------------------------------------- Name : sendmail Versions : rh73: sendmail-8.12.11-4.22.10.legacy Versions : rh9: sendmail-8.12.11-4.24.3.legacy Versions : fc1: sendmail-8.12.11-4.25.3.legacy Summary : A widely used Mail Transport Agent (MTA). Description : The Sendmail program is a very widely used Mail Transport Agent (MTA). MTAs send mail from one machine to another. Sendmail is not a client program, which you use to read your email. Sendmail is a behind-the-scenes program which actually moves your email over networks or the Internet to where you want it to go. --------------------------------------------------------------------- Update Information: Updated sendmail packages that fix a flaw in the handling of asynchronous signals are now available. A flaw in the handling of asynchronous signals was discovered in Sendmail. A remote attacker may be able to exploit a race condition to execute arbitrary code as root. The Common Vulnerabilities and Exposures project assigned the name CVE-2006-0058 to this issue. In order to correct this issue for RHL 7.3 users, it was necessary to upgrade the version of Sendmail from 8.11 as originally shipped to Sendmail 8.12.11 with the addition of the security patch supplied by Sendmail Inc. This erratum provides updated packages based on Sendmail 8.12 with a compatibility mode enabled as provided by Red Hat for RHEL 2.1. After updating to these packages, users should pay close attention to their sendmail logs to ensure that the upgrade completed sucessfully. In order to correct this issue for RHL 9 and FC1 users, it was necessary to upgrade the version of Sendmail from 8.12.8 and 8.12.10 respectively to 8.12.11 with the addition of the security patch supplied by Sendmail Inc. After updating to these packages, users should pay close attention to their sendmail logs to ensure that the upgrade completed sucessfully. Users of Sendmail should upgrade to this updated package, which contains a backported patch to correct this issue. --------------------------------------------------------------------- Changelogs rh73: * Sat Mar 25 2006 Marc Deslauriers 8.12.11-4.22.10.legacy - Added hesiod-devel to BuildRequires - Reverted to previous alternatives files - Removed new triggers - Modified instructions in sendmail.mc * Wed Mar 22 2006 Jesse Keating 8.12.11-4.22.9.legacy - Sourced in for RHL7.3 - Added groff buildreq - Enable alternatives rh9: * Sun Mar 26 2006 Marc Deslauriers - 8.12.11-4.24.3.legacy - Reverted statistics file path in mc file - Reverted CERT paths in mc file - Don't enable statistics by default * Sat Mar 25 2006 Marc Deslauriers - 8.12.11-4.24.2.legacy - Reverted statistics file to /etc/mail - Reverted to previous alternatives files * Wed Mar 22 2006 Jesse Keating - 8.12.11-4.24.1.legacy - fixed VU#834865 (#186277) - disable -fpie - enable old_setup - Add BuildReq gdbm-devel - Use sasl1 fc1: * Sun Mar 26 2006 Marc Deslauriers - 8.12.11-4.25.3.legacy - Reverted statistics file path in mc file - Reverted CERT paths in mc file - Don't enable statistics by default * Sat Mar 25 2006 Marc Deslauriers - 8.12.11-4.25.2.legacy - Reverted statistics file to /etc/mail - Reverted to previous alternatives files - Added gdbm-devel to BuildRequires * Wed Mar 22 2006 Jesse Keating - 8.12.11-4.25.1.legacy - fixed VU#834865 (#186277) - enable old_setup --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 950fc853550d93f521d4203b9f78023721fbdecd redhat/7.3/updates-testing/i386/sendmail-8.12.11-4.22.10.legacy.i386.rpm d8c06f3f92d7dd526426b86e52bdd244e75c061a redhat/7.3/updates-testing/i386/sendmail-cf-8.12.11-4.22.10.legacy.i386.rpm dde44f59a60481edae75ddf6d854341308e4ce62 redhat/7.3/updates-testing/i386/sendmail-devel-8.12.11-4.22.10.legacy.i386.rpm faf27d20eb151227225cc4e2ac5014bb205aa350 redhat/7.3/updates-testing/i386/sendmail-doc-8.12.11-4.22.10.legacy.i386.rpm e0b9ece564e8103a254311da19c6bc41a21c8ffc redhat/7.3/updates-testing/SRPMS/sendmail-8.12.11-4.22.10.legacy.src.rpm rh9: 9f1caeadce45e2922f6bc29ea0f4e7bce4e26d02 redhat/9/updates-testing/i386/sendmail-8.12.11-4.24.3.legacy.i386.rpm 6b7b437bb58ac9f805185ae992da9a157a0d755d redhat/9/updates-testing/i386/sendmail-cf-8.12.11-4.24.3.legacy.i386.rpm ae48cf1d3a5d8f5bfc789a408de392fe27e84b73 redhat/9/updates-testing/i386/sendmail-devel-8.12.11-4.24.3.legacy.i386.rpm 4571b20f603bf6f90558aa09107f5b2ae17e8111 redhat/9/updates-testing/i386/sendmail-doc-8.12.11-4.24.3.legacy.i386.rpm 4b4ed7d51e710a447c6a839dcf203bc4636c2f62 redhat/9/updates-testing/SRPMS/sendmail-8.12.11-4.24.3.legacy.src.rpm fc1: 3f6edb4bdcd42cca1f01fce9482d3ac10b56f530 fedora/1/updates-testing/i386/sendmail-8.12.11-4.25.3.legacy.i386.rpm 7aaa9743d312b7ebc95baa83e186acaa267f6915 fedora/1/updates-testing/i386/sendmail-cf-8.12.11-4.25.3.legacy.i386.rpm dfabadaa764d471b2c5963547643ca4bbe5ca0e7 fedora/1/updates-testing/i386/sendmail-devel-8.12.11-4.25.3.legacy.i386.rpm 121433ec0c71a163993cf2a94f33fa67df786b11 fedora/1/updates-testing/i386/sendmail-doc-8.12.11-4.25.3.legacy.i386.rpm d41f7652ea88a068e21c7f68bb018b8462695754 fedora/1/updates-testing/SRPMS/sendmail-8.12.11-4.25.3.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: From rbearpark.nospam at gmail.com Wed Mar 29 06:38:05 2006 From: rbearpark.nospam at gmail.com (Ralph Bearpark) Date: Wed, 29 Mar 2006 08:38:05 +0200 Subject: Sendmail Patch Breaks Virtusertable Settings In-Reply-To: <4429CED5.8090901@yahoo.com> References: <1e81e0190603280413y187281a2k59dbea9184dfeae7@mail.gmail.com> <1e81e0190603281216j4e70c1a9u1721f1dd7840441c@mail.gmail.com> <1e81e0190603281237uc4932bey2ba8f67ecfcc76e2@mail.gmail.com> <4429CED5.8090901@yahoo.com> Message-ID: <1e81e0190603282238hf95ea4ei7128a92c9f43bde3@mail.gmail.com> On 3/29/06, Jim Popovitch wrote: > I can't recall ever doing a sendmail upgrade (diff hosts, diff distro's, > manual builds, etc) that did not rebuild sendmail dbs via the Makefile > in /etc/mail/. Hmm, that might be a clue for me. When I put in a new alias, I manually "makemap hash virtusertable < virtusertable.txt". If the sendmail upgrade runs a Makefile to do its own virtusertable.db rebuild then it's possible it uses other sources, or "makemap dbm" instead of "makemap hash". That could explain the screw-up. I'll check this later. Ralph. From shiva at sewingwitch.com Wed Mar 29 20:10:15 2006 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 29 Mar 2006 12:10:15 -0800 Subject: Sendmail Patch Breaks Virtusertable Settings In-Reply-To: <1e81e0190603282238hf95ea4ei7128a92c9f43bde3@mail.gmail.com> References: <1e81e0190603280413y187281a2k59dbea9184dfeae7@mail.gmail.com> <1e81e0190603281216j4e70c1a9u1721f1dd7840441c@mail.gmail.com> <1e81e0190603281237uc4932bey2ba8f67ecfcc76e2@mail.gmail.com> <4429CED5.8090901@yahoo.com> <1e81e0190603282238hf95ea4ei7128a92c9f43bde3@mail.gmail.com> Message-ID: <1DB38B46C90A93E2A24905FB@[10.169.6.198]> On Wednesday, March 29, 2006 8:38 AM +0200 Ralph Bearpark wrote: > Hmm, that might be a clue for me. When I put in a new alias, I > manually "makemap hash virtusertable < virtusertable.txt". If the > sendmail upgrade runs a Makefile to do its own virtusertable.db > rebuild then it's possible it uses other sources, or "makemap dbm" > instead of "makemap hash". That could explain the screw-up. It indeed uses /etc/mail/Makefile to rebuild maps. The first thing I do after an upgrade is to edit the Makefile to remove the at-signs on the front of the commands so that I can see what gets made. If there's interest in making this edit in the package, I can file a bugzilla and supply a patch. From rbearpark.nospam at gmail.com Wed Mar 29 22:03:09 2006 From: rbearpark.nospam at gmail.com (Ralph Bearpark) Date: Thu, 30 Mar 2006 00:03:09 +0200 Subject: Sendmail Patch Breaks Virtusertable Settings In-Reply-To: <1DB38B46C90A93E2A24905FB@10.169.6.198> References: <1e81e0190603280413y187281a2k59dbea9184dfeae7@mail.gmail.com> <1e81e0190603281216j4e70c1a9u1721f1dd7840441c@mail.gmail.com> <1e81e0190603281237uc4932bey2ba8f67ecfcc76e2@mail.gmail.com> <4429CED5.8090901@yahoo.com> <1e81e0190603282238hf95ea4ei7128a92c9f43bde3@mail.gmail.com> <1DB38B46C90A93E2A24905FB@10.169.6.198> Message-ID: <1e81e0190603291403ga8c464fq67c8b67cbf442347@mail.gmail.com> On 3/29/06, Kenneth Porter wrote: > It indeed uses /etc/mail/Makefile to rebuild maps. > > The first thing I do after an upgrade is to edit the Makefile to remove the > at-signs on the front of the commands so that I can see what gets made. If > there's interest in making this edit in the package, I can file a bugzilla > and supply a patch. I guess the relevant lines in /etc/mail/Makefile are: %.db: % @makemap hash $@ < $< which I'm guessing means it tries to do a: makemap hash virtusertable < virtusertable which would perhaps explain the screw-up I experienced since MY virtusertable sources are in virtusertable.txt rather than virtusertable. i.e. I perform makemap hash virtusertable < virtusertable.txt However, I see there is a empty virtusertable file there (dates 23-Mar, now what does that mean?) and if the upgrade ran that makefile to generate virtusertable.db with the wrong virtusertable source, that certainly would explain my problems. From david at staff.webquarry.com Wed Mar 29 22:32:46 2006 From: david at staff.webquarry.com (David M. Shirley) Date: Wed, 29 Mar 2006 14:32:46 -0800 Subject: New sendmail breaks ability to mail to *@mmode.com Message-ID: Ok, this is strange. Since installing the new sendmail packages on several 7.3, 9, FC1 and 3 boxes, I am no longer to able to send email SMS messages to anything at mmode.com. In my maillog I see things like: Mar 29 14:13:32 ns sendmail[4969]: k2TMDWk9004967: to=, ctladdr= (500/500), delay=00:00:00, xdelay=00:00:00, mailer=esmtp, pri=30372, relay=mta01.cdpd.airdata.com. [199.88.234.33], dsn=2.0.0, stat=Sent (Message received and queued) But nothing comes through to my phone. (mmode silently drops the message) I can email SMS messages to my phone from any other machine on our network that is either running the older sendmail packages or other MTAs like qmail or exim. Anyone experience anything similar? David Shirley http://www.webquarry.com From david at staff.webquarry.com Wed Mar 29 23:37:41 2006 From: david at staff.webquarry.com (David M. Shirley) Date: Wed, 29 Mar 2006 15:37:41 -0800 Subject: New sendmail breaks ability to mail to *@mmode.com In-Reply-To: References: Message-ID: I have also confirmed that this happens with the sendmail updates that were released for Red Hat Enterprise Linux ES release 3 so this isn't just a fedoralegacy problem... Anyone one the list have access to or know a person that actually run the email to sms gateway for cingular wireless? It would be great if we could get them to bounce these messages rather than just silently dropping them. Maybe the bounce would tell us something. David Shirley http://www.webquarry.com On Mar 29, 2006, at 2:32 PM, David M. Shirley wrote: > Ok, this is strange. Since installing the new sendmail packages on > several 7.3, 9, FC1 and 3 boxes, I am no longer to able to send > email SMS messages to anything at mmode.com. In my maillog I see > things like: > > Mar 29 14:13:32 ns sendmail[4969]: k2TMDWk9004967: > to=, ctladdr= > (500/500), delay=00:00:00, xdelay=00:00:00, mailer=esmtp, > pri=30372, relay=mta01.cdpd.airdata.com. [199.88.234.33], > dsn=2.0.0, stat=Sent (Message received and queued) > > But nothing comes through to my phone. (mmode silently drops the > message) I can email SMS messages to my phone from any other > machine on our network that is either running the older sendmail > packages or other MTAs like qmail or exim. > > Anyone experience anything similar? > > > David Shirley > http://www.webquarry.com > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > From sheltren at cs.ucsb.edu Wed Mar 29 23:50:53 2006 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Wed, 29 Mar 2006 19:50:53 -0400 Subject: New sendmail breaks ability to mail to *@mmode.com In-Reply-To: References: Message-ID: Out of curiosity, what does your maillog show for a message that actually gets through to your phone? -Jeff On Mar 29, 2006, at 7:37 PM, David M. Shirley wrote: > I have also confirmed that this happens with the sendmail updates > that were released for Red Hat Enterprise Linux ES release 3 so > this isn't just a fedoralegacy problem... > > Anyone one the list have access to or know a person that actually > run the email to sms gateway for cingular wireless? It would be > great if we could get them to bounce these messages rather than > just silently dropping them. Maybe the bounce would tell us > something. > > David Shirley > http://www.webquarry.com > > > On Mar 29, 2006, at 2:32 PM, David M. Shirley wrote: > >> Ok, this is strange. Since installing the new sendmail packages >> on several 7.3, 9, FC1 and 3 boxes, I am no longer to able to send >> email SMS messages to anything at mmode.com. In my maillog I see >> things like: >> >> Mar 29 14:13:32 ns sendmail[4969]: k2TMDWk9004967: >> to=, ctladdr= >> (500/500), delay=00:00:00, xdelay=00:00:00, mailer=esmtp, >> pri=30372, relay=mta01.cdpd.airdata.com. [199.88.234.33], >> dsn=2.0.0, stat=Sent (Message received and queued) >> >> But nothing comes through to my phone. (mmode silently drops the >> message) I can email SMS messages to my phone from any other >> machine on our network that is either running the older sendmail >> packages or other MTAs like qmail or exim. >> >> Anyone experience anything similar? >> >> >> David Shirley >> http://www.webquarry.com >> >> >> -- >> fedora-legacy-list mailing list >> fedora-legacy-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-legacy-list >> > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list From david at staff.webquarry.com Thu Mar 30 00:21:47 2006 From: david at staff.webquarry.com (David M. Shirley) Date: Wed, 29 Mar 2006 16:21:47 -0800 Subject: New sendmail breaks ability to mail to *@mmode.com In-Reply-To: References: Message-ID: <415490A7-E4A5-43D1-ACA6-CA05E086511A@staff.webquarry.com> From a machine that still has the old sendmail on it shows the exact same message. Here is an example: Mar 29 16:11:43 hostnamehere sendmail[3079]: k2U0BgxL003077: to=, ctladdr= (0/0), delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=30365, relay=mta01.cdpd.airdata.com. [199.88.234.33], dsn=2.0.0, stat=Sent (Message received and queued) this message makes it through all the way to my phone. Something at mmode.com is deciding to silently drop emails received from newly patched sendmail boxes. No bounces are received. I should be clear that is has only been tried with the email to phone gateway where the recipient address looks like 18005551212 at mmode.com and not with their enterprise paging service that has an email address format of name at mmode.com. David Shirley http://www.webquarry.com On Mar 29, 2006, at 3:50 PM, Jeff Sheltren wrote: > Out of curiosity, what does your maillog show for a message that > actually gets through to your phone? > > -Jeff > > On Mar 29, 2006, at 7:37 PM, David M. Shirley wrote: > >> I have also confirmed that this happens with the sendmail updates >> that were released for Red Hat Enterprise Linux ES release 3 so >> this isn't just a fedoralegacy problem... >> >> Anyone one the list have access to or know a person that actually >> run the email to sms gateway for cingular wireless? It would be >> great if we could get them to bounce these messages rather than >> just silently dropping them. Maybe the bounce would tell us >> something. >> >> David Shirley >> http://www.webquarry.com >> >> >> On Mar 29, 2006, at 2:32 PM, David M. Shirley wrote: >> >>> Ok, this is strange. Since installing the new sendmail packages >>> on several 7.3, 9, FC1 and 3 boxes, I am no longer to able to >>> send email SMS messages to anything at mmode.com. In my maillog >>> I see things like: >>> >>> Mar 29 14:13:32 ns sendmail[4969]: k2TMDWk9004967: >>> to=, ctladdr= >>> (500/500), delay=00:00:00, xdelay=00:00:00, mailer=esmtp, >>> pri=30372, relay=mta01.cdpd.airdata.com. [199.88.234.33], >>> dsn=2.0.0, stat=Sent (Message received and queued) >>> >>> But nothing comes through to my phone. (mmode silently drops the >>> message) I can email SMS messages to my phone from any other >>> machine on our network that is either running the older sendmail >>> packages or other MTAs like qmail or exim. >>> >>> Anyone experience anything similar? >>> >>> >>> David Shirley >>> http://www.webquarry.com >>> >>> >>> -- >>> fedora-legacy-list mailing list >>> fedora-legacy-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-legacy-list >>> >> >> -- >> fedora-legacy-list mailing list >> fedora-legacy-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-legacy-list > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > From smooge at gmail.com Thu Mar 30 00:21:43 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Wed, 29 Mar 2006 17:21:43 -0700 Subject: New sendmail breaks ability to mail to *@mmode.com In-Reply-To: <415490A7-E4A5-43D1-ACA6-CA05E086511A@staff.webquarry.com> References: <415490A7-E4A5-43D1-ACA6-CA05E086511A@staff.webquarry.com> Message-ID: <80d7e4090603291621j3afd028ftc91502b38f64bbc7@mail.gmail.com> On 3/29/06, David M. Shirley wrote: > From a machine that still has the old sendmail on it shows the exact > same message. Here is an example: > > Mar 29 16:11:43 hostnamehere sendmail[3079]: k2U0BgxL003077: > to=, ctladdr= (0/0), > delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=30365, > relay=mta01.cdpd.airdata.com. [199.88.234.33], dsn=2.0.0, stat=Sent > (Message received and queued) > Well at this point, I would say tcpdump and ethereal to see what the diffs are in being sent.. beyond that mmode would be the people to contact. -- Stephen J Smoogen. CSIRT/Linux System Administrator From jkeating at j2solutions.net Thu Mar 30 00:23:37 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 29 Mar 2006 16:23:37 -0800 Subject: New sendmail breaks ability to mail to *@mmode.com In-Reply-To: <80d7e4090603291621j3afd028ftc91502b38f64bbc7@mail.gmail.com> References: <415490A7-E4A5-43D1-ACA6-CA05E086511A@staff.webquarry.com> <80d7e4090603291621j3afd028ftc91502b38f64bbc7@mail.gmail.com> Message-ID: <1143678218.2501.13.camel@ender> On Wed, 2006-03-29 at 17:21 -0700, Stephen J. Smoogen wrote: > > Well at this point, I would say tcpdump and ethereal to see what the > diffs are in being sent.. beyond that mmode would be the people to > contact. > And taking the issue upstream to Sendmail, and possibly Red Hat through your support contract. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From david at staff.webquarry.com Thu Mar 30 01:11:43 2006 From: david at staff.webquarry.com (David M. Shirley) Date: Wed, 29 Mar 2006 17:11:43 -0800 Subject: New sendmail breaks ability to mail to *@mmode.com In-Reply-To: <1143678218.2501.13.camel@ender> References: <415490A7-E4A5-43D1-ACA6-CA05E086511A@staff.webquarry.com> <80d7e4090603291621j3afd028ftc91502b38f64bbc7@mail.gmail.com> <1143678218.2501.13.camel@ender> Message-ID: Yeah I'm doing a little more research before I do that. How does one rollback to a previous rpm? I must confess I have forgotten. David Shirley http://www.webquarry.com On Mar 29, 2006, at 4:23 PM, Jesse Keating wrote: > On Wed, 2006-03-29 at 17:21 -0700, Stephen J. Smoogen wrote: >> >> Well at this point, I would say tcpdump and ethereal to see what the >> diffs are in being sent.. beyond that mmode would be the people to >> contact. >> > > And taking the issue upstream to Sendmail, and possibly Red Hat > through > your support contract. > > -- > Jesse Keating RHCE (geek.j2solutions.net) > Fedora Legacy Team (www.fedoralegacy.org) > GPG Public Key (geek.j2solutions.net/ > jkeating.j2solutions.pub) > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list From shiva at sewingwitch.com Thu Mar 30 02:43:30 2006 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 29 Mar 2006 18:43:30 -0800 Subject: New sendmail breaks ability to mail to *@mmode.com In-Reply-To: References: <415490A7-E4A5-43D1-ACA6-CA05E086511A@staff.webquarry.com> <80d7e4090603291621j3afd028ftc91502b38f64bbc7@mail.gmail.com> <1143678218.2501.13.camel@ender> Message-ID: <264E17786AF305C6912358D6@[10.169.6.198]> On Wednesday, March 29, 2006 5:11 PM -0800 "David M. Shirley" wrote: > How does one rollback to a previous rpm? I must confess I have > forgotten. I always run "rpm --help" to remember. The switch you want is --oldpackage. It tells RPM that it's acceptable to "update" to a package with a lower version/release number. I tar up /etc/mail and the random sendmail config files not yet moved there (eg. aliases and smrsh) before doing an upgrade. I then unpack it to /tmp and diff it to the upgrade aftermath to see what it changed. Usually it's harmless but this sounds like a case where the practice will be valuable. From david at staff.webquarry.com Thu Mar 30 06:55:26 2006 From: david at staff.webquarry.com (David M. Shirley) Date: Wed, 29 Mar 2006 22:55:26 -0800 Subject: New sendmail breaks ability to mail to *@mmode.com In-Reply-To: <264E17786AF305C6912358D6@[10.169.6.198]> References: <415490A7-E4A5-43D1-ACA6-CA05E086511A@staff.webquarry.com> <80d7e4090603291621j3afd028ftc91502b38f64bbc7@mail.gmail.com> <1143678218.2501.13.camel@ender> <264E17786AF305C6912358D6@[10.169.6.198]> Message-ID: <3BEEE87A-25BF-47AC-A042-953BCE9F3DF9@staff.webquarry.com> Thanks. This gets stranger by the minute. The folks at mmode.com SWEAR they have made no changes to their sms gateway system and yet tonight: I rolled back to a prior version of sendmail and found that messages sent from old (pre-upgrade) sendmail equipped servers are now also being dropped THE FIRST TIME by mmode.com. If you immediately send it again, the second message sails right through to my phone. I get the same behavior from old sendmail equipped servers that were functioning fine earlier today and have never been upgraded. I took a server that: can't get any messages through to mmode.com with the new sendmail and has it's first message to mmode.com lost using the old sendmail switched to using postfix and all messages now sail right through each and every time. In all three cases, the mmode.com server accepts the messages for delivery in exactly the same way as I have reported earlier in this thread. It's pretty clear now that this is purely an mmode.com problem but they seem unable to locate anything. If anyone has some insight, I'd love to be able to tell them, "Hey did you check this...?" This bit about always losing the first message sounds a bit like a botched attempt at greylisting but I don't understand how it only occurs with connections from sendmail mtas and not others like qmail, postfix and exim.... Indeed messages from any of these other mtas are accepted my mmode.com the first time, every time. David Shirley http://www.webquarry.com On Mar 29, 2006, at 6:43 PM, Kenneth Porter wrote: > On Wednesday, March 29, 2006 5:11 PM -0800 "David M. Shirley" > wrote: > >> How does one rollback to a previous rpm? I must confess I have >> forgotten. > > I always run "rpm --help" to remember. The switch you want is -- > oldpackage. It tells RPM that it's acceptable to "update" to a > package with a lower version/release number. > > I tar up /etc/mail and the random sendmail config files not yet > moved there (eg. aliases and smrsh) before doing an upgrade. I then > unpack it to /tmp and diff it to the upgrade aftermath to see what > it changed. Usually it's harmless but this sounds like a case where > the practice will be valuable. > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > From jimpop at yahoo.com Thu Mar 30 08:10:34 2006 From: jimpop at yahoo.com (Jim Popovitch) Date: Thu, 30 Mar 2006 03:10:34 -0500 Subject: New sendmail breaks ability to mail to *@mmode.com In-Reply-To: <3BEEE87A-25BF-47AC-A042-953BCE9F3DF9@staff.webquarry.com> References: <415490A7-E4A5-43D1-ACA6-CA05E086511A@staff.webquarry.com> <80d7e4090603291621j3afd028ftc91502b38f64bbc7@mail.gmail.com> <1143678218.2501.13.camel@ender> <264E17786AF305C6912358D6@[10.169.6.198]> <3BEEE87A-25BF-47AC-A042-953BCE9F3DF9@staff.webquarry.com> Message-ID: <442B927A.1090205@yahoo.com> David M. Shirley wrote: > > It's pretty clear now that this is purely an mmode.com problem but they > seem unable to locate anything. If anyone has some insight, I'd love to > be able to tell them, "Hey did you check this...?" First, Check that the IP address of your server(s) hasn't been blacklisted here: http://www.completewhois.com/rbl_lookup.htm Next, verify that your server(s) have proper DNS (A & PTR) records here: http://www.dnsreport.com Hth, -Jim P. From david at staff.webquarry.com Thu Mar 30 08:16:54 2006 From: david at staff.webquarry.com (David M. Shirley) Date: Thu, 30 Mar 2006 00:16:54 -0800 Subject: New sendmail breaks ability to mail to *@mmode.com In-Reply-To: <442B927A.1090205@yahoo.com> References: <415490A7-E4A5-43D1-ACA6-CA05E086511A@staff.webquarry.com> <80d7e4090603291621j3afd028ftc91502b38f64bbc7@mail.gmail.com> <1143678218.2501.13.camel@ender> <264E17786AF305C6912358D6@[10.169.6.198]> <3BEEE87A-25BF-47AC-A042-953BCE9F3DF9@staff.webquarry.com> <442B927A.1090205@yahoo.com> Message-ID: <97B4CDF0-4CAA-4385-805F-8B525C6DC1D2@staff.webquarry.com> Thanks. That's the very first thing that I checked and all's well there. David Shirley http://www.webquarry.com On Mar 30, 2006, at 12:10 AM, Jim Popovitch wrote: > First, Check that the IP address of your server(s) hasn't been > blacklisted here: http://www.completewhois.com/rbl_lookup.htm > > Next, verify that your server(s) have proper DNS (A & PTR) records > here: http://www.dnsreport.com From joachim.geiger at ipp.mpg.de Thu Mar 30 13:13:47 2006 From: joachim.geiger at ipp.mpg.de (Joachim Geiger) Date: Thu, 30 Mar 2006 15:13:47 +0200 Subject: redhat9 desktop problems after update Message-ID: <442BD98B.5040403@ipp.mpg.de> Hello, after an update (12.March 06)of my redhat9 with yum from the fedora-legacy repository I experienced the following strange behaviour of my gnome desktop environment: when I logout and then login again, I do no longer find my complete old environment: 1. the desktop picture is replaced with a blank blue background 2. the desktop icons disappeared ( the .gnome-desktop directory is still there and the files of the desktop icons also) 3. the usual popup-menue which appears when you right-click on the desktop does not appear. The desktop seems to be totally inactive. 4. if I start mozilla, I don't see anything happening. Nevertheless, run-mozilla.sh is there as well as mozilla and mozilla-bin, but not windows appear on the screen. This is also true for firefox which is installed separately. As I checked, the updates done at that time included all from 18.Feb.06 up to 07.Mar.06, i.e. squid, openssh, Apache httpd, sudo, mozilla, nfs-utils, gaim, perl, PostgreSQL, perl-DBI, XFree86 and pcre. I don't logout very often and did it this time to restart the X-server because of the XFree86 update. Does anyone have a suggestion what went wrong? I got this working once again by removing all (backed-up) gnome configuration files and all temporary files in /tmp. After that it worked again, but with a logout today, I am facing the same problem again and I don't want to clean-up this again and again just for the sake of login-out. I would appreciate any help. Best regards, Joachim P.S.: I did register to fedora-legacy-list today. From jimpop at yahoo.com Thu Mar 30 14:39:29 2006 From: jimpop at yahoo.com (Jim Popovitch) Date: Thu, 30 Mar 2006 09:39:29 -0500 Subject: New sendmail breaks ability to mail to *@mmode.com In-Reply-To: <97B4CDF0-4CAA-4385-805F-8B525C6DC1D2@staff.webquarry.com> References: <415490A7-E4A5-43D1-ACA6-CA05E086511A@staff.webquarry.com> <80d7e4090603291621j3afd028ftc91502b38f64bbc7@mail.gmail.com> <1143678218.2501.13.camel@ender> <264E17786AF305C6912358D6@[10.169.6.198]> <3BEEE87A-25BF-47AC-A042-953BCE9F3DF9@staff.webquarry.com> <442B927A.1090205@yahoo.com> <97B4CDF0-4CAA-4385-805F-8B525C6DC1D2@staff.webquarry.com> Message-ID: <442BEDA1.9090004@yahoo.com> Do you use a SPF DNS record? If so, make sure that the host(s) recorded in the TXT record are valid. Also, connect to your mailserver ("telnet 25") and see what hostname it thinks it is. -Jim P. David M. Shirley wrote: > Thanks. That's the very first thing that I checked and all's well there. > > David Shirley > http://www.webquarry.com > > > On Mar 30, 2006, at 12:10 AM, Jim Popovitch wrote: > >> First, Check that the IP address of your server(s) hasn't been >> blacklisted here: http://www.completewhois.com/rbl_lookup.htm >> >> Next, verify that your server(s) have proper DNS (A & PTR) records >> here: http://www.dnsreport.com > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > From jedgecombe at carolina.rr.com Thu Mar 30 14:57:51 2006 From: jedgecombe at carolina.rr.com (Jason Edgecombe) Date: Thu, 30 Mar 2006 09:57:51 -0500 Subject: New sendmail breaks ability to mail to *@mmode.com In-Reply-To: <3BEEE87A-25BF-47AC-A042-953BCE9F3DF9@staff.webquarry.com> References: <415490A7-E4A5-43D1-ACA6-CA05E086511A@staff.webquarry.com> <80d7e4090603291621j3afd028ftc91502b38f64bbc7@mail.gmail.com> <1143678218.2501.13.camel@ender> <264E17786AF305C6912358D6@[10.169.6.198]> <3BEEE87A-25BF-47AC-A042-953BCE9F3DF9@staff.webquarry.com> Message-ID: <442BF1EF.7090408@carolina.rr.com> Hmmm, sounds like greylisting. See http://projects.puremagic.com/greylisting/ David M. Shirley wrote: > Thanks. > > This gets stranger by the minute. The folks at mmode.com SWEAR they > have made no changes to their sms gateway system and yet tonight: > > I rolled back to a prior version of sendmail and found that messages > sent from old (pre-upgrade) sendmail equipped servers are now also > being dropped THE FIRST TIME by mmode.com. If you immediately send it > again, the second message sails right through to my phone. > > I get the same behavior from old sendmail equipped servers that were > functioning fine earlier today and have never been upgraded. > > I took a server that: > can't get any messages through to mmode.com with the new sendmail > and has it's first message to mmode.com lost using the old sendmail > switched to using postfix and all messages now sail right through each > and every time. > > In all three cases, the mmode.com server accepts the messages for > delivery in exactly the same way as I have reported earlier in this > thread. > > It's pretty clear now that this is purely an mmode.com problem but > they seem unable to locate anything. If anyone has some insight, I'd > love to be able to tell them, "Hey did you check this...?" > > This bit about always losing the first message sounds a bit like a > botched attempt at greylisting but I don't understand how it only > occurs with connections from sendmail mtas and not others like qmail, > postfix and exim.... Indeed messages from any of these other mtas are > accepted my mmode.com the first time, every time. > > David Shirley > http://www.webquarry.com From kelson at speed.net Thu Mar 30 17:08:14 2006 From: kelson at speed.net (Kelson) Date: Thu, 30 Mar 2006 09:08:14 -0800 Subject: New sendmail breaks ability to mail to *@mmode.com In-Reply-To: <442BF1EF.7090408@carolina.rr.com> References: <415490A7-E4A5-43D1-ACA6-CA05E086511A@staff.webquarry.com> <80d7e4090603291621j3afd028ftc91502b38f64bbc7@mail.gmail.com> <1143678218.2501.13.camel@ender> <264E17786AF305C6912358D6@[10.169.6.198]> <3BEEE87A-25BF-47AC-A042-953BCE9F3DF9@staff.webquarry.com> <442BF1EF.7090408@carolina.rr.com> Message-ID: <442C107E.5030206@speed.net> Jason Edgecombe wrote: > sounds like greylisting. See http://projects.puremagic.com/greylisting/ Not quite -- greylising would tempfail the first message instead of dropping it silently. Otherwise, how is the sending MTA to know it needs to re-send the message? Plus there's the matter where other MTAs on the same servers don't seem to be affected. -- Kelson Vibber SpeedGate Communications From jedgecombe at carolina.rr.com Fri Mar 31 13:53:58 2006 From: jedgecombe at carolina.rr.com (Jason Edgecombe) Date: Fri, 31 Mar 2006 08:53:58 -0500 Subject: New sendmail breaks ability to mail to *@mmode.com In-Reply-To: <442C107E.5030206@speed.net> References: <415490A7-E4A5-43D1-ACA6-CA05E086511A@staff.webquarry.com> <80d7e4090603291621j3afd028ftc91502b38f64bbc7@mail.gmail.com> <1143678218.2501.13.camel@ender> <264E17786AF305C6912358D6@[10.169.6.198]> <3BEEE87A-25BF-47AC-A042-953BCE9F3DF9@staff.webquarry.com> <442BF1EF.7090408@carolina.rr.com> <442C107E.5030206@speed.net> Message-ID: <442D3476.9040908@carolina.rr.com> Kelson wrote: > Jason Edgecombe wrote: >> sounds like greylisting. See http://projects.puremagic.com/greylisting/ > > Not quite -- greylising would tempfail the first message instead of > dropping it silently. Otherwise, how is the sending MTA to know it > needs to re-send the message? > > Plus there's the matter where other MTAs on the same servers don't > seem to be affected. Oh well. I hope things get worked out. From mgarringer at apacmail.com Fri Mar 31 18:20:01 2006 From: mgarringer at apacmail.com (Mark Garringer) Date: Fri, 31 Mar 2006 18:20:01 +0000 (UTC) Subject: New sendmail breaks ability to mail to * mmode.com References: Message-ID: > Ok, this is strange. Since installing the new sendmail packages on > several 7.3, 9, FC1 and 3 boxes, I am no longer to able to send email > SMS messages to anything at mmode.com. In my maillog I see things like: > > Anyone experience anything similar? We noticed the same problem yesterday. Here is what I did to confirm the issue: *) We use RHEL 3 ES on a large number of servers, and update the RPMs nightly from RHN. 8) We use Nagios to page us (via pin at mmode.com) when our systems have problems. *) The updated RPM for Sendmail we installed on our server on 3/23 at 4 am. *) We can confirm that the last SMS sent out correctly 3/27 at 6:44 am. *) Sometime between 3/27 6:44 am and 3/29 7:04 pm it stopped working. *) We booted up an old server which had not gotten the sendmail update (running sendmail-8.12.11-4.RHEL3.1) and verified that we could send SMS via mmode.com. *) We upgraded the sendmail RPM to sendmail-8.12.11-4.RHEL3.4 and verified that we could no longer send SMS via mmode.com. *) We rolled sendmail RPM back to sendmail-8.12.11-4.RHEL3.1 and verified that we could send SMS via mmode.com. *) We checked the email headers from the tests and saw that the version string in the header changed from "8.12.11" to "8.12.11.20060308" *) We downloaded the SRC RPM for sendmail-8.12.11-4.RHEL3.4 and removed the version string update from the patch, and rebuild the RPM. *) We installed the 'modified' RPM and verified that we COULD send SMS via mmode.com. Presently, we are not sure who to take this information to...