Re: ifdef APACHE_SSL

[Randy Terbush <ra...@zyzzyva.com>]

> This is before my time, but I thought that ifdef APACHE_SSL things could
> not be in the main source tree because the US gov't is stupid.
> 
> mod_rewrite has them.

I'm interested in starting a discussion about putting some of these 
hooks back in. I think things have cooled sufficiently that we 
could do this.

Re: ifdef APACHE_SSL

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

At 06:49 PM 7/5/97 -0400, Rasmus Lerdorf wrote:
>> I'm interested in starting a discussion about putting some of these 
>> hooks back in. I think things have cooled sufficiently that we 
>> could do this.
>
>We've discussed this briefly before.  As far as I understand things, the
>decision should be Brian's since the code would be available from his
>server.  He would be the only person taking any sort of risk.  However, I
>think the risk is non-existant.  I don't realistically see anybody going
>after someone like the Apache Group for this with all the talk about
>abolishing those export restrictions and courts refusing to uphold the
>bogus law.  I say go for it.  I would love to see a mod_ssl with
>appropriate hooks in standard Apache for it to work.

Two points:

1) The current "APACHE_SSL" hooks in mod_rewrite are not about crypto at
all, though if we are to follow the conventional wisdom that even hooks are
asking for trouble, then we should rethink that as a good name for a
#define.  In looking at those sections, here's my question - why not have
an "http_method" call in the core?  That's easy enough to do, and would
seem to obviate the need for the 2nd and 3rd use of the #define.  The first
use, though, is puzzling - apparently the section of code this wraps around
will only work if the client is using SSL.  Hmm?  Anyways, if there's an
easy way to get that #define out of the core code, it's a way to dodge the
issue for now.

2) Because the development effort is truly multinational, and because the
code has always been distributed in source form, the only way crypto would
go in the core is if it could be released under the same conditions as the
rest of the code.  Right now the *only* anti-gov-crypto effort underway
which would make this a possibility is the first amendment lawsuit being
pursued against the gov't by Daniel Bernstein and the ACLU.  I think they
have a very reasonable chance of succeeding, and if they do it will mean
that essentially all forms of speech involving cryptology will be allowed.
In so far as source code is "speech", this may open the door for us.  If
the lawsuit passes, I am willing to consider being a guinea pig for this,
though I'd like to talk with several people before doing that.  Also, John
Gilmore has expressed interest in helping us with this - he somehow was
able to get export permission for the secure DNS server he's been working
on with others, which I believe is a source-code release.  

In the meantime, we should definitely pursue a protocol abstraction layer
so SSL can be distributed separately with a minimum of fuss.

	Brian


--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
"Why not?" - TL                brian@organic.com - hyperreal.org - apache.org

Re: ifdef APACHE_SSL

[Lars Eilebrecht <La...@unix-ag.org>]

According to Marc Slemko:

> The other thing to consider is that, completely unrelated to the legal
> issues, a better abstraction would be good.  However, this probably has to
> wait for 2.0.  A good goal would be a completely abstracted setup so the
> SSL could be dropped in as a module.  If it is general enough, then there
> may be nothing to fear legally because they aren't crypto hooks, just
> anything hooks.

This is probably the best idea and maybe also makes it easier to include
other secure protocols like shttp as a module into Apache. BTW, has someone
taken a look at the shttp support in NCSA 1.6beta?

In my humble opinion the risk to get legal problems with any kind of
crypto hooks is extremely low...


Just my $0.02.

ciao...
-- 
Lars Eilebrecht
sfx@unix-ag.org

Re: ifdef APACHE_SSL

[Marc Slemko <ma...@worldgate.com>]

The other thing to consider is that, completely unrelated to the legal
issues, a better abstraction would be good.  However, this probably has to
wait for 2.0.  A good goal would be a completely abstracted setup so the
SSL could be dropped in as a module.  If it is general enough, then there
may be nothing to fear legally because they aren't crypto hooks, just
anything hooks.

Not sure if doing anything else for 1.3 would be good or not.



On Sat, 5 Jul 1997, Rasmus Lerdorf wrote:

> > I'm interested in starting a discussion about putting some of these 
> > hooks back in. I think things have cooled sufficiently that we 
> > could do this.
> 
> We've discussed this briefly before.  As far as I understand things, the
> decision should be Brian's since the code would be available from his
> server.  He would be the only person taking any sort of risk.  However, I
> think the risk is non-existant.  I don't realistically see anybody going
> after someone like the Apache Group for this with all the talk about
> abolishing those export restrictions and courts refusing to uphold the
> bogus law.  I say go for it.  I would love to see a mod_ssl with
> appropriate hooks in standard Apache for it to work.
> 
> -Rasmus
> 

Re: ifdef APACHE_SSL

[Rasmus Lerdorf <ra...@lerdorf.on.ca>]

> I'm interested in starting a discussion about putting some of these 
> hooks back in. I think things have cooled sufficiently that we 
> could do this.

We've discussed this briefly before.  As far as I understand things, the
decision should be Brian's since the code would be available from his
server.  He would be the only person taking any sort of risk.  However, I
think the risk is non-existant.  I don't realistically see anybody going
after someone like the Apache Group for this with all the talk about
abolishing those export restrictions and courts refusing to uphold the
bogus law.  I say go for it.  I would love to see a mod_ssl with
appropriate hooks in standard Apache for it to work.

-Rasmus