>>Should it go instead of Microsoft? Should we mention .NET code in addition
>>to Microsoft? >Yes, I think we can do this. Ignite targets both of the them. And .NET Core uses it’s own implementation of standard class library[1] >Pavel may correct me. We use crypto APIs from standard class library. We ship our binaries, but we don't ship the framework binaries. Our binaries can be executed with .NET Core (open-source, MIT license), Mono (open-source, MIT license), and .NET Classic (old framework, Windows-only, Microsoft license). I'm still not sure what is the question we are trying to answer, though. Thanks, Pavel On Mon, Jun 17, 2019 at 5:20 PM Alexandr Shapkin <[email protected]> wrote: > >1) Declaring older versions of Ignite. > > >2) Is it correct to mention that Ignite uses .NET core controlled by .NET > > >Foundation? E.g. as follows: > > >(controlled by) > > >.NET Foundation > > >title=Designed to use .NET Framework Cryptography Model > > >href=https://dotnetfoundation.org/projects > > > > >Should it go instead of Microsoft? Should we mention .NET code in addition > > >to Microsoft? > > > > Yes, I think we can do this. Ignite targets both of the them. And .NET > Core uses it’s own implementation of standard class library[1] > > Pavel may correct me. > > > > [1] https://github.com/dotnet/corefx > > > > *From: *Dmitriy Pavlov <[email protected]> > *Sent: *Monday, June 17, 2019 4:35 PM > *To: *dev <[email protected]> > *Cc: *Denis Magda <[email protected]>; Igor Sapego <[email protected]>; Pavel > Petroshenko <[email protected]>; Nikolay Izhikov <[email protected]> > *Subject: *Re: Signing off Ignite for export beyond the U.S. > > > > Thanks, Pavel! > > > > Denis, Pavel, Igniters, please review the following proposal: > > > > - Python, Node JS, ODBC to be declared as OpenSSL usage. > > - AWS-S3 client-side encryption to be declared as JCA/JCE usage. > > - SSLContextFactory usage to be declared as JCA/JCE usage. > > - TDE to be declared as JCA/JCE > > > > Export matrix data to be published in ASF-level SVN: > > <<<<< > > Product Name > > Apache Ignite > > > > Versions > > development > > 2.7 and later <Earlier versions-TBD?> > > > > ECCN > > 5D002 > > > > Controlled source > > ASF > > title=Designed to use with built-in Java Cryptography Architecture (JCA) > > href=https://gitbox.apache.org/repos/asf?p=ignite.git > > > > Oracle > > title=Designed to use with built-in Java encryption libraries (JCE) > > href=https://www.oracle.com/technetwork/java/javase/downloads/index.html > > > > The OpenSSL Project > > title=Designed to use General Purpose cryptography library included with > > OpenSSL > > href=https://www.openssl.org/source/ > > > > Microsoft > > title=Designed to use .NET Framework Cryptography Model > > href=https://dotnet.microsoft.com/download > > >>>>>> > > > > Open questions: > > 1) Declaring older versions of Ignite. > > 2) Is it correct to mention that Ignite uses .NET core controlled by .NET > > Foundation? E.g. as follows: > > (controlled by) > > .NET Foundation > > title=Designed to use .NET Framework Cryptography Model > > href=https://dotnetfoundation.org/projects > > > > Should it go instead of Microsoft? Should we mention .NET code in addition > > to Microsoft? > > > > Sincerely, > > Dmitriy Pavlov > > > > пн, 17 июн. 2019 г. в 16:07, Pavel Tupitsyn <[email protected]>: > > > > > Hi Denis, > > > > > > Ignite.NET uses .NET Framework Standard Library for all security and > > > cryptographic related code. There are no dependencies on external > > > libraries. > > > > > > Thanks > > > > > > ср, 12 июн. 2019 г., 21:07 Denis Magda <[email protected]>: > > > > > > > Igniters, > > > > > > > > Regardless of the fact that Ignite is an open source software, ASF as > an > > > > entity based in the U.S. has to comply with certain exporting > regulations > > > > [1]. > > > > > > > > Dmitry Pavlov and I are working on adding Ignite to the table [2] of > > > > projects allowed for export and might need the assistance of some of > you. > > > > > > > > Here is a list of cryptographic functions used by Ignite (and provided > by > > > > a 3rd party vendor): > > > > > > > > 1. JDK SSL/TLS libraries if a user wishes to enable secured > > > > connectivity between cluster nodes. Manufacturer - Oracle/OpenJDK ( > > > > https://apacheignite.readme.io/docs/ssltls) > > > > 2. JDK AES/CBC/PKCS5Padding encryption from the Java libraries for > > > > transparent data encryption of data on disk ( > > > > https://apacheignite.readme.io/docs/transparent-data-encryption) > > > > 3. Libraries/vendors for .NET nodes security?* Pavel Tupitsyn*, > could > > > > you check? > > > > 4. Libraries/vendors for C++ clients security (SSL, TLS, anything > > > > else?). *Igor Sapego*, could you please check? > > > > 5. Libraries/vendors for Python, PHP, Node.JS SSL/TLS? *Dear thin > > > > client contributors*, please facilitate. > > > > 6. Anything else missing from the list? We don't have any custom > > > > crypto features, right? > > > > > > > > All of these usages/integrations have to comply with the following > > > > checklist [3] before I, as a PMC Chair, submit a notice to Export > > > > Administration Regulations of the U.S.A. > > > > > > > > [1] http://www.apache.org/licenses/exports/ > > > > [2] http://www.apache.org/licenses/exports/#matrix > > > > [3] https://www.apache.org/dev/crypto.html#classify > > > > > > > > > > > > - > > > > Denis > > > > > > > > > >
