You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Paul Davis <pa...@gmail.com> on 2009/08/19 02:29:05 UTC
Cryptography in CouchDB
Legal Heroes,
Curt Arnold brought up on dev@couchdb.a.o that we may need to be
checking into the process for cryptography exports. After reading [2]
I found an interesting FAQ that almost seems to maybe affect us, but
I'm not entirely certain.
Quoting [2]:
> If my project ships a binary that provides bindings to OpenSSL, but does not
> include its source or binaries, what notifications must be made?
>
> The only required notification for an Apache project that is specially designed
> to use, but doesn't include, such crypto, is just the notification for the ASF
> product code.
There are two main spots of concern in CouchDB:
Situation one:
* We have a direct dependency on the Erlang crypto module [3]
* The Erlang crypto module makes calls to OpenSSL
* The only calls we make to crypto are, sha_mac, sha, rand_bytes and
rand_uniform, none of which would appear to be cryptographic in
nature.
Situation two:
* One of our dependencies uses the Erlang module priv_key [4]
* priv_key is only available in the most recent versions of Erlang so
we've disabled compiling that part of the dependency. (we prevent our
dependency from compiling code that would call the priv_key module.)
In general, the basic question is: What are the proper steps related
to code that makes calls into a library that may or may not be calling
OpenSSL? Does this constitute "providing bindings"? If this does place
restrictions on us, what are they and what should be done about them?
Thanks for your help,
Paul Davis
[1] http://mail-archives.apache.org/mod_mbox/couchdb-dev/200908.mbox/%3C0C366699-9810-4738-BC93-EEF12C5C6674@apache.org%3E
[2] http://www.apache.org/dev/crypto.html
[3] http://erlang.org/doc/apps/crypto/index.html
[4] http://www.erlang.org/doc/man/public_key.html
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Cryptography in CouchDB
Posted by Robert Burrell Donkin <rd...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Paul Davis wrote:
> Legal Heroes,
>
> Curt Arnold brought up on dev@couchdb.a.o that we may need to be
> checking into the process for cryptography exports. After reading [2]
> I found an interesting FAQ that almost seems to maybe affect us, but
> I'm not entirely certain.
>
> Quoting [2]:
>
>> If my project ships a binary that provides bindings to OpenSSL, but does not
>> include its source or binaries, what notifications must be made?
>>
>> The only required notification for an Apache project that is specially designed
>> to use, but doesn't include, such crypto, is just the notification for the ASF
>> product code.
>
> There are two main spots of concern in CouchDB:
>
> Situation one:
> * We have a direct dependency on the Erlang crypto module [3]
> * The Erlang crypto module makes calls to OpenSSL
> * The only calls we make to crypto are, sha_mac, sha, rand_bytes and
> rand_uniform, none of which would appear to be cryptographic in
> nature.
>
> Situation two:
> * One of our dependencies uses the Erlang module priv_key [4]
> * priv_key is only available in the most recent versions of Erlang so
> we've disabled compiling that part of the dependency. (we prevent our
> dependency from compiling code that would call the priv_key module.)
>
> In general, the basic question is: What are the proper steps related
> to code that makes calls into a library that may or may not be calling
> OpenSSL? Does this constitute "providing bindings"?
i'm not sure that's easy or safe to answer in general without legal
training. (if couchdb requires an opinion on this then it'll need to go
to legal internal.)
going by the summary on http://www.apache.org/dev/crypto.html, if you're
shipping your cryptography dependencies (either as part of the
distribution or through subversion) then you need to fill out the form.
if you're not then if you don't use restricted cryptographic functions
(see http://www.apache.org/dev/crypto.html) then you don't.
> If this does place
> restrictions on us, what are they and what should be done about them?
it's just a lightweight notification and including information for the
user. the details are given in http://www.apache.org/dev/crypto.html.
- - robert
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIcBAEBCgAGBQJKi5nJAAoJEHl6NpRAqILLklUP/R+cNVXMLKAdrjm7TJDfLFNt
2ld5fpBi5vS6WSf+2sAajM3iUTZRpWEsfU65OQUP4Zf1+Y1ToGs2nWnSKzC6LJYo
foVXWc4ALVkIo79/0+q6iNc2zWIR3lr7TqJEe3lSju7NMeSjN4mO7JL8wHxPKklA
dhcYIn0ZsVmDj0s/93pgNeKuK4rpF2DPFUNZR835kuNnnoeBf3/6KkP2Lqz/cHvB
yzEnHZh3WLtnRASIovlSxIdPjj4s86Nw4uL9lVf1ES/Bshl4z9a5VAX41hEad7gt
BBH0/3/ZgSZWG9fo8ltxoppIWmRNcnRdZDoXxRHWPlB47oif0x+KqXDN3Fm8RI8Y
m1/uKEynA7DHy4myNpbDvYA8IVuuhVk/48HKO0Q6fdDk7ACKJAYCmKI4NzE0w/HM
mKv5NkTw5UeLdYA37Cu9OMYkgWNKvPFkrNLLrZEhCnb2BtRBPkzREa2qBNoeLmWv
RjYueMyVCCmWrkLtF63OBgP7ADGO+bYpzki98FGmrKj95E9E5ikhJtjq0waUq5/G
m6KYXx3Ln2pc8SKVufGxOSPqxmkJX/7m21+MYqjkOL4IlmbSidk9oP2P/y3PWKG6
IDdq7Gp6pJkT0NFMQHfmikjphmh+Cg9T50AvRXiCv2xNGlekC2s2HCCZ0UINgFKy
B7usWnvuSyuuzCJUVuu6
=btbf
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Cryptography in CouchDB
Posted by Paul Davis <pa...@gmail.com>.
On Wed, Aug 19, 2009 at 12:20 PM, William A. Rowe,
Jr.<wr...@rowe-clan.net> wrote:
> Paul Davis wrote:
>>
>> There are two main spots of concern in CouchDB:
>>
>> Situation one:
>> * We have a direct dependency on the Erlang crypto module [3]
>> * The Erlang crypto module makes calls to OpenSSL
>> * The only calls we make to crypto are, sha_mac, sha, rand_bytes and
>> rand_uniform, none of which would appear to be cryptographic in
>> nature.
>
> This is not an issue. The 'signature' characteristics, even using such
> hashes to resolve a 'crypted' password, are not subject to crypto export
> controls as I understand them, you aren't shipping Erlang, you do not
> 'cause' Erlang to expose these (Erlang has them available or it does
> not, irrespective of your use of the crypto module).
>
>> Situation two:
>> * One of our dependencies uses the Erlang module priv_key [4]
>> * priv_key is only available in the most recent versions of Erlang so
>> we've disabled compiling that part of the dependency. (we prevent our
>> dependency from compiling code that would call the priv_key module.)
>>
>> In general, the basic question is: What are the proper steps related
>> to code that makes calls into a library that may or may not be calling
>> OpenSSL? Does this constitute "providing bindings"? If this does place
>> restrictions on us, what are they and what should be done about them?
>
> If used for "signatures" this is not an issue; however you are stepping
> closer and closer to the line, and it might be a good idea to file now,
> anyways. You need to follow the crypto dev policy upon initially committing
> this code if used for "encryption", irrespective of "releases", irrespective
> of "enabling" it by default. See http://www.apache.org/dev/crypto.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
William,
Thanks for the clarification. I'll start the ball rolling on our end
to get this done so we can just not worry about it.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Cryptography in CouchDB
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Paul Davis wrote:
>
> There are two main spots of concern in CouchDB:
>
> Situation one:
> * We have a direct dependency on the Erlang crypto module [3]
> * The Erlang crypto module makes calls to OpenSSL
> * The only calls we make to crypto are, sha_mac, sha, rand_bytes and
> rand_uniform, none of which would appear to be cryptographic in
> nature.
This is not an issue. The 'signature' characteristics, even using such
hashes to resolve a 'crypted' password, are not subject to crypto export
controls as I understand them, you aren't shipping Erlang, you do not
'cause' Erlang to expose these (Erlang has them available or it does
not, irrespective of your use of the crypto module).
> Situation two:
> * One of our dependencies uses the Erlang module priv_key [4]
> * priv_key is only available in the most recent versions of Erlang so
> we've disabled compiling that part of the dependency. (we prevent our
> dependency from compiling code that would call the priv_key module.)
>
> In general, the basic question is: What are the proper steps related
> to code that makes calls into a library that may or may not be calling
> OpenSSL? Does this constitute "providing bindings"? If this does place
> restrictions on us, what are they and what should be done about them?
If used for "signatures" this is not an issue; however you are stepping
closer and closer to the line, and it might be a good idea to file now,
anyways. You need to follow the crypto dev policy upon initially committing
this code if used for "encryption", irrespective of "releases", irrespective
of "enabling" it by default. See http://www.apache.org/dev/crypto.html
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org