Bug 971523

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.

Created attachment 757917 [details]
Or just always pass -y via the init script

May you let me understand the details?

Don't we have a possiblity to get the version from a libmilter include file?

(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?

(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 *));
 
 /*

(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.

In comment #6, I do not see different versions, that could be checked via some
preprocessor directive.

(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.

Created attachment 763996 [details]
Use SMFI_VERSION to know what libmilter we're built against

You noticed that the changed SMFI_VERSION depends on _FFR_MDS_NEGOTIATE only?

(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].

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 :)

(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...

mimedefang-2.74-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/mimedefang-2.74-1.fc19

mimedefang-2.74-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/mimedefang-2.74-1.fc18

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

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

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).

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.

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.

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.

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.