apr-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: Proposed Crypto Notification process
Date Mon, 31 Jul 2006 05:12:26 GMT

I realize you've done your best to create crystal clear answers to Justin's
and my questions below at the http://www.apache.org/dev/crypto.html page.
But your followup to this post would be most valuable so we can close this
cycle and complete our notification.  Call this a final sanity check ;)


William A. Rowe, Jr. wrote:
> Justin Erenkrantz wrote:
>> On 7/4/06, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
>>> That's my question... Cliff?  Is OpenSSL, in the context of being one component
>>> of the APR-util "product", or the Apache HTTP Server "product", its own,
>>> independent "product" that apr or httpd pmc's should be notifing the BIS of
>>> on its own?
>> My interpretation from Cliff is that OpenSSL is its own product and
>> that we have to perform notification for it since our product (be it
>> APR or HTTP Server) uses this other product that has crypto
>> functionalities.  We can include the BIS notice for OpenSSL in the one
>> email we send along with our notification.
> That's the question, isn't it?  Do we include OpenSSL in our BIS notice for
> our "APR-util" product?  Or send a BIS notice for "OpenSSL".  Since we don't
> produce the "OpenSSL" product, and I don't see us offering an "OpenSSL"
> download (only that there would be an openssl binary on some platforms that
> don't ship openssl as part of their base installation), I don't expect the
> later makes any sense.  This is  after I read Roy's comments on the "product"
> orientation for the regulations, and then heard Cliff's comments on how the
> BIS views a "product" and how they view the relationship of components
> (short answer; show us all the code, wherever it resides, in one notice, and
> then you can keep releasing it and distributing binaries of it.)
>> Likewise, the issue, as I understood it, was that *all* downstream APR
>> developers (Subversion, log4j, etc.) will now have to notify BIS about
>> their own products whenever they release as they now have a dependency
>> upon BIS-notifiable code.  Hence, they have to notify BIS about their
>> own projects and APR-util and OpenSSL now too.  Yikes.
> Right, so does svn provide four notices, of the "OpenSSL product", the
> "APR-util product", the "httpd product", and the "svn product"?
> No... that would be asinine ;-)  The send a single notice for the svn product
> once, that points to the dev trunk of svn (where all new crypto is first
> introduced) and pointers to the dist trees of httpd, apr-util (as this is
> increasingly unbundled from httpd) and OpenSSL.
> When a project ships on a dependency of another project, the dist tree seems
> so much more sane.  (They only distribute a 'shipped' version of the dependent
> libraries they require).  But the moment new crypto code hits, it should be at
> the location that BIS was told of (dev trunk/).
>> Of course, Cliff can (should!) reply too - but that's the impression I
>> got from him when talking about this during ApacheCon.  This is why I
>> mentioned in my earlier email that we'll need to notify regarding
>> OpenSSL too and why our downstream devs will have to do likewise.  I'd
>> *really* love to be wrong on this - so that we don't have to notify
>> for OpenSSL and that other projects don't have to notify for APR too;
>> but Cliff seemed pretty clear on this.
> +1   Yup - let's pause for his comments.
> Cliff made it clear our notification includes OpenSSL.  We've
> interpreted him differently on how ;)

I'll rephrase this; our notification includes OpenSSL only if we ship OpenSSL,
e.g. complete binary packages (we expect we would do this down the road.)

Likewise downstream users will be required to notify about apr-util, OpenSSL,
mod_ssl and httpd only if they ship a complete binary stack (as some of our
windows 3rd party friends already do, fortunately for their headaches, they
do so from Canada and elsewhere.)

But an external 'httpd module' type of project wouldn't have to notify
of httpd/mod_ssl/apr_util/OpenSSL unless they ship that whole stack for
their own binary distribution.  But if their code uses the https:// feature
of httpd, or the apr_ssl_socket feature of apr-util, their own code becomes
crypto-enabled, and therefore subject to notification requirements.  Right?

View raw message