It looks to me than Andy's statement, "None of the VCL-proper source code actually does any direct encryption via mathematical or other functions." puts the VCL-proper source code into the latter category of "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 ..." [emphasis added] described in the Overview.
I don't understand how Step 1 applies, since that's for crypto software. Might we be able to skip this? But Steps 2-4 look pretty straight forward and appear necessary. Will that do it? --henry On Tue, Jul 11, 2017 at 1:34 PM, Andy Kurth <[email protected]> wrote: > This thread is to discuss the pertinence of the U.S. export control laws > regarding cryptography described on the following page: > https://www.apache.org/dev/crypto.html > > The following seems to apply to VCL: > > > 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 > > > VCL has always used some cryptographic functionality and new features added > for VCL 2.5 expand the usage. The README lists requirements of > php-openssl, openssh, openssl-devel, and xmlsec1-openssl. The backend > installation scripts will install a few encryption-related modules and the > backend Perl code uses functions from the Crypt::OpenSSL::RSA and others. > The frontend does the same. Encrypted strings generated from these modules > and libraries are stored in the VCL database. None of the VCL-proper > source code actually does any direct encryption via mathematical or other > functions. > > I'm hoping I'm wrong, but it sounds like we should go through all of the > steps listed on the page and that all of this should be completed before > releasing VCL 2.5 so that the README includes the proper crypto notice. > > Please discuss... > > Thanks, > Andy > > PS - I think the *"before placing such code on any ASF server, including > commits to subversion"* part of the guidelines is irrelevant at the current > time since encryption code has been committed -- in some cases, years ago. > We'll certainly abide by this in the future once we figure out how things > need to be handled. >
