Created attachment 2085 [details]
patch against spamc.c

Created attachment 2086 [details]
patch against spamd.raw

Why not for spamd, too?

Created attachment 2087 [details]
real patch against spamd.raw

oops, I accidently attached spamd.raw, not the patch

Subject: Re:  [review] Add notice about SSL support to spamc -V

On Tue, Jul 06, 2004 at 11:54:01AM -0700, bugzilla-daemon@bugzilla.spamassassin.org wrote:
> Why not for spamd, too?

IMO, spamd can use either all the time.  spamc can only do SSL if it's
built to support it.

I'm not quite sure why we changed it from "always link SSL if it's
available" , but ...

doh. now I remember why the ENABLE_SSL wasn't passed to configure: it detected 
the presence of the OpenSSL libs automagically. 
 
Should we change the fix from bug 3569 so it passes the --enable-ssl only if 
ENABLE_SSL was given so its still determined automagically else? 
 
I actually prefer the current, new behaviour: It's more deterministic and 
linking against OpenSSL can be a real PITA because the interface often isn't 
binary compatible even between minor releases. 

I have some problems trying to use this:

In spamd, --version doesn't show up in in the usage display. Is that a bug?

I tried to use this by adding the following to SATest.pm:

I declared our $SSL_AVAILABLE; where the other our variables are declared, and
assigned it in sa_t_init after the commands for calling spamd and spamc are
defined, using the statement:

$SSL_AVAILABLE = ((`$perl_cmd ../spamd/spamd --version` =~ /with SSL support/) &&
                  (`$spamc -V` =~ /with SSL support/));

The problem is that spamc -V writes only to stderr. Can it go to stdout to make
it easy to capture with `spamc -V` or is there a simple way I don't know about
to do it with stderr? Remember that redirection syntax will not work with the
system command when running under Windows.

By defining and assigning $SSL_AVAILABLE in SATest.pm, it is available for my
spamd_ssl.t test to use to decide whether to run.

Yeah, --version should probably appear in spamd's usage. The same is true for 
--help. 
 
The version output should really go to stdout, don't ask me why I directed it 
to stderr when I wrote that code. Revised patch follows.  
 
(Side note: eat least under Windows XP's cmd.exe '2> &1' works :) 

Created attachment 2088 [details]
combined patch with stdout instead of stderr

Created attachment 2089 [details]
Test case that spamd/spamc work using SSL

A test case t/spamd_ssl.t and test key/certificate files to be installed in
t/data/etc/

The code in spamd_ssl.t refers to $SSL_AVAILABLE which is assumed to be set in
SATest.pm as per my comment, and which depends on the other patches uploaded
for this bug.

> at least under Windows XP's cmd.exe '2> &1' works :) 

Oh, right, it's some other case involving exec and redirection that doesn't work
under Windows whicn we had to deal with for forking a spamd for testing. My
brain refuses to retain exactly what that case is without looking it up again
every time :-)

Are any of these sent over the wire or something that needs to be read?

If so, this sort of information should be put into an easily parsed format
that would support more compile-time options than just SSL, the SSL
version number, etc.

Created attachment 2090 [details]
patch for t/SATest.pm to define $SSL_AVAILABLE

This patch uses the patches that are here for spamc and spamd to set a variable
$SSL_AVAILABLE that is used by the new test case spamd_ssl.t submitted in
another patch.

This completes the patches for this bug.

I vote +1

By the way, I pulled out the fix for bug 3527 and verified that this test case
would have caught that, as well as the build problem that was fixed for bug 3569

-1 for the test stuff.  this ticket isn't about a ssl test.  feel free to open another ticket/etc.

> this ticket isn't about a ssl test

Ah, ok. I thought of it as coming out of my question about the test on the
mailing list. But a mailing list post is not a ticket either... I'm off to file
a ticket...

I'm still +1 on the non-test parts of this one.

+1 on patch 2088

+1 on 2088

committed.  r22683