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... http://httpd.apache.org/dev/dist/apache_2.2.4-win32-x86-openssl-0.9.8d.msi and it's source tree... http://svn.apache.org/viewvc/httpd/httpd/win32-msi/trunk/ 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 http://svn.apache.org/repos/asf/httpd/httpd/win32-msi/ 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. http://www.apache.org/dist/httpd/binaries/win32/patches_applied/ 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 mod_ssl.so, 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. www.example.com) 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 [EMAIL PROTECTED] Bill
