httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject ReCap: 2.2.4 windows binary w/ssl?
Date Mon, 19 Feb 2007 04:01:43 GMT
William A. Rowe, Jr. wrote:
> I'd like to propose we ship apache_2.2.4-win32-x86-openssl-0.9.8d.msi with
> this release.

As such... I'm requesting review and feedback of the first installer
package candidate to include ssl...

and it's source tree...

which includes everything not incorporated from the official 2.2.4 release
tarball build (other than the msvcrt .msm merge module from Microsoft
which is pulled in automatically by InstallShield as a conditionally
installed item when MSVCRT 6.0 is less modern or isn't already installed.)
Yes, I understand the XML is hard to 'review' per-say, but as Roy had hinted
in the November report, this is a source code tree which needs the same sort
of review as the httpd primary branch.

The reason for to
remain out-of-tree (and for goodness sakes, the reason to REMOVE the .pkg
and .rpm generation sources) is that packaging after the tree is tagged
is largely a game of catch-up, and is a stupid reason to throw away the
release tag because they've fallen out-of-sync.

(I would have tagged already, but let's revise, then tag as adopted when
the package is suitable for distribution.)

Specific recap of this thread to date;

> apache_2.2.4-win32-x86-ssl.msi was the anticipated name.  The more I consider
> how tightly bound such a distribution is to openssl, and the version bound to
> the various security features in the corresponding release of openssl, the
> more I think we need an explicit package name.

Therefore, done - and the BIS notification reflects this.

> The zlib package used today is stock 1.2.3 with the /Oy- optimization override,
> to ensure we can read the Dr Watson backtrace for a crash report with or w/o
> the user deploying .pdb files.  It adds .pdb generation (/Zi linked with the
> /debug /opt:ref flags) which adds no overhead to the binary, but creates a
> parallel .pdb file. includes
this zlib-1.2.3-vc32-2005-rcver.patch.  (Always has, no change here.)

> The openssl package will be built also with /Oy- disable to ensure we can read
> backtraces (even more critical given how we hook into the module!) and also
> generating .pdb files.  It will be configured no-mdc2 no-rc5 no-idea enable-zlib
> against the zlib package I cited above.  (This is not zlib-dynamic!!! That would
> be a thread-unsafe choice :)

openssl-0.9.8a-vc32-2005.patch (same dir) fell out-of-sync, the new patch to
0.9.8d much smaller, will post it up.

> Note that the package then includes, and ab.exe compiled against
> openssl for https: stress measurement.  It also includes openssl.exe for the
> generation of keys and certs.

Note - to use openssl.exe one must tell OPENSSL_CONF envvar the path-to an
openssl.cnf, now copied from the openssl source package into Apache2.2/conf/.

We might consider a patch to make the prompt more sensible, e.g. patch
[ req_distinguished_name ]
CommonName = Common (Server) Name (e.g.

since the default prompt "Common Name (eg, YOUR name) is entirely nonsense :)

> A final question for all, do we wish to install an arbitrary, on the fly self
> signed default.crt/default.key?  Do we want to help them fill out the details
> or use stock details?  Or do we want them to use openssl.exe to generate one
> for themselves?

The consensus by jerenkrantz and I is - looking at the fact that other packages
do -not- do this by default (in httpd-2, what the modssl project has done isn't
relevant) and that #include httpd-ssl is commented out by default.  Our
opinion leans to not creating a cert by default.

Issac Goldstand respectfully disagrees and suggests a GUI-tool would be
nice to prompt users to enter the certificate information.

Jorge Schrauwen has interesting comments for both arguments.

A static example key is straight out.

Everyone agrees that a batch file or something that would help the users make
a server certificate would be goodness; this isn't a win32-specific issue,
either, if you examine the most FAQ'ed on users@.


View raw message