couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <dam...@apache.org>
Subject Re: Cryptography in CouchDB
Date Wed, 19 Aug 2009 20:16:15 GMT
What call to priv_key? Do you mean the calls to pubic_key? As far as I  
can tell we are only validating signatures.

"specially designed to work with any other 5D002 item"

We aren't specially designed to work with encryption, we are just  
using some code that happens to be bundled with an encryption library,  
but isn't encrypting anything.

-Damien

On Aug 19, 2009, at 3:56 PM, Paul Davis wrote:

> 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<damien@apache.org> 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<damien@apache.org>  
>>> 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/%3c4A8C2657.1090303@rowe-clan.net%3e
>>>>> [2] http://www.apache.org/dev/crypto.html
>>>>>
>>>>> On Tue, Aug 18, 2009 at 1:49 PM, Damien Katz<damien@apache.org>
 
>>>>> 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
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>


Mime
View raw message