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<[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
