Damien, Quoting the answer to "What are examples of when a crypto item is publicly accessible through ASF servers?" at [1]:
The less obvious example, is the point at which a subversion repository starts to include code that is specially designed to work with any other 5D002 item, whether that item is ever to be included within a product distribution or not. [1] http://www.apache.org/dev/crypto.html The calls to crypto are arguable. The calls to priv_key are not. Paul On Wed, Aug 19, 2009 at 3:30 PM, Damien Katz<[email protected]> wrote: > I disagree. I don't think why we need to remove calls to code that doesn't > encrypt anything. It doesn't matter that we have a dependency on the erlang > crypto lib, we simply aren't encrypting, or enabling encrypting. > > -Damien > > On Aug 19, 2009, at 3:07 PM, Paul Davis wrote: > >> Between William's response and reading the crypto page, I'm fairly >> certain that we either need to remove all calls to the priv_key and >> crypto modules from SVN or add the NOTICE. >> >> I'd vote for avoiding the export restrictions, but I'm pretty sure >> that we're gonna need to do something. >> >> Paul >> >> On Wed, Aug 19, 2009 at 2:55 PM, Damien Katz<[email protected]> wrote: >>> >>> There is no encryption inside of CouchDB and, there are no plans to add >>> encryption functionality. >>> >>> I'd rather not add export restrictions if it's unnecessary, since it is >>> intended to limit who can use it. >>> >>> -Damien >>> >>> On Aug 19, 2009, at 2:40 PM, Paul Davis wrote: >>> >>>> Damien, >>>> >>>> Looks like legal-discuss is suggesting that we fill out the notices >>>> [1]. The instructions [2] don't appear overly complicated but it does >>>> appear that you're the only one with the proper authority to make the >>>> updates to different web pages. >>>> >>>> Paul >>>> >>>> [1] >>>> >>>> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200908.mbox/%[email protected]%3e >>>> [2] http://www.apache.org/dev/crypto.html >>>> >>>> On Tue, Aug 18, 2009 at 1:49 PM, Damien Katz<[email protected]> wrote: >>>>> >>>>> On Aug 17, 2009, at 10:16 PM, Curt Arnold wrote: >>>>> >>>>>> >>>>>> On Aug 17, 2009, at 6:45 PM, Damien Katz wrote: >>>>>> >>>>>>> I don't think it's necessary as we aren't encrypting anything. We do >>>>>>> use >>>>>>> the crypto library, but only for generating random UUIDs. >>>>>>> >>>>>>> -Damien >>>>>>> >>>>>> >>>>>> Probably should have used "suspect" or "concerned" or something more >>>>>> speculative. Noticing that CouchDB would not start on an Erlang >>>>>> runtime >>>>>> without openssl was a bit jarring. OAuth would also seem to be have a >>>>>> significant likelihood of incorporating encryption. Those two facts >>>>>> seemed >>>>>> to warrant a message. >>>>>> >>>>>> The whole export license stuff is an quagmire that I've taken pains to >>>>>> avoid. Definitely think that you should check with legal-discuss if >>>>>> you >>>>>> have any questions. >>>>>> >>>>>> erlang_oauth has a module named oauth_rsa_sha1 which makes me suspect >>>>>> that >>>>>> it would need an export declaration. >>>>>> >>>>>> The following code snippet from couch_http_oauth.erl >>>>>> >>>>>> consumer_lookup(Key, MethodStr) -> >>>>>> SignatureMethod = case MethodStr of >>>>>> "PLAINTEXT" -> plaintext; >>>>>> "HMAC-SHA1" -> hmac_sha1; >>>>>> %"RSA-SHA1" -> rsa_sha1; >>>>>> _Else -> undefined >>>>>> >>>>>> appears to be at aware of specific encryption method. >>>>>> >>>>>> >>>>>> I also ran into this little snippet in couch_util.erl: >>>>>> >>>>>> %%% Purpose : Base 64 encoding and decoding. >>>>>> %%% Copied from ssl_base_64 to avoid using the >>>>>> %%% erlang ssl library >>>>>> >>>>>> If there is a required dependency on ssl elsewhere, the duplicated >>>>>> code >>>>>> probably should be eliminated. Also, the "license notice" doesn't >>>>>> give >>>>>> me >>>>>> much confidence. >>>>>> >>>>>> >>>>>> FYI: Encryption notice for Erlang ssl: >>>>>> http://erlang.org/doc/apps/ssl/index.html >>>>>> >>>>>> My wild guess is that the previous CouchDB releases did not need an >>>>>> export >>>>>> or cryptography notice if all they did was use the random number >>>>>> generator >>>>>> from the SSL module. erlang_oauth and couch_http_oauth seem to be >>>>>> aware >>>>>> of cryptographic methods which my reading means that they require some >>>>>> action, but exactly what I'm uncertain. >>>>> >>>>> I disagree. We don't encrypt anything and as far as I know neither does >>>>> any >>>>> of the Auth stuff, which just uses cryptographic strength hashes, not >>>>> encryption itself. >>>>> >>>>> -Damien >>>>> >>>>> >>> >>> > >
