mod_ssl (was: How to Add a Module to Apache)

[Greg Stein <gs...@lyra.org>]

On Sun, 12 Dec 1999, Eli Marmor wrote:
>...
> I understand that integrating crypto stuff, or even only EAPI
> patches, into the standard Apache, is too controversal, and there
> are other "competing" projects, such as KEAPI and the patches which
> are planned for Apache 2.0, as well as competing SSL implementations
> (Ben's) and the crypto limitations of U.S. (to be relaxed this week
> ???????).

There are a number of issues, yes, but "controversial" might be too strong
of a term. *shrug*

In Apache 2.0, there will be quite a few things to minimize the patch set
for mod_ssl. 2.0 has a "hooks" implementation and APR is theoretically
supposed to include the "mm" sub-package (it is there, but not really
integrated yet).

> The last thing that I want is a flaming war. So please, Jim (or
> whoever forwarded this message), tell them that it is only a forward
> and that I didn't have any intention to change the main source tree
> of Apache and/or to post this message to new-httpd mailing list.
> 
> (although that up to this minute, thanks God, nobody started this
> flaming war; But it will come, for sure!).

Don't worry about it so much. I've been reading new-httpd for a little
more than a year. I think the only time that I've actually seen a "flame
war" was the problem with the guys from Remote Communications. The Apache
Group is quite level-headed and generally resilient against flames; the RC
guys were just plain antagonistic and some of the AG members rose to the
bait :-)

> In addition, if the message was forwarded, it could be better to
> forward the previous messages too, at least the one discussing the
> patches required to insert into the patch scripts of UNIX and
> Windows, in order to make them "compatible".

I haven't seen the prior messages, but the one that Jim forwarded from you
was quite complete in itself. I think it raises a number of good issues
(which is probably why Jim forwarded it; otherwise, maybe an accident :-).

Personally, I would not recommend altering mod_ssl to be a complete
distribution. That makes it difficult to track changes in Apache and to
apply Apache patches. It kind of boils down to what would a person want to
see for their base, and what they want to incrementally apply (patch). I
think you would like to start with a solid Apache and then apply patches
against that (mod_ssl, mod_*, patchXXX, etc). Starting with an
Apache/mod_ssl combination generates a few issues with apply additional
patches, changes, modules, etc. I think it would also cause a small worry
in some people's minds of "how is the mod_ssl Apache different from the
regular distribution of Apache?" (other than the mod_ssl changes, which
can easily be inspected if mod_ssl remains as a patch set).

A combination distro can obviously be created... heck, it doesn't even
have to be Ralf to do it. Eli: you could be the Apache/mod_ssl combination
distro supplier :-). It might be interesting to see how many people are
truly interested in that combination.

I would simply recommend keeping mod_ssl as a patch set.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: mod_ssl (was: How to Add a Module to Apache)

[Eli Marmor <ma...@elmar.co.il>]

Scott Hess wrote:
(follows my answer)

1. As I already noted, it is off-topic for this mailing list. This
   thread is specific for mod_ssl, and should be discussed in its
   mailing list. When I respond to your message, I feel a little
   like a spammer, who forces many subscribers to read things which
   are not relevant for them. This is why the thread was began at
   that mailing list, and the forward to here was not done by me.
   I didn't bring it to here, so I ask anybody who respond to do it
   through the original list, and/or my personal e-mail address.

