Return-Path: X-Original-To: apmail-legal-discuss-archive@www.apache.org Delivered-To: apmail-legal-discuss-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B315F10E66 for ; Tue, 21 Jan 2014 18:38:35 +0000 (UTC) Received: (qmail 51029 invoked by uid 500); 21 Jan 2014 18:38:16 -0000 Delivered-To: apmail-legal-discuss-archive@apache.org Received: (qmail 50741 invoked by uid 500); 21 Jan 2014 18:38:16 -0000 Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: Reply-To: legal-discuss@apache.org List-Id: Delivered-To: mailing list legal-discuss@apache.org Received: (qmail 50734 invoked by uid 99); 21 Jan 2014 18:38:15 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 Jan 2014 18:38:15 +0000 Received: from localhost (HELO mail-wi0-f173.google.com) (127.0.0.1) (smtp-auth username apurtell, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 Jan 2014 18:38:15 +0000 Received: by mail-wi0-f173.google.com with SMTP id d13so4779569wiw.12 for ; Tue, 21 Jan 2014 10:38:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=Udy6jpHJcpWYpHQmgjGpJ+nEMwQLsY/2NX43+CGCQp8=; b=AE4J6TYBXCN23osMgA31rggTougYRhW2IAh1QutgydJ79/LPSlgQdBf8j0CvpYnDDm OKUplE2RuTktYbkSVLz7CIW5KhrctzbBfbs6EJzT8jOFrdx4JfhXVpvRXJWNyz/iXnD1 Zq2LA/lNkFynunO+Zul2AdKQsHmN6XjVdAixFjLfBsMLB2mFMC8AxNT9xAB3rHFpwg+v UDB1+JEZ/0X0rjA4f86JfnidNRQUDfPI7+hJWRpn1X5KapYprUQylpjyMipGO0OeTeuY ro8Uz5vUGI2uQjbxNZRPOkYmNKWsZaUHpL/FcWe/P7wLjCWtdyUZqZ8PGQYzFt4DsmV4 H/QQ== X-Received: by 10.194.78.179 with SMTP id c19mr1463132wjx.84.1390329493378; Tue, 21 Jan 2014 10:38:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.152.8 with HTTP; Tue, 21 Jan 2014 10:37:33 -0800 (PST) In-Reply-To: <-3246661568130012874@gmail297201516> References: <-3246661568130012874@gmail297201516> From: Andrew Purtell Date: Tue, 21 Jan 2014 10:37:33 -0800 Message-ID: Subject: Re: Cryptography audit for Twill To: "legal-discuss@apache.org" Content-Type: multipart/alternative; boundary=047d7bfcf6a292dae204f07f4fa5 --047d7bfcf6a292dae204f07f4fa5 Content-Type: text/plain; charset=ISO-8859-1 When considering adding features based on cryptography for Apache HBase I posted a query on this mailing list and received an "IANAL" answer, which was unfortunately unhelpful. We can forgive Twill for taking a maybe overly conservative position given what we have here is another volunteered personal opinion. I share that view but my opinion is worthless because I am neither a lawyer, nor one representing the Foundation. The material on http://www.apache.org/dev/crypto.html carries this ominous disclaimer: "Note - the regulations covering US export control laws for encryption were changed on June 25th 2010. This page describes the previous process. Until an updated version has been drawn up and approved by the Apache VP Legal Affairs, projects should check with the legal-discuss list before proceeding." It's fair to say at this point the Foundation does not provide effective guidance for use of cryptographic functions, or even what that means. On Mon, Jan 20, 2014 at 4:37 PM, Kevan Miller wrote: > > > On Thu Jan 16 2014 at 7:59:44 PM, Andreas Neumann wrote: > >> Hi, >> >> I am trying to complete the IP clearance for Twill and I am slightly >> confused by the cryptography part of that ( >> https://issues.apache.org/jira/browse/TWILL-28). >> >> Twill does not explicitly contain cryptographic code, except that: >> >> - It uses java.util.UUID.randomUUID() to generate random ids. This >> method uses "a cryptographically strong pseudo random number generator." >> Since it is part of Java, I assume that is nothing to worry about. >> - It uses Hadoop, which uses encryption. The only thing twill does >> here is store delegation tokens on HDFS and read them back. >> >> So is there anything to do for this? Do I need to add Twill to the export >> list at http://www.apache.org/licenses/exports/ ? Do we need to include >> a crypto notice in our README? It is not clear to me after reading the >> document at http://www.apache.org/dev/crypto.html >> > > How would you evaluate the following statement with regard to TWILL? > > PMCs considering including cryptographic functionality within their > products or specially designing their products to use other software with > cryptographic functionality should take the following steps *before > placing such code on any ASF server, including commits to subversion *: > > My personal opinion: using java.util.UUID.randomUUID() to generate a > unique id is not cryptographic functionality. Note: being part of Java or > not is not necessarily relevant... > > I don't have enough context to offer an opinion on 'store delegation > tokens on HDFS and read them back'. Was TWILL "specially designing their > products to use other software with cryptographic functionality"? Answer > that, and I think you have your answer. > > --kevan > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White) --047d7bfcf6a292dae204f07f4fa5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
When considering adding features based = on cryptography for Apache HBase I posted a query on this mailing list and = received an "IANAL" answer, which was unfortunately unhelpful. We= can forgive Twill for taking a maybe overly conservative position given wh= at we have here is another volunteered personal opinion. I share that view = but my opinion is worthless because I am neither a lawyer, nor one represen= ting the Foundation. The material on=A0http://www.apache.org/dev/crypto.html carries this ominou= s disclaimer:

"Note - the regulations covering US export = control laws for encryption were changed on June 25th 2010. This page descr= ibes the previous process. Until an updated version has been drawn up and a= pproved by the Apache VP Legal Affairs, projects should check with the lega= l-discuss list before proceeding."

It's fair to say = at this point the Foundation does not provide effective guidance for use of= cryptographic functions, or even what that means.=A0



On Mon, Jan 20, 2014 at 4:37 PM, Kevan Miller <kevan= .miller@gmail.com> wrote:


On Thu Jan 16 2014 at 7:59:44 P= M, Andreas Neumann <anew@apache.org> wrote:
Hi,=A0

I am trying to complete the IP c= learance for Twill and I am slightly confused by the cryptography part of t= hat (https://issues.apache.org/jira/browse/TWILL-28).=A0

Twill does not explicitly contain cryptographic code, except= that:
  • It uses java.util.UUID.randomUUID() to generate random id= s. This method uses "a cryptographically strong pseudo random number g= enerator." Since it is part of Java, I assume that is nothing to worry= about.
  • It uses Hadoop, which uses encryption. The only thing twill does h= ere is store delegation tokens on HDFS and read them back.
So is t= here anything to do for this? Do I need to add Twill to the export list at = http:= //www.apache.org/licenses/exports/ ? Do we need to include a crypto not= ice in our README? It is not clear to me after reading the document at http://www.= apache.org/dev/crypto.html

How would you evaluate the following state= ment with regard to TWILL?

PMCs considering including cryptographic function= ality within their products or specially designing their products to use ot= her software with cryptographic functionality should take the following ste= ps=A0before pla= cing such code on any ASF server,=A0including commits to subversion=A0:
=A0
My personal opinion: using=A0java.util.UUID.randomUUID() to generate = a unique id is not cryptographic functionality. Note: being part of Java or= not is not necessarily relevant...

I don't have enough context to offer an opinion on = 'store delegation tokens on HDFS and read them back'. Was TWILL &qu= ot;specially designing the= ir products=A0to use other software wi= th cryptographic functionality"? Answer that, and I think you h= ave your answer.

--kevan



--
Best regards= ,

=A0 =A0- Andy

Problems worthy of attack prove their worth = by hitting back. - Piet Hein (via Tom White)
--047d7bfcf6a292dae204f07f4fa5--