1.1 Apache and SSL [Long]

[Mark J Cox <ma...@ukweb.com>]

Theres been a bit of debate rolling around on the apache-ssl list over the
last few days about the status of the SSL patches.

Because of the large changes between 1.05 and 1.1 adding SSL to the new
version isn't trivial and hasn't yet been done by Ben or Sameer.
Apache-SSL-US customers are getting irate about not getting an upgrade (or
having to pay for it).

A number of months ago the consensus on this list was that protocol
extraction would be added to Apache (thus making the SSL additions a
single module).  A few people mentioned that we should integrate in the
SSL hooks and move the CVS archive out of the USA.

At the moment we have

* Apache-SSL (Ben)
	= Apache1.0.5 + Bens Hooks + SSLeay
	Source Available
	Can use outside USA, Free (Ben's copyright), No Verisign certificates

* Apache-SSL-US (Stronghold, Sameer [and Graphics 440 a VAR])
	= Apache1.0.5+ Bens Hooks + Sameers Hooks + SSLeay + RSAref +
	  Sameers CAtools
	Source Available
 	Can use only inside USA, Commercial, Verisign certificates

* Sioux (Thawte)
	= Apache1.0.5+ Thawte Hooks + SSLeay + RSAref + CAtools
	Source Available
	Can use in/out of USA, Commercial, Versign certificates

[RSAref needed only in the USA and incurs licensing fee around $100 a
server sold]

One message raises a few interesting issues and I've attached it.

Mark.

-------------------------
On Wed, 10 Jul 1996, Homer W. Smith wrote:
>
> > We (UUNET) had to go with Netscape for commerce servers, because the
> > Apache stuff just isn't ready for prime time.  For example, I
> > have read that when you SIGHUP the server to roll the logs (which we
> > have a cron job do every midnight), it rereads all the conf files and
> > you have to type the password to reactivate SSL.
>
>     I believe this can be done with a script.
>
> >
> > >     It is almost sure that most of the commercial world will gravitate
> > > towards apache and apachessl.  It is IMPERATIVE that there be a SINGLE
> > > COOPERATIVE channel for reporting bugs and getting them fixed quickly.  It
> > > is not acceptable to be told by the 1.05ssl people that they can't fix the
> > > apache bugs because they are only the ssl people, and then be told by the
> > > apache people that they can't fix the bug because they don't support 1.05
> > > any more.
> >
> > The Apache Group is volunteers, as I understand it, and non-SSL Apache
> > is free software.  Don't try to put demands on unpaid people.
>
>      This is fine.  Perhaps the apache group should reconsider their
> volunteer status and start making some money.
>
>      The POINT is that a hybrid situation where a moneyed product (ssl)
> is hooked onto a non moneyed product (apache) is going to create disaster
> in the long run.  You can't have a very expensive moneyed product (ssl),
> that people depend on to make their own money (our customers and their
> businesses) depending on a non moneyed product that is UNSUPPORTED by
> both sides except with attitude.
>
> > The eval version of Apache-SSL-US that I downloaded a few months ago
> > came with the set of patches that had been applied to it; they looked like
> > they had come from the Apache Group developers mailing list (which I
> > am not on).  But consider, from their point of view.  Thawte and C2
> > and the Apache Group are independent organizations.  They each do what
> > they can do and think is best, right?
>
> > Why burden your users with bugs
> > that you have a fix for, just because someone else hasn't decided to
> > release something including that fix yet?
>
>     Because you then create two tracks of software, with the
> concomittent confusions between the two.
>
>     A patched Apache 1.05 is no longer Apache 1.05.  It is misleading,
> incorrect and very bad business, it leads to confusions, rumors,
> and a lack of confidence which then leads to an inability to
> decide which way to turn.
>
>     I still don't KNOW if the 1.05ssl has the bug fixed in it that
> has been driving me nuts with 1.0 and which I was told was NOT fixed
> in standard 1.05.
>
> > >      It is also unacceptable that the ssl people are lagging behind the
> > > apache people.  This will greatly slow the development of apache as most
> > > of the commerical world will be stuck in the ssl version lagging behind.
> > > My customers are already screaming for 1.1, almost as loudly as the are
> > > screaming for ssl.  What do I tell them, you can't have both?  Do I run
> > > two servers?
> >
> > C2 and Thawte probably should have done their 1.1 SSL development
> > during the 1.1 beta period, so they'd have it ready within a week of
> > the 1.1 release, since the changes from 1.1b4 to 1.1 were minimal.
> >
> > >      1.) There needs to be one and only one track of the apache server.
> >
> > You can't force that on free software.  Sorry.
>
>      Then Apache should damn well make sure that SSL doesn't call
> their product Apache, as it no longer IS Apache.
>
>      *APACHE* has a vested interest that people use THEIR software,
> not someone else's hacked version of it.
>
> > >      3.) The version used by ssl MUST be fully and completely supported
> > > by the apache development team and MUST be identical to the non
> > > ssl version.
> >
> > That'd be nice.  Apache 1.0 hadn't been designed with the hooks to
> > support SSL so it wasn't possible.  In 1.1, that ought to be possible.
> > But keep in mind that the Apache Group isn't obligated to "support" anyone,
> > and since the SSL version of 1.1 isn't finished yet, it's possible
> > that during the porting, changes will be found which must be made to 1.1.
>
>      Remember I am not really talking obligation.  I am talking
> professionalism and looking out for Apache's own best interest.
>
>      They want to be the best, they want to be the defacto standard,
> they aren't all a bunch of grunges who don't give a damn what happens
> to their product or their name.
>
>      When Apache starts to let other's issue versions of their
> own software under identical names that have been hacked without
> notice, then I believe you have a long term problem, and it has
> nothing to do with money.
>
>      If Apache and SSL don't standardize their act, then everyone
> is going to go with the SSL version of Apache, and the Apache version
> will fall into disuse because people will know the SSL version is
> better.
>
>      Then who will test the Apache betas?  They will wait for SSL to
> come out with ITS paid for upgrade and we have Netscape/Microsnuff all
> over again.
>
>      The whole beauty of the Apache arrangement is we DO get to
> beta test it, and give feed back, and get patches.  That's how
> it got built.  They way they are going, they are locking themselves
> into SSL's commercial release, and that will be the end of it.
>
>      I strongly recommend they take over control of the situation.
>
>      Either they start issuing SSL themselves, which I would like to see.
>
>      Or they enforce name differentiation between their product
> and the SSL hacked versions.
>
> >
> > >      6.) It would also be nice if someone gave some thought to logging for
> > > virtual domains.  I have 80 virtual domains and growing.  I can't possibly
> > > create a log file for each one.
> >
> > Why not?  We do.  We run 40 Apache servers on each of about two dozen
> > machines, and each server has its own log files.  It's the easiest way
> > we can keep each customer's data straight.
>
>     You are running separate servers, rather than one right?
>
>     That involves 40 processes running at all times, rather than
> a few while the others are not being hit.
>
>     With hundreds of virtual domains I do not believe this is
> an efficient use of computer resources.
>
>     Maybe there is something I don't understand here.
>
> >
> > >  We need the ability to append the virtual
> > > domain AUTOMATICALLY to the begginning of each and every log record for
> > > everything INCLUDING ERRORS!
> >
> > You should be able to do this with mod_log_config, except perhaps for errors.
> > It would be nice to be able to associate errors with particular
> > requests more easily.
>
>     Yes, we have hacked the original 1.0 code to do this, just because
> the mod_log_config did not handle it.
>
>     Homer
>
>

