Bug 971523 - Version bump to mimedefang 2.74
Version bump to mimedefang 2.74
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: mimedefang (Show other bugs)
18
All Linux
unspecified Severity medium
: ---
: ---
Assigned To: Robert Scheck
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-06 13:34 EDT by Philip Prindeville
Modified: 2013-09-22 20:47 EDT (History)
2 users (show)

See Also:
Fixed In Version: mimedefang-2.74-1.fc18
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-22 13:38:24 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to bring up to 2.74... includes source patches (3.17 KB, patch)
2013-06-06 16:22 EDT, Philip Prindeville
no flags Details | Diff
Or just always pass -y via the init script (3.11 KB, patch)
2013-06-06 16:36 EDT, Philip Prindeville
no flags Details | Diff
Use SMFI_VERSION to know what libmilter we're built against (490 bytes, patch)
2013-06-21 18:59 EDT, Philip Prindeville
no flags Details | Diff

  None (edit)
Description Philip Prindeville 2013-06-06 13:34:44 EDT
Description of problem:

Mimedefang 2.74 has been released. It includes some fixes for Perl 5.12 and later.

Version-Release number of selected component (if applicable):

mimedefang-2.73-4

How reproducible:

N/A

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 1 Philip Prindeville 2013-06-06 16:22:04 EDT
Created attachment 757884 [details]
Patch to bring up to 2.74... includes source patches

Other than the mechanical bump of the Version, there's a new flag introduced that we'd be required to use (-y), except that it's always true. So short-circuit it at compile time.

Otherwise, we could patch mimedefang-2.74/redhat/mimedefang-init.in to always invoke $prog with '-y', i.e.:

     daemon $PROGDIR/$prog -P @SPOOLDIR@/$prog.pid \
-        -m $MX_SOCKET \
+        -m $MX_SOCKET -y \
         $([ -n "$LOOPBACK_RESERVED_CONNECTIONS" ] && echo "-R $LOOPBACK_RESERVED_CONNECTIONS") \

instead... Either way, we avoid ALL users having to manually add MD_EXTRA="-y" to their /etc/sysconfig/mimedefang file.

