ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@apache.org>
Subject Re: Signing off Ignite for export beyond the U.S.
Date Fri, 14 Jun 2019 21:56:34 GMT
Alex, Igor, thanks for the details. Looks good.

*Pavel Tupitsyn, Aleksandr Shapkin,* could you please help with .NET?

-
Denis


On Thu, Jun 13, 2019 at 2:08 AM Igor Sapego <isapego@apache.org> wrote:

> Denis,
>
> C++ thin client and ODBC use OpenSSL to establish secure connection with
> the cluster and do not contain any crypto algorithms in their own code.
>
> Best Regards,
> Igor
>
>
> On Thu, Jun 13, 2019 at 12:56 AM Alexey Kosenchuk <
> alexey.kosenchuk@nobitlost.com> wrote:
>
>> Hi Denis,
>>
>> Info about Python, PHP, Node.JS thin clients:
>>
>> The clients itself do not contain any cryptographic code but use the
>> features provided by the underlying platforms.
>>
>> Python client uses Python's SSL lib [1] which is a wrapper over OpenSSL
>> [2].
>> Python 2.7 and Python 3.4 require OpenSSL 1.0, Python 3.5 and higher
>> require OpenSSL 1.1.
>>
>> NodeJS client uses NodeJS's tls module [3] which is a wrapper over
>> OpenSSL [2].
>> NodeJS 8.x requires OpenSSL 1.0, NodeJS 10.x and higher require OpenSSL
>> 1.1.
>>
>> PHP client uses PHP OpenSSL extension [4].
>> PHP 7.2 and higher require OpenSSL 1.0.
>>
>> [1] https://docs.python.org/3/library/ssl.html
>> [2] https://www.openssl.org/
>> [3] https://nodejs.org/api/tls.html
>> [4] https://www.php.net/manual/en/book.openssl.php
>>
>> Regards,
>> -Alexey
>>
>> > 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
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message