Re: 1.1 Apache and SSL [Long]

[Paul Richards <p....@elsevier.co.uk>]

Ben Laurie writes:
 > > This setup is perfectly legal since the US folks never have anything to
 > > do with the SA server so there's no collaboration.
 > 
 > But that's essentially what is happening now. Except the US version doesn't
 > implement any non-exportable bits. If its going to then the protocol
 > abstraction would have to be in. And the protocol abstraction needs threads. 

Not really since the "Apache group" doesn't officially distribute SSL,
you and Sameer independantly release your own versions. Neither are the
same as each other or the mainstream Apache release. Personally, I
don't have a big problem with this but if Apache wants to integrate SSL
into the main  "official" version then a mirror server is the only way
around the US munitions law.

Re: 1.1 Apache and SSL [Long]

[Paul Richards <p....@elsevier.co.uk>]

David Robinson writes:
 > 
 > At the risk of sounding repititious,
 > a. Wouldn't having an SSL Apache outside the US prevent any US individuals
 >    from working on Apache?

Not if there was still a US server. The way FreeBSD works is that the
official releases are US only and come from WC but there's a mirror
site maintained in S. Africa that has separately implemented versions of
all the non-exportable bits.

This setup is perfectly legal since the US folks never have anything to
do with the SA server so there's no collaboration.

