Hi Madhu, * MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) ([EMAIL PROTECTED]) wrote: > I haven't gone through the entire stuff, but some quick questions, based on > your patch :
Thanks for the initial feedback, it's certainly useful to know this code has been on other people's minds, and that I didn't just stumble onto something old and forgotten. > 1. I thought we should not be enforcing openssl version number checks > (something like - openssl version SHOULD be > 0.9.6i) - mainly because ppl. > can apply patches to their previous versions of OpenSSL, and thus avoid > security problems.. (ofcourse, I know you're coming from the OpenSSL > background, but that was the message I got here when I tried doing something > like that) I put the version checks in simply because there are version checks in the existing M4 stuff and I would have thought it unacceptable to the ASF for me to remove them! :-) The current version checks are implemented in a cock-eyed fashion and are also out of date (0.9.6e used to be a meaningful cut-off point, but that has changed more recently). It would perhaps make sense to provide a "--force-ssl-ver" type of option that would bypass version checks, and then have any version checking failure text point out the existence of "--force-ssl-ver". This way, the more determined users can force configure to bypass that, whilst it still provides a certain safety-net for the more naive and less intrepid against accidently meddling with known-to-be-out-of-date support libraries. > 2. Regarding hardcoding "openssl/some_header_name.h", I think it's a bad > idea - how about ppl. who want to use other SSL toolkits along with apache > ?. Erm, like what? The only candidate I can think of would be the RSA-C toolkit? If so, I would say that it doesn't make much sense to try and deliberately reduce the focus (or increase the blur, if you prefer) of the configuration checking so that something other than openssl still slips through the configuration looking like openssl. The complexity doesn't seem worth the trouble to me. To support other SSL toolkits, the more sensible approach would be to introduce alternative autoconf checks that are tailored to those toolkits. But anyway, I find it difficult to imagine that the existing version checks in Apache's configure was letting through alternative toolkits anyway?? So perhaps something like "--with-rsa-c" could be implemented, and it would be able to target RSA-C directly without needing to be fudged to only check things common to both RSA-C and OpenSSL. Likewise, the includes in mod_ssl.h should be #ifdef,#elif,#endif'd so that you get precisely the headers you need for precisely the toolkit you are using (and using precisely the header paths defined in the respective API). The more things go, the more OpenSSL and RSA-C are likely to diverge - I strongly suspect they've already diverged too far for the code in its current form, but perhaps I'm mistaken there. If the only issue right now between the two is what prefix we do or don't add to the include paths, then that should be considered extremely good fortune. Sooner or later though, we'd end up needing to separating things with precompiler logic to handle differences between toolkits, syntax, symbol definitions, enhancements, optional extras, etc. Failing to do that in the autoconf support or the SSL/TLS module code puts Apache in a position of being dependant on two entirely independant development projects remaining "similar enough". That's not a solid position to maintain, and you lose any ability to tune to (or benefit from) a toolkit's evolution. It also goes against the grain of why things like autoconf exist. Of course, I'm hardly about to donate hours or days of my own time to further RSA's commercial cause. :-) But if doing some re-organisation work will benefit apache and openssl as well, I wouldn't begrudge helping create targetted support mechanisms for both OpenSSL and RSA-C. It certainly seems a better way to go than taking a hands-off approach to the use of fork()d toolkits - nobody can give Apache or its users any guarantees that they'll be able to rely on continued similarities. Or were you referring to SSLeay? Or compability layers built on top of something else? Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/
