Bug 186277
| Summary: | CVE-2006-0058 Sendmail race condition issue | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Retired] Fedora Legacy | Reporter: | Marc Bejarano <bugzilla.redhat> | ||||||
| Component: | sendmail | Assignee: | Fedora Legacy Bugs <bugs> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | |||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | high | ||||||||
| Version: | unspecified | CC: | bbaetz, curtis, deisenst, eric.rostetter, klk+redhat, luiz, pekkas, russ+bugzilla-redhat, sheltren, steven.marzec | ||||||
| Target Milestone: | --- | Keywords: | Security | ||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | rh73, rh90, 1, 2, 3 | ||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2006-04-05 00:28:07 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Marc Bejarano
2006-03-22 17:35:54 UTC
From CERT VU#834865[1]: The Problem Sendmail contains a race condition caused by the improper handling of asynchronous signals. In particular, by forcing SMTP server to have an I/O timeout at exactly the correct instant, the attacker may be able to execute arbitrary code with the privileges of the Sendmail process. More information is available in the Sendmail version 8.13.6 release page[2] and the Sendmail MTA Security Vulnerability Advisory[3]. Versions of Sendmail prior to 8.13.6 are affected. II. Impact A remote, unauthenticated attacker could execute arbitrary code with the privileges of the Sendmail process. If Sendmail is running as root, the attacker could take complete control of an affected system. III. Solution Upgrade This issue is corrected in Sendmail version 8.13.6[2]. Patches to correct this issue in Sendmail versions 8.12.11[4] and 8.13.5[5] are also available. Refer to the Sendmail MTA Security Vulnerability Advisory[6] for steps to reduce the impact of this vulnerability. References: 1. CERT VU#834865: <http://www.kb.cert.org/vuls/id/834865> 2. Sendmail 8.13.6 release page: <http://www.sendmail.org/8.13.6.html> 3. Vulnerability Advisory: <http://www.sendmail.com/company/advisory/> 4. ftp://ftp.sendmail.org/pub/sendmail/8.12.11.p0 5. ftp://ftp.sendmail.org/pub/sendmail/8.13.5.p0 6. http://www.sendmail.com/company/advisory/#mitigation Also: * CVE-2006-0058: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0058 Red Hat issued RHSA-2006-0264 and RHSA-2006-0265 today for these issues. <http://rhn.redhat.com/errata/RHSA-2006-0265.html> RHEL 2.1 <http://rhn.redhat.com/errata/RHSA-2006-0264.html> RHEL 3 & 4. All Legacy distros are affected. Affected packages for each distro: * RHL 7.3: sendmail-8.11.6-27.73 * RHL 9: sendmail-8.12.8-9.90 * FC1: sendmail-8.12.10-1.1.1 * FC2: sendmail-8.12.11-4.6 * FC3: sendmail-8.13.1-2 In order to fix RHL7.3, RHL9 and FC1, we will need to upgrade those versions to sendmail-8.12.11 in order to apply the patch available from upstream. Or we might just want to re-spin the RHEL 2.1 package, at least for RHL 7.3. Perhaps we can respin the RHEL 3 package for RHL9, FC1, & FC2. My suggestion for FC3 is that we just implement sendmail-8.13.6 instead of upgrading to sendmail-8.13.5 and patching. Here's the text from RHSA-2006-0265 advisory (for RHEL 2.1): "A flaw in the handling of asynchronous signals was discovered in Sendmail. A remote attacker may be able to exploit a race condition to execute arbitrary code as root. The Common Vulnerabilities and Exposures project assigned the name CVE-2006-0058 to this issue. "By default on Red Hat Enterprise Linux 2.1, Sendmail is configured to only accept connections from the local host. Therefore only users who have configured Sendmail to listen to remote hosts would be able to be remotely exploited by this vulnerability. "In order to correct this issue for Red Hat Enterprise Linux 2.1 users, it was necessary to upgrade the version of Sendmail from 8.11 as originally shipped to Sendmail 8.12 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. After updating to these packages, users should pay close attention to their sendmail logs to ensure that the upgrade completed sucessfully." I take back my suggestion for FC3. RHEL 4 released sendmail-8.13.1 today, presumably patched for this problem, so we could just use those sources. David, thanks for the research. I'll look into backporting RHEL patches, and hopefully post updated packages very soon. Note that the sendmail patch doesn't work on rh73 if you build with ssl support, because the SSL version that comes with that doesn't provide SSL_get_[rw]fd. Does anyone know what the 'gcc296' patch in the RHEL2 sendmail package is meant to fix? changelog doesn't point to anything specific, and we've been running stock 8.12.11 on rh7.3 (compiled with gcc296) for the last year or so without issues. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Packages for sendmail problem CVE-2006-0058 Sendmail race condition issue RHL7.3 package pulled directly from RHEL2.1. 7.3's sendmail was too old for the patch, so like RHEL2.1 did, pulled in the newer version but built it into compat mode. RHL9, FC1, and FC2's package are all the same, based on FC2's sendmail with the patch applied, and FC1 and RHL9s packages provide /etc/alias and RHL9's is built w/out -fpie (not available in the compiler). FC3's package just adds the patch. All packages add BuildRequires: groff so that man pages will build. These should get extra testing due to version upgrades necessary to apply patches. http://geek.j2solutions.net/rpms/legacy/sendmail/ 9442f310b50ab21962feb69004324752a705e598 ./7.3/SRPM/sendmail-8.12.11-4.22.8.legacy.src.rpm 03e40f075a5fe6793f8e7b5dc1fad24d8aeca411 ./7.3/i386/sendmail-devel-8.12.11-4.22.8.legacy.i386.rpm ccd79b18310db610cfeeff97a3a807347888250f ./7.3/i386/sendmail-8.12.11-4.22.8.legacy.i386.rpm c904cd0037dead018d212be03f6bce2507af25e0 ./7.3/i386/sendmail-cf-8.12.11-4.22.8.legacy.i386.rpm 8d4a3bc5d33d35955d8d2c536cf8717cb69d304e ./7.3/i386/sendmail-doc-8.12.11-4.22.8.legacy.i386.rpm 921719465dd9184e161787abce8023d6ffc633ff ./fc1/SRPM/sendmail-8.12.11-4.25.legacy.src.rpm 662be990c4dc5559e35fe07222fb061618b2ec4f ./fc1/i386/sendmail-devel-8.12.11-4.25.legacy.i386.rpm 58a67f3403be4bfcd4e69a4ddd4d57d56d95f41f ./fc1/i386/sendmail-doc-8.12.11-4.25.legacy.i386.rpm a62936d6e7bf86d74d083ef49416264ae320d023 ./fc1/i386/sendmail-8.12.11-4.25.legacy.i386.rpm f47c4b5c4e283b6c3d2afe7dc703e4e231aeebd7 ./fc1/i386/sendmail-cf-8.12.11-4.25.legacy.i386.rpm 053dd6ee565d3e071951c205b013f3e19c17c511 ./fc3/SRPM/sendmail-8.13.1-3.legacy.src.rpm 95fa2ca8970fbdd441fe483d27262412911a38eb ./fc3/i386/sendmail-cf-8.13.1-3.legacy.i386.rpm 7642014c3a37da2c971165e383f1b3a8d0536f1a ./fc3/i386/sendmail-doc-8.13.1-3.legacy.i386.rpm 1372277299112c57827c392c1ab2a974de44c570 ./fc3/i386/sendmail-8.13.1-3.legacy.i386.rpm c539ab544982ec1163381bdea9db23291956a728 ./fc3/i386/sendmail-devel-8.13.1-3.legacy.i386.rpm 59b713db0c3ab1899f9c0c91e3fd9188d97455c7 ./fc3/x86_64/sendmail-devel-8.13.1-3.legacy.x86_64.rpm 49be60337bf663c136be4abc0909e5e9831782e9 ./fc3/x86_64/sendmail-cf-8.13.1-3.legacy.x86_64.rpm 58b2a98e7524ff5bf2675c8a3a47726dce920cee ./fc3/x86_64/sendmail-8.13.1-3.legacy.x86_64.rpm 46025d459f9724e9c77730486e0adf009692485b ./fc3/x86_64/sendmail-doc-8.13.1-3.legacy.x86_64.rpm a3166b6b0227f450498561acd80042636019aff1 ./9/SRPM/sendmail-8.12.11-4.24.legacy.src.rpm 0b61665414349d5b885e50dbf5649edfab079eca ./9/i386/sendmail-doc-8.12.11-4.24.legacy.i386.rpm 77cc98ee8bd520b8b220b99254871ac57d3e4455 ./9/i386/sendmail-cf-8.12.11-4.24.legacy.i386.rpm 69efec9b25ab3d48bdd180d71070abbdc497ed0b ./9/i386/sendmail-devel-8.12.11-4.24.legacy.i386.rpm f36924313332e8fc85b11cfe5fdc263b9db48179 ./9/i386/sendmail-8.12.11-4.24.legacy.i386.rpm 7d9135551126681633b5999947bc69cf0fcb2d4c ./fc2/SRPM/sendmail-8.12.11-4.26.legacy.src.rpm 4a7f960685eac046f2cc60c8cbd0a569ec7e64f2 ./fc2/i386/sendmail-cf-8.12.11-4.26.legacy.i386.rpm c4c0fc021fc6d912ceaa1ce4af2183dcba306252 ./fc2/i386/sendmail-doc-8.12.11-4.26.legacy.i386.rpm 3ee7c42846137c5217bc80a22d56a92c8a2b301f ./fc2/i386/sendmail-devel-8.12.11-4.26.legacy.i386.rpm fb8928621816392580ebee32b31d7518483adf65 ./fc2/i386/sendmail-8.12.11-4.26.legacy.i386.rpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEIhsd4v2HLvE71NURAqbeAKC7h+1fg48iOxS1UtpdXpbokvwHRwCfagp2 Eqx59MizSOr4cCtmw4Iv9Sc= =2H4y -----END PGP SIGNATURE----- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 7.3 packages respun for: - - Use right name in changelog - - enable alternatives a9c43e6e124e89b5583a096b3c5b378e8552a66c 7.3/SRPM/sendmail-8.12.11-4.22.9.legacy.src.rpm 3c8b76e1180fef2eafda9479a9cce7a2350c6617 7.3/i386/sendmail-doc-8.12.11-4.22.9.legacy.i386.rpm aa639e9c26e2e24c0fd2c447c824a4f9eca310fb 7.3/i386/sendmail-8.12.11-4.22.9.legacy.i386.rpm b5e18e0536c7c5fbdd721d2a74995c98b18eaf29 7.3/i386/sendmail-devel-8.12.11-4.22.9.legacy.i386.rpm 60fe825ab8e0a1c376db3bd4567ff468c4e0fa67 7.3/i386/sendmail-cf-8.12.11-4.22.9.legacy.i386.rpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEIiUr4v2HLvE71NURAmshAKCANyAYQOfSUIzRvEO1RXYsEfVHFgCgtedk g6inFg6Sy8smr1aQdcuVTLA= =WEQ5 -----END PGP SIGNATURE----- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Er... wrong packages. Here are the right ones: a9c43e6e124e89b5583a096b3c5b378e8552a66c 7.3/SRPM/sendmail-8.12.11-4.22.9.legacy.src.rpm 48adbe1fa8ea9a5661d072322679cd4187d406b6 7.3/i386/sendmail-doc-8.12.11-4.22.9.legacy.i386.rpm da92a27da0ebf9179925c64ed6e77f283a200dfd 7.3/i386/sendmail-8.12.11-4.22.9.legacy.i386.rpm c9dbb555a482f42cccbcda4d2bde99525a4f87f8 7.3/i386/sendmail-devel-8.12.11-4.22.9.legacy.i386.rpm 52c4a6d18122c7edfaa20795edf2914fa350ffda 7.3/i386/sendmail-cf-8.12.11-4.22.9.legacy.i386.rpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEIiZd4v2HLvE71NURAgFKAJ9KInXyQ8Nwb0ZI2ECVHgH+jbRgvQCgvyqY 1iwOILP6mUn1w0ZxfdWvuVY= =T2Yn -----END PGP SIGNATURE----- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rebuilt RHL9 for - - correct alias file - - use sasl1 - - BuildReq gdbm-devel Rebuilt FC1 for - - correct alias file 1fcea0854577e577a65307f554b779fe5e1d895e 9/SRPM/sendmail-8.12.11-4.24.1.legacy.src.rpm e7327cc244fee93808d8e4d2b0ad442fcdac9d5b 9/i386/sendmail-8.12.11-4.24.1.legacy.i386.rpm 680eda3987ea2f6eb48d067c340220d34062fdb5 9/i386/sendmail-cf-8.12.11-4.24.1.legacy.i386.rpm 99f3014e97bbfcdac59b0d5ee8def509ad5650b0 9/i386/sendmail-devel-8.12.11-4.24.1.legacy.i386.rpm de2c2dfc0fb63fd07e68a9c8c8d9f1172c9e7855 9/i386/sendmail-doc-8.12.11-4.24.1.legacy.i386.rpm 7fa8de1a72b4b3b1baab1b4d0247be25b2490383 fc1/SRPM/sendmail-8.12.11-4.25.1.legacy.src.rpm df92215793717ae80e7d867037de263acb0d0c5f fc1/i386/sendmail-8.12.11-4.25.1.legacy.i386.rpm 002073c4317f9af5fdb5bbbb5e606abd8ad58b47 fc1/i386/sendmail-devel-8.12.11-4.25.1.legacy.i386.rpm aedbbedbdea17d9bf95cac16ef5323c8068ace2e fc1/i386/sendmail-doc-8.12.11-4.25.1.legacy.i386.rpm 973223a7106ab14a693dbb379aeb49ffacca2802 fc1/i386/sendmail-cf-8.12.11-4.25.1.legacy.i386.rpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEIjWf4v2HLvE71NURAvnOAJ4lduFvP/lEFEBOzPVF0RT3KMucpQCfbUMf eSdLTXAiuKMpYHATC+f7p8w= =o6Xv -----END PGP SIGNATURE----- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I did QA on Jesse's packages: a9c43e6e124e89b5583a096b3c5b378e8552a66c 7.3/SRPM/sendmail-8.12.11-4.22.9.legacy.src.rpm 1fcea0854577e577a65307f554b779fe5e1d895e 9/SRPM/sendmail-8.12.11-4.24.1.legacy.src.rpm 7fa8de1a72b4b3b1baab1b4d0247be25b2490383 fc1/SRPM/sendmail-8.12.11-4.25.1.legacy.src.rpm 7d9135551126681633b5999947bc69cf0fcb2d4c fc2/SRPM/sendmail-8.12.11-4.26.legacy.src.rpm 053dd6ee565d3e071951c205b013f3e19c17c511 fc3/SRPM/sendmail-8.13.1-3.legacy.src.rpm - - rh73 package matches RHEL21 with appropriate changes - - fc2 package matches previous release with upstream patch added - - fc1 package matches fc2 with appropriate changes - - rh9 package matches fc2 with appropriate changes - - fc3 package matches previous release with upstream patch added +PUBLISH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEIjldLMAs/0C4zNoRAncVAJ0WOFX62XYV53OlYNijcD83hXkoQQCfbIbl 7bfFApHclwXQTGvcn1Yr4Z8= =q3JN -----END PGP SIGNATURE----- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 e7327cc244fee93808d8e4d2b0ad442fcdac9d5b sendmail-8.12.11-4.24.1.legacy.i386.rpm680eda3987ea2f6eb48d067c340220d34062fdb5 sendmail-cf-8.12.11-4.24.1.legacy.i386.rpm 99f3014e97bbfcdac59b0d5ee8def509ad5650b0 sendmail-devel-8.12.11-4.24.1.legacy.i386.rpm de2c2dfc0fb63fd07e68a9c8c8d9f1172c9e7855 sendmail-doc-8.12.11-4.24.1.legacy.i386.rpm i note i got these packages direct from jesse's server (geek.j2solutions.net) rather than via yum. that said, they install OK. creating a new cf file via m4 works OK. mail comes and goes OK. +VERIFY RH9 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEIsYZePtvKV31zw4RAl6iAJ9DVcd2ZP7VWzO9Pkmeb9tKNmgO/QCghAed QtcfB5sda4EiL9q5/RTmTl4= =uT5A -----END PGP SIGNATURE----- i'm impressed by the speed at which this is moving forward, but it still sucks that the FL team didn't have the advance notice that all the other "vendors" have. anyone know how to get a rep from FL onto the vendor-sec list (or whatever it's called) so that we can prepare fixes to release at the same time everybody else does? had this been an easier hole to exploit, there would be a LOT of compromised RH73 and RH9 boxes out there right about now :( I did have advance notice and I was on vendor-sec. However like you said this was a hard hole to exploit, and we were in the middle of upgrading our build system. Had this been an easier hole to exploit, we would have had test packages ready prior to the public announcement. This bug was pushed to updates-testing at 02:50am EST 2006-03-23 (11:50pm PST 2006-03-22) by Jesse. Needs verify. The updates-testing announcement can be found here: <http://www.redhat.com/archives/fedora-legacy-list/2006-March/msg00171.html> Thanks, Jesse!! Ah, Tom! Thanks for your verify in comment #11! :-) (I rpm-build-compared the files you tested with the files pushed to updates- testing, and they contain exactly the same binaries and files.) The first paragraph of the announcement refers to 'An updated tar package'; that should presumably be 'Updated sendmail packages' Indeed heh (; Maybe something in the message about checking the .cf file, too? the rh7 8.11 .cf file used with 8.12 ends up having annoying features like ident enabled by default. The rh7.3 package includes a sendmail.mc that says to use make to rebuild sendmail.cf. However, the included Makefile is missing the %.cf target. Workaround is to remember the old way: m4 /etc/mail/sendmail.mc >/etc/sendmail.cf Comment #18 and comment #19 both seem like good things to include in the release announcement. Thanks for the feedback. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 QA for 7.3 packages: 80f02c886b020e6d6ef17389c22c8b530fb05a48 sendmail-8.12.11-4.22.9.legacy.i386.rpm 285816881a55fe4b8a74fee48205c8ceedaee5e5 sendmail-cf-8.12.11-4.22.9.legacy.i386.rpm b4154a342e7747d980b7acaf352649ddc1dcc40d sendmail-devel-8.12.11-4.22.9.legacy.i386.rpm 81a36048a12cc5c08a8e93490dde6817c402ae54 sendmail-doc-8.12.11-4.22.9.legacy.i386.rpm Packages install cleanly Sendmail restarted ok Sent multiple messages through sendmail without any problems RH73 VERIFY++ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEIykVKe7MLJjUbNMRAqFeAJsHW0SS/53dio1jyBS4DuFzJjtJ4QCgiC6W rK6VZU3kcucTgYxcnAb+uFw= =4feC -----END PGP SIGNATURE----- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 QA for FC1 packages: df880ab03eaeb2f82be81bee96c28392984a4b86 sendmail-8.12.11-4.25.1.legacy.i386.rpm 729bcaeb1269b65728f014bbbedb5c1a54a5158e sendmail-cf-8.12.11-4.25.1.legacy.i386.rpm 256ff91b67ecc7680a5f2fb97b3b32142bb80d18 sendmail-devel-8.12.11-4.25.1.legacy.i386.rpm 65725c811c4c7eede9f88c006a13c15e458d353f sendmail-doc-8.12.11-4.25.1.legacy.i386.rpm Packages install cleanly Sendmail restarted ok Sent multiple messages through sendmail without any problems FC1 VERIFY++ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEIyrtKe7MLJjUbNMRApwKAKC4IeXxEldtoz7RiNoICrwlChVE9ACcC3L6 yh4o+qlC68LInzy9k9R+mQo= =bl0b -----END PGP SIGNATURE----- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
QA on FC1 packages:
df880ab03eaeb2f82be81bee96c28392984a4b86__sendmail-8.12.11-4.25.1.legacy.i386.rpm
729bcaeb1269b65728f014bbbedb5c1a54a5158e__sendmail-cf-8.12.11-4.25.1.legacy.i386.rpm
256ff91b67ecc7680a5f2fb97b3b32142bb80d18__sendmail-devel-8.12.11-4.25.1.legacy.i386.rpm
65725c811c4c7eede9f88c006a13c15e458d353f__sendmail-doc-8.12.11-4.25.1.legacy.i386.rpm
* Packages install just fine
* Did rpm-build-compare on main sendmail package. Differences are
reasonable. sendmail 8.12.11 requires openldap and openssl, which
8.12.10 did not; but I don't see that as a problem.
* Starts up fine.
* Was able to send and receive several emails just fine. No burps.
* Was able to use the sendmail-cf files to do "make sendmail.cf" in the
/etc/mail directory. Worked just fine.
* I concur that it is a good idea to emphasize that folks check their
.cf files.
VERIFY++ FC1
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFEIz1Lxou1V/j9XZwRAs5yAKCRcJgU5NaSu54IYVtfygXz6QigdgCg7pU/
UqTHbwM7tpTu5gu2zPw0Vtc=
=KPCT
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I installed the FC3 package: 95fa2ca8970fbdd441fe483d27262412911a38eb fc3/i386/sendmail-cf-8.13.1-3.legacy.i386.rpm 7642014c3a37da2c971165e383f1b3a8d0536f1a fc3/i386/sendmail-doc-8.13.1-3.legacy.i386.rpm 1372277299112c57827c392c1ab2a974de44c570 fc3/i386/sendmail-8.13.1-3.legacy.i386.rpm c539ab544982ec1163381bdea9db23291956a728 fc3/i386/sendmail-devel-8.13.1-3.legacy.i386.rpm - - Installed OK - - Restarted OK - - Received and delivered mail +VERIFY -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEI0AYLMAs/0C4zNoRAqKXAJ9uAveY49KhkdhqVhz6hJaMDTKBQQCgvwcs kFQ6ZUCkFlCSBOIl3QRuPbE= =fy8K -----END PGP SIGNATURE----- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 QA for FC2 packages: 7e44b02696338832e2dfc0057aeb58c98511d0d2 sendmail-8.12.11-4.26.legacy.i386.rpm d159f0c92bd530799b75341d18b5b2cbe5aa5a0a sendmail-cf-8.12.11-4.26.legacy.i386.rpm 8421bfb2eb2f2b3fddb35e905fdcfecd0fb8088c sendmail-devel-8.12.11-4.26.legacy.i386.rpm b659d2733afa3d6f4df840a395c6eae3a5c07d50 sendmail-doc-8.12.11-4.26.legacy.i386.rpm Packages install cleanly Sendmail restarted ok Sent multiple messages through sendmail without any problems FC2 VERIFY++ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEI0FqKe7MLJjUbNMRAnlrAKC1z81NN1o/+lelrGJt9GdTgsTJPACgnfGK dfj7tQovOZR9r9ea9inyTd4= =jY03 -----END PGP SIGNATURE----- Is there any other testing we need to release? Comments #18 and #20 seem troubling to me. It seems inappropriate if the software upgrade just simply overwrites the config file, and requires manual intervention to fix the configuration. Would this be easily fixable without serious caveats? I don't believe that the software upgrade simply overwrites the config. file. It didn't on my install on FC1. The RHL7.3 sendmail.spec file has these lines: %config(noreplace) /etc/sendmail.cf %attr(0644,root,root) %config(noreplace) /etc/mail/sendmail.mc %config(noreplace) /etc/mail/local-host-names ... and many more like it in the %files section. I think the concern in comment #18 was that upgrading using the new 8.12.11 sendmail software in combination with the *old* 8.11.6 config file has some perhaps unanticipated side effects... Right - it doesn't replace it. It seems to work anyway, though. On RH9, since upgrading from 8.2.8 (the previous FL update) this morning, the users on my local network are unable to send mail. In /var/log/maillog I see messages like: Mar 24 09:36:47 biscotti sendmail[21526]: k2O9acSr021526: clares.zolv.com [192.168.0.141] (may be forged): possible SMTP attack: command=AUTH, count=4 Mar 24 10:03:53 biscotti sendmail[22105]: k2OA3kCj022105: clares.zolv.com [192.168.0.141] (may be forged) did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA I can send mail from the local machine OK. [root@biscotti mail]# rpm -qa | grep sendmail sendmail-8.12.11-4.24.1.legacy sendmail-cf-8.12.11-4.24.1.legacy sendmail-devel-8.12.11-4.24.1.legacy [root@biscotti mail]# uname -a Linux biscotti.zolv.com 2.4.20-43.9.legacy #1 Sat Apr 30 19:18:42 EDT 2005 i686 i686 i386 GNU/Linux I'm not sure if this is something in my local config (I can post config files if necessary) or a problem with the release. Anyone have any ideas? I'm going to roll back to 8.12.8 for now. Regarding comment #30 I think it must be something in your config. I just installed the packages on a RH9 machine and I'm able to telnet to port 25 (from a remote machine) and send messages that way. Did you change your configs when you upgraded, or are you still using the same config files? Same (customised) config files as before the update (I made sure the .cf files were definitely rebuilt after the update, but no joy). In /etc/mail/access this line enables relaying from our network: 192.168.0 RELAY Here's a few excerpts from /etc/mail/sendmail.mc that may be relevant (let me know if I can post anything else that might help): define(`confAUTH_OPTIONS', `A')dnl TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl For users, the symptom of the problem is that users (mostly using Thunderbird) get a box asking them for their password when sending mail, but their password is not accepted. Since people use laptops from home and the office, SMTP authentication is enabled in the clients. Interestingly, I started getting error e-mails like the following from Webmin's service monitor (running on same machine) as soon as I'd upgraded, which could be related: From: root.com (Cron Daemon) To: root.com Subject: Cron <root@biscotti> /etc/webmin/status/monitor.pl X-Cron-Env: <SHELL=/bin/sh> X-Cron-Env: <HOME=/root> X-Cron-Env: <PATH=/usr/bin:/bin> X-Cron-Env: <LOGNAME=root> Error ----- No mail program was found on your system! ----- I have rolled back to 8.12.8 from http://download.fedoralegacy.org/redhat/9/updates/i386/ and all is once again working (with the same config). I am having an issue similar to comment #30. Using the updated packages for FC1 (8.12.11-4.25.1.legacy) I am unable to send mail using TLS. I get errors like: robotics saslauthd[27723]: do_auth : auth failure: [user=klk] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error] robotics sendmail[28132]: Password verification failed in /var/log/messages. I am using the exact same config files as before the update. I downgraded to 8.12.10-1.1.1 and everything works as expected. I can attach my config file or other logs if that would help. seems that sasl might not be working right. I'm not entirely sure how to further investigate, are you absolutely certian that there was no config change between the two versions? Created attachment 126665 [details]
my sendmail config file.
I am absolutely certain that the config file is the same. I just checked again to make sure: - started with 8.12.10-1.1.1 (FC1) - backed up sendmail.mc just in case... - mail is sent with no problems. - upgraded to 8.12.11-4.25.1.legacy. Only sendmail, -doc, and -cf were upgraded. No other packages changed. - copied backed-up sendmail.mc to /etc/mail, ran "make", restarted sendmail. - mail can't be sent, mail client (kmail) says: The server responded: "5.7.0 authentication failed" - downgrade back to 8.12.10-1.1.1 - mail sends just fine. So the only thing changing is sendmail. I have made an attachment with my config file. I'll also make one with snippets of /var/log/maillog and /var/log/messages when things fail/work. Just a WAG... If you had hacked up or removed the old /etc/pam.d/smtp, the upgrade would have installed the new one which is now named /etc/pam.d/smtp.sendmail. Also, /etc/mail/certs/is not valid on some of the older distros. You need to go back to /usr/share/ssl/certs/ or wherever... Created attachment 126666 [details]
Logfile snippets
Snippets from /var/log/messages and /var/log/maillog. It may indicate that the
problem is on the client side, but nothing on the client is changing between
tests.
Kristo, check your /etc/sysconfig/saslauthd. It seems to use MECH=pam, which is ok. Then check to have /etc/pam.d/smtp, which should be a symlink target from origin /etc/pam.d/smtp.sendmail. The content has to be #%PAM-1.0 auth required pam_stack.so service=system-auth account required pam_stack.so service=system-auth Make sure saslauthd is running. RHL 7.3 update
Why is the Sendmail binary linked against SASLv2? RHL 7.3 came with SASL 1.5 only.
$ ldd sendmail.sendmail | grep sasl
libsasl.so.7 => /usr/lib/libsasl.so.7 (0x006ea000)
libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x0076d000)
Did someone test the update for 7.3 to be working with SMTP AUTH?
Which sendmail package for 7.3 did you install? Can you give me a sha1sum of it? The specfile used explicitly enables saslv1 not v2. In reference to Comment #39, everything is as you specified. Jesse http://download.fedoralegacy.org/redhat/7.3/updates/i386/sendmail-8.12.11-4.22.9.legacy.i386.rpm $ sha1sum sendmail-8.12.11-4.22.9.legacy.i386.rpm 80f02c886b020e6d6ef17389c22c8b530fb05a48 sendmail-8.12.11-4.22.9.legacy.i386.rpm I do not run RHL 7.3 myself but on comp.mail.sendmail was a report by someone complaing the update requiring saslauthd. So I investigated the package by defalting it using rpm2pio. `ldd /var/tmp/usr/sbin/sendmail.sendmail' shows what I pasted in #40. I can't reproduce the sasl issue on a 7.3 box:
$ rpm -q sendmail
sendmail-8.12.11-4.22.9.legacy
$ ldd /usr/sbin/sendmail.sendmail | grep sasl
libsasl.so.7 => /usr/lib/libsasl.so.7 (0x40106000)
As an FYI aside, the postuninstall script uses readlink but the rpm does not reflect the dependency on tetex. I just update another old rh73 system with minimalist packages and saw the error: /var/tmp/rpm-tmp.77878: readlink: command not found Yeah, the packages seem to be broken on so many levels, though some of it caused
by RHEL...
The packages will need to be re-rolled, IMHO. Due to the alternatives bug,
sendmail doesn't even restart anymore (as /usr/sbin/sendmail no longer exists,
the init script just exists), and hence the daemon is still vulnerable.
d9c001d8a34f11f528ff6be2a9f8dd15818caf40 sendmail-8.12.11-4.22.9.legacy.src.rpm
With rpm-build-compare.sh, I note the following problems in RHL73 just by
looking at the spec file for 10 minutes:
- as mentioned, readlink doesn't exist, so scripts fail in two places
- alternatives is "no" though earlier specfile enabled it (through 'errata >= 73')
- hesiod-devel buildprereq went missing
Some other broken stuff but doesn't affect RHL73: if old_setup is "no" (RHL73 is
yes), aliases file is sourced from **/etc/***
+%if "%{old_setup}" == "yes"
Source3: aliases
+%else
+Source3: /etc/aliases
+%endif
Wow...something happened there somewhere. The rh73 packages were specifically rebuilt to include alternatives, but somehow ended up in updates-testing with alternatives turned off. Ok, here's the problem. The binary packages and the source package in RH73 updates don't match, although they have the same release number. The binary packages have alternatives in with a relevant "- Enable alternatives" entry in the changelog. The source rpm is from a previous build that omits the alternatives modification. Somehow, the wrong source rpm got pushed to updates-testing. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The FC2 and FC3 seem fine. Here are fixed packages for rh73, rh9 and fc1 to QA. They should take care of the issues people are having with the previous upgrades. 7.3 changelog: * Sat Mar 25 2006 Marc Deslauriers <marcdeslauriers> 8.12.11-4.22.10.legacy - - Added hesiod-devel to BuildRequires - - Reverted to previous alternatives files - - Removed new triggers - - Modified instructions in sendmail.mc 9 changelog: * Sat Mar 25 2006 Marc Deslauriers <marcdeslauriers> - 8.12.11-4.24.2.legacy - - Reverted statistics file to /etc/mail - - Reverted to previous alternatives files fc1 changelog: * Sat Mar 25 2006 Marc Deslauriers <marcdeslauriers> - 8.12.11-4.25.2.legacy - - Reverted statistics file to /etc/mail - - Reverted to previous alternatives files - - Added gdbm-devel to BuildRequires 7.3: c57140069224f247c71bbdb87a9b4320d0b65a8d sendmail-8.12.11-4.22.10.legacy.i386.rpm c834e9b1089a1a6b7796209f0ce0e2fa87ca60b7 sendmail-cf-8.12.11-4.22.10.legacy.i386.rpm eac9d007dffbbcf7efb3e025e680407a737008f6 sendmail-devel-8.12.11-4.22.10.legacy.i386.rpm 24a25b9e22ffb6bf32895d2af99f28c83062883e sendmail-doc-8.12.11-4.22.10.legacy.i386.rpm http://turbosphere.fedoralegacy.org/logs/redhat-7.3-core/65-sendmail-8.12.11-4.22.10.legacy/i386/ 9: f2fe962096c186bbd45ae5494951aae3042b9d68 sendmail-8.12.11-4.24.2.legacy.i386.rpm d576a57e9e5e5d023c162a37590ecf55c24bbba2 sendmail-cf-8.12.11-4.24.2.legacy.i386.rpm d0805a6b17baf313756480b0ca8db614959b286f sendmail-devel-8.12.11-4.24.2.legacy.i386.rpm 46cd5e43f83f456bcdef06df638ee55ce70d7afc sendmail-doc-8.12.11-4.24.2.legacy.i386.rpm http://turbosphere.fedoralegacy.org/logs/redhat-9-core/66-sendmail-8.12.11-4.24.2.legacy/i386/ 1: 0fd91369abb6a9202046bfef39e60dbb50d453fa sendmail-8.12.11-4.25.2.legacy.i386.rpm 4b4571061a33a151bfd9b4541a7895b286028112 sendmail-cf-8.12.11-4.25.2.legacy.i386.rpm 225ab50da0fb3153293f9a51de70cbe06c202bcc sendmail-devel-8.12.11-4.25.2.legacy.i386.rpm 90d0e9b1c2438ee7fb1e0d06f69cdb858a695273 sendmail-doc-8.12.11-4.25.2.legacy.i386.rpm http://turbosphere.fedoralegacy.org/logs/fedora-1-core/67-sendmail-8.12.11-4.25.2.legacy/i386/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEJgXqLMAs/0C4zNoRAmP0AKDCzbWF098q5GyLch9aSqxeDOKaFQCgjTNa c6EIqAka2wvV3Tf/5utHpEo= =7BEG -----END PGP SIGNATURE----- Hmm.. I didn't quite understand the reason why you reverted to the old alternatives stuff: you seem to be partially simulating the case where alternatives is "no", even though it was already enabled in RHL73 so many years ago? If old_setup is set to "no", the packages still depend on the contents of /etc/aliases on the build machine (when it runs $RPM_BUILD_ROOT/usr/bin/makemap) on RHL9. That's not cool. (There's a lot of other nastiness in RHL73/RHL9 wrt old_setup -- old_setup=no is not correct on RHL73 while old_setup=yes is not correct on RHL9..) Perhaps on RHL73, removal of the readlink could be replaced with: ls -l /etc/alternatives/mta | sed s":.* /:/:" | sed s":.* -> ::" .. where the first sed strips out everything except the filename and path, and the second sed reads the symlink if it exists. + daemon /usr/sbin/sendmail $([ "x$DAEMON" = xyes ] && echo -bd) \ + $([ -n "$QUEUE" ] && echo -q$QUEUE) doesn't pass at the end $SENDMAIL_OPTARG, so if you do reload(), do you lose arguments if you defined any? On RHL9, the defined CERT dirs don't exist under /etc/mail/. /usr/share/ssl/certs do though, but weren't enabled. I guess it's bad practice to point to cert dirs that don't exist, maybe dnl these from .mc? RHL9 supports sasl2, but it wasn't enabled in the previous RHL9 sendmail update in 2003; it's not clear to me as I don't use SASL whether we should keep the old practice or upgrade sendmail to use sasl2. In RHL9, smmsp is no longer confTRUSTED_USER. Apparently RH removed this in Sep 2003, so I guess it's OK. The reason everyone is having problems is because the sendmail update we released contains three more files that were assigned to alternatives. When the package gets upgraded, sendmail is already configured in the systems alternatives system, so the three new symlinks don't get created. There are three possible ways around this problem, 1- remove sendmail from alternatives during the upgrade before adding it back in to force alternatives to re-create the symlinks, 2- try and get alternatives to recreate the symlinks with a funky postun trigger, 3- revert the three files to their previous behaviour with the previous sendmail release. After much thought, it appeared the simplest way was to revert to the way the previous sendmail package worked. Starting with FC2, sendmail doesn't provide the /etc/aliases anymore. The old_setup flag indicates in the spec file if we want an aliases file or not. It should be turned on for rh73, rh9 and fc1. I'm not sure why you say it's turned off in rh73, or why you say it shouldn't be turned on in rh9. Please explain. The readlink section of the spec file was to upgrade sendmail in RHEL21. This is unnecessary with our rh73 upgrade. The initscript doesn't pass the $SENDMAIL_OPTARG in the reload function as it doesn't actually start sendmail, it just sends it a -HUP. No need to pass arguments there. The defined CERT dirs under /etc/mail don't exist on any release. The included makecert.sh command creates them for you, as documented in the .mc file. For rhl9, the previous sendmail didn't use sasl2. There may have been a reason for that. It would be better to use sasl1, as the previous release did. OK, I guess the second option would have been easier if readlink had been available on RHL73.. But the functional difference is probably not significant enough to change to 2) and use an alternative to readlink.. Sorry for confusion, yes, old_setup is enabled for both rhl73 and rhl9. What I meant to say is that the non-default option (in this case "no") is broken on both src.rpm's. It's arguable whether this is more than a cosmetic problem or a way to shoot yourself in the foot.. sendmail-8.12.11-4.24.2.legacy (RH9): sendmail.mc -dnl define(`STATUS_FILE', `/etc/mail/statistics')dnl +define(`STATUS_FILE', `/var/log/mail/statistics')dnl - 8.12.8-9.90 sendmail.mc says /etc/mail/statistics - 12.11-4.24.2.legacy sendmail.mc says /var/log/statistics - and activates it! - rpm-qlp of 12.11-4.24.2.legacy CONTAINS /etc/mail/statistics - recommend revert back to old location -dnl define(`confCACERT_PATH',`/usr/share/ssl/certs') -dnl define(`confCACERT',`/usr/share/ssl/certs/ca-bundle.crt') -dnl define(`confSERVER_CERT',`/usr/share/ssl/certs/sendmail.pem') -dnl define(`confSERVER_KEY',`/usr/share/ssl/certs/sendmail.pem') +define(`CERT_DIR',`/etc/mail/certs') +define(`confCACERT_PATH',`CERT_DIR') +define(`confCACERT',`CERT_DIR/cacert.pem') +define(`confSERVER_CERT',`CERT_DIR/cert.pem') +define(`confSERVER_KEY',`CERT_DIR/key.pem') +define(`confCLIENT_CERT',`CERT_DIR/cert.pem') +define(`confCLIENT_KEY',`CERT_DIR/key.pem') - changes locations - changes CACert filename - changes server/client key filename - activates bogus config - recommend keep or DNL the new lines, but revert the locations back to the older supplied locations. Activating the config with new locations is introducing either a bug or a feature, and either may not be recommended. This package DOES appear to fix bug 186579, but ships with immediate concerns of its own. sendmail-8.12.11-4.25.1.legacy (FC1) contains the same random change to the sendmail.mc. I don't have an FC2 system,but I notice the FC3 packages *don't* include any new features/changes, and I'm definitely for the idea of keeping the MCs very similar to their normal formats -- not only because they'll be the same as originally released for all RH-derived distros released in almost a decade, and not only because it's an added feature of the type I've been told we don't like to add into updates, but also because I've learned the headache of supporting even a change as innocuous in appearance as this one. sendmail-8.12.11-4.25.1.legacy also do the Alternatives work in %post when upgrading from the next most recent version: [root@fishy /]# ls -l /etc/pam.d/smtp* /usr/lib/sendmail* -rw-r--r-- 1 root root 116 Mar 23 00:22 /etc/pam.d/smtp.sendmail lrwxrwxrwx 1 root root 16 Mar 26 17:41 /usr/lib/sendmail.sendmail -> ../sbin/sendmail I'd suggest 8.12.11-4.25.1 fails QA based on the random feature with the location change, and the alternatives concern. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In response to comment 53, here are updated packages for RH9 and FC1: - - Reverted statistics file path in mc file - - Reverted CERT paths in mc file - - Don't enable statistics by default rh9: 6ee6122a976ff1aa32d784cb817caf9aa53daa97 sendmail-8.12.11-4.24.3.legacy.i386.rpm 0b690b7dfd72d962c6a44897fb826ddc3c73e699 sendmail-cf-8.12.11-4.24.3.legacy.i386.rpm 7648da4c91b79a035ea7cad78e58eeff73c04b2e sendmail-devel-8.12.11-4.24.3.legacy.i386.rpm aa9cd92fa507433ed612f1b6889277f4fd46bdcd sendmail-doc-8.12.11-4.24.3.legacy.i386.rpm fab24bdbf1d46fb7d488de2fab60ed0da5dabaeb sendmail-8.12.11-4.24.3.legacy.src.rpm http://turbosphere.fedoralegacy.org/logs/redhat-9-core/68-sendmail-8.12.11-4.24.3.legacy/ fc1: a5e3f8c6aa59aa48ce78fb96cc03601173ba9f98 sendmail-8.12.11-4.25.3.legacy.i386.rpm 2a2299397fd86ca7c06ebfe2c4ca047385ee2988 sendmail-cf-8.12.11-4.25.3.legacy.i386.rpm ed85bed5db216b77949ddf4ac6e0721ae7688a52 sendmail-devel-8.12.11-4.25.3.legacy.i386.rpm 544a83a270864e118be0f98064eebaff1c783b10 sendmail-doc-8.12.11-4.25.3.legacy.i386.rpm e39214f5c41d727fe776ea36c37673ebb31ec7fa sendmail-8.12.11-4.25.3.legacy.src.rpm http://turbosphere.fedoralegacy.org/logs/fedora-1-core/69-sendmail-8.12.11-4.25.3.legacy/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEJ2GkLMAs/0C4zNoRArnrAJ4g5amzMQknJhQ3TmJwdg5L1ybX1QCgkEkw qXgPGk3DCXc464i4tNdtx7M= =JDxT -----END PGP SIGNATURE----- *** Bug 186927 has been marked as a duplicate of this bug. *** One of my complaints is it is overwriting my /etc/init.d/sendmail file (RHL 9).
Seems like we should patch the spec file:
555c555
< %config %{initdir}/sendmail
---
> %config(noreplace) %{initdir}/sendmail
This would create a /etc/init.d/sendmail.rpmnew if there is a custom script,
which is what I expect personally. I don't think there are any changes to
the init script which are needed for the update; rather they just make it
more robust and add a reload() and so on. I think leaving the custom script
in place will work fine, though I've not exhaustively researched the scripts.
Anyone else agree or disagree?
We might want to mention in the release note that the new /etc/init.d/sendmail script as well as the new /etc/mail/Makefile now rebuild the sendmail.cf file from the sendmail.mc file... This means if someone has been editing/customizing their sendmail.cf file without modifying/customizing the sendmail.mc file, then installing our package and rebooting, or installing our package and doing a "make all" in /etc/mail, will remove all their customizations and perhaps shutdown their mail services (and I don't think there is any way to recover without backups). This is kind of a critical point as some people do hand-edit sendmail.cf without ever touching sendmail.mc, perhaps even deleting sendmail.mc which our script might then replace with a stock one, and this could really bite them... In response to comment #58: I'm not sure why you think the behaviour has changed. The previous rh9 sendmail release does it also. Am I missing something? Because I was confusing versions? 7.3 doesn't do this, 9 does; and your updates seem to keep that the same way. Sorry for the noise, although it still wouldn't hurt to mention it even though it is "expected" behaviour... In any case, I stand corrected; the rpms are doing exactly what the RH rpms did for both 7.3 and 9. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 QA for updated 7.3 package (comment #49): b719f1d31d54a3326aa718faced760f1f854807f sendmail-8.12.11-4.22.10.legacy.src.rpm sendmail Source matches previous package Only other source change is to sendmail-redhat.mc where the comments are changed to reflect how to build the cf file Spec file changes look good and should correct problems people are experiencing with alternatives QA for updated RH9 package (comment #55): fab24bdbf1d46fb7d488de2fab60ed0da5dabaeb sendmail-8.12.11-4.24.3.legacy.src.rpm sendmail source matches previous package Other source changes are: removing makecert.sh included .mc uses /etc/mail/statistics instead of /var/log/mail/statistics included .mc uses /usr/share/ssl/certs instead of /etc/mail/certs Those all seem like valid changes to me as it reverts to previous expected behavior. Spec file changes all look good (reverting to behavior of previous rh9 package) RH73 PUBLISH++ RH9 PUBLISH++ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEKIckKe7MLJjUbNMRAnsGAJ0XmGXjPVNsyKXrUfw7I3RzH2PkdQCffGk2 vJOrVSrXb/RkflMAUXxJ4vg= =qwoJ -----END PGP SIGNATURE----- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 QA w/ rpm-build-compare.sh: - source integrity good - spec file changes minimal from the already-updated version, large from the original FC1 version but should be OK.. - no patch changes from the previous release, should be OK from the original FC1 version. +PUBLISH FC1 e39214f5c41d727fe776ea36c37673ebb31ec7fa sendmail-8.12.11-4.25.3.legacy.src.rpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQFEKMl7GHbTkzxSL7QRAiifAJ41HBH2xvSlAGh7WlKNbSwWqNz6tQCgpZKA iKspNi2OdTpM8818oBAgH+k= =Cw/J -----END PGP SIGNATURE----- Updated packages for rh73, rh9 and fc1 were pushed to updates-testing If some of the people who were having problems with the previous packages could test out the new packages in updates-testing, that would be very helpful! I can report that the FC1 package in updates-testing (8.12.11-4.25.3.legacy) seems to work fine for me. I do not have the problem first noted in comment #33. Seconded. On RH9 with legacy updates I got the secure SMTP auth problem after the published update. Updating from updates-testing solved it. No other changes were made manually either before or after the update between it and the one in updates-testing. I've just done some quick checks, mainly that auth now works and that my virtusertable is functioning. Hopefully there are no "hidden" problems. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 9f1caeadce45e2922f6bc29ea0f4e7bce4e26d02 sendmail-8.12.11-4.24.3.legacy.i386.rpm6b7b437bb58ac9f805185ae992da9a157a0d755d sendmail-cf-8.12.11-4.24.3.legacy.i386.rpm ae48cf1d3a5d8f5bfc789a408de392fe27e84b73 sendmail-devel-8.12.11-4.24.3.legacy.i386.rpm 4571b20f603bf6f90558aa09107f5b2ae17e8111 sendmail-doc-8.12.11-4.24.3.legacy.i386.rpm installs OK. mail come and goes OK, although as in comment #11 i reiterate that i generate my own sendmail.cf by hand, which i again did before verifying the functionality. +VERIFY RH9 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEK9yxePtvKV31zw4RAv48AKCFQKc6WOrOBkqiGqssTgdvuPvdwwCgtIve j2ET8esmXC0crpE/1eKoIFA= =IpwP -----END PGP SIGNATURE----- I'd say the FC1 comment is good enough to decrease the timeout to one week unless issues come up.. :-) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ++VERIFY for RHL 9 Downloaded packages: 9f1caeadce45e2922f6bc29ea0f4e7bce4e26d02 sendmail-8.12.11-4.24.3.legacy.i386.rpm 6b7b437bb58ac9f805185ae992da9a157a0d755d sendmail-cf-8.12.11-4.24.3.legacy.i386.rpm Package installed fine on a single machine. All previous problems I saw on that machine are now fixed. Vote for release for RHL 9. ++VERIFY -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFELDFD4jZRbknHoPIRAtgKAJ4mNOUFHnA6wx4T1jTD42ey6bZ5FgCfeGlz 1uqibmD5mAuN2JSWLhGb+1s= =gUWv -----END PGP SIGNATURE----- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Test of FC1 sendmail-8.12.11-4.25.3.legacy.i386.
3f6edb4bdcd42cca1f01fce9482d3ac10b56f530__sendmail-8.12.11-4.25.3.legacy.i386.rpm
7aaa9743d312b7ebc95baa83e186acaa267f6915__sendmail-cf-8.12.11-4.25.3.legacy.i386.rpm
dfabadaa764d471b2c5963547643ca4bbe5ca0e7__sendmail-devel-8.12.11-4.25.3.legacy.i386.rpm
121433ec0c71a163993cf2a94f33fa67df786b11__sendmail-doc-8.12.11-4.25.3.legacy.i386.rpm
* sha1sums and gpg signatures ok
* upgrading from original FC1 sendmail (8.12.10), seems to install well:
- Pre-install scriptlet worked fine.
- Package file Installation -- Config files:
. left /etc/aliases alone (I'd modified it), built new
/etc/aliases.db;
. replaced /etc/mail/access (I'd not changed it);
. replaced /etc/mail/Makefile (I'd not changed it);
. skipped /etc/mail/local-host-names (I'd modified it);
. left my /etc/mail/sendmail.cf alone, but created the packaged
file as sendmail.cf.rpmnew;
. same for /etc/mail/sendmail.mc;
. replaced /etc/mail/submit.cf (I'd not changed it);
. replaced /etc/mail/submit.mc (I'd not changed it);
. replaced /etc/mail/trusted-users (I'd not changed it);
. replaced /etc/pam.d/smtp (I'd not changed it);
. replaced /etc/rc.d/init.d/sendmail (which it would do whether
or not I changed it);
. replaced /etc/sysconfig/sendmail (I'd not changed it);
. kept (or replaced) the symlink /usr/lib/sendmail ->
../sbin/sendmail
- Post-install scriptlet appeared to work fine. No surprises.
- Alternatives system appears to be set up correctly, reverted to the
alternatives used in sendmail-8.12.10; no missing alternative files.
- Pre-uninstall scriptlet does nothing ([ 1 = 0 ]), which is correct,
as this is a sendmail update/upgrade.
- Erase of sendmail-8.12.10 packaged files skipped all files, since
they all were replaced by the 8.12.11-4.25.3 package. Good.
- Post-uninstall scriptlet restarted sendmail 'condrestart' (which
only stops and starts sendmail if it is already running). Good.
* Looks like previous issues have been taken care of:
- /etc/pam.d/smtp not missing (auth should work)
- /usr/lib/sendmail not missing
- /usr/share/man/man8/sendmail.8.gz not missing
- in new sendmail.mc file, status file left at /etc/mail/statistics
and left undefined ('dnl'); and certificate directory reverted to
/usr/share/ssl/certs and also left undefined.
* It works. Was able to send message from FC1 box to a hotmail account
and receive mail from hotmail to the FC1 box's sendmail.
VERIFY++ FC1 sendmail
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFEMbNvxou1V/j9XZwRAg+jAJsHDFqU/vXc0KuyJ3Pg2L4zlT7zWwCdH3Zv
Os/+BIGY6IOz6ZvbvQzc8PI=
=+AUH
-----END PGP SIGNATURE-----
FWIW, sendmail works fine on RHL73 as well, but as I recompiled it, I didn't want to write it as a verify vote.. The timeout is due today in any case, so this is going to be released in any case.. Packages were released to updates. A bit late I realise, but I just tested on RH9 and all is working correctly (none of the problems in comment 30 and comment 32). Thanks to all concerned! |