Re: 1.1 Apache and SSL [Long]

[Paul Richards <p....@elsevier.co.uk>]

Mark J. Cox writes:
 > Paul Richards wrote:
 > > We wouldn't move cvs out of the US, you'd just have another one somewhere
 > > else to do non-US releases from.
 > 
 > Then we have the scenario where nonUS people can't access the US tree and
 > US people can't access the nonUS tree.  So committing a bug fix to both
 > trees will be a problem.

Non-us Folks would still work on the US tree. I'll have to take a look
at the SSL code and thhink about this. It may not be separate enough for
this to work the way I thought it might. If it's not in separate files
then there'd be problems.

Re: 1.1 Apache and SSL [Long]

[Mark J Cox <ma...@ukweb.com>]

Paul Richards wrote:
> We wouldn't move cvs out of the US, you'd just have another one somewhere
> else to do non-US releases from.

Then we have the scenario where nonUS people can't access the US tree and
US people can't access the nonUS tree.  So committing a bug fix to both
trees will be a problem.

Mark

Re: 1.1 Apache and SSL [Long]

[Paul Richards <p....@elsevier.co.uk>]

Roy T. Fielding writes:
 > > At the risk of sounding repititious,
 > > a. Wouldn't having an SSL Apache outside the US prevent any US individuals
 > >    from working on Apache?
 > 
 > Putting it all into one CVS base, and then moving the CVS base outside
 > of the US, would certainly preclude my involvement while the ITAR

We wouldn't move cvs out of the US, you'd just have another one somewhere
else to do non-US releases from. As long as no SSL code leaves the US
then it'd be OK. The non-US guys would "independantly" re-implement those
bits of SSL that are done on the US server.

Re: 1.1 Apache and SSL [Long]

[Mark J Cox <ma...@ukweb.com>]

On Thu, 11 Jul 1996, David Robinson wrote:
> a. Wouldn't having an SSL Apache outside the US prevent any US individuals
>    from working on Apache?

I thought it would only prevent them from working on the SSL hooks, if
we keep them in a separate file then that would be fine.  I don't know
enough about the ITAR stuff though.

Mark

Re: 1.1 Apache and SSL [Long]

[David Robinson <dr...@esi.co.uk>]

On Thu, 11 Jul 1996, Mark J Cox wrote:

> Theres been a bit of debate rolling around on the apache-ssl list over the
> last few days about the status of the SSL patches.
> 
> Because of the large changes between 1.05 and 1.1 adding SSL to the new
> version isn't trivial and hasn't yet been done by Ben or Sameer.
> Apache-SSL-US customers are getting irate about not getting an upgrade (or
> having to pay for it).
> 
> A number of months ago the consensus on this list was that protocol
> extraction would be added to Apache (thus making the SSL additions a
> single module).  A few people mentioned that we should integrate in the
> SSL hooks and move the CVS archive out of the USA.

At the risk of sounding repititious,
a. Wouldn't having an SSL Apache outside the US prevent any US individuals
   from working on Apache?


 David.

Re: 1.1 Apache and SSL [Long]

[Brian Behlendorf <br...@organic.com>]

In my view, people only have a right to be irate about "service" if they
are paying for it; and there may be a perception there that the money they
paid to sameer for apache-SSL included support, which to them means fixing
bugs on a timely basis and incorporating new features from the non-SSL
distribution as quickly as possible.  If the customers have unrealistic
expectations, then the vendor either steps up to the challenge or corrects
the situation.  

Protocol abstraction is on my project plan for 2.0, along with
multithreading and autoconf being the other two "biggies".  Perhaps if Rob
has time he can comment on how well protocol abstraction could fit into
his apache-XX prototypes.  

	Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com  www.apache.org  hyperreal.com  http://www.organic.com/JOBS