You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2002/05/30 07:42:54 UTC
httpd-2.0 STATUS
* Port of mod_ssl to Apache 2.0:
The current porting state is summarized in modules/ssl/README. The
remaining work includes:
(1) stablizing/optimizing the SSL filter logic
(2) Enabling SSL extentions
(3) Trying to seperate the https filter logic from mod_ssl -
This is to facilitate other modules that wish to use the https
filter or the mod_ssl logic or both as required.
This is all so out of date, is modules/ssl/README even valuable anymore?
Shall we dump this little section from STATUS altogether [the port is finished]
and add new items in STATUS as we see them [e.g. number 3 above?]
Bill
Re: httpd-2.0 STATUS
Posted by Doug MacEachern <do...@covalent.net>.
On Thu, 30 May 2002, William A. Rowe, Jr. wrote:
> Perhaps we could resurrect the porting history [although I believe it's
> horribly
> incomplete] as modules/ssl/HISTORY? OTOH, those parts that are correct
> aught to have been committed to CHANGES if they were not in the first place.
they are in CHANGES, but it is HUGE. a summary is nice rather than
having to sift through that file. the httpd CHANGES file is not very
useful imho. too much info for users, to little for developers.
i like what Perl and PHP do, Changes is generated from the perforce/cvs
logs, has filenames, dates, submitter, committer, etc., handy for
developers.
then perldelta.pod contains a brief summary of the Changes that is
useful and easy for users to understand. PHP has something similar, but
calls it NEWS i think.
Re: httpd-2.0 STATUS
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 12:02 PM 5/30/2002, you wrote:
>i see value the old modules/ssl/README. it has been very handy in the
>past, and i would expect it to be for anybody coming from mod_ssl 1.3
>based sources to contribute to 2.0 or even just being brand new to the 2.0
>source. now they have lost the source roadmap, summary of major changes,
>incompatibilities, etc. todo items being in modules/ssl or in the
>top-level STATUS, i don't really care. but why blow away the rest of the
>useful info that was in there?
The TODO list has moved to STATUS so that's good.
Based on feedback, I'll create a top-level LAYOUT describing the directory
trees within the httpd-2.0 layout, and fill in the SSL items from the old
README.
This allows any developers to grasp any part of the server [including mod_ssl]
without jumping between different files and different conventions for each of
the server's components.
Perhaps we could resurrect the porting history [although I believe it's
horribly
incomplete] as modules/ssl/HISTORY? OTOH, those parts that are correct
aught to have been committed to CHANGES if they were not in the first place.
What I -don't- want is to continue special-casing modules where each has
their own conventions for additional developer documentation and files.
This will continue to be an issue when modules like proxy jump from their
own sub-projects for development into the httpd-2.0/modules repository
for general inclusion in the server.
Bill
RE: httpd-2.0 STATUS
Posted by Sander Striker <st...@apache.org>.
> From: Justin Erenkrantz [mailto:jerenkrantz@apache.org]
> Sent: 30 May 2002 18:38
> On Thu, May 30, 2002 at 10:43:54AM -0500, William A. Rowe, Jr. wrote:
> > Then I'll ask a simple question before I resurrect ... Do we want individual
> > READMEs or LAYOUTs that describe all the files throughout each Apache
> > source tree directory, only one top-level LAYOUT that describes the entire
> > directory tree and it's contents, or neither?
> >
> > List, what is your preference?
>
> +1 for one file at the top-level. -- justin
I'll see your +1 and raise you 1.
Sander
Re: httpd-2.0 STATUS
Posted by Justin Erenkrantz <je...@apache.org>.
On Thu, May 30, 2002 at 10:43:54AM -0500, William A. Rowe, Jr. wrote:
> Then I'll ask a simple question before I resurrect ... Do we want individual
> READMEs or LAYOUTs that describe all the files throughout each Apache
> source tree directory, only one top-level LAYOUT that describes the entire
> directory tree and it's contents, or neither?
>
> List, what is your preference?
+1 for one file at the top-level. -- justin
Re: httpd-2.0 STATUS
Posted by Doug MacEachern <do...@covalent.net>.
i see value the old modules/ssl/README. it has been very handy in the
past, and i would expect it to be for anybody coming from mod_ssl 1.3
based sources to contribute to 2.0 or even just being brand new to the 2.0
source. now they have lost the source roadmap, summary of major changes,
incompatibilities, etc. todo items being in modules/ssl or in the
top-level STATUS, i don't really care. but why blow away the rest of the
useful info that was in there?
Re: httpd-2.0 STATUS
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 01:07 AM 5/30/2002, you wrote:
>On Thu, 30 May 2002, William A. Rowe, Jr. wrote:
>
> > is modules/ssl/README even valuable anymore?
>
>yes. fine to remove the stale stuff, but not the whole damn thing. there
>was a useful roadmap of the source in there ...
Then I'll ask a simple question before I resurrect ... Do we want individual
READMEs or LAYOUTs that describe all the files throughout each Apache
source tree directory, only one top-level LAYOUT that describes the entire
directory tree and it's contents, or neither?
List, what is your preference?
I'll be happy to create the single template or all the LAYOUT skeletons
and the group can populate all of them over time?
>... and everything that was in the
>TODO section is still valid:
>
> o SSL renegotiations in combination with POST request
> o Port all remaining code (code inside #if 0...#endif blocks)
> o Do we need SSL_set_read_ahead()?
> o the ssl_expr api is NOT THREAD SAFE. race conditions exist:
> -in ssl_expr_comp() if SSLRequire is used in .htaccess
> (ssl_expr_info is global)
> -is ssl_expr_eval() if there is an error
> (ssl_expr_error is global)
> o SSLRequire directive (parsing of) leaks memory
> o Diffie-Hellman-Parameters for temporary keys are hardcoded in
> ssl_engine_dh.c, while the comment in ssl_engine_kernel.c says:
> "it is suggested that keys be changed daily or every 500
> transactions, and more often if possible."
> o ssl_var_lookup could be rewritten to be MUCH faster
> o CRL callback should be pluggable
> o session cache store should be pluggable
> o init functions should return status code rather than ssl_die()
> o ssl_engine_pphrase.c needs to be reworked so it is generic enough
> to also decrypt proxy keys
> o the shmcb code should just align its memory segment rather than
> jumping through all the "safe" memcpy and memset hoops
Adding to our top-level STATUS, thanks Doug!!!
Bill
Re: httpd-2.0 STATUS
Posted by Doug MacEachern <do...@covalent.net>.
On Thu, 30 May 2002, William A. Rowe, Jr. wrote:
> is modules/ssl/README even valuable anymore?
yes. fine to remove the stale stuff, but not the whole damn thing. there
was a useful roadmap of the source in there and everything that was in the
TODO section is still valid:
o SSL renegotiations in combination with POST request
o Port all remaining code (code inside #if 0...#endif blocks)
o Do we need SSL_set_read_ahead()?
o the ssl_expr api is NOT THREAD SAFE. race conditions exist:
-in ssl_expr_comp() if SSLRequire is used in .htaccess
(ssl_expr_info is global)
-is ssl_expr_eval() if there is an error
(ssl_expr_error is global)
o SSLRequire directive (parsing of) leaks memory
o Diffie-Hellman-Parameters for temporary keys are hardcoded in
ssl_engine_dh.c, while the comment in ssl_engine_kernel.c says:
"it is suggested that keys be changed daily or every 500
transactions, and more often if possible."
o ssl_var_lookup could be rewritten to be MUCH faster
o CRL callback should be pluggable
o session cache store should be pluggable
o init functions should return status code rather than ssl_die()
o ssl_engine_pphrase.c needs to be reworked so it is generic enough
to also decrypt proxy keys
o the shmcb code should just align its memory segment rather than
jumping through all the "safe" memcpy and memset hoops