2. The current discussion, at least for the last 48 hours, is not
   "how to create a merged source tree", but "how to make the
   different patch script (e.g. UNIX, Windows), compatible with
   each other", so the source trees created by them will be equal
   (to see the last development in this field, look at:
http://www.progressive-comp.com/Lists/?l=apache-modssl&m=94516756227897&w=2

3. Even the original discussion (about migrating to a distribution
   of a merged source tree), is only semantical. It's like when
   A+B=C, and A is known, and the argument is whether to supply B
   and get C as a result of a '+' operation, or supply C and get B
   as a result of a '-' operation. Both operations can even be
   automated, by complex scripts. Yes, C is what most users are
   interested in (and not B), but this was not the main motivation;
   The main difference between the '-' operation and the '+', is
   that it is a nightmare to support '+' under different platforms.
   Windows, for example: Any change which is done in "configure"
   (you see?  It's not only off-topic, but even deals with specific
   files of mod_ssl!), which is a shell script for UNIX, must be
   replicated in "configure.bat", which is written in a different
   language (perl), and then the updated perl-script must be tested
   under Windows. Moreover, to use this "configure.bat", a naive
   and poor user must download perl, patch.exe, and other packages.
   Using your words: "Keeping two development branches in sync is
   painful", I'm convinced that you will agree with me when you
   will know the full details.

4. You don't have to teach me the pain of maintaining patches,
   either as deltas/diffs/pathces, or as two parallel versions. I
   have too much experience with this, in dozens of projects I did
   in the last years, including a project with hundreds of patches
   to Motif (since 1.0, through all the minor versions, to 1.2.5),
   and including xterm (again, hundreds of patches, though many
   versions, etc.).

5. If you are so concerned about having two versions, please vote
   for including EAPI patches in 1.3.10. It doesn't break anything
   (because it is disabled by default and ifdefed), and it doesn't
   have anything to do with crypto. These patches are used for
   various purposes, and nobody should suffer only because some
   people (about 100,000, according to some statistics) use it as
   hooks for mod_ssl. Even when hooks were disallowed, it referred
   only to hooks which their only purpose was crypto, otherwise -
   even the standard Apache was considered as crypto...  (but
   IANAL...)

Scott Hess wrote:
> 
> Eli Marmor <ma...@elmar.co.il> wrote:
> > I only thought that it would be easier to use "diff" to show the
> > differences, than to use complex scripts (not only "patch") to apply
> > the patches. Don't forget, Windows users must download many tools for
> > any simple patch script, such as perl, patch.exe, etc.
> 
> As you noted earlier, all things considered the end-user has a lot of pain
> applying the patches, and developers can generally handle diff'ing things
> with little or no pain.
> 
> Unfortunately, it's the developers which cause progress in Apache, not the
> end users, at least directly.  If there are two Apache distributions, they
> _will_ be out of sync with each other.  Developers will generally only
> patch the version they are using.  If all patches are required to apply
> cleanly to both distributions, then less development will feed back into
> Apache.
> 
> Beyond that, I think you overestimate the ease of using diff to show
> differences.  Keeping two development branches in sync is painful in
> proportion to the square of the number of expected differences, at minimum.
> If you've ever been on a project trying to do that, you even start to
> wonder if the pain is proportional to 2 to the power of the number of
> expected differences...
> 
> Later,
> scott

-- 
Eli Marmor

Re: mod_ssl (was: How to Add a Module to Apache)

[Scott Hess <sc...@avantgo.com>]

Eli Marmor <ma...@elmar.co.il> wrote:
> I only thought that it would be easier to use "diff" to show the
> differences, than to use complex scripts (not only "patch") to apply
> the patches. Don't forget, Windows users must download many tools for
> any simple patch script, such as perl, patch.exe, etc.

As you noted earlier, all things considered the end-user has a lot of pain
applying the patches, and developers can generally handle diff'ing things
with little or no pain.

Unfortunately, it's the developers which cause progress in Apache, not the
end users, at least directly.  If there are two Apache distributions, they
_will_ be out of sync with each other.  Developers will generally only
patch the version they are using.  If all patches are required to apply
cleanly to both distributions, then less development will feed back into
Apache.

Beyond that, I think you overestimate the ease of using diff to show
differences.  Keeping two development branches in sync is painful in
proportion to the square of the number of expected differences, at minimum.
If you've ever been on a project trying to do that, you even start to
wonder if the pain is proportional to 2 to the power of the number of
expected differences...

Later,
scott

Re: mod_ssl (was: How to Add a Module to Apache)

[Eli Marmor <ma...@elmar.co.il>]

Greg Stein wrote:

> more than a year. I think the only time that I've actually seen a "flame
> war" was the problem with the guys from Remote Communications. The Apache
> Group is quite level-headed and generally resilient against flames; the RC
> guys were just plain antagonistic and some of the AG members rose to the
> bait :-)

Remember, remember...

> > In addition, if the message was forwarded, it could be better to
> > forward the previous messages too, at least the one discussing the
> > patches required to insert into the patch scripts of UNIX and
> > Windows, in order to make them "compatible".
> 
> I haven't seen the prior messages, but the one that Jim forwarded from you
> was quite complete in itself. I think it raises a number of good issues
> (which is probably why Jim forwarded it; otherwise, maybe an accident :-).

In short, it discusses the current anomally that each platform (UNIX,
Windows) has its own patch script, in a different language (shell,
perl), and so on. I inspected the differences between the different
scripts, and found a way to produce the same source tree for all the
platforms, so you can apply the patches under one platform and move
it to another before building it. I don't want to quote the message,
because it discusses technical issues specific to mod_ssl, file-names,
etc.

> Personally, I would not recommend altering mod_ssl to be a complete
> distribution. That makes it difficult to track changes in Apache and to
> apply Apache patches. It kind of boils down to what would a person want to
> see for their base, and what they want to incrementally apply (patch). I
> think you would like to start with a solid Apache and then apply patches
> against that (mod_ssl, mod_*, patchXXX, etc). Starting with an
> Apache/mod_ssl combination generates a few issues with apply additional
> patches, changes, modules, etc. I think it would also cause a small worry
> in some people's minds of "how is the mod_ssl Apache different from the
> regular distribution of Apache?" (other than the mod_ssl changes, which
> can easily be inspected if mod_ssl remains as a patch set).

I only thought that it would be easier to use "diff" to show the
differences, than to use complex scripts (not only "patch") to apply
the patches. Don't forget, Windows users must download many tools for
any simple patch script, such as perl, patch.exe, etc.

> A combination distro can obviously be created... heck, it doesn't even
> have to be Ralf to do it. Eli: you could be the Apache/mod_ssl combination
> distro supplier :-). It might be interesting to see how many people are
> truly interested in that combination.

A good idea!

I must check before, what is Israel's policy regarding to crypto
stuff, but if it is not a problem, I'll probably do it. In any case,
if my suggestion regarding to unifying of the patch scripts for the
various platforms will be adopted (Ralf?), then 90% of the work will
be already done.

-- 
Eli Marmor