httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: restructuring mod_ssl as an overlay
Date Wed, 07 Jun 2006 20:39:08 GMT
Roy T. Fielding wrote:
> 
> Thoughts?  Anyone have any better ideas?

+1 to an overlay; I know you have - but for the rest of the participants, also
consider that it 'illegal' to have crypto in some jurisdictions (and actually
if you are traveling to some jurisdictions it's best to leave your ssl enabled
laptop with all of the cool crypto features as home.)  This would help people
who are complying with jurisdictional restraints to avoid the whole issue and
to continue to use httpd.  I won't add any political comments in this thread
about this wisdom of said laws.

On the T-8 prohibited countries list, note it is a crime to export technologies
to them (it's hard for the US to define a crime to obtain said technologies in
a foreign jurisdiction - let's not get into that debate).  However, as a 'public
download' I believe we are now  exempted from trying to discern where these
parties are.  Providing both the base server and an ssl feature demonstrates 
good faith that we are providing unrestricted access to our httpd sources, and
permitting our users to avoid mod_ssl/crypto.

On very important points;

      we have to file export notices prior to each release in which
      the crypto capabilities are changed;

This means the strength of the crypto or feature set.  This doesn't mean that if
we fix a null-deref bug we provide notification.  Does apr's sha1 and m5 hashing
still fall into this category?

      we have to file export notices prior to publishing each binary
      package that includes mod_ssl and the notice must include a
      URL to the 100% open source version of that package;

and

      we can only distribute binary versions of openssl if we can point
      to the 100% open source package from which it was built *and*
      file an export notice for that package prior to our publication;

seem in once sense to be the same issue.  Package mod_ssl + OpenSSL 0.9.7i
and does this become one notification or two seperate notifications?

When/If OpenSSL 0.9.8 is distributed 'by us', it's crypto capabilites are
changed (notably ECC) so renotification is absolutely required.  Less clear
when we go from 0.9.7i to 0.9.7j (it happened to be a buildfix release) what
is required.

But if I understood Cliff's research and even our earliest legal advise, it's
not the 'binaries' we notify BIX of, it's actually the "source", so it wouldn't
seem that once we have notified them of the source code to our packages, that
any renotification would be needed for individual binaries.

Are we 100% certain the 'hooks' for plugging in mod_ssl themselves are now
totally and completely clear of all this garbage?  That was once a concern back
in the 90's, and I'm almost certain it's technically irrelevant now.

   c) each redistributor (re-exporter) of our packages must do the same

Yes, that's always been true.  If they sell it, notification may not be enough,
they become a 'commercial exporter'.  But that's their problem to follow the
laws, not ours, and that's the answer we provide to all folks asking for our
internal lists for clarification.  "Our terms" with the BIX don't map 1:1 to
their terms and they need to handle their export independently of the ASF.

Another marvelous justification for moving mod_ssl from /repos/asf/httpd/httpd/
over to /repos/asf/httpd/mod_ssl/ with a big fat NOTICE.txt sitting there that
it contains crypto.  If someone wants to redistribute without hassle, there's
a tarball with no encumberances to set up http:.

Bill

Mime
View raw message