From marcdeslauriers at videotron.ca Sat Apr 1 21:46:12 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sat, 01 Apr 2006 16:46:12 -0500 Subject: [UPDATED] Fedora Legacy Test Update Notification: gnupg Message-ID: <442EF4A4.6070508@videotron.ca> The rh73 packages were updated to correct a broken info page. --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-185355 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185355 2006-04-01 --------------------------------------------------------------------- Name : gnupg Versions : rh73: gnupg-1.0.7-13.3.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: * Sat Apr 01 2006 Marc Deslauriers 1.0.7-13.3.legacy - Added missing texinfo to BuildPrereq * 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: 8908e71fbca5c2bae5f3aadd774e42a49a5cb957 redhat/7.3/updates-testing/i386/gnupg-1.0.7-13.3.legacy.i386.rpm dd9dc31630ca66faffb4f214f425b973cb3212cf redhat/7.3/updates-testing/SRPMS/gnupg-1.0.7-13.3.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 deisenst at gtw.net Tue Apr 4 23:51:06 2006 From: deisenst at gtw.net (David Eisenstein) Date: Tue, 04 Apr 2006 18:51:06 -0500 Subject: [Fwd: "Official" (security) update announcement repository? fedora-announce-list? Re: Flaw discovered in Sendmail 8.13.5] Message-ID: <4433066A.4080809@gtw.net> Note: I am forwarding this to you all, as you may find these issues relevant. Main discussion of this will likely happen either on fedora-security-list or fedora-websites-list. Warm regards, David Eisenstein -------- Original Message -------- Subject: "Official" (security) update announcement repository? fedora-announce-list? Re: Flaw discovered in Sendmail 8.13.5 Date: Tue, 04 Apr 2006 18:39:16 -0500 From: David Eisenstein To: fedora-security-list at redhat.com, Thomas Chung CC: Ronald Nissley Thomas Chung wrote: > On 4/4/06, Ronald Nissley wrote (to fedora-security-list): > >>A security flaw has been found in Sendmail 8.13.5. The flaw is resolved >>in 8.13.6 or by patching 8.13.5. You can read more at >>http://www.sendmail.org under Recent News. What is Fedora's response for >>issues like this? Are users expected to install the patch, >>compile/install the fixed version, or will Fedora release 8.13.6 rpms >>shortly? >Ronald, >Fedora Project already pushed 8.13.6 for FC5. >http://fedoranews.org/cms/node/466 For some reason, the announcements 'FEDORA-2006-193' for sendmail-8.13.6- 0.FC5.1 and 'FEDORA-2006-194' for sendmail-8.13.6-0.FC4.1, both apparently published March 22nd, never appeared to make it into the fedora-announce-list archives. But they indeed do appear on the fedoranews.org site, as and , respectively. Where did you get those announcements from, Thomas? Since I consider fedora-announce-list's archives to be a rather "official" repository of what is fixed or updated for Fedora Core, I generally go by the rule that whatever's in fedora-announce-list's archives are things that are fixed; and if it's not there in the archives, it's not fixed. Therefore, I, too, might have been lead to believe that this sendmail vulnerability remained unpatched in Fedora Core. Should these announcements be re-published to fedora-announce-list? Further, should fedora-announce-list be considered an official repository of security and non-security update announcements for Fedora packages? If not, does the Fedora Project need to define such an official repository? -- some web location where we can all agree to point end-users to and say, "Here. This is where all update announcements will reside, so if there's no announcement here about issue xyz, then issue xyz's not been fixed." ?? Warm regards, David Eisenstein ps: By the way, FYI, Fedora Legacy ran into a number of bugs in our initial release of packages that patch the CVE-2006-0058 sendmail issue for three of the five distributions we work with, RHL 7.3, RHL 9, and FC1; the FC2 and FC3 packages appeared to be fine on initial release. The bugs were mostly due to the fact that we had to *upgrade* older sendmail's to sendmail-8.12.11, which broke some things. (See Bugzilla #186277 starting with comments #30 ff. for more info....) We have just today finished our QA process on the RHL 7.3, RHL9, and FC1 pack- ages that are currently in updates-testing, so updated packages should be released soon. -dde From marcdeslauriers at videotron.ca Wed Apr 5 00:42:48 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 04 Apr 2006 20:42:48 -0400 Subject: [FLSA-2006:152873] Updated xine package fixes security issues Message-ID: <44331288.3010106@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated xine package fixes security issues Advisory ID: FLSA:152873 Issue date: 2006-04-04 Product: Red Hat Linux 7.3 Keywords: Bugfix, Security CVE Names: CVE-2004-0372, CVE-2004-1379 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: An updated xine package that fixes security bugs is now available. xine is a free gpl-licensed video player for unix-like systems. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 3. Problem description: 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 (cve.mitre.org) 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. The Common Vulnerabilities and Exposures project has assigned the name CVE-2004-1379 to this issue. All users of xine should upgrade to this updated package, which includes 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=152873 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/xine-0.9.8-4.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/xine-0.9.8-4.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/xine-devel-0.9.8-4.2.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- http://download.fedoralegacy.org/ 297e2b6fb5bb2dad8629944e03dc8d7635f5c225 redhat/7.3/updates/i386/xine-0.9.8-4.2.legacy.i386.rpm 465a4ea2a12017a0cee76883e9263ece27c31a6d redhat/7.3/updates/i386/xine-devel-0.9.8-4.2.legacy.i386.rpm 7336c58504919c05a6ccd5caac1c4a41bb7b7c12 redhat/7.3/updates/SRPMS/xine-0.9.8-4.2.legacy.src.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0372 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1379 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 Wed Apr 5 00:43:31 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 04 Apr 2006 20:43:31 -0400 Subject: [FLSA-2006:152896] Updated mod_python package fixes a security issue Message-ID: <443312B3.7060803@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated mod_python package fixes a security issue Advisory ID: FLSA:152896 Issue date: 2006-04-04 Product: Red Hat Linux, Fedora Core Keywords: Bugfix, Security CVE Name: CVE-2005-0088 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: 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. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 3. Problem description: 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. 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=152896 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/mod_python-2.7.8-1.7.3.3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/mod_python-2.7.8-1.7.3.3.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/mod_python-3.0.1-4.1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/mod_python-3.0.1-4.1.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/mod_python-3.0.4-0.1.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/mod_python-3.0.4-0.1.1.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- f936f1ddb29779efae651ff90a19fa17d4edb9f8 redhat/7.3/updates/i386/mod_python-2.7.8-1.7.3.3.legacy.i386.rpm d7792718f71006a00d5e932009dff9b8688330a5 redhat/7.3/updates/SRPMS/mod_python-2.7.8-1.7.3.3.legacy.src.rpm 6b1e637878a7af1f58f1127d07b7614334b71136 redhat/9/updates/i386/mod_python-3.0.1-4.1.legacy.i386.rpm 5ef5e32ac4d17f77c602d99299baab7f7c00c52d redhat/9/updates/SRPMS/mod_python-3.0.1-4.1.legacy.src.rpm d3959d23e0718b15a4a0b4fc4126b3198e7e98f8 fedora/1/updates/i386/mod_python-3.0.4-0.1.1.legacy.i386.rpm 20c04acf2eadcb2d99cf6c076a6d1ea34537ed24 fedora/1/updates/SRPMS/mod_python-3.0.4-0.1.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-0088 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 Wed Apr 5 00:44:08 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 04 Apr 2006 20:44:08 -0400 Subject: [FLSA-2006:156139] Updated tcpdump packages fix security issues Message-ID: <443312D8.9020405@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated tcpdump packages fix security issues Advisory ID: FLSA:156139 Issue date: 2006-04-04 Product: Red Hat Linux, Fedora Core Keywords: Bugfix, Security CVE Names: CVE-2005-1267, CVE-2005-1278, CVE-2005-1279, CVE-2005-1280 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated tcpdump packages that fix several security issues are now available. Tcpdump is a command-line tool for monitoring network traffic. 2. Relevant releases/architectures: Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 3. Problem description: 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. 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=156139 6. RPMs required: Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/tcpdump-3.7.2-7.9.4.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/tcpdump-3.7.2-7.9.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/libpcap-0.7.2-7.9.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/arpwatch-2.1a11-7.9.4.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/tcpdump-3.7.2-8.fc1.3.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/tcpdump-3.7.2-8.fc1.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/libpcap-0.7.2-8.fc1.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/arpwatch-2.1a11-8.fc1.3.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/tcpdump-3.8.2-6.FC2.3.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/tcpdump-3.8.2-6.FC2.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/libpcap-0.8.3-6.FC2.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/arpwatch-2.1a13-6.FC2.3.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 0beccb4a6dd929174bc2d70d680a2e3c4a094391 redhat/9/updates/i386/tcpdump-3.7.2-7.9.4.legacy.i386.rpm 71e1ffc2c4dbf2a5c754630e198f17af94000e66 redhat/9/updates/i386/libpcap-0.7.2-7.9.4.legacy.i386.rpm 843a832974f531413a8e406491f6c91d09bda24d redhat/9/updates/i386/arpwatch-2.1a11-7.9.4.legacy.i386.rpm 192fa5bbebe8039f3c23b8aa26804d1c4b788412 redhat/9/updates/SRPMS/tcpdump-3.7.2-7.9.4.legacy.src.rpm 1a426b6225718dbd325fbe0c6d54f8904b710103 fedora/1/updates/i386/tcpdump-3.7.2-8.fc1.3.legacy.i386.rpm 45cffdb7d98c2eb03da004d89b776a7050ff5c40 fedora/1/updates/i386/libpcap-0.7.2-8.fc1.3.legacy.i386.rpm 75e263aa296969c873d0475cc1c0785c30ea24d6 fedora/1/updates/i386/arpwatch-2.1a11-8.fc1.3.legacy.i386.rpm 6e86c20a8af1fc607809c713d7ac00ab5e2f717c fedora/1/updates/SRPMS/tcpdump-3.7.2-8.fc1.3.legacy.src.rpm 32d0dcf31fbe12225954cc32dad45dbcb6c5f5e4 fedora/2/updates/i386/tcpdump-3.8.2-6.FC2.3.legacy.i386.rpm c84625e92600faa8566129c8229daa6c328dcee9 fedora/2/updates/i386/libpcap-0.8.3-6.FC2.3.legacy.i386.rpm dbdcbed104a6d3985a0735aab55031a3be0e1a74 fedora/2/updates/i386/arpwatch-2.1a13-6.FC2.3.legacy.i386.rpm bb98c4cd71507e4dec94da2c1c9f95ee9bbacde1 fedora/2/updates/SRPMS/tcpdump-3.8.2-6.FC2.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-1267 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1278 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1279 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1280 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 Wed Apr 5 00:44:42 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 04 Apr 2006 20:44:42 -0400 Subject: [FLSA-2006:156290] Updated cyrus-imapd packages fix security issues Message-ID: <443312FA.9090800@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated cyrus-imapd packages fix security issues Advisory ID: FLSA:156290 Issue date: 2006-04-04 Product: Fedora Core Keywords: Bugfix, Security CVE Names: CVE-2005-0546 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: 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. 2. Relevant releases/architectures: Fedora Core 2 - i386 3. Problem description: 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. 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=156290 6. RPMs required: Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/cyrus-imapd-2.2.12-1.1.fc2.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/cyrus-imapd-2.2.12-1.1.fc2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/cyrus-imapd-devel-2.2.12-1.1.fc2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/cyrus-imapd-murder-2.2.12-1.1.fc2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/cyrus-imapd-nntp-2.2.12-1.1.fc2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/cyrus-imapd-utils-2.2.12-1.1.fc2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/perl-Cyrus-2.2.12-1.1.fc2.1.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 869a5d94e05156e2bdcff36242fd25b2c0e1c6d1 fedora/2/updates/i386/cyrus-imapd-2.2.12-1.1.fc2.1.legacy.i386.rpm b3bfaca68420697544395c17dbf2cefb5eabcf8f fedora/2/updates/i386/cyrus-imapd-devel-2.2.12-1.1.fc2.1.legacy.i386.rpm 0a8652c25f5d608811b64c634191845b6dcd672a fedora/2/updates/i386/cyrus-imapd-murder-2.2.12-1.1.fc2.1.legacy.i386.rpm d7cfe6d91b0aa23b189949bf516e94479eefd8ef fedora/2/updates/i386/cyrus-imapd-nntp-2.2.12-1.1.fc2.1.legacy.i386.rpm 03b23f099fd26fa8421bf90f4542ff4e56226d36 fedora/2/updates/i386/cyrus-imapd-utils-2.2.12-1.1.fc2.1.legacy.i386.rpm 1d1f935c0d88f209321ebb9ae679af9a0ff23e42 fedora/2/updates/i386/perl-Cyrus-2.2.12-1.1.fc2.1.legacy.i386.rpm de27bfdc5d7e2a2c5268d769ef0842aba85bfed5 fedora/2/updates/SRPMS/cyrus-imapd-2.2.12-1.1.fc2.1.legacy.src.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0546 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 Wed Apr 5 00:45:15 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 04 Apr 2006 20:45:15 -0400 Subject: [FLSA-2006:170411] Updated imap packages fix security issue Message-ID: <4433131B.20300@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated imap packages fix security issue Advisory ID: FLSA:170411 Issue date: 2006-04-04 Product: Red Hat Linux, Fedora Core Keywords: Bugfix, Security CVE Names: CVE-2005-2933 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: 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. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 3. Problem description: 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. 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=170411 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/imap-2001a-10.3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/imap-2001a-10.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/imap-devel-2001a-10.3.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/imap-2001a-18.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/imap-2001a-18.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/imap-devel-2001a-18.2.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/imap-2002d-3.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/imap-2002d-3.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/imap-devel-2002d-3.2.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- a516bdac39c9b3946a51e2aa1b2c525418405097 redhat/7.3/updates/i386/imap-2001a-10.3.legacy.i386.rpm 7492a4f5a96f61a50bc1d486004a991407fb8a93 redhat/7.3/updates/i386/imap-devel-2001a-10.3.legacy.i386.rpm eb6df42d990be3bbf408b9c9cfe759d4ac31d82f redhat/7.3/updates/SRPMS/imap-2001a-10.3.legacy.src.rpm dd3d1a3bac748d1db5643a76a86c02568abec7d2 redhat/9/updates/i386/imap-2001a-18.2.legacy.i386.rpm d7986d8efea12260ebb0613bb6cd486d72ef4ac1 redhat/9/updates/i386/imap-devel-2001a-18.2.legacy.i386.rpm aef5ef7d054ff02b594bcb2ba564bfbb4778f00b redhat/9/updates/SRPMS/imap-2001a-18.2.legacy.src.rpm 369fb568801a2d2865a55b2ceabab87e496d8705 fedora/1/updates/i386/imap-2002d-3.2.legacy.i386.rpm 967a77fbc8a4d2dcc3fdfac8b715d7a84537c0c0 fedora/1/updates/i386/imap-devel-2002d-3.2.legacy.i386.rpm 43b5221927cbeb9c2f3387f6a4b8f46f66d4d77d fedora/1/updates/SRPMS/imap-2002d-3.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-2933 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 Wed Apr 5 00:45:50 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 04 Apr 2006 20:45:50 -0400 Subject: [FLSA-2006:183571-1] Updated tar package fixes security issue Message-ID: <4433133E.30403@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated tar package fixes security issue Advisory ID: FLSA:183571-1 Issue date: 2006-04-04 Product: Red Hat Linux, Fedora Core Keywords: Bugfix, Security CVE Names: CVE-2005-1918 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: 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. 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: 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. 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=183571 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/tar-1.13.25-4.7.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/tar-1.13.25-4.7.2.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/tar-1.13.25-11.1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/tar-1.13.25-11.1.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/tar-1.13.25-12.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/tar-1.13.25-12.1.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/tar-1.13.25-14.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/tar-1.13.25-14.1.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 57d5b198335bcb254ff49b26b60b2ded6fdc3c29 redhat/7.3/updates/i386/tar-1.13.25-4.7.2.legacy.i386.rpm aec36c77c75a882b3c44a61fa61c23ff204ef4e5 redhat/7.3/updates/SRPMS/tar-1.13.25-4.7.2.legacy.src.rpm df30641462702e447ac80e5e71db048e039cc378 redhat/9/updates/i386/tar-1.13.25-11.1.legacy.i386.rpm 27e7678d52f44d3872047c5b05c6dfd751c2a806 redhat/9/updates/SRPMS/tar-1.13.25-11.1.legacy.src.rpm 0caee4057c9325f93ac327e1a4d067fee8b1a744 fedora/1/updates/i386/tar-1.13.25-12.1.legacy.i386.rpm 458a1d96fdf8f580b5702a7243f7653d8c581ac6 fedora/1/updates/SRPMS/tar-1.13.25-12.1.legacy.src.rpm 5565230fd52a82671b69a9310883a25f7844b8a6 fedora/2/updates/i386/tar-1.13.25-14.1.legacy.i386.rpm 864f986b64392dacaec2bde2c42339a4e6bd7e35 fedora/2/updates/SRPMS/tar-1.13.25-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-1918 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 Wed Apr 5 00:46:22 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 04 Apr 2006 20:46:22 -0400 Subject: [FLSA-2006:183571-2] Updated tar package fixes security issue Message-ID: <4433135E.4040600@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated tar package fixes security issue Advisory ID: FLSA:183571-2 Issue date: 2006-04-04 Product: Fedora Core Keywords: Bugfix, Security CVE Names: CVE-2006-0300 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: 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. 2. Relevant releases/architectures: Fedora Core 3 - i386, x86_64 3. Problem description: 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. 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=183571 6. RPMs required: Fedora Core 3: SRPM: http://download.fedoralegacy.org/fedora/3/updates/SRPMS/tar-1.14-5.FC3.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/3/updates/i386/tar-1.14-5.FC3.1.legacy.i386.rpm x86_64: http://download.fedoralegacy.org/fedora/3/updates/x86_64/tar-1.14-5.FC3.1.legacy.x86_64.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 4f6bcb8de3d063812be162a217aeea29f2fc5963 fedora/3/updates/i386/tar-1.14-5.FC3.1.legacy.i386.rpm 42eec5a437fb2d1205684c224d10efde0ff8c65e fedora/3/updates/x86_64/tar-1.14-5.FC3.1.legacy.x86_64.rpm 244730a9296048ff02b1700ca982bc10cef7fec0 fedora/3/updates/SRPMS/tar-1.14-5.FC3.1.legacy.src.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0300 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 Wed Apr 5 00:47:00 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 04 Apr 2006 20:47:00 -0400 Subject: [FLSA-2006:180159] Updated unzip package fixes security issue Message-ID: <44331384.8040307@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated unzip package fixes security issue Advisory ID: FLSA:180159 Issue date: 2006-04-04 Product: Red Hat Linux, Fedora Core Keywords: Bugfix, Security CVE Names: CVE-2005-4667 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: 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. 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 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. 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=180159 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/unzip-5.50-31.1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/unzip-5.50-31.1.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/unzip-5.50-33.1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/unzip-5.50-33.1.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/unzip-5.50-35.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/unzip-5.50-35.1.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/unzip-5.50-37.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/unzip-5.50-37.1.legacy.i386.rpm Fedora Core 3: SRPM: http://download.fedoralegacy.org/fedora/3/updates/SRPMS/unzip-5.51-4.fc3.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/3/updates/i386/unzip-5.51-4.fc3.1.legacy.i386.rpm x86_64: http://download.fedoralegacy.org/fedora/3/updates/x86_64/unzip-5.51-4.fc3.1.legacy.x86_64.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 5d341df449ddf2d22410bd37bfba7d124960c1ae redhat/7.3/updates/i386/unzip-5.50-31.1.legacy.i386.rpm d76fb8e7acc75cfca6d419b461ded4176348e2a2 redhat/7.3/updates/SRPMS/unzip-5.50-31.1.legacy.src.rpm 00b6b6b34e4229e9a2547418c83470752c9c9ff9 redhat/9/updates/i386/unzip-5.50-33.1.legacy.i386.rpm 30aa7fdaf8aada1dbb30dab4e6058a846d6a1e34 redhat/9/updates/SRPMS/unzip-5.50-33.1.legacy.src.rpm 473bf802cf9257684f534cb99e7813e4257bf189 fedora/1/updates/i386/unzip-5.50-35.1.legacy.i386.rpm 5f5fba20950799ed5676fa1e65044f3b2a61c497 fedora/1/updates/SRPMS/unzip-5.50-35.1.legacy.src.rpm 475ae5bed64d3273ccd986d5ee55bd5300b9b01f fedora/2/updates/i386/unzip-5.50-37.1.legacy.i386.rpm 4d35e2bceeb45747e415b66deea0e955b258889e fedora/2/updates/SRPMS/unzip-5.50-37.1.legacy.src.rpm 3fdea3917830be7fd801a2872ef2caa115592d13 fedora/3/updates/i386/unzip-5.51-4.fc3.1.legacy.i386.rpm a55ddb890db2308be565ea22057624808afda1b3 fedora/3/updates/x86_64/unzip-5.51-4.fc3.1.legacy.x86_64.rpm e1f9b432cec0100d9a50ad99d3b72c8b19aea8b4 fedora/3/updates/SRPMS/unzip-5.51-4.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-4667 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 Wed Apr 5 00:47:35 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 04 Apr 2006 20:47:35 -0400 Subject: [FLSA-2006:184074] Updated pine package fixes security issue Message-ID: <443313A7.9000402@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated pine package fixes security issue Advisory ID: FLSA:184074 Issue date: 2006-04-04 Product: Red Hat Linux Keywords: Bugfix, Security CVE Names: CVE-2003-0297 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: An updated Pine package is now available to fix a denial of service attack. Pine is an email user agent. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 3. Problem description: 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. 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=184074 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/pine-4.44-19.73.1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/pine-4.44-19.73.1.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/pine-4.44-19.90.1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/pine-4.44-19.90.1.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 2f5de5f092e8d5c2d821e3715fcc6656b19e1b54 redhat/7.3/updates/i386/pine-4.44-19.73.1.legacy.i386.rpm 4fc304469e6dad1025ac0eb1c428bbc84a9ed76f redhat/7.3/updates/SRPMS/pine-4.44-19.73.1.legacy.src.rpm 043112c55f52e5454ab01e52f7a50968016ac6a1 redhat/9/updates/i386/pine-4.44-19.90.1.legacy.i386.rpm d84320a9dbe9b1b1917e2acb8c6306c005711075 redhat/9/updates/SRPMS/pine-4.44-19.90.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-2003-0297 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 Wed Apr 5 00:48:08 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 04 Apr 2006 20:48:08 -0400 Subject: [FLSA-2006:184098] Updated libc-client packages fixes security issue Message-ID: <443313C8.8050503@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated libc-client packages fixes security issue Advisory ID: FLSA:184098 Issue date: 2006-04-04 Product: Fedora Core 2 Keywords: Bugfix, Security CVE Names: CVE-2005-2933 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated libc-client packages that fix a buffer overflow issue are now available. C-client is a common API for accessing mailboxes. 2. Relevant releases/architectures: Fedora Core 2 - i386 3. Problem description: 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. 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=184098 6. RPMs required: Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/libc-client-2002e-5.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/libc-client-2002e-5.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/libc-client-devel-2002e-5.1.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 5232f6a722f64fac4c5e09ca3d34a8e5d33192ed fedora/2/updates/i386/libc-client-2002e-5.1.legacy.i386.rpm 5e03f3725e30f607708e8da1e9c1537d6e929a29 fedora/2/updates/i386/libc-client-devel-2002e-5.1.legacy.i386.rpm 489cbea579ce3fece1527c68df20f24e8c9bfe75 fedora/2/updates/SRPMS/libc-client-2002e-5.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-2933 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 Wed Apr 5 00:49:42 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 04 Apr 2006 20:49:42 -0400 Subject: [Updated] [FLSA-2006:186277] Updated sendmail packages fix security issue Message-ID: <44331426.9000300@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated sendmail packages fix security issue Advisory ID: FLSA:186277 Issue date: 2006-04-04 Product: Red Hat Linux, Fedora Core Keywords: Bugfix, Security 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). [Updated 4th April 2006] Red Hat Linux 7.3, Red Hat Linux 9, and Fedora Core 1 packages have been updated to correct numerous problems with the previously released updates. 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. 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 backported patch to correct this issue. Users updating to these packages are urged to review their sendmail.cf file after updating. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. 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.10.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/sendmail-8.12.11-4.22.10.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/sendmail-cf-8.12.11-4.22.10.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/sendmail-devel-8.12.11-4.22.10.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/sendmail-doc-8.12.11-4.22.10.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/sendmail-8.12.11-4.24.3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/sendmail-8.12.11-4.24.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/sendmail-cf-8.12.11-4.24.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/sendmail-devel-8.12.11-4.24.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/sendmail-doc-8.12.11-4.24.3.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/sendmail-8.12.11-4.25.3.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/sendmail-8.12.11-4.25.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/sendmail-cf-8.12.11-4.25.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/sendmail-devel-8.12.11-4.25.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/sendmail-doc-8.12.11-4.25.3.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 --------------------------------------------------------------------- 950fc853550d93f521d4203b9f78023721fbdecd redhat/7.3/updates/i386/sendmail-8.12.11-4.22.10.legacy.i386.rpm d8c06f3f92d7dd526426b86e52bdd244e75c061a redhat/7.3/updates/i386/sendmail-cf-8.12.11-4.22.10.legacy.i386.rpm dde44f59a60481edae75ddf6d854341308e4ce62 redhat/7.3/updates/i386/sendmail-devel-8.12.11-4.22.10.legacy.i386.rpm faf27d20eb151227225cc4e2ac5014bb205aa350 redhat/7.3/updates/i386/sendmail-doc-8.12.11-4.22.10.legacy.i386.rpm e0b9ece564e8103a254311da19c6bc41a21c8ffc redhat/7.3/updates/SRPMS/sendmail-8.12.11-4.22.10.legacy.src.rpm 9f1caeadce45e2922f6bc29ea0f4e7bce4e26d02 redhat/9/updates/i386/sendmail-8.12.11-4.24.3.legacy.i386.rpm 6b7b437bb58ac9f805185ae992da9a157a0d755d redhat/9/updates/i386/sendmail-cf-8.12.11-4.24.3.legacy.i386.rpm ae48cf1d3a5d8f5bfc789a408de392fe27e84b73 redhat/9/updates/i386/sendmail-devel-8.12.11-4.24.3.legacy.i386.rpm 4571b20f603bf6f90558aa09107f5b2ae17e8111 redhat/9/updates/i386/sendmail-doc-8.12.11-4.24.3.legacy.i386.rpm 4b4ed7d51e710a447c6a839dcf203bc4636c2f62 redhat/9/updates/SRPMS/sendmail-8.12.11-4.24.3.legacy.src.rpm 3f6edb4bdcd42cca1f01fce9482d3ac10b56f530 fedora/1/updates/i386/sendmail-8.12.11-4.25.3.legacy.i386.rpm 7aaa9743d312b7ebc95baa83e186acaa267f6915 fedora/1/updates/i386/sendmail-cf-8.12.11-4.25.3.legacy.i386.rpm dfabadaa764d471b2c5963547643ca4bbe5ca0e7 fedora/1/updates/i386/sendmail-devel-8.12.11-4.25.3.legacy.i386.rpm 121433ec0c71a163993cf2a94f33fa67df786b11 fedora/1/updates/i386/sendmail-doc-8.12.11-4.25.3.legacy.i386.rpm d41f7652ea88a068e21c7f68bb018b8462695754 fedora/1/updates/SRPMS/sendmail-8.12.11-4.25.3.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 65086d18cb29e02b57ce07b6abf79ba378ae1c3c fedora/2/updates/SRPMS/sendmail-8.12.11-4.26.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 fbfba64eac81e57ae098f967b7d3bf4e47e04c87 fedora/3/updates/SRPMS/sendmail-8.13.1-3.legacy.src.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://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: OpenPGP digital signature URL: From nars at gmx.net Wed Apr 5 02:07:48 2006 From: nars at gmx.net (NARS) Date: Wed, 5 Apr 2006 03:07:48 +0100 Subject: 1-2-3 out, time for FC2? Message-ID: <29fb01c65855$e0314e70$0201a8c0@p3000> Hello, I'm another one still running FC2 on a server... :) If fedoralegacy supported FC1 for so long why to take fc2 out now? Try to do a search on dedicated servers providers, you will find most of them still provide FC2, and for eg. Plesk supports FC3 only on latest versions (officially)... another example, look at this poll at ART's site: http://www.atomicrocketturtle.com/modules.php?op=modload&name=NS-Polls&file=index&req=results&pollID=6&mode=thread&order=0&thold=0 I think FC2 is still used by many people, I would suggest you consider supporting FC2 for some more time if possible. Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From gene.heskett at verizon.net Wed Apr 5 04:08:32 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Wed, 05 Apr 2006 00:08:32 -0400 Subject: download.fedoralegacy.org not reachable Message-ID: <200604050008.32206.gene.heskett@verizon.net> Greetings; Am I the only one having trouble with this? I am getting a dns lookup failure. And this seems to be a chronic thing over the last 2-3 weeks for verizon's unprintable name servers. Can someone toss me the numerical address please. -- 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 Wed Apr 5 04:30:34 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Wed, 05 Apr 2006 00:30:34 -0400 Subject: download.fedoralegacy.org not reachable In-Reply-To: <200604050008.32206.gene.heskett@verizon.net> References: <200604050008.32206.gene.heskett@verizon.net> Message-ID: <200604050030.35056.gene.heskett@verizon.net> On Wednesday 05 April 2006 00:08, Gene Heskett wrote: >Greetings; > >Am I the only one having trouble with this? I am getting a dns lookup >failure. And this seems to be a chronic thing over the last 2-3 weeks >for verizon's unprintable name servers. > >Can someone toss me the numerical address please. Never mind, I found that somehow nscd had been restarted on ths machine, kiling it and doing another 'chkconfig nscd off' fixed it. I point the dns address on this box to the firewall, which in turn forwards things to vz's servers. When I didn't even see the lights blink on the switch as I tapped the retry button in firefox, I knew then it was my problem. Sorry for the noise. -- 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 Wed Apr 5 04:46:20 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 5 Apr 2006 07:46:20 +0300 (EEST) Subject: download.fedoralegacy.org not reachable In-Reply-To: <200604050008.32206.gene.heskett@verizon.net> References: <200604050008.32206.gene.heskett@verizon.net> Message-ID: On Wed, 5 Apr 2006, Gene Heskett wrote: > Am I the only one having trouble with this? I am getting a dns lookup > failure. And this seems to be a chronic thing over the last 2-3 weeks > for verizon's unprintable name servers. Btw, it would be nice if someone updated the private rsync access lists. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From agibson at ptm.com Wed Apr 5 16:50:13 2006 From: agibson at ptm.com (Adam Gibson) Date: Wed, 05 Apr 2006 12:50:13 -0400 Subject: [Updated] [FLSA-2006:186277] Updated sendmail packages fix security issue In-Reply-To: <44331426.9000300@videotron.ca> References: <44331426.9000300@videotron.ca> Message-ID: <4433F545.8030301@ptm.com> One thing I noticed after the latest yum update of sendmail from the previous update is that alternatives is broken for /etc/pam.d/smtp for the sendmail package. Sendmail used to create /etc/pam.d/smtp.sendmail which alternatives would create a symlink at /etc/pam.d/smtp to eventually point to the current configured smtp pam config (/etc/pam.d/smtp.sendmail for sendmail). a yum update showed this: warning: /etc/pam.d/smtp created as /etc/pam.d/smtp.rpmnew # ls -al /etc/pam.d/smtp* lrwxrwxrwx 1 root root 25 Mar 28 12:48 /etc/pam.d/smtp -> /etc/alternatives/mta-pam -rw-r--r-- 1 root root 116 Mar 26 22:37 smtp.rpmnew # ls -al /etc/alternatives/mta-pam lrwxrwxrwx 1 root root 24 Mar 28 12:48 /etc/alternatives/mta-pam -> /etc/pam.d/smtp.sendmail smtp.sendmail no longer exists. It appears to just be directly smtp now which was stored as smtp.rpmnew because the symlink created by alternatives was at /etc/pam.d/smtp. Issuing an alternatives --config mta will just setup /etc/pam.d/smtp to eventually point to /etc/pam.d/smtp.sendmail again which does not exist. Moving /etc/pam.d/smtp.rpmnew to /etc/pam.d/smtp.sendmail fixes the problem for me. I do not know what the ramifications are of having a broken symlink to /etc/pam.d/smtp but it must be used for something. Marc Deslauriers wrote: > --------------------------------------------------------------------- > Fedora Legacy Update Advisory > > Synopsis: Updated sendmail packages fix security issue > Advisory ID: FLSA:186277 > Issue date: 2006-04-04 > Product: Red Hat Linux, Fedora Core > Keywords: Bugfix, Security > 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). > > [Updated 4th April 2006] > Red Hat Linux 7.3, Red Hat Linux 9, and Fedora Core 1 packages have been > updated to correct numerous problems with the previously released > updates. > > 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 > From agibson at ptm.com Wed Apr 5 17:08:46 2006 From: agibson at ptm.com (Adam Gibson) Date: Wed, 05 Apr 2006 13:08:46 -0400 Subject: [Updated] [FLSA-2006:186277] Updated sendmail packages fix security issue In-Reply-To: <4433F545.8030301@ptm.com> References: <44331426.9000300@videotron.ca> <4433F545.8030301@ptm.com> Message-ID: <4433F99E.30708@ptm.com> Adam Gibson wrote: > One thing I noticed after the latest yum update of sendmail from the > previous update is that alternatives is broken for /etc/pam.d/smtp for > the sendmail package. Sendmail used to create /etc/pam.d/smtp.sendmail > which alternatives would create a symlink at /etc/pam.d/smtp to > eventually point to the current configured smtp pam config > (/etc/pam.d/smtp.sendmail for sendmail). > > a yum update showed this: > warning: /etc/pam.d/smtp created as /etc/pam.d/smtp.rpmnew > > # ls -al /etc/pam.d/smtp* > lrwxrwxrwx 1 root root 25 Mar 28 12:48 /etc/pam.d/smtp > -> /etc/alternatives/mta-pam > -rw-r--r-- 1 root root 116 Mar 26 22:37 smtp.rpmnew > > # ls -al /etc/alternatives/mta-pam > lrwxrwxrwx 1 root root 24 Mar 28 12:48 > /etc/alternatives/mta-pam -> /etc/pam.d/smtp.sendmail > > smtp.sendmail no longer exists. It appears to just be directly smtp now > which was stored as smtp.rpmnew because the symlink created by > alternatives was at /etc/pam.d/smtp. Issuing an alternatives --config > mta will just setup /etc/pam.d/smtp to eventually point to > /etc/pam.d/smtp.sendmail again which does not exist. This is incorrect. I moved smtp.rpmnew to smtp and alternatives does not do anything with the /etc/pam.d/smtp. I mistakenly thought it did the first time but it was just leftover from the previous sendmail package. Moving /etc/pam.d/smtp.rpmnew to /etc/pam.d/smtp fixes the problem. So basically it boils down to alternatives with the newer sendmail updates do not do anything with /etc/pam.d/smtp anymore(It is part of the packages itself and not a symlink). The problem I had is that the old symlink was in the way when sendmail was updated. I wonder if other MTAs expect /etc/pam.d/smtp to still be a symlink. If you do an alternatives for postfix or some other mta will it overwrite /etc/pam.d/smtp? If so that could be a problem if you switch back. > > Moving /etc/pam.d/smtp.rpmnew to /etc/pam.d/smtp.sendmail fixes the > problem for me. > > I do not know what the ramifications are of having a broken symlink to > /etc/pam.d/smtp but it must be used for something. > > Marc Deslauriers wrote: >> --------------------------------------------------------------------- >> Fedora Legacy Update Advisory >> >> Synopsis: Updated sendmail packages fix security issue >> Advisory ID: FLSA:186277 >> Issue date: 2006-04-04 >> Product: Red Hat Linux, Fedora Core >> Keywords: Bugfix, Security >> 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). >> >> [Updated 4th April 2006] >> Red Hat Linux 7.3, Red Hat Linux 9, and Fedora Core 1 packages have been >> updated to correct numerous problems with the previously released >> updates. >> >> 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 >> > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list From guallar at easternrad.com Wed Apr 5 17:10:28 2006 From: guallar at easternrad.com (Josep L. Guallar-Esteve) Date: Wed, 5 Apr 2006 13:10:28 -0400 Subject: 1-2-3 out, time for FC2? In-Reply-To: <29fb01c65855$e0314e70$0201a8c0@p3000> References: <29fb01c65855$e0314e70$0201a8c0@p3000> Message-ID: <200604051310.33692.guallar@easternrad.com> On Tuesday 04 April 2006 22:07, NARS wrote: > I think FC2 is still used by many people, I would suggest you consider > supporting FC2 for some more time if possible. Hi NARS, I believe the problem is caused by lack of enough manpower. Maybe, if you can round up some volunteers with time, machines and knowledge, FC2 might get extended support. If FC1 is still supported by Fedora Legacy (FL), it is b/c there are members of FL that volunteer time, machines and knowledge to make it happen. Regards, Josep -- Josep L. Guallar-Esteve - IT Department - Eastern Radiologists, Inc. Systems and PACS Administration http://www.easternrad.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From kurt at uniqsys.com Wed Apr 5 17:24:21 2006 From: kurt at uniqsys.com (Kurt Bechstein) Date: Wed, 05 Apr 2006 13:24:21 -0400 Subject: sendmail updates Message-ID: <1144257861.2980.34.camel@scooby.uniqsys.com> I have a question on the recent sendmail updates. I'm referencing two urls here and they are: http://fedoranews.org/cms/node/489 http://fedoranews.org/cms/node/581 They both appear to refer to the same sendmail bug so I'm just curious if the initial packages didn't fully fix the problem or if there is something else that I'm missing here since the detail info on each url is identical. -- Kurt Bechstein From kelson at speed.net Wed Apr 5 18:05:30 2006 From: kelson at speed.net (Kelson) Date: Wed, 05 Apr 2006 11:05:30 -0700 Subject: sendmail updates In-Reply-To: <1144257861.2980.34.camel@scooby.uniqsys.com> References: <1144257861.2980.34.camel@scooby.uniqsys.com> Message-ID: <443406EA.7050606@speed.net> Kurt Bechstein wrote: > I have a question on the recent sendmail updates. I'm referencing two > urls here and they are: > http://fedoranews.org/cms/node/489 > http://fedoranews.org/cms/node/581 > > They both appear to refer to the same sendmail bug so I'm just curious > if the initial packages didn't fully fix the problem or if there is > something else that I'm missing here since the detail info on each url > is identical. The initial release fixed the bug, but introduced packaging problems on some OS versions because they used versions of Sendmail that were too old to patch. FL provided an upgraded Sendmail, but the initial packages didn't play well with other parts of the OS (particularly the alternatives system). The new release is to fix the packaging problems. As I understand it, this only affected RH7.3, RH9, and FC1, because Fedora Core 2 and later used recent enough Sendmail versions that they could use the patch, so no major changes in the packaging spec were necessary. This is mentioned briefly in the "1. Topic" section: > [Updated 4th April 2006] > Red Hat Linux 7.3, Red Hat Linux 9, and Fedora Core 1 packages have been > updated to correct numerous problems with the previously released > updates. -- Kelson Vibber SpeedGate Communications From jancio_wodnik at wp.pl Wed Apr 5 19:15:27 2006 From: jancio_wodnik at wp.pl (Jancio Wodnik) Date: Wed, 05 Apr 2006 21:15:27 +0200 Subject: sendmail updates In-Reply-To: <443406EA.7050606@speed.net> References: <1144257861.2980.34.camel@scooby.uniqsys.com> <443406EA.7050606@speed.net> Message-ID: <4434174F.6060007@wp.pl> Kelson napisa?(a): > Kurt Bechstein wrote: >> I have a question on the recent sendmail updates. I'm referencing two >> urls here and they are: >> http://fedoranews.org/cms/node/489 >> http://fedoranews.org/cms/node/581 >> >> They both appear to refer to the same sendmail bug so I'm just curious >> if the initial packages didn't fully fix the problem or if there is >> something else that I'm missing here since the detail info on each url >> is identical. > > The initial release fixed the bug, but introduced packaging problems > on some OS versions because they used versions of Sendmail that were > too old to patch. FL provided an upgraded Sendmail, but the initial > packages didn't play well with other parts of the OS (particularly the > alternatives system). > > The new release is to fix the packaging problems. As I understand it, > this only affected RH7.3, RH9, and FC1, because Fedora Core 2 and > later used recent enough Sendmail versions that they could use the > patch, so no major changes in the packaging spec were necessary. > > This is mentioned briefly in the "1. Topic" section: > >> [Updated 4th April 2006] >> Red Hat Linux 7.3, Red Hat Linux 9, and Fedora Core 1 packages have been >> updated to correct numerous problems with the previously released >> updates. > Hi. but above statement is not true. There are still problem with alternatives on rh7.3 and rh9 when updated to latest sendmail update. Lates update didn't fix that. Sorry, but there is still some work to do. Regrads, Irens. From rostetter at mail.utexas.edu Wed Apr 5 19:32:25 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 5 Apr 2006 14:32:25 -0500 Subject: sendmail updates In-Reply-To: <4434174F.6060007@wp.pl> References: <1144257861.2980.34.camel@scooby.uniqsys.com> <443406EA.7050606@speed.net> <4434174F.6060007@wp.pl> Message-ID: <20060405143225.p8ni6hy7yfk84c44@mail.ph.utexas.edu> Quoting Jancio Wodnik : > Hi. but above statement is not true. There are still problem with > alternatives on rh7.3 and rh9 when updated to latest sendmail update. > > Lates update didn't fix that. Sorry, but there is still some work to do. > > Regrads, > > Irens. Then you best report what those issues are, and how to reproduce them. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From jkeating at redhat.com Wed Apr 5 20:23:30 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 5 Apr 2006 16:23:30 -0400 Subject: 1-2-3 out, time for FC2? In-Reply-To: <29fb01c65855$e0314e70$0201a8c0@p3000> References: <29fb01c65855$e0314e70$0201a8c0@p3000> Message-ID: <200604051623.30549.jkeating@redhat.com> On Tuesday 04 April 2006 22:07, NARS wrote: > If fedoralegacy supported FC1 for so long why to take fc2 out now? Try to > do a search on dedicated servers providers, you will find most of them > still provide FC2, and for eg. Plesk supports FC3 only on latest versions > (officially)... another example, look at this poll at ART's site: > http://www.atomicrocketturtle.com/modules.php?op=modload&name=NS-Polls&file >=index&req=results&pollID=6&mode=thread&order=0&thold=0 > > I think FC2 is still used by many people, I would suggest you consider > supporting FC2 for some more time if possible. Honestly, I feel that supporting FC1 for so long was a mistake. It set a precedence that I really don't want to continue. Legacy picked a timeline that fit well with what Fedora produces, and what RHEL (and rebuilds) offer. Going further than that is really beyond the scope of the Fedora Project as a whole. Falling back into our 1-2-3 and out set schedule will be the best thing, and to get to that point we need to drop FC1 and FC2, to make room for FC3. We need to concentrate on doing better for the releases we do support, and adding to the workload is not the way to do this. Fedora is great, and the lifespan we can give it is a good, but if you need more, you should probably be looking at RHEL or one of its rebuilds. -- 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 Mike.McCarty at sbcglobal.net Wed Apr 5 20:25:16 2006 From: Mike.McCarty at sbcglobal.net (Mike McCarty) Date: Wed, 05 Apr 2006 15:25:16 -0500 Subject: 1-2-3 out, time for FC2? In-Reply-To: <200604051310.33692.guallar@easternrad.com> References: <29fb01c65855$e0314e70$0201a8c0@p3000> <200604051310.33692.guallar@easternrad.com> Message-ID: <443427AC.5050502@sbcglobal.net> Josep L. Guallar-Esteve wrote: > On Tuesday 04 April 2006 22:07, NARS wrote: > >>I think FC2 is still used by many people, I would suggest you consider >>supporting FC2 for some more time if possible. > > > Hi NARS, > > I believe the problem is caused by lack of enough manpower. Maybe, if you can > round up some volunteers with time, machines and knowledge, FC2 might get > extended support. > > If FC1 is still supported by Fedora Legacy (FL), it is b/c there are members > of FL that volunteer time, machines and knowledge to make it happen. I have volunteered some time for test if (1) The changes can be "contained" so that they do not compromise my machine if they fail. IOW, there is a guaranteed backout which loses no information. (2) I have the space on my disc (which is admittedly rather low). So far, (1) has been a sticking point, I think. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From jkeating at j2solutions.net Wed Apr 5 20:26:31 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 5 Apr 2006 16:26:31 -0400 Subject: download.fedoralegacy.org not reachable In-Reply-To: References: <200604050008.32206.gene.heskett@verizon.net> Message-ID: <200604051626.31465.jkeating@j2solutions.net> On Wednesday 05 April 2006 00:46, Pekka Savola wrote: > Btw, it would be nice if someone updated the private rsync access > lists. Whoops. I had this on my to-do list, but my move across the country has dropped a few things. I'll add it back to my list and try to update that for you. FWIW, the private list doesn't really add much, for now you can use the non-private port. -- 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 deisenst at gtw.net Wed Apr 5 20:42:50 2006 From: deisenst at gtw.net (David Eisenstein) Date: Wed, 05 Apr 2006 15:42:50 -0500 Subject: [Updated] [FLSA-2006:186277] Updated sendmail packages fix security issue In-Reply-To: <4433F99E.30708@ptm.com> References: <44331426.9000300@videotron.ca> <4433F545.8030301@ptm.com> <4433F99E.30708@ptm.com> Message-ID: <44342BCA.5020409@gtw.net> Adam Gibson wrote: > Adam Gibson wrote: > >> One thing I noticed after the latest yum update of sendmail from the >> previous update is that alternatives is broken for /etc/pam.d/smtp for >> the sendmail package. <> > So basically it boils down to alternatives with the newer sendmail > updates do not do anything with /etc/pam.d/smtp anymore(It is part of > the packages itself and not a symlink). The problem I had is that the > old symlink was in the way when sendmail was updated. My take, judging from previous comments you've posted, Adam, is that you run the Red Hat 9 version of sendmail? There are 3 packages available in updates for RH9: 1) sendmail-8.12.8-9.90.i386.rpm (Release 9/17/03 by RH, vulnerable) 2) sendmail-8.12.11-4.24.1.legacy.i386.rpm (Released 3/23/06 by FL) 3) sendmail-8.12.11-4.24.3.legacy.i386.rpm (Released yesterday by FL) The original Sendmail (8.11.6 for RH7.3, 8.12.8 for RH9 and 8.12.10 for FC1) did not create any kind of alternatives for /etc/pam.d/smtp nor for /usr/lib/sendmail. They were just plain files, packaged as part of the rpm. However, the first updated packages for RH9 and FC1 *did* create alternatives for both of those files, and perhaps also for the sendmail.8 man-page. This created problems for many of our users. Although in the process of updating from 8.12.8 to 8.12.11-4.24.1.legacy, the alternatives system would (during the run of the POST-INSTALL scriptlet) create /etc/pam.d/smtp and /usr/lib/sendmail as symlinks to files in /etc/mta, later in the rpm update process (when uninstalling 8.12.8) those symbolic links would be erased, because /etc/pam.d/smtp and /usr/lib/sendmail were packaged files in the former rpm. This ended up then with many users that depended on /etc/pam.d/smtp (for SMTP AUTH to work correctly) with broken sendmail packages; similarly with users who needed /usr/lib/sendmail to point to the MTA program. To fix this bug in RH9's sendmail-8.12.11-4.24.1.legacy (similarly in FC1's), we elected to revert the alternatives behavior to what it had been in sendmail-8.12.8. The various scenarios might be, then: a) User is using 8.12.8, elects to upgrade directly to 8.12.11-4.24.3. No problem. Alternatives system the same, so /etc/pam.d/smtp and /usr/lib/sendmail files are upgraded unless changed by the end user, in which case /etc/pam.d/smtp.rpmnew is created. b) User is using 8.12.8, has upgraded to 8.12.11-4.24.1. Uh oh, smtp auth is no longer working or /usr/lib/sendmail gone. User reverts to 8.12.8, sendmail works again. User then upgrades to 8.12.11-4.24.3. Works okay; alternative system the same. c) User is using 8.12.8, upgraded to 8.12.11-4.24.1. Same problems as (b). User either fixes this by hand (by making a symlink /etc/pam.d/ smtp -> smtp.sendmail &c) or fixes this using the "alternatives --config mta" command, as suggested by Marc in . If user does either of these two things, a later upgrade to sendmail-8.12.11-4.24.3 will break /etc/pam.d/smtp, causing it to point to a non-existent /etc/pam.d/smtp.sendmail, and create /etc/pam.d/smtp.rpmnew. This one, I think, would have been your scenario, Adam. You have provided a good workaround for this. d) User using 8.12.8, upgraded to 8.12.11-4.24.1, finds it doesn't work, then upgrades to 8.12.11.4.24.3 without making any config changes. This, too, works okay, because at the end of installing 8.12.11-4.24.1, the user never ended up with /etc/pam.d/smtp nor /usr/lib/sendmail in the first place. So a subsequent upgrade to 8.12.11-4.24.3 will in- stall those files as new. In 3 out of 4 scenarios (perhaps there are more?), upgrading to our most recently-released package works, at least for RH9. I believe there would be similar scenarios for RH7.3 and FC1. Otherwise, as in (c) above, the user needs to employ a workaround if needing /etc/pam.d/smtp or /usr/lib/sendmail. > I wonder if other MTAs expect /etc/pam.d/smtp to still be a symlink. If > you do an alternatives for postfix or some other mta will it overwrite > /etc/pam.d/smtp? If so that could be a problem if you switch back. I checked the most recent postfix package for RH9, and it appears that the alternatives is correctly configured. However, for FC1's postfix, it does not appear to be correctly configured, so this could be an issue for FC1 users who switch from sendmail to postfix. As this is not a security issue per se, it is not likely to be fixed. None of these alternatives system issues should affect FC2 or FC3 users, as Fedora Legacy's updates used the same alternatives configuration as were previously used for FC2 and FC3, so the upgrade should "just work." Hope this helps explain the situation, Adam. It was a mess, and we did the best we knew to fix it. Sorry for the trouble it has caused. Warm regards, David Eisenstein From jancio_wodnik at wp.pl Wed Apr 5 20:58:57 2006 From: jancio_wodnik at wp.pl (Jancio Wodnik) Date: Wed, 05 Apr 2006 22:58:57 +0200 Subject: sendmail updates In-Reply-To: <20060405143225.p8ni6hy7yfk84c44@mail.ph.utexas.edu> References: <1144257861.2980.34.camel@scooby.uniqsys.com> <443406EA.7050606@speed.net> <4434174F.6060007@wp.pl> <20060405143225.p8ni6hy7yfk84c44@mail.ph.utexas.edu> Message-ID: <44342F91.2020704@wp.pl> Eric Rostetter napisa?(a): > Quoting Jancio Wodnik : > >> Hi. but above statement is not true. There are still problem with >> alternatives on rh7.3 and rh9 when updated to latest sendmail update. >> >> Lates update didn't fix that. Sorry, but there is still some work to do. >> >> Regrads, >> >> Irens. > > Then you best report what those issues are, and how to reproduce them. > > --Eric Rostetter > The Department of Physics > The University of Texas at Austin > > Go Longhorns! > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > > It's me again. I have got latest sendmail's update on my rh73 and rh9 boxes. Issues are still the same: after update there is lack of those files: 1) there is no more /etc/pam.d/smtp.sendmail -> but thereis /etc/pam.d/smtp.rpmnew 2) there is no more /usr/lib/sendmail.sendmail In /etc/alternatives were broken links: mta-pam, mta-sendmail, mta-sendmailman My sendmail rejects incoming mail form LAN, so i must by hand fix above broken symlinks, after that and sendmail reload all goes fine. So there are still problems with the latest update, when we spoke about: problems with alternatives and sendmail. In my opinion: the latest update didn't fix that. That's all. best reg ... Irens From agibson at ptm.com Wed Apr 5 21:05:19 2006 From: agibson at ptm.com (Adam Gibson) Date: Wed, 05 Apr 2006 17:05:19 -0400 Subject: [Updated] [FLSA-2006:186277] Updated sendmail packages fix security issue In-Reply-To: <44342BCA.5020409@gtw.net> References: <44331426.9000300@videotron.ca> <4433F545.8030301@ptm.com> <4433F99E.30708@ptm.com> <44342BCA.5020409@gtw.net> Message-ID: <4434310F.2090309@ptm.com> David Eisenstein wrote: > Adam Gibson wrote: >> Adam Gibson wrote: >> >>> One thing I noticed after the latest yum update of sendmail from the >>> previous update is that alternatives is broken for /etc/pam.d/smtp for >>> the sendmail package. <> >> So basically it boils down to alternatives with the newer sendmail >> updates do not do anything with /etc/pam.d/smtp anymore(It is part of >> the packages itself and not a symlink). The problem I had is that the >> old symlink was in the way when sendmail was updated. > > My take, judging from previous comments you've posted, Adam, is that you run > the Red Hat 9 version of sendmail? Correct. I realized that I did not include an OS version after submitting the second email and didn't want to send a third reply. Good guess :). ... > To fix this bug in RH9's sendmail-8.12.11-4.24.1.legacy (similarly in > FC1's), we elected to revert the alternatives behavior to what it had > been in sendmail-8.12.8. The various scenarios might be, then: > c) User is using 8.12.8, upgraded to 8.12.11-4.24.1. Same problems as > (b). User either fixes this by hand (by making a symlink /etc/pam.d/ > smtp -> smtp.sendmail &c) or fixes this using the "alternatives > --config mta" command, as suggested by Marc in > . If user does either of these two things, a > later upgrade to sendmail-8.12.11-4.24.3 will break /etc/pam.d/smtp, > causing it to point to a non-existent /etc/pam.d/smtp.sendmail, and > create /etc/pam.d/smtp.rpmnew. This one, I think, would have been your > scenario, Adam. You have provided a good workaround for this. That is precisely what I saw. Thanks. > Hope this helps explain the situation, Adam. It was a mess, and we did the > best we knew to fix it. Sorry for the trouble it has caused. > The problems were relatively minor. I was just posting the information mainly in case others experienced the same issue so they would know of a fix. I am surprised that you were able to decipher the 2 previous emails... It was very confusing even trying to explain the symlink because the symlink in question points to a symlink which points to a missing file :). Thanks for the reply. I really didn't expect a reply that explained things as well as you did. From kleskoe at hotmail.com Wed Apr 5 23:21:18 2006 From: kleskoe at hotmail.com (kles koe) Date: Wed, 05 Apr 2006 23:21:18 +0000 Subject: sendmail updates In-Reply-To: <1144257861.2980.34.camel@scooby.uniqsys.com> Message-ID: i was going to ask the same question... sort of. i installed the first sendmail fix (22.9) on a redhat 7.3 system last week without noticing any problems since. would you guys still advice me to also update to the newly updated sendmail packages(22.10) or would it be wiser not fix something that aint broke anymore or could that have consequenses for future updates. in other words, could this latest update still mess things up where they went correctly last week? >From: Kurt Bechstein >Reply-To: Discussion of the Fedora Legacy Project > >To: fedora-legacy-list at redhat.com >Subject: sendmail updates >Date: Wed, 05 Apr 2006 13:24:21 -0400 > >I have a question on the recent sendmail updates. I'm referencing two >urls here and they are: >http://fedoranews.org/cms/node/489 >http://fedoranews.org/cms/node/581 > >They both appear to refer to the same sendmail bug so I'm just curious >if the initial packages didn't fully fix the problem or if there is >something else that I'm missing here since the detail info on each url >is identical. > > >-- >Kurt Bechstein > >-- >fedora-legacy-list mailing list >fedora-legacy-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-legacy-list _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From marcdeslauriers at videotron.ca Wed Apr 5 23:35:41 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 05 Apr 2006 19:35:41 -0400 Subject: [Updated] [FLSA-2006:186277] Updated sendmail packages fix security issue In-Reply-To: <4433F545.8030301@ptm.com> References: <44331426.9000300@videotron.ca> <4433F545.8030301@ptm.com> Message-ID: <1144280141.22175.19.camel@mdlinux> On Wed, 2006-04-05 at 12:50 -0400, Adam Gibson wrote: > One thing I noticed after the latest yum update of sendmail from the > previous update is that alternatives is broken for /etc/pam.d/smtp for > the sendmail package. Sendmail used to create /etc/pam.d/smtp.sendmail > which alternatives would create a symlink at /etc/pam.d/smtp to > eventually point to the current configured smtp pam config > (/etc/pam.d/smtp.sendmail for sendmail). > Sendmail on rh73, rh9 and fc1 didn't use alternatives for /etc/pam.d/smtp. It was a real file. That was the problem with the first sendmail update we came out with, it used alternatives for that file and the proper symlink wouldn't get automatically created. In the latest update, we reverted to the previous functionality of having the package create a real /etc/pam.d/smtp file. 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 tseaver at palladion.com Wed Apr 5 23:33:42 2006 From: tseaver at palladion.com (Tres Seaver) Date: Wed, 05 Apr 2006 19:33:42 -0400 Subject: 1-2-3 out, time for FC2? In-Reply-To: <200604051623.30549.jkeating@redhat.com> References: <29fb01c65855$e0314e70$0201a8c0@p3000> <200604051623.30549.jkeating@redhat.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: > On Tuesday 04 April 2006 22:07, NARS wrote: > >>If fedoralegacy supported FC1 for so long why to take fc2 out now? Try to >>do a search on dedicated servers providers, you will find most of them >>still provide FC2, and for eg. Plesk supports FC3 only on latest versions >>(officially)... another example, look at this poll at ART's site: >>http://www.atomicrocketturtle.com/modules.php?op=modload&name=NS-Polls&file >>=index&req=results&pollID=6&mode=thread&order=0&thold=0 >> >>I think FC2 is still used by many people, I would suggest you consider >>supporting FC2 for some more time if possible. > > > Honestly, I feel that supporting FC1 for so long was a mistake. It set a > precedence that I really don't want to continue. Legacy picked a timeline > that fit well with what Fedora produces, and what RHEL (and rebuilds) offer. > Going further than that is really beyond the scope of the Fedora Project as a > whole. Falling back into our 1-2-3 and out set schedule will be the best > thing, and to get to that point we need to drop FC1 and FC2, to make room for > FC3. We need to concentrate on doing better for the releases we do support, > and adding to the workload is not the way to do this. Fedora is great, and > the lifespan we can give it is a good, but if you need more, you should > probably be looking at RHEL or one of its rebuilds. I don't know that you had any alternative: AFAICT, the active maintainers *all* care about older releases (RH73., RH9, FC1); I haven't seen a package QA'ed for FC2 before those since it rolled to Legacy. Dropping the releases which get actual love may feel cleaner, but I don't think you are going to get the folks who have been maintaining those older releases to switch to a newer FC: they will, as you point out, more likely switch away from Fedora altogether. Perhaps there are a group of volunteers who care about more recent FC releases, and who can take up the load. Best, 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 iD8DBQFENFPW+gerLs4ltQ4RAppSAJ4rPLER4mHRLDDLWnmqgzEIIjIwaACgocF0 TeOzPYSiUUuW/EqmRkSk4zs= =hLgg -----END PGP SIGNATURE----- From alan at datdec.com Thu Apr 6 01:23:52 2006 From: alan at datdec.com (Alan Johnson) Date: Wed, 05 Apr 2006 21:23:52 -0400 Subject: sendmail updates In-Reply-To: <44342F91.2020704@wp.pl> References: <1144257861.2980.34.camel@scooby.uniqsys.com> <443406EA.7050606@speed.net> <4434174F.6060007@wp.pl> <20060405143225.p8ni6hy7yfk84c44@mail.ph.utexas.edu> <44342F91.2020704@wp.pl> Message-ID: <44346DA8.80001@datdec.com> I can confirm most of this info on my RH 9 and 7.3 systems as well. For me, it was just user auth that appeared to be broken by this last package. The secure cert setup that was part of the last bad-package-fix-effort didn't show any direct errors, relaying from localhost worked fine, receiving worked fine, etc. See additional comments in-line and after below... (I apologize in advance if I am barfing obvious and useless info as most of what I know about sendmail I learned from these broken packages) _______________ Alan Johnson alan at datdec.com Jancio Wodnik wrote: > It's me again. > > I have got latest sendmail's update on my rh73 and rh9 boxes. > > Issues are still the same: after update there is lack of those files: > > 1) there is no more /etc/pam.d/smtp.sendmail -> but thereis > /etc/pam.d/smtp.rpmnew Also, for me, in /etc/pam.d/, was a symlink from smtp -> /etc/alternatives/mta-pam but that file did not exists. As soon as I did a I did a `cp smtp.rpmnew smtp` to fix the link (total guess), the broken auth started working again and smtp.sendmail appeared. No service restart needed. Now, prior to that I had guessed at a remake of the sendmail.cf file from my own sendmail.mc, and the alternatives command mentioned in a previous thread regarding the last bad-package, but I don't think they had anything to do with it. I don't think that because the /only/ thing I did on 2 other RH 9 boxes and one 7.3 box was the `cp smtp.rpmnew smtp` and auth started working again. > 2) there is no more /usr/lib/sendmail.sendmail > I also do not have this file, but I do have a symlink in that dir from sendmail -> ../sbin/sendmail and in ../sbin (/usr/sbin) there is a sendmail.sendmail and another symlink from sendmail -> /etc/alternatives/mta. > In /etc/alternatives were broken links: mta-pam, mta-sendmail, > mta-sendmailman > mta-pam is not broken for me, but since mta-pam -> /etc/pam.d/smtp.sendmail, and /etc/pam.d/smtp -> /etc/alternatives/mta-pam -> /etc/pam.d/smtp.sendmail, so when I did that `cp smtp.rpmnew smtp`, that would explain why the link is fixed and why smtp.sendmail appeared in /etc/pam.d as soon as I did the cp. The other two are also still broken, but they don't seem to impact operations of sendmail in anyway I have noticed yet: mta-sendmail -> /usr/lib/sendmail.sendmail mta-sendmailman -> /usr/share/man/man8/sendmail.sendmail.8.gz > My sendmail rejects incoming mail form LAN, so i must by hand fix above > broken symlinks, after that and sendmail reload all goes fine. > As I already mentioned, I did not have to restart anything for auth to start working again, and nothing else seems to be broken. > So there are still problems with the latest update, when we spoke about: > problems with alternatives and sendmail. In my opinion: the latest > update didn't fix that. That's all. > Agreed, while the efforts are certainly greatly appreciated, nonetheless. > best reg ... > > Irens > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > From rostetter at mail.utexas.edu Thu Apr 6 01:27:49 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 5 Apr 2006 20:27:49 -0500 Subject: 1-2-3 out, time for FC2? In-Reply-To: <443427AC.5050502@sbcglobal.net> References: <29fb01c65855$e0314e70$0201a8c0@p3000> <200604051310.33692.guallar@easternrad.com> <443427AC.5050502@sbcglobal.net> Message-ID: <20060405202749.8jgv4leejnk08o0w@mail.ph.utexas.edu> Quoting Mike McCarty : > I have volunteered some time for test if I will assume you mean the second part of QA, the "verify" step. > (1) The changes can be "contained" so that they do not compromise > my machine if they fail. IOW, there is a guaranteed backout > which loses no information. Easiest way to do that is just to run it in a virtual machine. The only other guaranteed way is to backup your system before hand, and restore it afterwards, with the needed downtime for that, or to have a second machine you don't care so much about to test on. > (2) I have the space on my disc (which is admittedly rather low). That isn't a problem if you are already running the package, as it shouldn't increase disk usage much if it all; it is replacing programs so the space usage is more-or-less the same. > So far, (1) has been a sticking point, I think. This is a fact of life, and nothing specific to the FL Project. And it applies to released packages (ala the recent sendmail debacle) as well as test packages. In other words, there is little that FL can do to help you meet those two constraints. Even if we offered a virtual machine test environment, your lack of disk space would probably prohibit its use. Now, here is the real kicker: You can do the first step of QA (publish votes rather than verify votes) on ANY system and without compromising the system at all. It only involves comparing the files to other known files, etc. You don't have to install anything on the system. So, you can help, within your constraints, if you choose, by doing the first QA step rather than the second. > Mike -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From rostetter at mail.utexas.edu Thu Apr 6 02:05:48 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 5 Apr 2006 21:05:48 -0500 Subject: sendmail updates In-Reply-To: <44342F91.2020704@wp.pl> References: <1144257861.2980.34.camel@scooby.uniqsys.com> <443406EA.7050606@speed.net> <4434174F.6060007@wp.pl> <20060405143225.p8ni6hy7yfk84c44@mail.ph.utexas.edu> <44342F91.2020704@wp.pl> Message-ID: <20060405210548.yq2f0lqrfjdcccks@mail.ph.utexas.edu> Quoting Jancio Wodnik : > I have got latest sendmail's update on my rh73 and rh9 boxes. > > Issues are still the same: after update there is lack of those files: After update from which version? Were any manual changes made those files on the machine before the latest install? Did you install or upgrade the package? > 1) there is no more /etc/pam.d/smtp.sendmail -> but thereis > /etc/pam.d/smtp.rpmnew > 2) there is no more /usr/lib/sendmail.sendmail See the excellent post by David E. and see which category you fit in, and whether or not his explainations there explain your problems or not. > In /etc/alternatives were broken links: mta-pam, mta-sendmail, > mta-sendmailman I can confirm if you did both updates in order you have broken links on RH9, but interesting my broken links are different from what you report. > My sendmail rejects incoming mail form LAN, so i must by hand fix above > broken symlinks, after that and sendmail reload all goes fine. If you remove sendmail and reinstall the latest package (you should certainly backup /etc/mail before doing this) does it resolve all the problems you see? > So there are still problems with the latest update, when we spoke > about: problems with alternatives and sendmail. In my opinion: the > latest update didn't fix that. That's all. We need more info on what you did before we can conclude that. I think the biggest problem/complaint would be that the fine details about how to apply the newest package based on previous updates was missing. It should have made mention of what would happen in the 4 different cases. > best reg ... > > Irens -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From jkosin at beta.intcomgrp.com Thu Apr 6 12:45:48 2006 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Thu, 06 Apr 2006 08:45:48 -0400 Subject: 1-2-3 out, time for FC2? In-Reply-To: References: <29fb01c65855$e0314e70$0201a8c0@p3000> <200604051623.30549.jkeating@redhat.com> Message-ID: <44350D7C.7030505@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tres Seaver wrote: > Jesse Keating wrote: >>> On Tuesday 04 April 2006 22:07, NARS wrote: >>> >>>> If fedoralegacy supported FC1 for so long why to take fc2 out >>>> > now? Try to >>>> do a search on dedicated servers providers, you will find >>>> most > of them >>>> still provide FC2, and for eg. Plesk supports FC3 only on >>>> latest > versions >>>> (officially)... another example, look at this poll at ART's >>>> site: >>>> > http://www.atomicrocketturtle.com/modules.php?op=modload&name=NS-Polls&file > >>>> =index&req=results&pollID=6&mode=thread&order=0&thold=0 >>>> >>>> I think FC2 is still used by many people, I would suggest you >>>> > consider >>>> supporting FC2 for some more time if possible. >>> >>> Honestly, I feel that supporting FC1 for so long was a mistake. >>> > It set a >>> precedence that I really don't want to continue. Legacy picked >>> a > timeline >>> that fit well with what Fedora produces, and what RHEL (and > rebuilds) offer. >>> Going further than that is really beyond the scope of the >>> Fedora > Project as a >>> whole. Falling back into our 1-2-3 and out set schedule will >>> be > the best >>> thing, and to get to that point we need to drop FC1 and FC2, to >>> > make room for >>> FC3. We need to concentrate on doing better for the releases >>> we > do support, >>> and adding to the workload is not the way to do this. Fedora >>> is > great, and >>> the lifespan we can give it is a good, but if you need more, >>> you > should >>> probably be looking at RHEL or one of its rebuilds. > > I don't know that you had any alternative: AFAICT, the active > maintainers *all* care about older releases (RH73., RH9, FC1); I > haven't seen a package QA'ed for FC2 before those since it rolled > to Legacy. > > Dropping the releases which get actual love may feel cleaner, but > I don't think you are going to get the folks who have been > maintaining those older releases to switch to a newer FC: they > will, as you point out, more likely switch away from Fedora > altogether. Perhaps there are a group of volunteers who care about > more recent FC releases, and who can take up the load. > > Best, > > > Tres. Tres, I think that may be a better compromise. We just need to break it up into whoever is willing to support each release and for how long and not worry about scrapping each release before it is time. It will go like RH8 did with support for 7.3 sticking around.... mostly, due to the support of the community. James Kosin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFENQ18kNLDmnu1kSkRArDtAJ9uiLmaRZQ/koRdsC00PWp1ZDNEHwCfWReV 6BRVwA63LtpKZyuCjMkh74g= =ioVN -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From jkosin at beta.intcomgrp.com Thu Apr 6 12:45:48 2006 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Thu, 06 Apr 2006 08:45:48 -0400 Subject: 1-2-3 out, time for FC2? In-Reply-To: References: <29fb01c65855$e0314e70$0201a8c0@p3000> <200604051623.30549.jkeating@redhat.com> Message-ID: <44350D7C.7030505@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tres Seaver wrote: > Jesse Keating wrote: >>> On Tuesday 04 April 2006 22:07, NARS wrote: >>> >>>> If fedoralegacy supported FC1 for so long why to take fc2 out >>>> > now? Try to >>>> do a search on dedicated servers providers, you will find >>>> most > of them >>>> still provide FC2, and for eg. Plesk supports FC3 only on >>>> latest > versions >>>> (officially)... another example, look at this poll at ART's >>>> site: >>>> > http://www.atomicrocketturtle.com/modules.php?op=modload&name=NS-Polls&file > >>>> =index&req=results&pollID=6&mode=thread&order=0&thold=0 >>>> >>>> I think FC2 is still used by many people, I would suggest you >>>> > consider >>>> supporting FC2 for some more time if possible. >>> >>> Honestly, I feel that supporting FC1 for so long was a mistake. >>> > It set a >>> precedence that I really don't want to continue. Legacy picked >>> a > timeline >>> that fit well with what Fedora produces, and what RHEL (and > rebuilds) offer. >>> Going further than that is really beyond the scope of the >>> Fedora > Project as a >>> whole. Falling back into our 1-2-3 and out set schedule will >>> be > the best >>> thing, and to get to that point we need to drop FC1 and FC2, to >>> > make room for >>> FC3. We need to concentrate on doing better for the releases >>> we > do support, >>> and adding to the workload is not the way to do this. Fedora >>> is > great, and >>> the lifespan we can give it is a good, but if you need more, >>> you > should >>> probably be looking at RHEL or one of its rebuilds. > > I don't know that you had any alternative: AFAICT, the active > maintainers *all* care about older releases (RH73., RH9, FC1); I > haven't seen a package QA'ed for FC2 before those since it rolled > to Legacy. > > Dropping the releases which get actual love may feel cleaner, but > I don't think you are going to get the folks who have been > maintaining those older releases to switch to a newer FC: they > will, as you point out, more likely switch away from Fedora > altogether. Perhaps there are a group of volunteers who care about > more recent FC releases, and who can take up the load. > > Best, > > > Tres. Tres, I think that may be a better compromise. We just need to break it up into whoever is willing to support each release and for how long and not worry about scrapping each release before it is time. It will go like RH8 did with support for 7.3 sticking around.... mostly, due to the support of the community. James Kosin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFENQ18kNLDmnu1kSkRArDtAJ9uiLmaRZQ/koRdsC00PWp1ZDNEHwCfWReV 6BRVwA63LtpKZyuCjMkh74g= =ioVN -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From matt.followers at gmail.com Thu Apr 6 13:34:00 2006 From: matt.followers at gmail.com (Matt Nuzum) Date: Thu, 6 Apr 2006 08:34:00 -0500 Subject: 1-2-3 out, time for FC2? In-Reply-To: <200604051623.30549.jkeating@redhat.com> References: <29fb01c65855$e0314e70$0201a8c0@p3000> <200604051623.30549.jkeating@redhat.com> Message-ID: <27c475ec0604060634p58e1c927l1ae937d347abbead@mail.gmail.com> On 4/5/06, Jesse Keating wrote: > On Tuesday 04 April 2006 22:07, NARS wrote: > > If fedoralegacy supported FC1 for so long why to take fc2 out now? Try to > > do a search on dedicated servers providers, you will find most of them > > still provide FC2, and for eg. Plesk supports FC3 only on latest versions > > (officially)... another example, look at this poll at ART's site: > > http://www.atomicrocketturtle.com/modules.php?op=modload&name=NS-Polls&file > >=index&req=results&pollID=6&mode=thread&order=0&thold=0 > > > > I think FC2 is still used by many people, I would suggest you consider > > supporting FC2 for some more time if possible. > > Honestly, I feel that supporting FC1 for so long was a mistake. It set a > precedence that I really don't want to continue. Legacy picked a timeline > that fit well with what Fedora produces, and what RHEL (and rebuilds) offer. > Going further than that is really beyond the scope of the Fedora Project as a > whole. Falling back into our 1-2-3 and out set schedule will be the best > thing, and to get to that point we need to drop FC1 and FC2, to make room for > FC3. We need to concentrate on doing better for the releases we do support, > and adding to the workload is not the way to do this. Fedora is great, and > the lifespan we can give it is a good, but if you need more, you should > probably be looking at RHEL or one of its rebuilds. > Jesse is 100% correct. People keep forgetting that the Fedora project is not intended for those who hate change. Fedora is for people who want to be on the cutting edge. FC2 was the first big distro to support 2.6. People swarmed to FC2 so that they could try out the latest technology. This is the way it's been with every Fedora release and really all of the RHL releases too. If you need stability for a long period of time, there are other distros out there. RHEL is an excellent migration path. If your enterprise software has standardized on a particular version of FC, they should be drawn and quartered because they obviously have no clue what Fedora is about. Are you still on FC2? Upgrade! The path from FC2 to FC3 is a piece of cake, and really, why stop there? Go on to 4 or 5. Using an older version? I've migrated RHL 7,8,9 & FC1 (aka RHL9.1) to Ubuntu very successfully (it has Apache 1.3 and other mature products readily available in Universe). By the way, it is not the job of FL (with the exception of Jesse maybe) to make people happy with RH. They flat out said that they have divided their products so that they can appease those who want the newest technology (FC) and at the same time, those who want stability (RHEL). If you don't like the fact that FC is for people who like to upgrade *every 9 months* then you should find another solution. -- Matthew Nuzum www.followers.net - Makers of "Elite Content Management System" View samples of Elite CMS in action by visiting http://www.followers.net/portfolio/ From rostetter at mail.utexas.edu Thu Apr 6 15:36:20 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 6 Apr 2006 10:36:20 -0500 Subject: 1-2-3 out, time for FC2? In-Reply-To: <44350D7C.7030505@beta.intcomgrp.com> References: <29fb01c65855$e0314e70$0201a8c0@p3000> <200604051623.30549.jkeating@redhat.com> <44350D7C.7030505@beta.intcomgrp.com> Message-ID: <20060406103620.mk7thr1ajc0gkokw@mail.ph.utexas.edu> Quoting James Kosin : > I think that may be a better compromise. We just need to break it up > into whoever is willing to support each release and for how long and > not worry about scrapping each release before it is time. Problem is I am willing to support Fedora Core 3 64 bit, but I've been unable to. I don't have the time to track the bugs and do publish votes right now (maybe I will later). And by the time I install the updates-testing stuff (which I do on a regular basis), test it for a day or so, write up a report, the damn things already been released! So my testing is useless as I can't get it done before the package is released... So, it may look like no one has any interest in FC3, but in reality I do. If the release was say 6 days instead of 4, I could actually test the stuff. I'm not in a position where I can stop my life to test the updates-testing stuff just because we want a 4 day release period. > It will go like RH8 did with support for 7.3 sticking around.... > mostly, due to the support of the community. Yes, if we don't do a strict 1-2-3-out, then this is the way to go; keep what people support, dump what they won't support. > James Kosin -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From jancio_wodnik at wp.pl Thu Apr 6 20:09:20 2006 From: jancio_wodnik at wp.pl (Jancio Wodnik) Date: Thu, 06 Apr 2006 22:09:20 +0200 Subject: sendmail updates In-Reply-To: <20060405210548.yq2f0lqrfjdcccks@mail.ph.utexas.edu> References: <1144257861.2980.34.camel@scooby.uniqsys.com> <443406EA.7050606@speed.net> <4434174F.6060007@wp.pl> <20060405143225.p8ni6hy7yfk84c44@mail.ph.utexas.edu> <44342F91.2020704@wp.pl> <20060405210548.yq2f0lqrfjdcccks@mail.ph.utexas.edu> Message-ID: <44357570.2040502@wp.pl> Eric Rostetter napisa?(a): > Quoting Jancio Wodnik : > >> I have got latest sendmail's update on my rh73 and rh9 boxes. >> >> Issues are still the same: after update there is lack of those files: > > After update from which version? Were any manual changes made those files > on the machine before the latest install? Did you install or upgrade > the package? When i remember, there was an update of sendmail in march, wait, i will grep that for you: 25 of march my system was update with sendmail-8.12.11-4.22.9.legacy and then was problem with AUTH - mail from local lan were rejected, so i greep mailing list, irc and i made: alternatives --configure mta so (when i can well remember) this command rebuild all broken symlink, in /etc/pam.d too. After that, there cam another update of sendmail, sendmail-8.12.11-4.22.10.legacy which broke again AUTH, i fix that by making necessery symbolic links by hand, i make that quickly, alternatives --config mail didn't make necessry symlinks (wired ?). > >> 1) there is no more /etc/pam.d/smtp.sendmail -> but thereis >> /etc/pam.d/smtp.rpmnew >> 2) there is no more /usr/lib/sendmail.sendmail > > See the excellent post by David E. and see which category you fit in, > and whether or not his explainations there explain your problems or > not. > Saddly, but all these boxes are production servers, so i have no time to do further investigation. >> In /etc/alternatives were broken links: mta-pam, mta-sendmail, >> mta-sendmailman > > I can confirm if you did both updates in order you have broken links > on RH9, but interesting my broken links are different from what you > report. > >> My sendmail rejects incoming mail form LAN, so i must by hand fix above >> broken symlinks, after that and sendmail reload all goes fine. > > If you remove sendmail and reinstall the latest package (you should > certainly > backup /etc/mail before doing this) does it resolve all the problems you > see? Sory, but i can't experiment for that, it is production box and we are planning to move to CentOS. > >> So there are still problems with the latest update, when we spoke >> about: problems with alternatives and sendmail. In my opinion: the >> latest update didn't fix that. That's all. > > We need more info on what you did before we can conclude that. > > I think the biggest problem/complaint would be that the fine details > about > how to apply the newest package based on previous updates was missing. > It should have made mention of what would happen in the 4 different > cases. Yes i saw that. How to apply ? By yum night updates ! I'm tired, so i close this case for me and will not do further investigation. Sorry. See ya. > >> best reg ... >> >> Irens > > --Eric Rostetter > The Department of Physics > The University of Texas at Austin > > Go Longhorns! > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > > From jancio_wodnik at wp.pl Thu Apr 6 20:20:14 2006 From: jancio_wodnik at wp.pl (Jancio Wodnik) Date: Thu, 06 Apr 2006 22:20:14 +0200 Subject: sendmail updates In-Reply-To: <20060405210548.yq2f0lqrfjdcccks@mail.ph.utexas.edu> References: <1144257861.2980.34.camel@scooby.uniqsys.com> <443406EA.7050606@speed.net> <4434174F.6060007@wp.pl> <20060405143225.p8ni6hy7yfk84c44@mail.ph.utexas.edu> <44342F91.2020704@wp.pl> <20060405210548.yq2f0lqrfjdcccks@mail.ph.utexas.edu> Message-ID: <443577FE.1040807@wp.pl> Eric Rostetter napisa?(a): > Quoting Jancio Wodnik : > >> I have got latest sendmail's update on my rh73 and rh9 boxes. >> >> Issues are still the same: after update there is lack of those files: > > After update from which version? Were any manual changes made those files > on the machine before the latest install? Did you install or upgrade > the package? > >> 1) there is no more /etc/pam.d/smtp.sendmail -> but thereis >> /etc/pam.d/smtp.rpmnew >> 2) there is no more /usr/lib/sendmail.sendmail > > See the excellent post by David E. and see which category you fit in, > and whether or not his explainations there explain your problems or > not. I checked it's (c) scenario. > >> In /etc/alternatives were broken links: mta-pam, mta-sendmail, >> mta-sendmailman > > I can confirm if you did both updates in order you have broken links > on RH9, but interesting my broken links are different from what you > report. > >> My sendmail rejects incoming mail form LAN, so i must by hand fix above >> broken symlinks, after that and sendmail reload all goes fine. > > If you remove sendmail and reinstall the latest package (you should > certainly > backup /etc/mail before doing this) does it resolve all the problems you > see? > >> So there are still problems with the latest update, when we spoke >> about: problems with alternatives and sendmail. In my opinion: the >> latest update didn't fix that. That's all. > > We need more info on what you did before we can conclude that. > > I think the biggest problem/complaint would be that the fine details > about > how to apply the newest package based on previous updates was missing. > It should have made mention of what would happen in the 4 different > cases. > >> best reg ... >> >> Irens > > --Eric Rostetter > The Department of Physics > The University of Texas at Austin > > Go Longhorns! > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > > From rostetter at mail.utexas.edu Thu Apr 6 21:00:10 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 6 Apr 2006 16:00:10 -0500 Subject: sendmail updates In-Reply-To: <44357570.2040502@wp.pl> References: <1144257861.2980.34.camel@scooby.uniqsys.com> <443406EA.7050606@speed.net> <4434174F.6060007@wp.pl> <20060405143225.p8ni6hy7yfk84c44@mail.ph.utexas.edu> <44342F91.2020704@wp.pl> <20060405210548.yq2f0lqrfjdcccks@mail.ph.utexas.edu> <44357570.2040502@wp.pl> Message-ID: <20060406160010.hbe2c29jz38k40cs@mail.ph.utexas.edu> Quoting Jancio Wodnik : > When i remember, there was an update of sendmail in march, wait, i will > grep that for you: > > 25 of march my system was update with sendmail-8.12.11-4.22.9.legacy > and then was problem with AUTH - mail from local lan were rejected, so > i greep mailing list, irc and i made: alternatives --configure mta so > (when i can well remember) this command rebuild all broken symlink, in > /etc/pam.d too. > > After that, there cam another update of sendmail, > sendmail-8.12.11-4.22.10.legacy which broke again AUTH, i fix that by > making necessery symbolic links by hand, i make that quickly, > alternatives --config mail didn't make necessry symlinks (wired ?). Yeah, I think that all is "expected behaviour" for that upgrade path. Unfortunately such was not stated in the update release, and wasn't stated on the mailing list until later (in response to your mail). > Saddly, but all these boxes are production servers, so i have no time > to do further investigation. Understood. > Sory, but i can't experiment for that, it is production box and we are > planning to move to CentOS. Yes, if it is working, there is no reason to do anything. > How to apply ? By yum night updates ! I would never (personally) apply automatic updates to a production server... See http://www.fedoraproject.org/wiki/AutoUpdates for full details... > I'm tired, so i close this case for me and will not do further > investigation. Sorry. No problem. I think the long post by David E. about the 4 upgrade paths and what happens in each path documents the path well enough for now. And since any new updates will probably skip the intermediate package, this shouldn't be a problem for anyone in the future (I hope). -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From gene.heskett at verizon.net Thu Apr 6 23:58:09 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Thu, 06 Apr 2006 19:58:09 -0400 Subject: 1-2-3 out, time for FC2? In-Reply-To: <44350D7C.7030505@beta.intcomgrp.com> References: <29fb01c65855$e0314e70$0201a8c0@p3000> <44350D7C.7030505@beta.intcomgrp.com> Message-ID: <200604061958.09383.gene.heskett@verizon.net> On Thursday 06 April 2006 08:45, James Kosin wrote: [...] >Tres, > >I think that may be a better compromise. We just need to break it up >into whoever is willing to support each release and for how long and >not worry about scrapping each release before it is time. > >It will go like RH8 did with support for 7.3 sticking around.... >mostly, due to the support of the community. > >James Kosin > I'll stand up and wave my hand to confirm that its a good idea. >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.2 (MingW32) >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >iD8DBQFENQ18kNLDmnu1kSkRArDtAJ9uiLmaRZQ/koRdsC00PWp1ZDNEHwCfWReV >6BRVwA63LtpKZyuCjMkh74g= >=ioVN >-----END PGP SIGNATURE----- > >-- >Scanned by ClamAV - http://www.clamav.net -- 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 zoubidoo at hotmail.com Thu Apr 6 23:55:19 2006 From: zoubidoo at hotmail.com (Parker Jones) Date: Fri, 07 Apr 2006 11:55:19 +1200 Subject: sendmail update left me in a fix Message-ID: The 5th April sendmail update screwed up mail on my RH-7.3 box. In /var/log/maillog I'm getting lots of these: Apr 7 01:28:17 stancomb sendmail[6702]: k36NSHhs006702: localhost [127.0.0.1] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA Not knowing anything about sendmail configuration this has left me in a fix. Out of urgency I reverted sendmail.cf to a version prior to the update and it now seems to work ok. A diff between the old and new sendmail.cf's shows several pages of changes which I can't even begin to understand. I am not sure of the implications of using the old sendmail.cf... I appreciate the effort you guys put into packaging this code, but it's a royal pain when new problems like this are introduced. Sendmail update history: [root at stancomb etc]# grep sendmail /var/log/yum.log* /var/log/yum.log:04/05/06 05:59:52 Updated: sendmail-cf.i386 /var/log/yum.log:04/05/06 05:59:52 Updated: sendmail.i386 /var/log/yum.log:04/05/06 05:59:52 Updated: sendmail-devel.i386 /var/log/yum.log:04/05/06 05:59:52 Updated: sendmail-doc.i386 /var/log/yum.log.2:03/24/06 05:58:34 Updated: sendmail-cf.i386 /var/log/yum.log.2:03/24/06 05:58:34 Updated: sendmail.i386 /var/log/yum.log.2:03/24/06 05:58:34 Updated: sendmail-devel.i386 /var/log/yum.log.2:03/24/06 05:58:34 Updated: sendmail-doc.i386 _________________________________________________________________ Read the latest Hollywood gossip @ http://xtramsn.co.nz/entertainment From A.E.Lawrence at lboro.ac.uk Fri Apr 7 12:36:07 2006 From: A.E.Lawrence at lboro.ac.uk (A.E.Lawrence) Date: Fri, 07 Apr 2006 13:36:07 +0100 Subject: Fedora Legacy Update : kdelibs dependency problems In-Reply-To: <4421FBCD.9070302@gtw.net> References: <44219D4B.9090408@lboro.ac.uk> <4421FBCD.9070302@gtw.net> Message-ID: <44365CB7.3060109@lboro.ac.uk> David Eisenstein wrote: > 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? Thanks to every one for the replies. Unfortunately, the Maxtor hard disc on the machine failed, and I have rebuilt the machine with a current distribution, so the legacy issue is no longer relevant. ael -- Dr A E Lawrence http://www.lboro.ac.uk/departments/co/people/acad_staff/lawrence.html http://www-staff.lboro.ac.uk/~coael/ From rostetter at mail.utexas.edu Fri Apr 7 17:47:41 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 7 Apr 2006 12:47:41 -0500 Subject: sendmail update left me in a fix In-Reply-To: References: Message-ID: <20060407124741.sfw30e519ao0wcc0@mail.ph.utexas.edu> Quoting Parker Jones : > The 5th April sendmail update screwed up mail on my RH-7.3 box. How so? It is probably due to your having installed the earlier update actually, and not due to the current update. But in any case, if something is broken it is broken. But you never do say what it is that is broken. > In /var/log/maillog I'm getting lots of these: > Apr 7 01:28:17 stancomb sendmail[6702]: k36NSHhs006702: localhost > [127.0.0.1] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA That message doesn't mean much of anything by itself. In fact, I see lots of these in normal operation. Now, something is no doubt causing them, but we can't tell what without more information from you. > Not knowing anything about sendmail configuration this has left me in a fix. Sounds like you already got yourself out of the fix actually. But then, you never really told us what was broken. > Out of urgency I reverted sendmail.cf to a version prior to the update > and it now seems to work ok. That should be fine and should not cause any problems. > A diff between the old and new > sendmail.cf's shows several pages of changes which I can't even begin > to understand. I am not sure of the implications of using the old > sendmail.cf... It should work fine with the old sendmail.cf. But you should check the status of sendmail.mc also, to prevent problems in the future in case it rebuilds sendmail.cf from sendmail.mc. > I appreciate the effort you guys put into packaging this code, but it's > a royal pain when new problems like this are introduced. Yes. But if you want any help, you need to provide much more information, like at least what the problems where, and whether we should even bother to try to help as it sounds like you already fixed all the problems? -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From zoubidoo at hotmail.com Mon Apr 10 01:45:01 2006 From: zoubidoo at hotmail.com (Parker Jones) Date: Mon, 10 Apr 2006 13:45:01 +1200 Subject: sendmail update left me in a fix In-Reply-To: <20060407124741.sfw30e519ao0wcc0@mail.ph.utexas.edu> Message-ID: >>The 5th April sendmail update screwed up mail on my RH-7.3 box. > >How so? Problem: Sending mail failed after the update. I send locally using nmh. Restarting sendmail didn't help. Receiving appeared to be unaffected. Quick fix: After waiting several days hoping the problem would just go away, I had to do something about it. I appear to have made the problem go away by replacing sendmail.cf with its old version (prior to the sendmail update) and restarting sendmail. Looking for an explanation: I tried to reproduce the problem by restoring the sendmail.cf supplied with the update and restarting sendmail. Surprisingly I could still send - I expected it to break. This would suggest that there is something else going on that I'm not taking into consideration (rebuilding of sendmail.mc perhaps?) So I still have no satisfactory explanation of the cause of the problem. If sendmail.mc is compiled will the problem reappear? Is the sendmail.mc replaced during the update? Should there be a backup of the old version e.g as sendmail.mc.rpmnew? I didn't find one. Why is there a sendmail.cf.rpmnew and not a sendmail.mc.rpmnew? It looks like the update caused the problem but not being able to reproduce it is frustrating. >>In /var/log/maillog I'm getting lots of these: >>Apr 7 01:28:17 stancomb sendmail[6702]: k36NSHhs006702: localhost >>[127.0.0.1] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA > >That message doesn't mean much of anything by itself. In fact, I see >lots of these in normal operation. Now, something is no doubt causing >them, but we can't tell what without more information from you. Well that's what maillog says. Perhaps you could be more specific about what further information would be useful. _________________________________________________________________ Read the latest Hollywood gossip @ http://xtramsn.co.nz/entertainment From Mike.McCarty at sbcglobal.net Mon Apr 10 04:28:04 2006 From: Mike.McCarty at sbcglobal.net (Mike McCarty) Date: Sun, 09 Apr 2006 23:28:04 -0500 Subject: 1-2-3 out, time for FC2? In-Reply-To: <20060405202749.8jgv4leejnk08o0w@mail.ph.utexas.edu> References: <29fb01c65855$e0314e70$0201a8c0@p3000> <200604051310.33692.guallar@easternrad.com> <443427AC.5050502@sbcglobal.net> <20060405202749.8jgv4leejnk08o0w@mail.ph.utexas.edu> Message-ID: <4439DED4.4020400@sbcglobal.net> Eric Rostetter wrote: > Quoting Mike McCarty : > >> I have volunteered some time for test if > > > I will assume you mean the second part of QA, the "verify" step. Well, perhaps I used the word "test" in a technical sense. In my background, test means "verification of proper operation". > >> (1) The changes can be "contained" so that they do not compromise >> my machine if they fail. IOW, there is a guaranteed backout >> which loses no information. [snip] >> So far, (1) has been a sticking point, I think. > > > This is a fact of life, and nothing specific to the FL Project. > And it applies to released packages (ala the recent sendmail > debacle) as well as test packages. > > In other words, there is little that FL can do to help you meet those > two constraints. Even if we offered a virtual machine test environment, > your lack of disk space would probably prohibit its use. Most likely. > Now, here is the real kicker: > > You can do the first step of QA (publish votes rather than verify votes) > on ANY system and without compromising the system at all. It only involves > comparing the files to other known files, etc. You don't have to install > anything on the system. So, you can help, within your constraints, if > you choose, by doing the first QA step rather than the second. Ok, if you can give me more information, I'll be glad to donate some time. 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 Apr 10 04:29:59 2006 From: Mike.McCarty at sbcglobal.net (Mike McCarty) Date: Sun, 09 Apr 2006 23:29:59 -0500 Subject: 1-2-3 out, time for FC2? In-Reply-To: References: <29fb01c65855$e0314e70$0201a8c0@p3000> <200604051623.30549.jkeating@redhat.com> Message-ID: <4439DF47.1000804@sbcglobal.net> Tres Seaver wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jesse Keating wrote: > [snip] >>Honestly, I feel that supporting FC1 for so long was a mistake. It set a >>precedence that I really don't want to continue. Legacy picked a timeline [snip] > Dropping the releases which get actual love may feel cleaner, but I > don't think you are going to get the folks who have been maintaining > those older releases to switch to a newer FC: they will, as you point > out, more likely switch away from Fedora altogether. Perhaps there are > a group of volunteers who care about more recent FC releases, and who > can take up the load. If things get to the point where I feel I *must* replace my load, I'm switching to Debian. 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 hjp+fedora-legacy at wsr.ac.at Mon Apr 10 08:25:58 2006 From: hjp+fedora-legacy at wsr.ac.at (Peter J. Holzer) Date: Mon, 10 Apr 2006 10:25:58 +0200 Subject: sendmail update left me in a fix In-Reply-To: References: <20060407124741.sfw30e519ao0wcc0@mail.ph.utexas.edu> Message-ID: <20060410082558.GA10540@wsr.ac.at> On 2006-04-10 13:45:01 +1200, Parker Jones wrote: > Is the sendmail.mc replaced during the update? Should there be a backup of the > old version e.g as sendmail.mc.rpmnew? I didn't find one. Why is there a > sendmail.cf.rpmnew and not a sendmail.mc.rpmnew? Configuration files are silently replaced during an upgrade if they haven't been changed locally. If they have been changed, they are left alone and the new config file from the package is stored with a .rpmnew suffix[0]. So, if you have a sendmail.cf.rpmnew, but no sendmail.mc.rpmnew, it is most probably the case that you changed the sendmail.cf, but not the sendmail.mc. Maybe you just rebuilt the .cf file at one time (it contains a a line which looks like a timestamp, so it would appear to be changed even if the "real" content was the same). hp [0] Or sometimes, they are replaced and your file is renamed to .rpmsave. I still haven't figured out when that happens. -- _ | 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 bdm at fenrir.org.uk Mon Apr 10 08:38:18 2006 From: bdm at fenrir.org.uk (Brian Morrison) Date: Mon, 10 Apr 2006 09:38:18 +0100 Subject: sendmail update left me in a fix In-Reply-To: <20060410082558.GA10540@wsr.ac.at> References: <20060407124741.sfw30e519ao0wcc0@mail.ph.utexas.edu> <20060410082558.GA10540@wsr.ac.at> Message-ID: <443A197A.5000007@fenrir.org.uk> Peter J. Holzer wrote: > > [0] Or sometimes, they are replaced and your file is renamed to > .rpmsave. I still haven't figured out when that happens. That's when the config file has essential changes for the updated package to work at all, and hence must be installed. The rpmsave file is there as a hint that you need to merge your previous changes with the new format. -- Brian Morrison bdm at fenrir.org.uk From hjp+fedora-legacy at wsr.ac.at Mon Apr 10 09:06:58 2006 From: hjp+fedora-legacy at wsr.ac.at (Peter J. Holzer) Date: Mon, 10 Apr 2006 11:06:58 +0200 Subject: sendmail update left me in a fix In-Reply-To: <443A197A.5000007@fenrir.org.uk> References: <20060407124741.sfw30e519ao0wcc0@mail.ph.utexas.edu> <20060410082558.GA10540@wsr.ac.at> <443A197A.5000007@fenrir.org.uk> Message-ID: <20060410090658.GC10540@wsr.ac.at> On 2006-04-10 09:38:18 +0100, Brian Morrison wrote: > Peter J. Holzer wrote: > > [0] Or sometimes, they are replaced and your file is renamed to > > .rpmsave. I still haven't figured out when that happens. > > That's when the config file has essential changes for the updated > package to work at all, and hence must be installed. The rpmsave file is > there as a hint that you need to merge your previous changes with the > new format. How does RPM decide whether the changes are "essential"? Is there a flag in the SPEC file? 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: 384 bytes Desc: not available URL: From deisenst at gtw.net Mon Apr 10 09:42:43 2006 From: deisenst at gtw.net (David Eisenstein) Date: Mon, 10 Apr 2006 04:42:43 -0500 Subject: sendmail update left me in a fix In-Reply-To: References: Message-ID: <443A2893.2090401@gtw.net> Parker Jones wrote: >>> The 5th April sendmail update screwed up mail on my RH-7.3 box. > > Problem: Sending mail failed after the update. I send locally using > nmh. Restarting sendmail didn't help. Receiving appeared to be unaffected. > > Quick fix: After waiting several days hoping the problem would just go > away, I had to do something about it. I appear to have made the problem > go away by replacing sendmail.cf with its old version (prior to the > sendmail update) and restarting sendmail. Hi Parker, Can you send a copy of your old /etc/sendmail.cf (that worked) and the new one (that didn't work, initially)? And a copy of your old /etc/mail/sendmail.mc and a copy of the new one (if there are two or more versions)? You said, "I appear to have made the problem go away by replacing sendmail.cf with its old version (prior to the sendmail update) and restarting sendmail." Prior to which sendmail update, do you know? > Looking for an explanation: I tried to reproduce the problem by > restoring the sendmail.cf supplied with the update and restarting > sendmail. Surprisingly I could still send - I expected it to break. > This would suggest that there is something else going on that I'm not > taking into consideration (rebuilding of sendmail.mc perhaps?) I would have expected it to break too, since it was your replacing the new sendmail.cf with the old one (and restarting sendmail?) that seemed to fix the problem for you initially. > So I still have no satisfactory explanation of the cause of the problem. > > If sendmail.mc is compiled will the problem reappear? Don't know. You can try it. Depends on the contents of sendmail.mc. Did you make any changes to either sendmail.mc or sendmail.cf on your system before the updates started coming out at all? (That is, when sendmail was still running as sendmail-8.11.6, before March 24th?) > Is the sendmail.mc replaced during the update? It can be, but should not be if you made any customizations to it. In the case of sendmail.mc, when the RPM upgrade process finds /etc/mail/sendmail.mc in the new rpm binary package that might replace one currently on your system, it first checks the one already installed to see if any (manual) changes have been made to it since it was initially installed. If manual changes were made (say, by you going in and tweaking it), then the upgrade process installs the new packaged file as "sendmail.mc.rpmnew" and leaves the already-installed one alone. If no changes were made, it replaces it with the new one. It does the same checks for /etc/sendmail.cf as well. It would have only replaced /etc/sendmail.cf if you had never touched it. At least, that's how it is *supposed* to work. > Should there be a backup > of the old version e.g as sendmail.mc.rpmnew? I didn't find one. Why > is there a sendmail.cf.rpmnew and not a sendmail.mc.rpmnew? Okay. It sounds like sendmail.mc was never changed since the install of the old sendmail-8.11.6. However, it sounds like sendmail.cf *was* fiddled with, somewhere, somehow... You can help us verify that by sharing what sendmail.cf.* files you have. > It looks like the update caused the problem but not being able to > reproduce it is frustrating. I know how you feel. It always seems that your car acts up until you take it to the mechanic's shop. When you do, it always runs perfectly. As soon as it's out of sight of the mechanic, it acts up again. ;-) Hope this helped. Please do send the config files. Maybe there is something that was overlooked. Warm regards, David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From sheltren at cs.ucsb.edu Mon Apr 10 10:31:37 2006 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Mon, 10 Apr 2006 06:31:37 -0400 Subject: 1-2-3 out, time for FC2? In-Reply-To: <4439DF47.1000804@sbcglobal.net> References: <29fb01c65855$e0314e70$0201a8c0@p3000> <200604051623.30549.jkeating@redhat.com> <4439DF47.1000804@sbcglobal.net> Message-ID: <827E2526-88E2-44EF-8A76-45EAA7421B2D@cs.ucsb.edu> On Apr 10, 2006, at 12:29 AM, Mike McCarty wrote: > Tres Seaver wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> Jesse Keating wrote: > > [snip] > >>> Honestly, I feel that supporting FC1 for so long was a mistake. >>> It set a precedence that I really don't want to continue. Legacy >>> picked a timeline > > [snip] > >> Dropping the releases which get actual love may feel cleaner, but I >> don't think you are going to get the folks who have been maintaining >> those older releases to switch to a newer FC: they will, as you >> point >> out, more likely switch away from Fedora altogether. Perhaps >> there are >> a group of volunteers who care about more recent FC releases, and who >> can take up the load. > > If things get to the point where I feel I *must* replace my load, > I'm switching to Debian. > > Mike Mike, I thought you had already stopped using Legacy. If so, I'm not sure how this affects you. I'm referring to your post here: https://www.redhat.com/archives/fedora-legacy-list/2006-February/ msg00138.html -Jeff From bdm at fenrir.org.uk Mon Apr 10 10:53:04 2006 From: bdm at fenrir.org.uk (Brian Morrison) Date: Mon, 10 Apr 2006 11:53:04 +0100 Subject: sendmail update left me in a fix In-Reply-To: <20060410090658.GC10540@wsr.ac.at> References: <20060407124741.sfw30e519ao0wcc0@mail.ph.utexas.edu> <20060410082558.GA10540@wsr.ac.at> <443A197A.5000007@fenrir.org.uk> <20060410090658.GC10540@wsr.ac.at> Message-ID: <443A3910.80206@fenrir.org.uk> On 10/04/2006 Peter J. Holzer wrote: > > That's when the config file has essential changes for the updated > > package to work at all, and hence must be installed. The rpmsave > > file is there as a hint that you need to merge your previous changes with > > the new format. > > How does RPM decide whether the changes are "essential"? Is there a > flag in the SPEC file? It is decided by whoever writes the spec file. Suppose that the default config settings for a program have changed after a major revision increment, so new entries are required and old ones *must* be removed. The only way to do this is to use a new config file template and save the old config file. The spec file has the appropriate entries to force an overwrite after the backup has been done, and there should be a message to tell the system administrator to review things. The answer is never to blindly update in this way without checking what is changing. -- Brian Morrison bdm at fenrir.org.uk From hjp+fedora-legacy at wsr.ac.at Mon Apr 10 11:41:07 2006 From: hjp+fedora-legacy at wsr.ac.at (Peter J. Holzer) Date: Mon, 10 Apr 2006 13:41:07 +0200 Subject: sendmail update left me in a fix In-Reply-To: <443A3910.80206@fenrir.org.uk> References: <20060407124741.sfw30e519ao0wcc0@mail.ph.utexas.edu> <20060410082558.GA10540@wsr.ac.at> <443A197A.5000007@fenrir.org.uk> <20060410090658.GC10540@wsr.ac.at> <443A3910.80206@fenrir.org.uk> Message-ID: <20060410114107.GG10540@wsr.ac.at> On 2006-04-10 11:53:04 +0100, Brian Morrison wrote: > On 10/04/2006 Peter J. Holzer wrote: > > > That's when the config file has essential changes for the updated > > > package to work at all, and hence must be installed. The rpmsave > > > file is there as a hint that you need to merge your previous changes with > > > the new format. > > > > How does RPM decide whether the changes are "essential"? Is there a > > flag in the SPEC file? > > It is decided by whoever writes the spec file. Hmpf. I guess that's what I deserve for asking such imprecise questions. Ok, I think I found it in /usr/share/doc/rpm-4.3.1/spec: | The %config(noreplace) indicates that the file in the package should | be installed with extension .rpmnew if there is already a modified file | with the same name on the installed machine. So, the default seems to be to replace config files, but it the packager deems an update non-essential he can mark it with noreplace. BTW, is there somewhere a complete up-to-date description of the spec file? The file above is just a "what's new since some unspecified release" file, and RPM to the max is now over 5 years old. 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 nils at lemonbit.nl Mon Apr 10 13:00:23 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Mon, 10 Apr 2006 15:00:23 +0200 Subject: sendmail update left me in a fix In-Reply-To: <20060410114107.GG10540@wsr.ac.at> References: <20060407124741.sfw30e519ao0wcc0@mail.ph.utexas.edu> <20060410082558.GA10540@wsr.ac.at> <443A197A.5000007@fenrir.org.uk> <20060410090658.GC10540@wsr.ac.at> <443A3910.80206@fenrir.org.uk> <20060410114107.GG10540@wsr.ac.at> Message-ID: Peter J. Holzer wrote: > BTW, is there somewhere a complete up-to-date description of the spec > file? The file above is just a "what's new since some unspecified > release" file, and RPM to the max is now over 5 years old. See the documentation section on the frontpage of http://www.rpm.org/ Nils. From hjp+fedora-legacy at wsr.ac.at Mon Apr 10 13:21:21 2006 From: hjp+fedora-legacy at wsr.ac.at (Peter J. Holzer) Date: Mon, 10 Apr 2006 15:21:21 +0200 Subject: sendmail update left me in a fix In-Reply-To: References: <20060407124741.sfw30e519ao0wcc0@mail.ph.utexas.edu> <20060410082558.GA10540@wsr.ac.at> <443A197A.5000007@fenrir.org.uk> <20060410090658.GC10540@wsr.ac.at> <443A3910.80206@fenrir.org.uk> <20060410114107.GG10540@wsr.ac.at> Message-ID: <20060410132121.GJ10540@wsr.ac.at> On 2006-04-10 15:00:23 +0200, Nils Breunese (Lemonbit Internet) wrote: > Peter J. Holzer wrote: > > >BTW, is there somewhere a complete up-to-date description of the spec > >file? The file above is just a "what's new since some unspecified > >release" file, and RPM to the max is now over 5 years old. > > See the documentation section on the frontpage of http://www.rpm.org/ Thanks. http://fedora.redhat.com/docs/drafts/rpm-guide-en/ does indeed seem to be fairly complete and up-to-date. I remember seeing only RPM to the max and the howto there, which are both rather old (including the "next version" of RPM to the max). 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 d.terweij at nettuning.net Mon Apr 10 13:51:34 2006 From: d.terweij at nettuning.net (Danny Terweij - Net Tuning | Net) Date: Mon, 10 Apr 2006 15:51:34 +0200 Subject: FC3 (j)whois on .eu fails Message-ID: <00a001c65ca5$e1d35300$1e00a8c0@prvd321> Hi, I have : jwhois-3.2.2-6.FC3.1 And whois on .eu fails (falling back to default whois server). When i add in jwhois.conf the following line : "\\.eu$" = "whois.eu"; Then it works. Time for an jwhois package update? Danny. From rostetter at mail.utexas.edu Mon Apr 10 14:28:03 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 10 Apr 2006 09:28:03 -0500 Subject: sendmail update left me in a fix In-Reply-To: <443A2893.2090401@gtw.net> References: <443A2893.2090401@gtw.net> Message-ID: <20060410092803.gckxlmvsoe800kc0@mail.ph.utexas.edu> Just to point out some potential issues (depending on upgrade paths, etc). Some old sendmail configurations kept files in /etc/ while newer configurations keep these files in /etc/mail/ instead. A similar problem might exist for some files moved from /etc/ or /etc/mail/ to /var/run et al. These changes might cause problems? Some people might have files linked or copied in multiple places because of these changes (thinking they were providing backwards compatibility or such) and this could really cause problems. In addition, the upgrade might have moved the base mc files on old systems which would cause the sendmail.mc file not to compile. If something does a "blind" update of sendmail.cf from sendmail.mc without checking for errors, it could produce a broken sendmail.cf file. I've not seen any of these problems with the latest sendmail package (but I've also not tested it much) but I did see some of these issues with the first sendmail update... IMHO, almost all the problems were caused by the first package, not the second package. The problem is everyone rushed to install the first package, and the if so, the second package can't undo all the problems the first one created... -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From maillist at jasonlim.com Mon Apr 10 14:12:49 2006 From: maillist at jasonlim.com (Jason Lim) Date: Mon, 10 Apr 2006 22:12:49 +0800 Subject: 1-2-3 out, time for FC2? References: <29fb01c65855$e0314e70$0201a8c0@p3000> <200604051623.30549.jkeating@redhat.com> <4439DF47.1000804@sbcglobal.net> <827E2526-88E2-44EF-8A76-45EAA7421B2D@cs.ucsb.edu> Message-ID: <144d01c65cae$bff7f0c0$0800a8c0@SYSTEM8> Hi all, After following a lot of the conversations here, and having FC boxes for servers, I can tell you that a LOT of our customers did NOT expect and know that there was such a short timeline per release. They thought they could keep running FC1 for a long time, so a lot of them fell for FC1 at the time for running servers. However, now that everyone knows publically that the FC releases are so short-lived, less and less people are running it on their servers, to the point that almost all servers now run RHEL / CentOS now (as they should be). However, some customers are still stuck on FC1. We have almost no boxes stuck on FC2/3/4 simply because everyone already knows about the short timeline. Almost none of this affects people running it on the desktop, since downtime is far less damaging on a desktop/laptop than on a server, so the only people still being "forced" to run FC1 are the server guys. That is probably why interest in FC1 is far more than say FC2 or FC3, because people fell for the "trap" of installing FC1 on servers. Anyway, just my 2 cents, I would hope that FC1 is maintained and forget about having long lifetimes for the rest, people who want long lifetimes already use RHEL/CentOS which is far more suited to that kind of situation anyway. Jas ----- Original Message ----- From: "Jeff Sheltren" To: "Discussion of the Fedora Legacy Project" Sent: Monday, 10 April, 2006 6:31 PM Subject: Re: 1-2-3 out, time for FC2? > > On Apr 10, 2006, at 12:29 AM, Mike McCarty wrote: > > > Tres Seaver wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> Jesse Keating wrote: > > > > [snip] > > > >>> Honestly, I feel that supporting FC1 for so long was a mistake. > >>> It set a precedence that I really don't want to continue. Legacy > >>> picked a timeline > > > > [snip] > > > >> Dropping the releases which get actual love may feel cleaner, but I > >> don't think you are going to get the folks who have been maintaining > >> those older releases to switch to a newer FC: they will, as you > >> point > >> out, more likely switch away from Fedora altogether. Perhaps > >> there are > >> a group of volunteers who care about more recent FC releases, and who > >> can take up the load. > > > > If things get to the point where I feel I *must* replace my load, > > I'm switching to Debian. > > > > Mike > > Mike, I thought you had already stopped using Legacy. If so, I'm not > sure how this affects you. > > I'm referring to your post here: > https://www.redhat.com/archives/fedora-legacy-list/2006-February/ > msg00138.html > > -Jeff > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > From kleskoe at hotmail.com Mon Apr 10 17:49:13 2006 From: kleskoe at hotmail.com (kles koe) Date: Mon, 10 Apr 2006 17:49:13 +0000 Subject: sendmail update left me in a fix In-Reply-To: <20060410092803.gckxlmvsoe800kc0@mail.ph.utexas.edu> Message-ID: i did install the first package too and after restarting it gave some errors which were easily fixed by adding a few settings to the old mc file and rebuilding the cf file from it. can anybody advise me on what steps to take in order to have the second package install without to many problems? thanks! >From: Eric Rostetter >Reply-To: Discussion of the Fedora Legacy Project > >To: fedora-legacy-list at redhat.com >Subject: Re: sendmail update left me in a fix >Date: Mon, 10 Apr 2006 09:28:03 -0500 > > >Just to point out some potential issues (depending on upgrade paths, etc). > >Some old sendmail configurations kept files in /etc/ while newer >configurations >keep these files in /etc/mail/ instead. A similar problem might exist for >some files moved from /etc/ or /etc/mail/ to /var/run et al. These changes >might cause problems? Some people might have files linked or copied in >multiple places because of these changes (thinking they were providing >backwards compatibility or such) and this could really cause problems. > >In addition, the upgrade might have moved the base mc files on old systems >which would cause the sendmail.mc file not to compile. If something does >a "blind" update of sendmail.cf from sendmail.mc without checking for >errors, >it could produce a broken sendmail.cf file. > >I've not seen any of these problems with the latest sendmail package (but >I've also not tested it much) but I did see some of these issues with the >first sendmail update... > >IMHO, almost all the problems were caused by the first package, not the >second package. The problem is everyone rushed to install the first >package, and the if so, the second package can't undo all the problems >the first one created... > >-- >Eric Rostetter >The Department of Physics >The University of Texas at Austin > >Go Longhorns! > >-- >fedora-legacy-list mailing list >fedora-legacy-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-legacy-list _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From rostetter at mail.utexas.edu Mon Apr 10 18:18:55 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 10 Apr 2006 13:18:55 -0500 Subject: sendmail update left me in a fix In-Reply-To: References: Message-ID: <20060410131855.mcox0gv875wgoows@mail.ph.utexas.edu> Quoting Parker Jones : > Problem: Sending mail failed after the update. I send locally using > nmh. Restarting sendmail didn't help. Receiving appeared to be > unaffected. > > Quick fix: After waiting several days hoping the problem would just go > away, I had to do something about it. I appear to have made the > problem go away by replacing sendmail.cf with its old version (prior to > the sendmail update) and restarting sendmail. > > Looking for an explanation: I tried to reproduce the problem by > restoring the sendmail.cf supplied with the update and restarting > sendmail. Surprisingly I could still send - I expected it to break. > This would suggest that there is something else going on that I'm not > taking into consideration (rebuilding of sendmail.mc perhaps?) > > So I still have no satisfactory explanation of the cause of the problem. Could it perhaps be the /etc/mail/submit.cf file that was the problem? I'm not sure how nmh submits the mail (via local sendmail invocation, or via port 25, or via port 587, etc. Each could have its own problems (missing symlink, bad .cf files, etc). > If sendmail.mc is compiled will the problem reappear? Try it and find out (but I doubt it). -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From rostetter at mail.utexas.edu Mon Apr 10 18:28:27 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 10 Apr 2006 13:28:27 -0500 Subject: 1-2-3 out, time for FC2? In-Reply-To: <4439DED4.4020400@sbcglobal.net> References: <29fb01c65855$e0314e70$0201a8c0@p3000> <200604051310.33692.guallar@easternrad.com> <443427AC.5050502@sbcglobal.net> <20060405202749.8jgv4leejnk08o0w@mail.ph.utexas.edu> <4439DED4.4020400@sbcglobal.net> Message-ID: <20060410132827.msfu1t0d4hcsww00@mail.ph.utexas.edu> Quoting Mike McCarty : > Eric Rostetter wrote: >> Quoting Mike McCarty : >> >>> I have volunteered some time for test if >> >> I will assume you mean the second part of QA, the "verify" step. > > Well, perhaps I used the word "test" in a technical sense. > In my background, test means "verification of proper operation". That is only part of testing. For example, you don't want to release code which operates properly, but isn't secure (contains a trojan, etc). >> Now, here is the real kicker: >> >> You can do the first step of QA (publish votes rather than verify votes) >> on ANY system and without compromising the system at all. It only involves >> comparing the files to other known files, etc. You don't have to install >> anything on the system. So, you can help, within your constraints, if >> you choose, by doing the first QA step rather than the second. > > Ok, if you can give me more information, I'll be glad to donate some > time. See http://www.fedoraproject.org/wiki/Legacy/QAPublish and follow the info there. Do the manditory steps, but skip any optional steps which you can't do because of disk space, installation, etc. My own "checklist" reads: * Download the old (original) package. * Download the new package. * Download the original upstream source of the patches, if needed. * Compare the changelogs: rpm -qp --changelog old.rpm > old.changes rpm -qp --changelog new.rpm > new.changes diff -u old.changes new.changes | grep "^+" * Compare the file lists: rpmdiff old.rpm new.rpm * Compare the files: mkdir old; (cd old; rpm2cpio ../old.rpm | cpio -i --make-directories) mkdir new; ( cd new; rpm2cpio ../new.rpm | cpio -i --make-directories) diff -uNr old new | more * Compare the patches in the new package to the upstream patch sources. * If exploit is available: * test exploit to see if it works. * build and install new package. * test exploit to see if it fails. You don't have to follow the same proceedure though... > Mike -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From zoubidoo at hotmail.com Mon Apr 10 18:40:04 2006 From: zoubidoo at hotmail.com (Parker Jones) Date: Tue, 11 Apr 2006 06:40:04 +1200 Subject: sendmail update left me in a fix In-Reply-To: <20060410131855.mcox0gv875wgoows@mail.ph.utexas.edu> Message-ID: >Could it perhaps be the /etc/mail/submit.cf file that was the problem? >I'm not sure how nmh submits the mail (via local sendmail invocation, >or via port 25, or via port 587, etc. Each could have its own problems >(missing symlink, bad .cf files, etc). > >>If sendmail.mc is compiled will the problem reappear? > >Try it and find out (but I doubt it). Possibly interesting? submit.cf is older than submit.mc and the mc was changed recently in the "first" sendmail update. [root at stancomb root]# ls -l /usr/share/sendmail-cf/cf/submit* -r--r--r-- 1 root root 38944 Jan 18 2004 /usr/share/sendmail-cf/cf/submit.cf -rw-r--r-- 1 root root 952 Mar 26 03:34 /usr/share/sendmail-cf/cf/submit.mc -rw-r--r-- 1 root root 802 Sep 11 2003 /usr/share/sendmail-cf/cf/submit.mc.pid _________________________________________________________________ Shop ?til you drop at XtraMSN Shopping http://shopping.xtramsn.co.nz/home/ From drees76 at gmail.com Mon Apr 10 21:29:29 2006 From: drees76 at gmail.com (David Rees) Date: Mon, 10 Apr 2006 14:29:29 -0700 Subject: FC3 (j)whois on .eu fails In-Reply-To: <00a001c65ca5$e1d35300$1e00a8c0@prvd321> References: <00a001c65ca5$e1d35300$1e00a8c0@prvd321> Message-ID: <72dbd3150604101429n41a09fa3g235875bf9622a14@mail.gmail.com> On 4/10/06, Danny Terweij - Net Tuning | Net wrote: > > I have : jwhois-3.2.2-6.FC3.1 > > And whois on .eu fails (falling back to default whois server). > > When i add in jwhois.conf the following line : > > "\\.eu$" = "whois.eu"; > > Then it works. > > Time for an jwhois package update? Not a security related issue, so not going to happen in Fedora Legacy. -Dave From nils at lemonbit.nl Mon Apr 10 21:59:39 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Mon, 10 Apr 2006 23:59:39 +0200 Subject: FC3 (j)whois on .eu fails In-Reply-To: <72dbd3150604101429n41a09fa3g235875bf9622a14@mail.gmail.com> References: <00a001c65ca5$e1d35300$1e00a8c0@prvd321> <72dbd3150604101429n41a09fa3g235875bf9622a14@mail.gmail.com> Message-ID: <78D29343-C7AE-4278-B993-BB9C16D9F0DD@lemonbit.nl> David Rees wrote: > On 4/10/06, Danny Terweij - Net Tuning | Net > wrote: >> >> I have : jwhois-3.2.2-6.FC3.1 >> >> And whois on .eu fails (falling back to default whois server). >> >> When i add in jwhois.conf the following line : >> >> "\\.eu$" = "whois.eu"; >> >> Then it works. >> >> Time for an jwhois package update? > > Not a security related issue, so not going to happen in Fedora Legacy. The tzdata update wan't a security issue either. I reckon this is an issue at least somewhat like the tzdata issue. Nils Breunese. From jkeating at j2solutions.net Mon Apr 10 22:07:24 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 10 Apr 2006 18:07:24 -0400 Subject: FC3 (j)whois on .eu fails In-Reply-To: <78D29343-C7AE-4278-B993-BB9C16D9F0DD@lemonbit.nl> References: <00a001c65ca5$e1d35300$1e00a8c0@prvd321> <72dbd3150604101429n41a09fa3g235875bf9622a14@mail.gmail.com> <78D29343-C7AE-4278-B993-BB9C16D9F0DD@lemonbit.nl> Message-ID: <1144706844.18861.49.camel@ender> On Mon, 2006-04-10 at 23:59 +0200, Nils Breunese (Lemonbit Internet) wrote: > > The tzdata update wan't a security issue either. I reckon this is an > issue at least somewhat like the tzdata issue. > Time being correct is something of a security issue, at a stretch. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nils at lemonbit.nl Mon Apr 10 22:23:07 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Tue, 11 Apr 2006 00:23:07 +0200 Subject: FC3 (j)whois on .eu fails In-Reply-To: <1144706844.18861.49.camel@ender> References: <00a001c65ca5$e1d35300$1e00a8c0@prvd321> <72dbd3150604101429n41a09fa3g235875bf9622a14@mail.gmail.com> <78D29343-C7AE-4278-B993-BB9C16D9F0DD@lemonbit.nl> <1144706844.18861.49.camel@ender> Message-ID: Jesse Keating wrote: > On Mon, 2006-04-10 at 23:59 +0200, Nils Breunese (Lemonbit Internet) > wrote: >> >> The tzdata update wan't a security issue either. I reckon this is an >> issue at least somewhat like the tzdata issue. > > Time being correct is something of a security issue, at a stretch. Isn't being able to use whois for all TLDs too (at a stretch)? Nils Breunese. From smooge at gmail.com Mon Apr 10 22:25:29 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Mon, 10 Apr 2006 16:25:29 -0600 Subject: FC3 (j)whois on .eu fails In-Reply-To: <1144706844.18861.49.camel@ender> References: <00a001c65ca5$e1d35300$1e00a8c0@prvd321> <72dbd3150604101429n41a09fa3g235875bf9622a14@mail.gmail.com> <78D29343-C7AE-4278-B993-BB9C16D9F0DD@lemonbit.nl> <1144706844.18861.49.camel@ender> Message-ID: <80d7e4090604101525s503a4ccbi2f521b47030e55a6@mail.gmail.com> On 4/10/06, Jesse Keating wrote: > On Mon, 2006-04-10 at 23:59 +0200, Nils Breunese (Lemonbit Internet) > wrote: > > > > The tzdata update wan't a security issue either. I reckon this is an > > issue at least somewhat like the tzdata issue. > > > > Time being correct is something of a security issue, at a stretch. > Correct time is always a security issue. A fixed whois may also be a security issue for log reviews and reverse name lookups. It is a similar stretch :). -- Stephen J Smoogen. CSIRT/Linux System Administrator From zoubidoo at hotmail.com Mon Apr 10 15:55:33 2006 From: zoubidoo at hotmail.com (Parker Jones) Date: Tue, 11 Apr 2006 03:55:33 +1200 Subject: sendmail update left me in a fix Message-ID: Thank you to all for looking into this. Attached are the sendmail config files as requested. The sendmail.cf.2002 dates back to July 2002 and to the best of my knowledge hasn't been changed since (despite the recent timestamp). I am (and always have been) the sole admin of the machine and don't know enough about sendmail to be changing mc/cf files directly - so no tweaking going on. I do my sendmail parameterisation through webmin (aliases, relay domains, address mappings etc). As far as I'm aware I don't have the sendmail.mc that generates the 2002 cf. [root at stancomb mail]# ls -l /etc/mail/sendmail.mc -rw-r--r-- 1 root root 4369 Mar 26 03:35 /etc/mail/sendmail.mc [root at stancomb mail]# ls -l /etc/sendmail.cf* -r--r--r-- 1 root root 46557 Apr 10 03:38 /etc/sendmail.cf -r--r--r-- 1 root root 46557 Apr 7 01:24 /etc/sendmail.cf.2002 -rw-r--r-- 1 root root 57549 Mar 26 03:35 /etc/sendmail.cf.rpmnew [root at stancomb mail]# diff /etc/sendmail.cf /etc/sendmail.cf.2002 [root at stancomb mail]# Rebuilding sendmail.cf from mc [root at stancomb etc]# m4 /etc/mail/sendmail.mc > foo [root at stancomb etc]# diff sendmail.cf.rpmnew foo |more 19,21c19,21 < ##### built by mockbuild at turbosphere.fedoralegacy.org on Sat Mar 25 20:35:32 EST 2006 < ##### in /builddir/build/BUILD/sendmail-8.12.11/cf/cf < ##### using ../ as configuration include directory --- >##### built by root at stancomb.co.uk on Mon Apr 10 17:50:32 CEST 2006 >##### in /etc >##### using /usr/share/sendmail-cf/ as configuration include directory The same. _________________________________________________________________ Is your PC infected? Get a FREE online computer virus scan from McAfee? Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -------------- next part -------------- A non-text attachment was scrubbed... Name: sendmail.mc Type: application/octet-stream Size: 4369 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sendmail.cf.2002 Type: application/octet-stream Size: 46557 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sendmail.cf.rpmnew Type: application/octet-stream Size: 57549 bytes Desc: not available URL: From cra at WPI.EDU Tue Apr 11 00:51:29 2006 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 10 Apr 2006 20:51:29 -0400 Subject: FC3 (j)whois on .eu fails In-Reply-To: References: <00a001c65ca5$e1d35300$1e00a8c0@prvd321> <72dbd3150604101429n41a09fa3g235875bf9622a14@mail.gmail.com> <78D29343-C7AE-4278-B993-BB9C16D9F0DD@lemonbit.nl> <1144706844.18861.49.camel@ender> Message-ID: <20060411005129.GC22579@angus.ind.WPI.EDU> On Tue, Apr 11, 2006 at 12:23:07AM +0200, Nils Breunese (Lemonbit Internet) wrote: > Isn't being able to use whois for all TLDs too (at a stretch)? I remember a time when you had to manually specify which server to query for whois data. whois -h server foo.eu or whois foo.eu at server. From kevin.kofler at chello.at Tue Apr 11 17:08:06 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 11 Apr 2006 17:08:06 +0000 (UTC) Subject: FC3 (j)whois on .eu fails References: <00a001c65ca5$e1d35300$1e00a8c0@prvd321> Message-ID: This isn't quite a legacy-specific issue. The FC5 whois reacts the same way. Passing -h whois.eu on the command line works around this, just like your config file edit. Kevin Kofler From nils at lemonbit.nl Wed Apr 12 07:56:03 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Wed, 12 Apr 2006 09:56:03 +0200 Subject: FC3 (j)whois on .eu fails In-Reply-To: References: <00a001c65ca5$e1d35300$1e00a8c0@prvd321> Message-ID: Kevin Kofler wrote: > This isn't quite a legacy-specific issue. The FC5 whois reacts the > same way. > Passing -h whois.eu on the command line works around this, just > like your > config file edit. But Red Hat maintained packages will probably be updated, while the legacy packages may not. The question is whether legacy should do update the FL maintained package or say: "This has nothing to do with security so we won't fix it". I believe some people on this least agree this could be a slight security issue (at a stretch), i.e. when whois is used for automated lookups. Nils Breunese. From Mike.McCarty at sbcglobal.net Wed Apr 12 18:20:38 2006 From: Mike.McCarty at sbcglobal.net (Mike McCarty) Date: Wed, 12 Apr 2006 13:20:38 -0500 Subject: RKHUNTER reporting on my system Message-ID: <443D44F6.50809@sbcglobal.net> Hi, I have an FC2 system which rkhunter reports some suspicious files. In particular, during the MD5 hash scan, it reports /bin/dmesg /bin/kill /bin/login /bin/mount /usr/bin/kill as having unknown/incorrect hashes, and comments that this can be caused by using an old database or new binaries. I ran it again with --update, and it indeed pulled more database. However, it still reports those five files. It also now reports more packages as being old (it was complaining about 3, now about 4). It also doesn't like the fact that root can log in, and that SSHv1 is permitted to run. Anyway, does anyone have more information about why rkhunter might flag these programs? Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From pekkas at netcore.fi Wed Apr 12 18:33:21 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 12 Apr 2006 21:33:21 +0300 (EEST) Subject: FC3 (j)whois on .eu fails In-Reply-To: References: <00a001c65ca5$e1d35300$1e00a8c0@prvd321> Message-ID: On Wed, 12 Apr 2006, Nils Breunese (Lemonbit Internet) wrote: > But Red Hat maintained packages will probably be updated, while the legacy > packages may not. The question is whether legacy should do update the FL > maintained package or say: "This has nothing to do with security so we won't > fix it". I believe some people on this least agree this could be a slight > security issue (at a stretch), i.e. when whois is used for automated lookups. Let me put a challenge for you guys. If I see work on jwhois src.rpm packages AND at least one another NEEDSWORK package [1], for all the relevant distributions [2], I would probably consider evaluation these under publish criteria. But unless a proponent of the update actually steps up to do the work (and some token work for some other Fedora Legacy updates), I wouldn't recommend anyone else from Fedora Legacy project to spend their time on this. We have far too many, much more important packages still sitting on the "needs packages" pile. [1] http://netcore.fi/pekkas/buglist.html [2] http://fedoraproject.org/wiki/Legacy/QASubmit 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 Mike.McCarty at sbcglobal.net Wed Apr 12 18:36:03 2006 From: Mike.McCarty at sbcglobal.net (Mike McCarty) Date: Wed, 12 Apr 2006 13:36:03 -0500 Subject: 1-2-3 out, time for FC2? In-Reply-To: <827E2526-88E2-44EF-8A76-45EAA7421B2D@cs.ucsb.edu> References: <29fb01c65855$e0314e70$0201a8c0@p3000> <200604051623.30549.jkeating@redhat.com> <4439DF47.1000804@sbcglobal.net> <827E2526-88E2-44EF-8A76-45EAA7421B2D@cs.ucsb.edu> Message-ID: <443D4893.7020305@sbcglobal.net> Jeff Sheltren wrote: > > On Apr 10, 2006, at 12:29 AM, Mike McCarty wrote: > >> If things get to the point where I feel I *must* replace my load, >> I'm switching to Debian. >> >> Mike > > > Mike, I thought you had already stopped using Legacy. If so, I'm not > sure how this affects you. > > I'm referring to your post here: > https://www.redhat.com/archives/fedora-legacy-list/2006-February/ > msg00138.html I'm not permitted to view that, so I can't respond specifically. What I've done is remove Fedora Legacy from my yum update list. I've still got FC2 loaded on my machine, but the load is frozen. 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 pyz at brama.com Wed Apr 12 18:38:20 2006 From: pyz at brama.com (Max Pyziur) Date: Wed, 12 Apr 2006 14:38:20 -0400 (EDT) Subject: RKHUNTER reporting on my system In-Reply-To: <443D44F6.50809@sbcglobal.net> References: <443D44F6.50809@sbcglobal.net> Message-ID: <56480.68.161.199.190.1144867100.squirrel@webmail.brama.com> > Hi, > > I have an FC2 system which rkhunter reports some suspicious > files. In particular, during the MD5 hash scan, it reports > > /bin/dmesg > /bin/kill > /bin/login > /bin/mount > /usr/bin/kill I run FC2 and have a similar issue. I've run rkhunter --update many times in the hopes of updating the installed database to resolve this problem. Is there a way of updating the the FC2-related rkhunter database in order to resolve this? Thanks. Max Pyziur pyz at brama.com > as having unknown/incorrect hashes, and comments that this can > be caused by using an old database or new binaries. I ran it > again with --update, and it indeed pulled more database. However, > it still reports those five files. It also now reports more > packages as being old (it was complaining about 3, now about 4). > > It also doesn't like the fact that root can log in, and that > SSHv1 is permitted to run. > > Anyway, does anyone have more information about why rkhunter > might flag these programs? > > 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! > > -- > 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 Apr 12 19:09:45 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Wed, 12 Apr 2006 21:09:45 +0200 Subject: RKHUNTER reporting on my system In-Reply-To: <56480.68.161.199.190.1144867100.squirrel@webmail.brama.com> References: <443D44F6.50809@sbcglobal.net> <56480.68.161.199.190.1144867100.squirrel@webmail.brama.com> Message-ID: Max Pyziur wrote: >> I have an FC2 system which rkhunter reports some suspicious >> files. In particular, during the MD5 hash scan, it reports >> >> /bin/dmesg >> /bin/kill >> /bin/login >> /bin/mount >> /usr/bin/kill > > I run FC2 and have a similar issue. I've run rkhunter --update > many times > in the hopes of updating the installed database to resolve this > problem. > Is there a way of updating the the FC2-related rkhunter database in > order > to resolve this? I experience the same (for the same files). I tried installing an older version of util-linux and everything was fine again. I updated util-linux again and it didn't recognize these files again. So I wouldn't be to worried. If rkhunter doesn't recognize certain files you're supposed to report this on the rkhunter website. I reported this issue twice already, but apparently no one has looked into this. >> It also doesn't like the fact that root can log in, and that >> SSHv1 is permitted to run. Rightly so. Do not allow these things or change /etc/rkhunter.conf to not let it warn you about these things. Nils. From res00vl8 at alltel.net Wed Apr 12 19:13:26 2006 From: res00vl8 at alltel.net (taharka) Date: Wed, 12 Apr 2006 15:13:26 -0400 Subject: 1-2-3 out, time for FC2? In-Reply-To: <443D4893.7020305@sbcglobal.net> References: <29fb01c65855$e0314e70$0201a8c0@p3000> <200604051623.30549.jkeating@redhat.com> <4439DF47.1000804@sbcglobal.net> <827E2526-88E2-44EF-8A76-45EAA7421B2D@cs.ucsb.edu> <443D4893.7020305@sbcglobal.net> Message-ID: <1144869208.18357.13.camel@Khufu.local> Howdy, On Wed, 2006-04-12 at 13:36 -0500, Mike McCarty wrote: > Jeff Sheltren wrote: > > > > On Apr 10, 2006, at 12:29 AM, Mike McCarty wrote: > > > >> If things get to the point where I feel I *must* replace my load, > >> I'm switching to Debian. > >> > >> Mike > > > > > > Mike, I thought you had already stopped using Legacy. If so, I'm not > > sure how this affects you. > > > > I'm referring to your post here: > > https://www.redhat.com/archives/fedora-legacy-list/2006-February/ > > msg00138.html > > I'm not permitted to view that, so I can't respond specifically. > What I've done is remove Fedora Legacy from my yum update list. > I've still got FC2 loaded on my machine, but the load is frozen. You'd be permitted to view that, if the link wasn't wrapped :-( Try the following instead ;-) https://www.redhat.com/archives/fedora-legacy-list/2006-February/msg00138.html > Mike taharka Lexington, Kentucky U.S.A. From Mike.McCarty at sbcglobal.net Wed Apr 12 19:27:32 2006 From: Mike.McCarty at sbcglobal.net (Mike McCarty) Date: Wed, 12 Apr 2006 14:27:32 -0500 Subject: 1-2-3 out, time for FC2? In-Reply-To: <1144869208.18357.13.camel@Khufu.local> References: <29fb01c65855$e0314e70$0201a8c0@p3000> <200604051623.30549.jkeating@redhat.com> <4439DF47.1000804@sbcglobal.net> <827E2526-88E2-44EF-8A76-45EAA7421B2D@cs.ucsb.edu> <443D4893.7020305@sbcglobal.net> <1144869208.18357.13.camel@Khufu.local> Message-ID: <443D54A4.8090507@sbcglobal.net> taharka wrote: > Howdy, > > On Wed, 2006-04-12 at 13:36 -0500, Mike McCarty wrote: > >>Jeff Sheltren wrote: >> >>>On Apr 10, 2006, at 12:29 AM, Mike McCarty wrote: >>> >>> >>>>If things get to the point where I feel I *must* replace my load, >>>>I'm switching to Debian. >>>> >>>>Mike >>> >>> >>>Mike, I thought you had already stopped using Legacy. If so, I'm not >>>sure how this affects you. >>> >>>I'm referring to your post here: >>>https://www.redhat.com/archives/fedora-legacy-list/2006-February/ >>>msg00138.html >> >>I'm not permitted to view that, so I can't respond specifically. >>What I've done is remove Fedora Legacy from my yum update list. >>I've still got FC2 loaded on my machine, but the load is frozen. > > > You'd be permitted to view that, if the link wasn't wrapped :-( Try the > following instead ;-) > https://www.redhat.com/archives/fedora-legacy-list/2006-February/msg00138.html I should have noticed that, myself! (wipes egg from face) But it's exactly as I said... 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 kleskoe at hotmail.com Wed Apr 12 20:23:22 2006 From: kleskoe at hotmail.com (kles koe) Date: Wed, 12 Apr 2006 20:23:22 +0000 Subject: RKHUNTER reporting on my system In-Reply-To: Message-ID: why don't you just ask the author of rkhunter to update the hashes for these packges? i think i did once and it was fixed within a few days. >From: "Nils Breunese (Lemonbit Internet)" >Reply-To: Discussion of the Fedora Legacy Project > >To: Discussion of the Fedora Legacy Project >Subject: Re: RKHUNTER reporting on my system >Date: Wed, 12 Apr 2006 21:09:45 +0200 > >Max Pyziur wrote: > >>>I have an FC2 system which rkhunter reports some suspicious >>>files. In particular, during the MD5 hash scan, it reports >>> >>> /bin/dmesg >>> /bin/kill >>> /bin/login >>> /bin/mount >>> /usr/bin/kill >> >>I run FC2 and have a similar issue. I've run rkhunter --update many >>times >>in the hopes of updating the installed database to resolve this problem. >>Is there a way of updating the the FC2-related rkhunter database in order >>to resolve this? > >I experience the same (for the same files). I tried installing an older >version of util-linux and everything was fine again. I updated util-linux >again and it didn't recognize these files again. So I wouldn't be to >worried. If rkhunter doesn't recognize certain files you're supposed to >report this on the rkhunter website. I reported this issue twice already, >but apparently no one has looked into this. > >>>It also doesn't like the fact that root can log in, and that >>>SSHv1 is permitted to run. > >Rightly so. Do not allow these things or change /etc/rkhunter.conf to not >let it warn you about these things. > >Nils. > >-- >fedora-legacy-list mailing list >fedora-legacy-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-legacy-list _________________________________________________________________ Don?t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From deisenst at gtw.net Wed Apr 12 20:27:24 2006 From: deisenst at gtw.net (David Eisenstein) Date: Wed, 12 Apr 2006 15:27:24 -0500 Subject: RKHUNTER reporting on my system In-Reply-To: References: <443D44F6.50809@sbcglobal.net> <56480.68.161.199.190.1144867100.squirrel@webmail.brama.com> Message-ID: <443D62AC.1090005@gtw.net> Nils Breunese (Lemonbit Internet) wrote: > Max Pyziur wrote: > >>> I have an FC2 system which rkhunter reports some suspicious >>> files. In particular, during the MD5 hash scan, it reports >>> >>> /bin/dmesg >>> /bin/kill >>> /bin/login >>> /bin/mount >>> /usr/bin/kill >> >> >> I run FC2 and have a similar issue. I've run rkhunter --update many >> times >> in the hopes of updating the installed database to resolve this problem. >> Is there a way of updating the the FC2-related rkhunter database in >> order >> to resolve this? > > > I experience the same (for the same files). I tried installing an older > version of util-linux and everything was fine again. I updated > util-linux again and it didn't recognize these files again. So I > wouldn't be to worried. If rkhunter doesn't recognize certain files > you're supposed to report this on the rkhunter website. I reported this > issue twice already, but apparently no one has looked into this. We've seen this issue before. There was a bugzilla on this same topic in mid-December. Like what you did, Nils, I asked the reporter to report this upstream. Thanks for doing that. This issue may affect RHL7.3, RHL9, FC1 and FC2 packages, due to the util-linux/mount update advisory FLSA-2005:168326 announced here: Here's the bugzilla entry (closed upstream): -David From nils at lemonbit.nl Wed Apr 12 20:45:58 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Wed, 12 Apr 2006 22:45:58 +0200 Subject: RKHUNTER reporting on my system In-Reply-To: References: Message-ID: <022EBAB9-0832-4BFB-9A97-C77CA30C769D@lemonbit.nl> kles koe wrote: > why don't you just ask the author of rkhunter to update the hashes > for these packges? > i think i did once and it was fixed within a few days. I said I already reported this issue twice, but so far I haven't received any reaction and the latest version of the hashes still doesn't recognize these Fedora Legacy versions of those files. Nils. From mic at npgx.com.au Wed Apr 12 23:15:52 2006 From: mic at npgx.com.au (Michael Mansour) Date: Thu, 13 Apr 2006 09:15:52 +1000 Subject: RKHUNTER reporting on my system In-Reply-To: <022EBAB9-0832-4BFB-9A97-C77CA30C769D@lemonbit.nl> References: <022EBAB9-0832-4BFB-9A97-C77CA30C769D@lemonbit.nl> Message-ID: <20060412230619.M24900@npgx.com.au> > kles koe wrote: > > > why don't you just ask the author of rkhunter to update the hashes > > for these packges? > > i think i did once and it was fixed within a few days. > > I said I already reported this issue twice, but so far I haven't > received any reaction and the latest version of the hashes still > doesn't recognize these Fedora Legacy versions of those files. > > Nils. Sometimes Michael (the rkhunter author) is good and quick at these, and responds well, other times he never responds and ignores you. I've been trying to get him to support Scientific Linux for over a year now, sent him all the reports and outputs he needs to add support for the distribution (he supports RHEL and CentOS, but for some reason not SL), I've had him go halfway with the support (our emails get to the halfway point of "ready to include in rkhunter"), then nada, no more responses. I've also reported a bug with one of his mirrors (mirror13) which is broken and holds rkhunter updates from 2005 (and fails my nightly checks for updates as a result), he's acknowledged the problem and told me he's re-doing alot of the way mirrors work etc, but the problem is still there and has been there for 5 months. Don't get me wrong, I'm not bagging the guy, but just saying you're not alone and it's something I've learnt to accept from him. Regards, Michael. From deisenst at gtw.net Mon Apr 17 15:24:33 2006 From: deisenst at gtw.net (David Eisenstein) Date: Mon, 17 Apr 2006 10:24:33 -0500 (CDT) Subject: Heads up! Firefox & Mozilla Message-ID: Hi Folks, Over the (HOLIDAY!) weekend, Mozilla released a new Firefox (1.0.8) fixing a set of critical vulnerabilities. The upstream (mozilla.org) chose *not*, however, to release the Mozilla code for 1.7.13 yet, but I am told that the updated Mozilla will be released officially in the near future. We may, however, be able to get our hands on the sources before then and get it in the pipeline for QA and such. Some of the critical issues (potential remotely exploited code execution) can be mitigated by turning off Javascript, but not all, as there is one issue that I am told that can be triggered by HTML tags. From MFSA 2006-18 , : "A particular sequence of HTML tags that reliably crash Mozilla clients was reported by an anonymous researcher via TippingPoint and the Zero Day Initiative. The crash is due to memory corruption that can be exploited to run arbitary code. "Mozilla mail clients will crash on the tag sequence, but without the ability to run scripts to fill memory with the attack code it may not be possible for an attacker to exploit this crash." These issues affect Mozilla Firefox and Thunderbird 1.x before 1.5 and 1.0.x before 1.0.8, Mozilla Suite before 1.7.13, and SeaMonkey before 1.0, according to CVE-2006-0749. Be careful out there! We'll get these out for Legacy as soon as we can. Regards, David Eisenstein From chris.b.olds at corvallisonline.us Mon Apr 17 16:49:21 2006 From: chris.b.olds at corvallisonline.us (Chris Olds) Date: Mon, 17 Apr 2006 09:49:21 -0700 Subject: fedora Core2 updates Message-ID: <652cde540604170949v2404492aq630b343fb6a5255d@mail.gmail.com> hello all, I'm new to the list, I have some webservers running Fedora Core2, i'm using yum to manage updates. I've run into a dependency snafu, does anyone have a suggestion for satisfying this lib dependency? Resolving dependencies ....Unable to satisfy dependencies Package glibc-dummy-fedora-core-2 needs glibc-common = 2.3.3-27.1, this is not available. Thanks, -- Chris Olds ~ 541-326-9474 Southern Oregon Online ~ Internet & Network Services ~ www.southernoregon-online.com From sheltren at cs.ucsb.edu Mon Apr 17 18:29:19 2006 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Mon, 17 Apr 2006 14:29:19 -0400 (AST) Subject: fedora Core2 updates In-Reply-To: <652cde540604170949v2404492aq630b343fb6a5255d@mail.gmail.com> References: <652cde540604170949v2404492aq630b343fb6a5255d@mail.gmail.com> Message-ID: <10023.209.88.66.94.1145298559.squirrel@letters.cs.ucsb.edu> On Mon, April 17, 2006 12:49 pm, Chris Olds wrote: > hello all, > > I'm new to the list, I have some webservers running Fedora Core2, i'm > using yum to manage updates. I've run into a dependency snafu, > > does anyone have a suggestion for satisfying this lib dependency? > > > Resolving dependencies > ....Unable to satisfy dependencies > Package glibc-dummy-fedora-core-2 needs glibc-common = 2.3.3-27.1, > this is not available. > > Thanks, Hi Chris, what repos do you have enabled (or were enabled previously) on this box? glibc-dummy looks like something from a 3rd party repo. If you've since disabled that repo, you may want to remove that package and then try a yum update... -Jeff From paul at weycrest.net Mon Apr 17 00:53:06 2006 From: paul at weycrest.net (Paul Lee) Date: Mon, 17 Apr 2006 01:53:06 +0100 Subject: fedora Core2 updates In-Reply-To: <652cde540604170949v2404492aq630b343fb6a5255d@mail.gmail.com> References: <652cde540604170949v2404492aq630b343fb6a5255d@mail.gmail.com> Message-ID: <4442E6F2.2020807@weycrest.net> Chris Olds wrote: > hello all, > > I'm new to the list, I have some webservers running Fedora Core2, i'm > using yum to manage updates. I've run into a dependency snafu, > > does anyone have a suggestion for satisfying this lib dependency? > > > Resolving dependencies > ....Unable to satisfy dependencies > Package glibc-dummy-fedora-core-2 needs glibc-common = 2.3.3-27.1, > this is not available. > > Thanks, Hi Chris Are you per chance running FC2 in a Virtuozzo VPS? The glibc-dummy looks like an SW-Soft package to me. Best Regards Paul Lee www.weycrest.co.uk From nils at lemonbit.nl Tue Apr 18 09:58:18 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Tue, 18 Apr 2006 11:58:18 +0200 Subject: fedora Core2 updates In-Reply-To: <652cde540604170949v2404492aq630b343fb6a5255d@mail.gmail.com> References: <652cde540604170949v2404492aq630b343fb6a5255d@mail.gmail.com> Message-ID: Chris Olds wrote: > I'm new to the list, I have some webservers running Fedora Core2, i'm > using yum to manage updates. I've run into a dependency snafu, > > does anyone have a suggestion for satisfying this lib dependency? > > Resolving dependencies > ....Unable to satisfy dependencies > Package glibc-dummy-fedora-core-2 needs glibc-common = 2.3.3-27.1, > this is not available. I'm pretty sure you're running a virtual server and this is glibc- dummy-fedora-core-2 is a package your provider put in. I usually just exclude glibc\* when installing yum on these virtual servers (put exclude=glibc\* in the updates section of your yum configuration). Nils Breunese. From sundaram at fedoraproject.org Tue Apr 18 16:57:11 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 18 Apr 2006 22:27:11 +0530 Subject: Heads up! Firefox & Mozilla In-Reply-To: References: Message-ID: <1145379432.349.148.camel@sundaram.pnq.redhat.com> On Mon, 2006-04-17 at 10:24 -0500, David Eisenstein wrote: > Hi Folks, > > Over the (HOLIDAY!) weekend, Mozilla released a new Firefox (1.0.8) fixing > a set of critical vulnerabilities. The upstream (mozilla.org) chose > *not*, however, to release the Mozilla code for 1.7.13 yet, but I am told > that the updated Mozilla will be released officially in the near future. > We may, however, be able to get our hands on the sources before then and > get it in the pipeline for QA and such. > > Some of the critical issues (potential remotely exploited code execution) > can be mitigated by turning off Javascript, but not all, as there is one > issue that I am told that can be triggered by HTML tags. From MFSA > 2006-18 , > : > > "A particular sequence of HTML tags that reliably crash Mozilla clients > was reported by an anonymous researcher via TippingPoint and the Zero > Day Initiative. The crash is due to memory corruption that can be > exploited to run arbitary code. > > "Mozilla mail clients will crash on the tag sequence, but without the > ability to run scripts to fill memory with the attack code it may not > be possible for an attacker to exploit this crash." > > These issues affect Mozilla Firefox and Thunderbird 1.x before 1.5 and > 1.0.x before 1.0.8, Mozilla Suite before 1.7.13, and SeaMonkey before 1.0, > according to CVE-2006-0749. > > Be careful out there! We'll get these out for Legacy as soon as we can. Updates have been announced for Fedora Core 4 and Fedora Core 5. It should be easy enough to rebuild it and provide them for Fedora Legacy. Rahul From Axel.Thimm at atrpms.net Tue Apr 18 18:18:53 2006 From: Axel.Thimm at atrpms.net (Axel Thimm) Date: Tue, 18 Apr 2006 20:18:53 +0200 Subject: Warning: RHL chroots on FC5/2.6.16 break Message-ID: <20060418181853.GF9692@neu.nirvana> Hi, I'm setting up an FC5/x86_64 host as a build server and stumbed over a bug that effectively kills RH7.3-RH9 chroots. After some debugging it looks like it's a kernel issue. Check the following bug entry for details and hopefully a fix: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189267 -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From deisenst at gtw.net Fri Apr 21 04:47:29 2006 From: deisenst at gtw.net (David Eisenstein) Date: Thu, 20 Apr 2006 23:47:29 -0500 (CDT) Subject: Red Hat Bugzilla changes for security? Message-ID: Hey, Jesse. Do you know anything about changes to Bugzilla that appeared to happen today around 17:00 CDT? I asked on the #Fedora-devel IRC channel, and someone said, yes, there were changes made to Bugzilla, but news of that was only broadcast internally. (I assume that means only to Red Hat people.) You're a Red Hat people now. :) Here are the symptoms I saw of today's changes: * All the bugs on my bug-list(s) that were Severity="Security" have now become Severity="Normal," and it appears that these same bugs have had a new Keyword "Security" placed in the Keyword field. A side-effect is that all the bugs listed in lists are now colored black, instead of security ones being colored red. * Selecting "Security" from the drop-down list of the Severity field is no longer an option. * The Priority field now appears to be unsettable (at least on bug- pages) and looks fixed to be "Normal". Any news on what all these changes are about? Thanks! Regards, David Eisenstein From dcbw at redhat.com Wed Apr 26 13:58:25 2006 From: dcbw at redhat.com (Dan Williams) Date: Wed, 26 Apr 2006 09:58:25 -0400 Subject: Red Hat Bugzilla changes for security? In-Reply-To: References: Message-ID: <1146059905.2280.9.camel@localhost.localdomain> On Thu, 2006-04-20 at 23:47 -0500, David Eisenstein wrote: > Hey, Jesse. Do you know anything about changes to Bugzilla that appeared > to happen today around 17:00 CDT? I asked on the #Fedora-devel IRC > channel, and someone said, yes, there were changes made to Bugzilla, but > news of that was only broadcast internally. (I assume that means only to > Red Hat people.) You're a Red Hat people now. :) > > Here are the symptoms I saw of today's changes: > > * All the bugs on my bug-list(s) that were Severity="Security" have > now become Severity="Normal," and it appears that these same bugs > have had a new Keyword "Security" placed in the Keyword field. A > side-effect is that all the bugs listed in > lists are now > colored black, instead of security ones being colored red. > > * Selecting "Security" from the drop-down list of the Severity field > is no longer an option. Correct: AI: add BZ Keyword Security AI: add BZ Priority urgent AI: add BZ Priority regression AI: delete BZ severity translation and move to severity normal AI: delete BZ severity regression and set Keyword Regression AI: delete BZ severity security and set Keyword Security > * The Priority field now appears to be unsettable (at least on bug- > pages) and looks fixed to be "Normal". AI: only @redhat.com can set BZ priority https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=91306 *** BZ priority was actually changed to be @redhat.com _AND_ people in the 'fedora_contrib' bugzilla group, not just @redhat.com. *** Ask Dave Lawrence (dkl@), Jesse, or somebody else how people in Legacy get into the fedora-contrib group if they are not there already. I think in general, just cleanups. The big danger with bugzilla is essentially feature-creep. The "process" doesn't work 100% for everyone, so everyone wants their own little fields or changes to the process. Which of course, doesn't work for everyone. Lather, rinse, repeat. Dan From gene.heskett at verizon.net Wed Apr 26 14:05:15 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Wed, 26 Apr 2006 10:05:15 -0400 Subject: Q re dhcpd.conf setup Message-ID: <200604261005.15780.gene.heskett@verizon.net> Greetings; As I get to do a bit of computer repairs from time to time, I've setup a little 5 address wide dhcpd server on my firewall box. But I had a problem last night getting a fresh winderz XP (spit) install to connect, specifically I had to enter a gateway address in the tcp/ip properties and reboot before it would connect. It was given an dhcp address according to the logs on the firewall box, but apparently not a gateway address. Should the dhcpd protocol have handled that? It is not setup in the dhcpd.conf I'm using, and I can find no references to defining a "gateway address" in any of the dhcp related manpages, which does seem a bit odd to me. It never crossed my mind when setting it for my new lappy running FC5 because I'd already set that up on a fixed address basis before converting it to BOOTPROTO=dhcp in the ifcfg-wlan0 file. The dhcpd daemon itself is running on my firewall, a rh7.3 box. A second question: How can one add a level of security by password protecting this dhcp login, makeing the client supply a correct password before the lease is negotiated? That doesn't seem to be mentioned in the manpages either. -- 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 michal at harddata.com Wed Apr 26 15:37:20 2006 From: michal at harddata.com (Michal Jaegermann) Date: Wed, 26 Apr 2006 09:37:20 -0600 Subject: Q re dhcpd.conf setup In-Reply-To: <200604261005.15780.gene.heskett@verizon.net> References: <200604261005.15780.gene.heskett@verizon.net> Message-ID: <20060426153720.GA25064@mail.harddata.com> On Wed, Apr 26, 2006 at 10:05:15AM -0400, Gene Heskett wrote: > It was given an dhcp > address according to the logs on the firewall box, but apparently not a > gateway address. > > Should the dhcpd protocol have handled that? Yes, it should and it does. > It is not setup in the dhcpd.conf I'm using, In such case clients, obviously enough, are not getting that information too. Look at 'man dhcpd.conf' and there is an example there which starts with: subnet 10.0.0.0 netmask 255.255.255.0 { option routers 10.0.0.254; <--- this is your gateway address ...... Name servers and ntpd servers and various others things can be specified there too. It is true that dhcpd documentation could be really better, and one often has to rely on various examples to figure our how to set up things, but this has nothing to do with legacy issues so this looks like a really wrong list for questions of that sort. Michal From A.Fadyushin at it-centre.ru Wed Apr 26 17:09:51 2006 From: A.Fadyushin at it-centre.ru (A.Fadyushin at it-centre.ru) Date: Wed, 26 Apr 2006 21:09:51 +0400 Subject: Q re dhcpd.conf setup Message-ID: <9F9AB50444D7084C81C27B730AD84D9E0B39E6@viewer.it-centre.ru> Yes, you can give clients the address of gateway via DHCP. The necessary option in dhcp configuration is called 'routers'. You should put in the dhcpd.conf file (usually in the subnet definition) the following line option routers ; Change the '' with the address of your gateway. If yor network is complex and includes more than gateway for the client, list on that line all the gateways addresses separated by commas (see the description of this option in 'dhcp-options' manpage). The dhcpd server does not support the client authentication at this time (howewer, it may support it in the future). You could try to make something similar to protection you need using dhcpd's ability to include conditions in its configuration (see 'dhcpd-eval' manpage). Alexey Fadyushin. Brainbench MVP for Linux. http://www.brainbench.com > -----Original Message----- > From: fedora-legacy-list-bounces at redhat.com [mailto:fedora-legacy-list- > bounces at redhat.com] On Behalf Of Gene Heskett > Sent: Wednesday, April 26, 2006 6:05 PM > To: fedora-legacy-list at redhat.com > Subject: Q re dhcpd.conf setup > > Greetings; > > As I get to do a bit of computer repairs from time to time, I've setup a > little 5 address wide dhcpd server on my firewall box. But I had a > problem last night getting a fresh winderz XP (spit) install to > connect, specifically I had to enter a gateway address in the tcp/ip > properties and reboot before it would connect. It was given an dhcp > address according to the logs on the firewall box, but apparently not a > gateway address. > > Should the dhcpd protocol have handled that? It is not setup in the > dhcpd.conf I'm using, and I can find no references to defining a > "gateway address" in any of the dhcp related manpages, which does seem > a bit odd to me. > > It never crossed my mind when setting it for my new lappy running FC5 > because I'd already set that up on a fixed address basis before > converting it to BOOTPROTO=dhcp in the ifcfg-wlan0 file. > > The dhcpd daemon itself is running on my firewall, a rh7.3 box. > > A second question: How can one add a level of security by password > protecting this dhcp login, makeing the client supply a correct > password before the lease is negotiated? That doesn't seem to be > mentioned in the manpages either. > > -- > 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. > > -- > 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 Wed Apr 26 21:49:11 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Wed, 26 Apr 2006 17:49:11 -0400 Subject: Q re dhcpd.conf setup In-Reply-To: <20060426153720.GA25064@mail.harddata.com> References: <200604261005.15780.gene.heskett@verizon.net> <20060426153720.GA25064@mail.harddata.com> Message-ID: <200604261749.11242.gene.heskett@verizon.net> On Wednesday 26 April 2006 11:37, Michal Jaegermann wrote: >On Wed, Apr 26, 2006 at 10:05:15AM -0400, Gene Heskett wrote: >> It was given an dhcp >> address according to the logs on the firewall box, but apparently >> not a gateway address. >> >> Should the dhcpd protocol have handled that? > >Yes, it should and it does. > >> It is not setup in the dhcpd.conf I'm using, > >In such case clients, obviously enough, are not getting that >information too. > >Look at 'man dhcpd.conf' and there is an example there which starts >with: > > subnet 10.0.0.0 netmask 255.255.255.0 { > option routers 10.0.0.254; <--- this is your gateway address Humm, I had that set for 192.168.1.1, which is the address of my router, which is on a different subnet from the rest of the house. When I set dhcpd.conf up, it absolutely had to know all the bloody details of both network cards in that box before it would even start the daemon, and I would have assumed, since there is only one card on the local side of this dhcp server, that info on that card only would have been sufficient to make it work. The other card only comes into play, going out toward the internet, when a request is forwarded out by iptables. My normal path is gateway 192.168.xx.1 for all local machines, with iptables sending stuff on to 192.168.1.1 (the router, and it then functions in the gateway mode) and sends the data on out to the dsl modem and vice versa for return data if its from an established connection. If this is set correctly for the NIC on the local network address, can I then do away with all the data for the subnet the router is on? It sure seems like I should be able to, it has no need of any knowledge of the outside path on the other side of iptables. And I asked this list because the firewall is a rh7.3 box yet, running a 2.4.30 kernel, but its still rh7.3... I'd say thats legacy for sure. :) At any rate, I've now changed that in the sections for both cards and I'll see it it works if I take the GATEWAY statement out of the lappies ifcfg-wlan0 file. > ...... > >Name servers and ntpd servers and various others things can be >specified there too. > >It is true that dhcpd documentation could be really better, and one >often has to rely on various examples to figure our how to set up >things, but this has nothing to do with legacy issues so this looks >like a really wrong list for questions of that sort. [...] -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From marcdeslauriers at videotron.ca Thu Apr 27 00:10:02 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 26 Apr 2006 20:10:02 -0400 Subject: Fedora Legacy Test Update Notification: tetex Message-ID: <44500BDA.70008@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-152868 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152868 2006-04-26 --------------------------------------------------------------------- Name : tetex Versions : rh73: tetex-1.0.7-47.5.legacy Versions : rh9: tetex-1.0.7-66.3.legacy Versions : fc1: tetex-2.0.2-8.2.legacy Versions : fc2: tetex-2.0.2-14FC2.3.legacy Summary : The TeX text formatting system. Description : TeTeX is an implementation of TeX for Linux or UNIX systems. TeX takes a text file and a set of formatting commands as input and creates a typesetter-independent .dvi (DeVice Independent) file as output. Usually, TeX is used in conjunction with a higher level formatting package like LaTeX or PlainTeX, since TeX by itself is not very user-friendly. --------------------------------------------------------------------- Update Information: Updated tetex packages that fix several security issues are now available. TeTeX is an implementation of TeX. TeX takes a text file and a set of formatting commands as input and creates a typesetter-independent .dvi (DeVice Independent) file as output. A number of integer overflow bugs that affect Xpdf were discovered. The teTeX package contains a copy of the Xpdf code used for parsing PDF files and is therefore affected by these bugs. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CVE-2004-0888 and CVE-2004-1125 to these issues. Several flaws were discovered in the teTeX PDF parsing library. An attacker could construct a carefully crafted PDF file that could cause teTeX to crash or possibly execute arbitrary code when opened. The Common Vulnerabilities and Exposures project assigned the names CVE-2005-3191, CVE-2005-3192, CVE-2005-3193, CVE-2005-3624, CVE-2005-3625, CVE-2005-3626, CVE-2005-3627 and CVE-2005-3628 to these issues. Users of teTeX should upgrade to these updated packages, which contain backported patches and are not vulnerable to these issues. --------------------------------------------------------------------- Changelogs rh73: * Tue Apr 25 2006 Marc Deslauriers 1.0.7-47.5.legacy - Added tetex tetex-latex and tetex-dvips to BuildPreReq! * Fri Apr 21 2006 Marc Deslauriers 1.0.7-47.4.legacy - Added patch to remove expiration check * Wed Apr 19 2006 Marc Deslauriers 1.0.7-47.3.legacy - Added missing netpbm-progs, ghostscript, ed and texinfo to BuildPrereq * Fri Mar 17 2006 Donald Maner 1.0.7-47.2.legacy - Patches for CESA-2004-007, CAN-2004-1125, CAN-2004-0888, CVE-2005-3193 rh9: * Tue Apr 25 2006 Marc Deslauriers 1.0.7-66.3.legacy - Added missing tetex, tetex-latex and tetex-dvips to BuildPreReq * Fri Apr 21 2006 Marc Deslauriers 1.0.7-66.2.legacy - Added missing ed and texinfo to BuildPrereq * Thu Mar 16 2006 Donald Maner 1.0.7-66.1.legacy - Patches for CESA-2004-007 CAN-2004-0888 CAN-2004-1125 CVE-2005-3193 (#152868) fc1: * Wed Apr 26 2006 Marc Deslauriers 2.0.2-8.2.legacy - Added missing ed, texinfo, tetex, tetex-latex and tetex-dvips to BuildPreReq * Thu Mar 16 2006 Donald Maner 2.0.2-8.1.legacy - Patches for CAN-2004-0888, CAN-2004-1125, CAN-2005-0064 and 2005-3193 fc2: * Tue Apr 25 2006 Marc Deslauriers 2.0.2-14FC2.3.legacy - Fixed release tag - Added missing tetex, tetex-latex and tetex-dvips to BuildPreReq * Thu Mar 16 2006 Donald Maner 2.0.2-14.3.legacy - Patch CVE-2005-3193 (#152868) --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 80b05b7896c5db589e960da0d73b1cd4ae120cce redhat/7.3/updates-testing/i386/tetex-1.0.7-47.5.legacy.i386.rpm 28c6022b4f6a237d4695d1f268276ec6b18dcf4c redhat/7.3/updates-testing/i386/tetex-afm-1.0.7-47.5.legacy.i386.rpm 017fa321d9834685f04819070d4f5fb799e05d01 redhat/7.3/updates-testing/i386/tetex-doc-1.0.7-47.5.legacy.i386.rpm 3303175840f2fc37c5f3f77e672eeb3fafae718a redhat/7.3/updates-testing/i386/tetex-dvilj-1.0.7-47.5.legacy.i386.rpm fa43c7cbdf02cb7d439c9beeb0e358f8c69a5f22 redhat/7.3/updates-testing/i386/tetex-dvips-1.0.7-47.5.legacy.i386.rpm 1e69a574c3d47cec5b58963387956dfc8337d6ec redhat/7.3/updates-testing/i386/tetex-fonts-1.0.7-47.5.legacy.i386.rpm bb229acb3b38ae16025d56a77c41cab939a512ac redhat/7.3/updates-testing/i386/tetex-latex-1.0.7-47.5.legacy.i386.rpm d21419415faefcb90b688f8d8dc60a57a6374bad redhat/7.3/updates-testing/i386/tetex-xdvi-1.0.7-47.5.legacy.i386.rpm f646b3f3c2ebafa6ae264f20a3f056c778bd84db redhat/7.3/updates-testing/SRPMS/tetex-1.0.7-47.5.legacy.src.rpm rh9: 26f54ca0403372b21e6fd441d9bb64073f23e7de redhat/9/updates-testing/i386/tetex-1.0.7-66.3.legacy.i386.rpm e74de7855d1d07bcef6a713f4a8735e8008f5249 redhat/9/updates-testing/i386/tetex-afm-1.0.7-66.3.legacy.i386.rpm c836a796ad112f79c84c528006a14a3ff1f99a20 redhat/9/updates-testing/i386/tetex-doc-1.0.7-66.3.legacy.i386.rpm 5d60fb658c5581eff85e589b2f71e49b4b7132b0 redhat/9/updates-testing/i386/tetex-dvips-1.0.7-66.3.legacy.i386.rpm 7ea6340fe95a63586bebc82f0869f962a178a8b2 redhat/9/updates-testing/i386/tetex-fonts-1.0.7-66.3.legacy.i386.rpm 62790eea2119387ad7c9ff4dc52aa9f24ae188f3 redhat/9/updates-testing/i386/tetex-latex-1.0.7-66.3.legacy.i386.rpm 55f398c9781e6a75c14becd57930afd91632c8fb redhat/9/updates-testing/i386/tetex-xdvi-1.0.7-66.3.legacy.i386.rpm a696b9b616557bf0d9b8ae7f884e543061e0e110 redhat/9/updates-testing/SRPMS/tetex-1.0.7-66.3.legacy.src.rpm fc1: 5560c992700e00a6f69d9ee7d2835522142fb93b fedora/1/updates-testing/i386/tetex-2.0.2-8.2.legacy.i386.rpm 416e95e8c3241c6fb239ca534dbb5654f5bb4206 fedora/1/updates-testing/i386/tetex-afm-2.0.2-8.2.legacy.i386.rpm 55adc5facf3a5c44cd5eb8b57559b03728fb7a64 fedora/1/updates-testing/i386/tetex-doc-2.0.2-8.2.legacy.i386.rpm e893ad3c1c95abd91830b43fa74138be297da25e fedora/1/updates-testing/i386/tetex-dvips-2.0.2-8.2.legacy.i386.rpm b5b4de3d22bf7696ed5194f68c271d08d912d571 fedora/1/updates-testing/i386/tetex-fonts-2.0.2-8.2.legacy.i386.rpm 57029989a0bba05d33c566bdb0df6ff921f3addd fedora/1/updates-testing/i386/tetex-latex-2.0.2-8.2.legacy.i386.rpm 857555c989ce1db61ddec8a7fdaf30a21bd1a207 fedora/1/updates-testing/i386/tetex-xdvi-2.0.2-8.2.legacy.i386.rpm f4cd83ce6594ce3a2ba6f3371d22b46435be8fbd fedora/1/updates-testing/SRPMS/tetex-2.0.2-8.2.legacy.src.rpm fc2: b02943e6007fc24a8c187d94c1511110d3d6e6e0 fedora/2/updates-testing/i386/tetex-2.0.2-14FC2.3.legacy.i386.rpm 08f84cc10ee1b4ea4a0a28b0d06cba8209c0c5f3 fedora/2/updates-testing/i386/tetex-afm-2.0.2-14FC2.3.legacy.i386.rpm ea6b0ea52e2784a8d4de505e8866b6ca24ff94dd fedora/2/updates-testing/i386/tetex-doc-2.0.2-14FC2.3.legacy.i386.rpm 61298e2841be9ce39260139387502f2caa555653 fedora/2/updates-testing/i386/tetex-dvips-2.0.2-14FC2.3.legacy.i386.rpm 42271d0bf5aab0b7b77c6ccb90723588395e06a2 fedora/2/updates-testing/i386/tetex-fonts-2.0.2-14FC2.3.legacy.i386.rpm 555556960f4e116cc1f92d57d8896284cf125935 fedora/2/updates-testing/i386/tetex-latex-2.0.2-14FC2.3.legacy.i386.rpm 23d0051001771158b6573c846d1e736308cba424 fedora/2/updates-testing/i386/tetex-xdvi-2.0.2-14FC2.3.legacy.i386.rpm c05978c27472e3a8fbfc12896e26d78ae18e065b fedora/2/updates-testing/SRPMS/tetex-2.0.2-14FC2.3.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Thu Apr 27 00:09:36 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 26 Apr 2006 20:09:36 -0400 Subject: Fedora Legacy Test Update Notification: emacs Message-ID: <44500BC0.40700@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-152898 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152898 2006-04-26 --------------------------------------------------------------------- Name : emacs Versions : rh73: emacs-21.2-3.legacy Versions : rh9: emacs-21.2-34.legacy Versions : fc1: emacs-21.3-9.2.legacy Summary : The libraries needed to run the GNU Emacs text editor. Description : Emacs is a powerful, customizable, self-documenting, modeless text editor. Emacs contains special code editing features, a scripting language (elisp), and the capability to read mail, news, and more without leaving the editor. --------------------------------------------------------------------- Update Information: Updated Emacs packages that fix a string format issue are now available. Emacs is a powerful, customizable, self-documenting, modeless text editor. Max Vozeler discovered several format string vulnerabilities in the movemail utility of Emacs. If a user connects to a malicious POP server, an attacker can execute arbitrary code as the user running emacs. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0100 to this issue. Users of Emacs are advised to upgrade to these updated packages, which contain backported patches to correct this issue. --------------------------------------------------------------------- Changelogs rh73: * Sun Mar 12 2006 Jesse Keating 21.2-3.legacy - Patch for CAN-2005-0100 (#152898) rh9: * Sun Mar 12 2006 Jesse Keating 21.2-34.legacy - Patch for CAN-2005-0100 (#152898) fc1: * Wed Mar 15 2006 David Eisenstein 21.3-9.2.legacy - Clean up the #101818 (vm/break dumper problem) workaround * Wed Mar 15 2006 David Eisenstein 21.3-9.1.legacy - Oops. Forgot to rework "make install" for the broken setarch. Now done. * Wed Mar 15 2006 David Eisenstein 21.3-9.legacy - Re-instate setarch stuff; but make use of setarch dependent upon whether or not it is broken in this given invocation of rpmbuild. Why? If setarch doesn't break, it is probably needed and will be used for the bugzilla #101818 issue. If setarch *does* break, then it is likely breaking because it is operating within another setarch (FC1's setarch breaks under that circumstance), such as when being built by plague/mock. In that instance, it is not needed. * Sun Mar 12 2006 Jesse Keating 21.3-8.legacy - Patch for CAN-2005-0100 (#152898) - Remove setarch stuff, not needed in new build system - Added builddep on autoconf213 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 4441c55cfe91aabf2203d68bcbc0cf2bbd5f8798 redhat/7.3/updates-testing/i386/emacs-21.2-3.legacy.i386.rpm 33e802e8f306f13519dd2c3f045eb9efe5e4680a redhat/7.3/updates-testing/i386/emacs-el-21.2-3.legacy.i386.rpm f6293ffe1c51c3bb31f1b3941da0938d8a98eff2 redhat/7.3/updates-testing/i386/emacs-leim-21.2-3.legacy.i386.rpm a5767f1100037b49602abb80831fa22da135c081 redhat/7.3/updates-testing/SRPMS/emacs-21.2-3.legacy.src.rpm rh9: ae56dba68d59f5d49105f7afb6918ac945ad8b01 redhat/9/updates-testing/i386/emacs-21.2-34.legacy.i386.rpm 84047366c8488fa3c95070466b1bd20ce5d8687a redhat/9/updates-testing/i386/emacs-el-21.2-34.legacy.i386.rpm 8eb8449c456e7d475157992c3e6f8bc4bdf64c7b redhat/9/updates-testing/i386/emacs-leim-21.2-34.legacy.i386.rpm 4cf0ba484c3ab93210d186beb3c79b68b4e56984 redhat/9/updates-testing/SRPMS/emacs-21.2-34.legacy.src.rpm fc1: d56260f010b4603c89516ccf2ddd09c33c8c53c4 fedora/1/updates-testing/i386/emacs-21.3-9.2.legacy.i386.rpm 6bf7cb9bacc6c0f9374849fa4507ededa13193cf fedora/1/updates-testing/i386/emacs-el-21.3-9.2.legacy.i386.rpm fb23df114772b6c758499401751dfc389e2e1d88 fedora/1/updates-testing/i386/emacs-leim-21.3-9.2.legacy.i386.rpm 1a1133d917d4993c92a03c30ba08e8916c6a7bfe fedora/1/updates-testing/SRPMS/emacs-21.3-9.2.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From gene.heskett at verizon.net Thu Apr 27 00:11:04 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Wed, 26 Apr 2006 20:11:04 -0400 Subject: Q re dhcpd.conf setup In-Reply-To: <9F9AB50444D7084C81C27B730AD84D9E0B39E6@viewer.it-centre.ru> References: <9F9AB50444D7084C81C27B730AD84D9E0B39E6@viewer.it-centre.ru> Message-ID: <200604262011.04219.gene.heskett@verizon.net> On Wednesday 26 April 2006 13:09, A.Fadyushin at it-centre.ru wrote: >Yes, you can give clients the address of gateway via DHCP. The > necessary option in dhcp configuration is called 'routers'. You > should put in the dhcpd.conf file (usually in the subnet definition) > the following line > >option routers ; > >Change the '' with the address of your gateway. If > yor network is complex and includes more than gateway for the client, > list on that line all the gateways addresses separated by commas (see > the description of this option in 'dhcp-options' manpage). > >The dhcpd server does not support the client authentication at this > time (howewer, it may support it in the future). You could try to > make something similar to protection you need using dhcpd's ability > to include conditions in its configuration (see 'dhcpd-eval' > manpage). > There doesn't seem to be a man 'dhcpd-eval' on that box. And whatever I've done, there is no response in the logs on that box for a dhcp negotiation session. Here is the last restart of the dhcpd daemon as it shows in /var/log/messages: Apr 26 19:34:43 gene dhcpd: Apr 26 19:34:43 gene dhcpd: Listening on Socket/eth1/192.168.71.0 Apr 26 19:34:43 gene dhcpd: Sending on Socket/eth1/192.168.71.0 Apr 26 19:34:43 gene dhcpd: Listening on Socket/eth0/192.168.1.0 Apr 26 19:34:43 gene dhcpd: Sending on Socket/eth0/192.168.1.0 Apr 26 19:34:43 gene dhcpd: Listening on Socket/eth1/192.168.71.0 Apr 26 19:34:43 gene dhcpd: Sending on Socket/eth1/192.168.71.0 Apr 26 19:34:43 gene dhcpd: Listening on Socket/eth0/192.168.1.0 Apr 26 19:34:43 gene dhcpd: Sending on Socket/eth0/192.168.1.0 Apr 26 19:34:43 gene dhcpd: dhcpd startup succeeded Here is the networks lashup: HP-laptopwap11[8-port-switch]firewall-1.92.168.71.1firewall-191.168.1.1[DSL-modem] Here is the current, I think identical to what WAS working partially I think, dhcpd.conf on the firewall box: subnet 192.168.71.0 netmask 255.255.255.0 { # --- default gateway option routers 192.168.1.1; option subnet-mask 255.255.255.0; option nis-domain "coyote.den"; option domain-name "coyote.den"; option domain-name-servers 192.168.71.1; option time-offset -18000; # Eastern Standard Time # option ntp-servers 192.168.1.1; # option netbios-name-servers 192.168.1.1; # --- Selects point-to-point node (default is hybrid). Don't change this unless # -- you understand Netbios very well # option netbios-node-type 2; range dynamic-bootp 192.168.71.101 192.168.71.105; range 192.168.71.101 192.168.71.105; default-lease-time 21600; max-lease-time 43200; # we want the nameserver to appear at a fixed address host ns { next-server 192.168.71.1; #gene.coyote.den; hardware ethernet 00:09:5B:07:7E:7D; fixed-address 192.168.71.1; } } # I've NDI why I even need this section, nothing comes from there that # needs to have access to dhcpd services. subnet 192.168.1.0 netmask 255.255.255.0 { option routers 192.168.1.1; option subnet-mask 255.255.255.0; option nis-domain "coyote.den"; option domain-name "coyote.den"; option domain-name-servers 192.168.71.1; host ns { next-server 192.168.1.1; hardware ethernet 00:40:33:57:28:51; fixed-address 192.168.1.100; } } ----------------------------- There is more than just the routers wrong in the above file, as I did try it at 71.1, and that broke it even when converted back to 1.1. Here is the currently working ifcfg-wlan0 from diablo[HP laptop] [root at diablo network-scripts]# cat ifcfg-wlan0 DEVICE=wlan0 ONBOOT=yes BOOTPROTO=none TYPE=Wireless MODE=Managed ESSID=ICECAP4NIGHTCAP CHANNEL=6 IPADDR=192.168.71.6 DOMAIN=coyote.den NETMASK=255.255.255.0 GATEWAY=192.168.71.1 USERCTL=no PEERDNS=no IPV6INIT=no RATE=Auto DHCP_HOSTNAME=diablo.coyote.den HWADDR=00:14:A5:75:32:C9 ---------------------------- Now, if I change to BOOTPROTO=dhcp and comment out the gateway & local addresses, then restart the network on the lappy, there is no query for dhcp showing in the firewalls logs. I'm obviously in over my head here as that was working this morning before I took it to the tv station and tried and failed to connect to their wifi network, for about 2 hours of the infinite monkeys routine. The wap11 currently has an address, obtained before trying to figure out howto dhcp connect to a new network. XP on that same lappy even remembered the key from the session before, so it Just Worked(TM) when I tried it today. Is the above enough to see what it is I need to do? -- 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 lmilligan at co.walton.ga.us Wed Apr 26 15:03:37 2006 From: lmilligan at co.walton.ga.us (Lamar Milligan) Date: Wed, 26 Apr 2006 11:03:37 -0400 Subject: Q re dhcpd.conf setup In-Reply-To: <200604261005.15780.gene.heskett@verizon.net> Message-ID: > -----Original Message----- > From: fedora-legacy-list-bounces at redhat.com > [mailto:fedora-legacy-list-bounces at redhat.com]On Behalf Of Gene Heskett > Sent: Wednesday, April 26, 2006 10:05 AM > To: fedora-legacy-list at redhat.com > Subject: Q re dhcpd.conf setup > > > Greetings; > > As I get to do a bit of computer repairs from time to time, I've setup a > little 5 address wide dhcpd server on my firewall box. But I had a > problem last night getting a fresh winderz XP (spit) install to > connect, specifically I had to enter a gateway address in the tcp/ip > properties and reboot before it would connect. It was given an dhcp > address according to the logs on the firewall box, but apparently not a > gateway address. > > Should the dhcpd protocol have handled that? It is not setup in the > dhcpd.conf I'm using, and I can find no references to defining a > "gateway address" in any of the dhcp related manpages, which does seem > a bit odd to me. You can add a line similar to this: option routers 1.2.3.4; Good luck. > It never crossed my mind when setting it for my new lappy running FC5 > because I'd already set that up on a fixed address basis before > converting it to BOOTPROTO=dhcp in the ifcfg-wlan0 file. > > The dhcpd daemon itself is running on my firewall, a rh7.3 box. > > A second question: How can one add a level of security by password > protecting this dhcp login, makeing the client supply a correct > password before the lease is negotiated? That doesn't seem to be > mentioned in the manpages either. > > -- > 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. > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From jason at jazbo.dyndns.org Thu Apr 27 10:30:58 2006 From: jason at jazbo.dyndns.org (Jason A. Smith) Date: Thu, 27 Apr 2006 06:30:58 -0400 Subject: Recent glibc updates are not on the Advisories web page. Message-ID: <1146133855.13325.11.camel@localhost> Last month's glibc updates for RH-7.3 & RH-9, which contain the recent daylight savings rule enhancements, are not listed on the Advisories web pages: http://www.fedoralegacy.org/updates/RH9/ http://www.fedoralegacy.org/updates/RH7.3/ The updates were announced to the mailing lists though: https://www.redhat.com/archives/fedora-legacy-announce/2006-March/msg00014.html http://www.redhat.com/archives/fedora-legacy-list/2006-March/msg00172.html ~Jason From gene.heskett at verizon.net Thu Apr 27 15:14:29 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Thu, 27 Apr 2006 11:14:29 -0400 Subject: Q re dhcpd.conf setup In-Reply-To: References: Message-ID: <200604271114.30090.gene.heskett@verizon.net> On Wednesday 26 April 2006 11:03, Lamar Milligan wrote: >> -----Original Message----- >> From: fedora-legacy-list-bounces at redhat.com >> [mailto:fedora-legacy-list-bounces at redhat.com]On Behalf Of Gene >> Heskett Sent: Wednesday, April 26, 2006 10:05 AM >> To: fedora-legacy-list at redhat.com >> Subject: Q re dhcpd.conf setup >> >> >> Greetings; >> >> As I get to do a bit of computer repairs from time to time, I've >> setup a little 5 address wide dhcpd server on my firewall box. But >> I had a problem last night getting a fresh winderz XP (spit) install >> to connect, specifically I had to enter a gateway address in the >> tcp/ip properties and reboot before it would connect. It was given >> an dhcp address according to the logs on the firewall box, but >> apparently not a gateway address. >> >> Should the dhcpd protocol have handled that? It is not setup in the >> dhcpd.conf I'm using, and I can find no references to defining a >> "gateway address" in any of the dhcp related manpages, which does >> seem a bit odd to me. > >You can add a line similar to this: > > option routers 1.2.3.4; > Thats in there. And I got tired of fighting with the daemons insistance on knowing the full details of both nics, which furnishes a path to bypass iptables that I shut it down on that machine and now have ot trying to run on this box. But the lappy isn't even asking for dhcp even though the ifcfg-wlan0 is setup to use it. So I'm slowly going crazy here trying to make it work when nothing I do seems to effect it other than hardcoding everything in ifcfg-wlan0. The it works, but how can I do discovery on a new net if it never asks for service? >Good luck. > I seem to have run fresh out of that. >> It never crossed my mind when setting it for my new lappy running >> FC5 because I'd already set that up on a fixed address basis before >> converting it to BOOTPROTO=dhcp in the ifcfg-wlan0 file. >> >> The dhcpd daemon itself is running on my firewall, a rh7.3 box. >> >> A second question: How can one add a level of security by password >> protecting this dhcp login, makeing the client supply a correct >> password before the lease is negotiated? That doesn't seem to be >> mentioned in the manpages either. >> >> -- >> 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. >> >> -- >> fedora-legacy-list mailing list >> fedora-legacy-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-legacy-list >> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. -- 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 A.Fadyushin at it-centre.ru Thu Apr 27 17:11:20 2006 From: A.Fadyushin at it-centre.ru (A.Fadyushin at it-centre.ru) Date: Thu, 27 Apr 2006 21:11:20 +0400 Subject: Q re dhcpd.conf setup Message-ID: <9F9AB50444D7084C81C27B730AD84D9E0B3B0B@viewer.it-centre.ru> > -----Original Message----- > From: fedora-legacy-list-bounces at redhat.com [mailto:fedora-legacy-list- > bounces at redhat.com] On Behalf Of Gene Heskett > Sent: Thursday, April 27, 2006 4:11 AM > To: Discussion of the Fedora Legacy Project > Subject: Re: Q re dhcpd.conf setup > > On Wednesday 26 April 2006 13:09, A.Fadyushin at it-centre.ru wrote: > >Yes, you can give clients the address of gateway via DHCP. The > > necessary option in dhcp configuration is called 'routers'. You > > should put in the dhcpd.conf file (usually in the subnet definition) > > the following line > > > >option routers ; > > > >Change the '' with the address of your gateway. If > > yor network is complex and includes more than gateway for the client, > > list on that line all the gateways addresses separated by commas (see > > the description of this option in 'dhcp-options' manpage). > > > >The dhcpd server does not support the client authentication at this > > time (howewer, it may support it in the future). You could try to > > make something similar to protection you need using dhcpd's ability > > to include conditions in its configuration (see 'dhcpd-eval' > > manpage). > > > There doesn't seem to be a man 'dhcpd-eval' on that box. Oops, I mistyped the manpage name - it should be 'dhcp-eval', not 'dhcpd-eval'. > > And whatever I've done, there is no response in the logs on that box for > a dhcp negotiation session. Here is the last restart of the dhcpd > daemon as it shows in /var/log/messages: > Apr 26 19:34:43 gene dhcpd: > Apr 26 19:34:43 gene dhcpd: Listening on Socket/eth1/192.168.71.0 > Apr 26 19:34:43 gene dhcpd: Sending on Socket/eth1/192.168.71.0 > Apr 26 19:34:43 gene dhcpd: Listening on Socket/eth0/192.168.1.0 > Apr 26 19:34:43 gene dhcpd: Sending on Socket/eth0/192.168.1.0 > Apr 26 19:34:43 gene dhcpd: Listening on Socket/eth1/192.168.71.0 > Apr 26 19:34:43 gene dhcpd: Sending on Socket/eth1/192.168.71.0 > Apr 26 19:34:43 gene dhcpd: Listening on Socket/eth0/192.168.1.0 > Apr 26 19:34:43 gene dhcpd: Sending on Socket/eth0/192.168.1.0 > Apr 26 19:34:43 gene dhcpd: dhcpd startup succeeded > > Here is the networks lashup: > > HP-laptopwap11[8-port-switch]firewall- > 1.92.168.71.1firewall-191.168.1.1[DSL-modem] > > Here is the current, I think identical to what WAS working partially I > think, dhcpd.conf on the firewall box: > subnet 192.168.71.0 netmask 255.255.255.0 { > # --- default gateway > option routers 192.168.1.1; The router should be in 192.168.71.0 network, not in 192.168.1.0 network. > option subnet-mask 255.255.255.0; > > option nis-domain "coyote.den"; > option domain-name "coyote.den"; > option domain-name-servers 192.168.71.1; > > option time-offset -18000; # Eastern Standard Time > # option ntp-servers 192.168.1.1; > # option netbios-name-servers 192.168.1.1; > # --- Selects point-to-point node (default is hybrid). Don't change this > unless > # -- you understand Netbios very well > # option netbios-node-type 2; > > range dynamic-bootp 192.168.71.101 192.168.71.105; > range 192.168.71.101 192.168.71.105; > default-lease-time 21600; > max-lease-time 43200; > > # we want the nameserver to appear at a fixed address > host ns { > next-server 192.168.71.1; #gene.coyote.den; > hardware ethernet 00:09:5B:07:7E:7D; > fixed-address 192.168.71.1; > } > } > > # I've NDI why I even need this section, nothing comes from there that > # needs to have access to dhcpd services. > subnet 192.168.1.0 netmask 255.255.255.0 { > option routers 192.168.1.1; > option subnet-mask 255.255.255.0; > option nis-domain "coyote.den"; > option domain-name "coyote.den"; > option domain-name-servers 192.168.71.1; > host ns { > next-server 192.168.1.1; > hardware ethernet 00:40:33:57:28:51; > fixed-address 192.168.1.100; > } > } > ----------------------------- > There is more than just the routers wrong in the above file, as I did > try it at 71.1, and that broke it even when converted back to 1.1. > > Here is the currently working ifcfg-wlan0 from diablo[HP laptop] > > [root at diablo network-scripts]# cat ifcfg-wlan0 > DEVICE=wlan0 > ONBOOT=yes > BOOTPROTO=none > TYPE=Wireless > MODE=Managed > ESSID=ICECAP4NIGHTCAP > CHANNEL=6 > IPADDR=192.168.71.6 > DOMAIN=coyote.den > NETMASK=255.255.255.0 > GATEWAY=192.168.71.1 > USERCTL=no > PEERDNS=no > IPV6INIT=no > RATE=Auto > DHCP_HOSTNAME=diablo.coyote.den > HWADDR=00:14:A5:75:32:C9 > ---------------------------- > Now, if I change to BOOTPROTO=dhcp > and comment out the gateway & local addresses, then restart the network > on the lappy, there is no query for dhcp showing in the firewalls logs. It seems that you have a problem with DHCP client, not with DHCP server configuration because you do not see the DHCH requests in the server logs. The client just does not ask for its network settings. Try to comment out all parameters in ifcfg-wlan0 on the client, except for DEVICE, ONBOOT and BOOTPROTO. > > I'm obviously in over my head here as that was working this morning > before I took it to the tv station and tried and failed to connect to > their wifi network, for about 2 hours of the infinite monkeys routine. > > The wap11 currently has an address, obtained before trying to figure out > howto dhcp connect to a new network. XP on that same lappy even > remembered the key from the session before, so it Just Worked(TM) when > I tried it today. > > Is the above enough to see what it is I need to do? > Alexey Fadyushin. Brainbench MVP for Linux. http://www.brainbench.com From gene.heskett at verizon.net Thu Apr 27 22:55:20 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Thu, 27 Apr 2006 18:55:20 -0400 Subject: Q re dhcpd.conf setup In-Reply-To: <9F9AB50444D7084C81C27B730AD84D9E0B3B0B@viewer.it-centre.ru> References: <9F9AB50444D7084C81C27B730AD84D9E0B3B0B@viewer.it-centre.ru> Message-ID: <200604271855.20818.gene.heskett@verizon.net> On Thursday 27 April 2006 13:11, A.Fadyushin at it-centre.ru wrote: >> -----Original Message----- >> From: fedora-legacy-list-bounces at redhat.com > >[mailto:fedora-legacy-list- > >> bounces at redhat.com] On Behalf Of Gene Heskett >> Sent: Thursday, April 27, 2006 4:11 AM >> To: Discussion of the Fedora Legacy Project >> Subject: Re: Q re dhcpd.conf setup >> >> On Wednesday 26 April 2006 13:09, A.Fadyushin at it-centre.ru wrote: >> >Yes, you can give clients the address of gateway via DHCP. The >> > necessary option in dhcp configuration is called 'routers'. You >> > should put in the dhcpd.conf file (usually in the subnet >> > definition) the following line >> > >> >option routers ; >> > >> >Change the '' with the address of your gateway. If >> > yor network is complex and includes more than gateway for the > >client, > >> > list on that line all the gateways addresses separated by commas > >(see > >> > the description of this option in 'dhcp-options' manpage). >> > >> >The dhcpd server does not support the client authentication at this >> > time (howewer, it may support it in the future). You could try to >> > make something similar to protection you need using dhcpd's >> > ability to include conditions in its configuration (see >> > 'dhcpd-eval' manpage). >> >> There doesn't seem to be a man 'dhcpd-eval' on that box. > >Oops, I mistyped the manpage name - it should be 'dhcp-eval', not >'dhcpd-eval'. > >> And whatever I've done, there is no response in the logs on that box > >for > >> a dhcp negotiation session. Here is the last restart of the dhcpd >> daemon as it shows in /var/log/messages: >> Apr 26 19:34:43 gene dhcpd: >> Apr 26 19:34:43 gene dhcpd: Listening on Socket/eth1/192.168.71.0 >> Apr 26 19:34:43 gene dhcpd: Sending on Socket/eth1/192.168.71.0 >> Apr 26 19:34:43 gene dhcpd: Listening on Socket/eth0/192.168.1.0 >> Apr 26 19:34:43 gene dhcpd: Sending on Socket/eth0/192.168.1.0 >> Apr 26 19:34:43 gene dhcpd: Listening on Socket/eth1/192.168.71.0 >> Apr 26 19:34:43 gene dhcpd: Sending on Socket/eth1/192.168.71.0 >> Apr 26 19:34:43 gene dhcpd: Listening on Socket/eth0/192.168.1.0 >> Apr 26 19:34:43 gene dhcpd: Sending on Socket/eth0/192.168.1.0 >> Apr 26 19:34:43 gene dhcpd: dhcpd startup succeeded >> >> Here is the networks lashup: >> >> HP-laptopwap11[8-port-switch]firewall- >> 1.92.168.71.1firewall-191.168.1.1[DSL-modem] >> >> Here is the current, I think identical to what WAS working partially >> I think, dhcpd.conf on the firewall box: >> subnet 192.168.71.0 netmask 255.255.255.0 { >> # --- default gateway >> option routers 192.168.1.1; > >The router should be in 192.168.71.0 network, not in 192.168.1.0 >network. > >> option subnet-mask 255.255.255.0; >> >> option nis-domain "coyote.den"; >> option domain-name "coyote.den"; >> option domain-name-servers 192.168.71.1; >> >> option time-offset -18000; # Eastern Standard > >Time > >> # option ntp-servers 192.168.1.1; >> # option netbios-name-servers 192.168.1.1; >> # --- Selects point-to-point node (default is hybrid). Don't change > >this > >> unless >> # -- you understand Netbios very well >> # option netbios-node-type 2; >> >> range dynamic-bootp 192.168.71.101 192.168.71.105; >> range 192.168.71.101 192.168.71.105; >> default-lease-time 21600; >> max-lease-time 43200; >> >> # we want the nameserver to appear at a fixed address >> host ns { >> next-server 192.168.71.1; #gene.coyote.den; >> hardware ethernet 00:09:5B:07:7E:7D; >> fixed-address 192.168.71.1; >> } >> } >> >> # I've NDI why I even need this section, nothing comes from there >> that # needs to have access to dhcpd services. >> subnet 192.168.1.0 netmask 255.255.255.0 { >> option routers 192.168.1.1; >> option subnet-mask 255.255.255.0; >> option nis-domain "coyote.den"; >> option domain-name "coyote.den"; >> option domain-name-servers 192.168.71.1; >> host ns { >> next-server 192.168.1.1; >> hardware ethernet 00:40:33:57:28:51; >> fixed-address 192.168.1.100; >> } >> } >> ----------------------------- >> There is more than just the routers wrong in the above file, as I >> did try it at 71.1, and that broke it even when converted back to >> 1.1. >> >> Here is the currently working ifcfg-wlan0 from diablo[HP laptop] >> >> [root at diablo network-scripts]# cat ifcfg-wlan0 >> DEVICE=wlan0 >> ONBOOT=yes >> BOOTPROTO=none BOOTPROTO=dhcp >> TYPE=Wireless >> MODE=Managed >> ESSID=ICECAP4NIGHTCAP >> CHANNEL=6 IPADDR=192.168.71.6<--wrong, needed to be wap11's IP of 192.168.71.102 The wap11 is the other end of the radio link, connecting to the switch and the rest of the local ethernet network. >> DOMAIN=coyote.den >> NETMASK=255.255.255.0 >> GATEWAY=192.168.71.1 >> USERCTL=no USRCTL=yes >> PEERDNS=no PEERDNS=yes >> IPV6INIT=no >> RATE=Auto >> DHCP_HOSTNAME=diablo.coyote.den >> HWADDR=00:14:A5:75:32:C9 >> ---------------------------- >> Now, if I change to BOOTPROTO=dhcp >> and comment out the gateway & local addresses, then restart the And it all works. >network > >> on the lappy, there is no query for dhcp showing in the firewalls > >logs. > >It seems that you have a problem with DHCP client, not with DHCP > server configuration because you do not see the DHCH requests in the > server logs. The client just does not ask for its network settings. > Try to comment out all parameters in ifcfg-wlan0 on the client, > except for DEVICE, ONBOOT and BOOTPROTO. Twasn't the dhcpd although I've moved it to a machine with only one nic in it, making the config a heck of a lot cleaner. >> I'm obviously in over my head here as that was working this morning >> before I took it to the tv station and tried and failed to connect >> to their wifi network, for about 2 hours of the infinite monkeys >> routine. >> >> The wap11 currently has an address, obtained before trying to figure > >out > >> howto dhcp connect to a new network. XP on that same lappy even >> remembered the key from the session before, so it Just Worked(TM) >> when I tried it today. >> >> Is the above enough to see what it is I need to do? > >Alexey Fadyushin. >Brainbench MVP for Linux. >http://www.brainbench.com > >-- >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 Axel.Thimm at ATrpms.net Fri Apr 28 07:53:34 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 28 Apr 2006 09:53:34 +0200 Subject: Security Response Team / EOL In-Reply-To: <1146203217.20233.15.camel@thl.ct.heise.de> References: <1146203217.20233.15.camel@thl.ct.heise.de> Message-ID: <20060428075334.GB5957@neu.nirvana> On Fri, Apr 28, 2006 at 07:46:56AM +0200, Thorsten Leemhuis wrote: > When a Fedora Core release reaches Maintenance state (such as Fedora > Core 3 reached when Fedora Core 5 Test 2 was released), the > corresponding release of Fedora Extras will also enter a Maintenance > state. In this state maintainers will be allowed to issue updates to > existing packages, but Maintainers are strongly urged to only issue > severe bugfix or security fixes. New software versions should be avoided > except when necessary for resolving issues with the the current version. Currently there are five releases in maintenance mode, aka managed by fedora legacy. Maybe in the future this will decrease, but somehow whenever legacy tries to kick out a release some people start crying and it is kept. But let's assume 3-4 releases on the average in the future. For a package maintainer that covers a package that has lived in these releases this means 3-4 additional versions/specifles of the software to maintain, e.g. (hopfully only) one version for the current 2 active FCs and in the worse case 3-4 further distinct specfiles to look out for. I guess the packager will wish that upcoming releases will fix severe bugs or security flaws to allow him to sync all his trees ;) To cut a long story short: I would soften the above requirement and make it a recommendation or similar. And I would also include the legacy folks in this discussion (Cc'd), as all of this very much depends on the EOL/concurrent releases policies there. Some (unfinished?) thoughts about extras in legacy have already been discussed in the past, and the outcome may prove valuable. I also think that the organisational separation of core vs extras blurs in legacy mode, as legacy for core is already in a community driven entity like extras is, so convergence is easier in that domain. legacy is a community security response team for core and creating a second for extras doesn't sound right, it's better to consolidate forces. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Apr 28 20:43:30 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 28 Apr 2006 16:43:30 -0400 Subject: Security Response Team / EOL In-Reply-To: <20060428075334.GB5957@neu.nirvana> References: <1146203217.20233.15.camel@thl.ct.heise.de> <20060428075334.GB5957@neu.nirvana> Message-ID: <1146255281.13972.2.camel@ender> On Fri, 2006-04-28 at 09:53 +0200, Axel Thimm wrote: > Currently there are five releases in maintenance mode, aka managed by > fedora legacy. Maybe in the future this will decrease, but somehow > whenever legacy tries to kick out a release some people start crying > and it is kept. But let's assume 3-4 releases on the average in the > future. Lets not assume that. I'm tired of hearing people cry, and releases will get dropped, and a strict adherence to the timeline will be met. It was a mistake of mine to ever extend the life beyond what we set forth. > > I also think that the organisational separation of core vs extras > blurs in legacy mode, as legacy for core is already in a community > driven entity like extras is, so convergence is easier in that > domain. legacy is a community security response team for core and > creating a second for extras doesn't sound right, it's better to > consolidate forces. Because we're in the process of moving our stuff over to Extras like land, so that we could possibly get folded into the Extras version of it, or it could all fall under our name, but for now a separate team is needed. Also if we ever get to the point where all of Fedora lives outside, then the core/extras line is really blurred and then we can really merge the teams. That said, I wouldn't be surprised to see Legacy folks in the Extras team (and hopefully vice versa). -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- -- fedora-extras-list mailing list fedora-extras-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-extras-list From Axel.Thimm at ATrpms.net Sat Apr 29 16:59:12 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 29 Apr 2006 18:59:12 +0200 Subject: Confusing use of EOL term Message-ID: <20060429165912.GK10223@neu.nirvana> Hi, threads that use the word "EOL" (and "support") very soon come to the point where people use different notions of them and the thread's signal to noise ratio drops. Historically EOL was used for the point in time when RH passed maintenance of RHL or FC over to Fedora Legacy. But later it was considered bad marketing to call a security maintained release as already EOL'd. Currently the most prominent URL mentioning EOL and Fedora under redhat.com is the project definition of Fedora Legacy, which uses EOL in the above way and calls the "total EOL" an effective lifetime. http://fedora.redhat.com/About/Projects/legacy.html says: | The goal of The Fedora Legacy Project is to work with the Linux | community to provide security and critical bug fix errata packages | for select Red Hat Linux and Fedora Core releases after they reach | their EOL, thus extending their effective lifetime in environments | where frequent upgrades are not possible or desirable. I think these definitions need to be sorted out and used consistently everywhere. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sat Apr 29 17:11:33 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 29 Apr 2006 13:11:33 -0400 Subject: Confusing use of EOL term In-Reply-To: <20060429165912.GK10223@neu.nirvana> References: <20060429165912.GK10223@neu.nirvana> Message-ID: <1146330324.13972.34.camel@ender> On Sat, 2006-04-29 at 18:59 +0200, Axel Thimm wrote: > http://fedora.redhat.com/About/Projects/legacy.html says: > | The goal of The Fedora Legacy Project is to work with the Linux > | community to provide security and critical bug fix errata packages > | for select Red Hat Linux and Fedora Core releases after they reach > | their EOL, thus extending their effective lifetime in environments > | where frequent upgrades are not possible or desirable. > > I think these definitions need to be sorted out and used consistently > everywhere. You are very correct. I can change this one right now, and longer term we're moving all this content over to fedoraproject.org so that it can be changed more easily. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- -- fedora-extras-list mailing list fedora-extras-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-extras-list