We also add a trivial patch to mimedefang.pl to stop it from complaining at startup about a missing prototype on a recursive function.
Comment 2 Philip Prindeville 2013-06-06 16:36:27 EDT
Created attachment 757917 [details]
Or just always pass -y via the init script
Comment 3 Robert Scheck 2013-06-21 17:31:25 EDT
May you let me understand the details?
Comment 4 Robert Scheck 2013-06-21 18:00:58 EDT
Don't we have a possiblity to get the version from a libmilter include file?
Comment 5 Robert Scheck 2013-06-21 18:38:45 EDT
(In reply to Robert Scheck from comment #4)
> Don't we have a possiblity to get the version from a libmilter include file?

Obviously not as it seems.

Which impact does it have, if we don't use -y with a non-leaking libmilter?
Comment 6 Philip Prindeville 2013-06-21 18:39:37 EDT
(In reply to Robert Scheck from comment #4)
> Don't we have a possiblity to get the version from a libmilter include file?

Umm....  I guess so?

Diffing 8.14.3 (bug present) and 8.14.4 (bug fixed) I see that SMFI_VERSION was bumped:


--- sendmail-8.14.3/include/libmilter/mfapi.h	2008-02-27 15:30:34.000000000 -0700
+++ sendmail-8.14.4/include/libmilter/mfapi.h	2009-11-05 17:57:08.000000000 -0700
@@ -7,7 +7,7 @@
  * the sendmail distribution.
  *
  *
- *	$Id: mfapi.h,v 8.78 2008/02/27 22:30:34 ca Exp $
+ *	$Id: mfapi.h,v 8.80 2009/11/06 00:57:08 ca Exp $
  */
 
 /*
@@ -18,7 +18,14 @@
 # define _LIBMILTER_MFAPI_H	1
 
 #ifndef SMFI_VERSION
-# define SMFI_VERSION	0x01000001	/* libmilter version number */
+# if _FFR_MDS_NEGOTIATE
+#  define SMFI_VERSION	0x01000002	/* libmilter version number */
+
+   /* first libmilter version that has MDS support */
+#  define SMFI_VERSION_MDS	0x01000002
+# else /* _FFR_MDS_NEGOTIATE */
+#  define SMFI_VERSION	0x01000001	/* libmilter version number */
+# endif /* _FFR_MDS_NEGOTIATE */
 #endif /* ! SMFI_VERSION */
 
 #define SM_LM_VRS_MAJOR(v)	(((v) & 0x7f000000) >> 24)
@@ -163,9 +170,7 @@
 LIBMILTER_API int smfi_settimeout __P((int));
 LIBMILTER_API int smfi_setconn __P((char *));
 LIBMILTER_API int smfi_stop __P((void));
-#if _FFR_MAXDATASIZE
 LIBMILTER_API size_t smfi_setmaxdatasize __P((size_t));
-#endif /* _FFR_MAXDATASIZE */
 LIBMILTER_API int smfi_version __P((unsigned int *, unsigned int *, unsigned int *));
 
 /*
Comment 7 Philip Prindeville 2013-06-21 18:49:31 EDT
(In reply to Robert Scheck from comment #5)
> (In reply to Robert Scheck from comment #4)
> > Don't we have a possiblity to get the version from a libmilter include file?
> 
> Obviously not as it seems.

Wait... what?

> Which impact does it have, if we don't use -y with a non-leaking libmilter?

If we don't run it with -y, then only the variables that are EXPORTED by sendmail "O Milter.macros.*" lines will be exported, I believe.

No additional variables may be requested explicitly via the StandardSendmailMacros[] in mimedefang.c nor via the -a flag at run-time.
Comment 8 Robert Scheck 2013-06-21 18:55:51 EDT
In comment #6, I do not see different versions, that could be checked via some
preprocessor directive.
Comment 9 Philip Prindeville 2013-06-21 18:57:38 EDT
(In reply to Robert Scheck from comment #8)
> In comment #6, I do not see different versions, that could be checked via
> some preprocessor directive.

-# define SMFI_VERSION	0x01000001	/* libmilter version number */
+#  define SMFI_VERSION	0x01000002	/* libmilter version number */

Attaching a new fix.
Comment 10 Philip Prindeville 2013-06-21 18:59:06 EDT
Created attachment 763996 [details]
Use SMFI_VERSION to know what libmilter we're built against
Comment 11 Robert Scheck 2013-06-21 19:00:18 EDT
You noticed that the changed SMFI_VERSION depends on _FFR_MDS_NEGOTIATE only?
Comment 12 Philip Prindeville 2013-06-21 19:07:37 EDT
(In reply to Robert Scheck from comment #11)
> You noticed that the changed SMFI_VERSION depends on _FFR_MDS_NEGOTIATE only?

Yeah, but I thought that was also being defined in the same header file: turns out it's not. It's set during the sendmail build.  Oh, well.

We can still go with Attachment 757884 [details].
Comment 13 Robert Scheck 2013-06-21 19:13:17 EDT
Okay. We will simply go with the initscript change. Nevertheless thanks for
pointing the issue out, I wouldn't have noticed that.

Is the prototype patch already upstream? And since when does Perl care about 
prototyping? I thought Perl would have invented the implicity :)
Comment 14 Philip Prindeville 2013-06-21 19:57:47 EDT
(In reply to Robert Scheck from comment #13)
> Okay. We will simply go with the initscript change. Nevertheless thanks for
> pointing the issue out, I wouldn't have noticed that.
> 
> Is the prototype patch already upstream? And since when does Perl care about 
> prototyping? I thought Perl would have invented the implicity :)

I've sent it upstream but it's not been accepted (nor rejected).

Perl is only fussy about prototypes when it sees a function being defined with a prototype after that function has been referenced...
Comment 15 Fedora Update System 2013-08-31 14:20:36 EDT
mimedefang-2.74-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/mimedefang-2.74-1.fc19
Comment 16 Fedora Update System 2013-08-31 14:21:01 EDT
mimedefang-2.74-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/mimedefang-2.74-1.fc18
Comment 17 Fedora Update System 2013-08-31 14:23:53 EDT
mimedefang-2.74-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/mimedefang-2.74-1.el6
Comment 18 Fedora Update System 2013-08-31 14:24:23 EDT
mimedefang-2.74-1.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/mimedefang-2.74-1.el5
Comment 19 Fedora Update System 2013-09-01 14:46:56 EDT
Package mimedefang-2.74-1.el5:
* should fix your issue,
* was pushed to the Fedora EPEL 5 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing mimedefang-2.74-1.el5'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11399/mimedefang-2.74-1.el5
then log in and leave karma (feedback).
Comment 20 Fedora Update System 2013-09-22 13:38:24 EDT
mimedefang-2.74-1.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 21 Fedora Update System 2013-09-22 13:39:21 EDT
mimedefang-2.74-1.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 22 Fedora Update System 2013-09-22 20:20:27 EDT
mimedefang-2.74-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 23 Fedora Update System 2013-09-22 20:47:34 EDT
mimedefang-2.74-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.