Re: Signing off Ignite for export beyond the U.S.
Dmitriy Pavlov < >> > > >> dpav...@apache.org> >> > > >> > > >>> wrote: >> > > >> > > >>> >> > > >> > > >>> > Igniters, >> > > >> > > >>> > >> > > >> > > >>> > please review crypto notice in >> > > >> > > >>> > >> > > >> > > >>> > >> > > >> > > >>> >> > > >> > > >> > > >> > >> > > >> >> > > >> > >> https://github.com/apache/ignite/pull/6616/files#diff-26fd799ea07494916e9da9b91b2aac64R29 >> > > >> > > >>> > >> > > >> > > >>> > Only 2 open questions: about declaring released versions, >> > and >> > > >> about >> > > >> > > >>> > declaring .NET versions (.NET Core & . NET Classic). By >> > > >> default, I >> > > >> > > >>> propose >> > > >> > > >>> > to keep both. >> > > >> > > >>> > >> > > >> > > >>> > Sincerely, >> > > >> > > >>> > Dmitriy Pavlov >> > > >> > > >>> > >> > > >> > > >>> > пн, 17 июн. 2019 г. в 19:24, Dmitriy Pavlov < >> > > dpav...@apache.org >> > > >> >: >> > > >> > > >>> > >> > > >> > > >>> > > Pavel, >> > > >> > > >>> > > >> > > >> > > >>> > > we need to follow the process from >> > > >> > > >>> > > https://www.apache.org/dev/crypto.html#classify >> > > >> > > >>> > > >> > > >> > > >>> > > Please see similar products in the draft export matrix, >> > > >> > > >>> > > >> > > >> > > >>> > > >> > > >> > > >>> > >> > > >> > > >>> >> > > >> > > >> > > >> > >> > > >> >> > > >> > >> https://github.com/apache/ignite/pull/6616/files#diff-1995c8a78832996cb48db91f7550479cR7 >> > > >> > > >>> > > >> > > >> > > >>> > > >> > > >> > > >>> > > We don't ship JDK, but we designed our product to use a >> > > >> > > cryptographic >> > > >> > > >>> > > feature from this 3rd party product, so we need to >> follow >> > > this >> > > >> > > >>> process >> > > >> > > >>> > and >> > > >> > > >>> > > provide matrix update, add CRYPTO notice (I'll draft >> it). >> > > >> > > >>> > > >> > > >> > > >>> > > Other products don't declare all possible JDKs - >> > > >> > > >>> > > http://www.apache.org/licenses/exports/#matrix So, >> > > probably, >> > > >> one >> > > >> > > >>> > > declaration of .NET classic (Microsoft) would be >> enough. >> > > >> > > >>> > > >> > > >> > > >>> > > Sincerely, >> > > >> > > >>> > > Dmitriy Pavlov >> > > >> > > >>> > > >> > > >> > > >>> > > пн, 17 июн. 2019 г. в 19:11, Pavel Tupitsyn < >> > > >> > ptupit...@apache.org >> > > >> > > >: >> > > >> > > >>> > > >> > > >> > > >>> > >> >>Should it go instead of Microsoft? Should we mention >> > .NET >> > > >> code >> > > >> > > in >> > > >> > > >>> > >> addition >> > > >> > > >>> > >> >> > > >> > > >>> > >> >>to Microsoft? >> &
Re: Signing off Ignite for export beyond the U.S.
he.org/repos/asf/infrastructure/site/trunk/ > > > >> > > >> bisnotice.cmd > > > >> > > >> bisnotice.sh > > > >> > > >> > > > >> > > >> Sincerely, > > > >> > > >> Dmitriy Pavlov > > > >> > > >> > > > >> > > >> ср, 19 июн. 2019 г. в 01:40, Denis Magda >: > > > >> > > >> > > > >> > > >>> Dmitriy, > > > >> > > >>> > > > >> > > >>> I think that it's required to enlist all of the publicly > > > released > > > >> > > Ignite > > > >> > > >>> versions (available for download from the website). It means > > > that > > > >> the > > > >> > > XML > > > >> > > >>> should have the following controlled sources grouped by > Ignite > > > >> > > versions' > > > >> > > >>> ranges. > > > >> > > >>> > > > >> > > >>>- Ignite 1.0.0 - Ignite 1.5.0-b1: ASF, Oracle, The > Eclipse > > > >> > > Foundation > > > >> > > >>>- Ignite 1.5.0 and later: all of the controller versions > > > >> listed by > > > >> > > >>> you. > > > >> > > >>> > > > >> > > >>> Not sure about JCraft only. What was the first Ignite > version > > > the > > > >> lib > > > >> > > was > > > >> > > >>> added to? > > > >> > > >>> > > > >> > > >>> As for .NET versions declarations, I'm for the way it > handled > > > >> right > > > >> > now > > > >> > > >>> by > > > >> > > >>> you. Btw, do you know where ASF explains the website build > > > >> process? > > > >> > > >>> Failed > > > >> > > >>> to find it, it's not enough just to update the XML. > > > >> > > >>> > > > >> > > >>> Finally, looping in Garrett who can help with the editorial > > > >> review. > > > >> > > >>> Garrett, could you please review README.txt from this > > > >> pull-request? > > > >> > > >>> > > > >> > > >>> > > > >> > > > > > >> > > > > >> > > > > > > https://github.com/apache/ignite/pull/6616/files#diff-26fd799ea07494916e9da9b91b2aac64R29 > > > >> > > >>> > > > >> > > >>> > > > >> > > >>> - > > > >> > > >>> Denis > > > >> > > >>> > > > >> > > >>> > > > >> > > >>> On Tue, Jun 18, 2019 at 5:06 AM Dmitriy Pavlov < > > > >> dpav...@apache.org> > > > >> > > >>> wrote: > > > >> > > >>> > > > >> > > >>> > Igniters, > > > >> > > >>> > > > > >> > > >>> > please review crypto notice in > > > >> > > >>> > > > > >> > > >>> > > > > >> > > >>> > > > >> > > > > > >> > > > > >> > > > > > > https://github.com/apache/ignite/pull/6616/files#diff-26fd799ea07494916e9da9b91b2aac64R29 > > > >> > > >>> > > > > >> > > >>> > Only 2 open questions: about declaring released versions, > > and > > > >> about > > > >> > > >>> > declaring .NET versions (.NET Core & . NET Classic). By > > > >> default, I > > > >> > > >>> propose > > > >> > > >>> > to keep both. > > > >> > > >>> > > > > >> > > >>> > Sincerely, > > > >> > > >>> > Dmitriy Pavlov > > > >> > > >>> > > > > >> > > >>> > пн, 17 июн. 2019 г. в 19:24, Dmitriy Pavlov < > > > dpav...@apache.org > > &
Re: Signing off Ignite for export beyond the U.S.
;> > > >>> Not sure about JCraft only. What was the first Ignite version > > the > > >> lib > > >> > > was > > >> > > >>> added to? > > >> > > >>> > > >> > > >>> As for .NET versions declarations, I'm for the way it handled > > >> right > > >> > now > > >> > > >>> by > > >> > > >>> you. Btw, do you know where ASF explains the website build > > >> process? > > >> > > >>> Failed > > >> > > >>> to find it, it's not enough just to update the XML. > > >> > > >>> > > >> > > >>> Finally, looping in Garrett who can help with the editorial > > >> review. > > >> > > >>> Garrett, could you please review README.txt from this > > >> pull-request? > > >> > > >>> > > >> > > >>> > > >> > > > > >> > > > >> > > > https://github.com/apache/ignite/pull/6616/files#diff-26fd799ea07494916e9da9b91b2aac64R29 > > >> > > >>> > > >> > > >>> > > >> > > >>> - > > >> > > >>> Denis > > >> > > >>> > > >> > > >>> > > >> > > >>> On Tue, Jun 18, 2019 at 5:06 AM Dmitriy Pavlov < > > >> dpav...@apache.org> > > >> > > >>> wrote: > > >> > > >>> > > >> > > >>> > Igniters, > > >> > > >>> > > > >> > > >>> > please review crypto notice in > > >> > > >>> > > > >> > > >>> > > > >> > > >>> > > >> > > > > >> > > > >> > > > https://github.com/apache/ignite/pull/6616/files#diff-26fd799ea07494916e9da9b91b2aac64R29 > > >> > > >>> > > > >> > > >>> > Only 2 open questions: about declaring released versions, > and > > >> about > > >> > > >>> > declaring .NET versions (.NET Core & . NET Classic). By > > >> default, I > > >> > > >>> propose > > >> > > >>> > to keep both. > > >> > > >>> > > > >> > > >>> > Sincerely, > > >> > > >>> > Dmitriy Pavlov > > >> > > >>> > > > >> > > >>> > пн, 17 июн. 2019 г. в 19:24, Dmitriy Pavlov < > > dpav...@apache.org > > >> >: > > >> > > >>> > > > >> > > >>> > > Pavel, > > >> > > >>> > > > > >> > > >>> > > we need to follow the process from > > >> > > >>> > > https://www.apache.org/dev/crypto.html#classify > > >> > > >>> > > > > >> > > >>> > > Please see similar products in the draft export matrix, > > >> > > >>> > > > > >> > > >>> > > > > >> > > >>> > > > >> > > >>> > > >> > > > > >> > > > >> > > > https://github.com/apache/ignite/pull/6616/files#diff-1995c8a78832996cb48db91f7550479cR7 > > >> > > >>> > > > > >> > > >>> > > > > >> > > >>> > > We don't ship JDK, but we designed our product to use a > > >> > > cryptographic > > >> > > >>> > > feature from this 3rd party product, so we need to follow > > this > > >> > > >>> process > > >> > > >>> > and > > >> > > >>> > > provide matrix update, add CRYPTO notice (I'll draft it). > > >> > > >>> > > > > >> > > >>> > > Other products don't declare all possible JDKs - > > >> > > >>> > > http://www.apache.org/licenses/exports/#matrix So, > > probably, > > >> one > > >> > > >>> > > declaration of .NET classic (Microsoft) would be enough. > > >> > > >>> >
Re: Signing off Ignite for export beyond the U.S.
; > > >>> > >> > > >>> On Tue, Jun 18, 2019 at 5:06 AM Dmitriy Pavlov < > >> dpav...@apache.org> > >> > > >>> wrote: > >> > > >>> > >> > > >>> > Igniters, > >> > > >>> > > >> > > >>> > please review crypto notice in > >> > > >>> > > >> > > >>> > > >> > > >>> > >> > > > >> > > >> > https://github.com/apache/ignite/pull/6616/files#diff-26fd799ea07494916e9da9b91b2aac64R29 > >> > > >>> > > >> > > >>> > Only 2 open questions: about declaring released versions, and > >> about > >> > > >>> > declaring .NET versions (.NET Core & . NET Classic). By > >> default, I > >> > > >>> propose > >> > > >>> > to keep both. > >> > > >>> > > >> > > >>> > Sincerely, > >> > > >>> > Dmitriy Pavlov > >> > > >>> > > >> > > >>> > пн, 17 июн. 2019 г. в 19:24, Dmitriy Pavlov < > dpav...@apache.org > >> >: > >> > > >>> > > >> > > >>> > > Pavel, > >> > > >>> > > > >> > > >>> > > we need to follow the process from > >> > > >>> > > https://www.apache.org/dev/crypto.html#classify > >> > > >>> > > > >> > > >>> > > Please see similar products in the draft export matrix, > >> > > >>> > > > >> > > >>> > > > >> > > >>> > > >> > > >>> > >> > > > >> > > >> > https://github.com/apache/ignite/pull/6616/files#diff-1995c8a78832996cb48db91f7550479cR7 > >> > > >>> > > > >> > > >>> > > > >> > > >>> > > We don't ship JDK, but we designed our product to use a > >> > > cryptographic > >> > > >>> > > feature from this 3rd party product, so we need to follow > this > >> > > >>> process > >> > > >>> > and > >> > > >>> > > provide matrix update, add CRYPTO notice (I'll draft it). > >> > > >>> > > > >> > > >>> > > Other products don't declare all possible JDKs - > >> > > >>> > > http://www.apache.org/licenses/exports/#matrix So, > probably, > >> one > >> > > >>> > > declaration of .NET classic (Microsoft) would be enough. > >> > > >>> > > > >> > > >>> > > Sincerely, > >> > > >>> > > Dmitriy Pavlov > >> > > >>> > > > >> > > >>> > > пн, 17 июн. 2019 г. в 19:11, Pavel Tupitsyn < > >> > ptupit...@apache.org > >> > > >: > >> > > >>> > > > >> > > >>> > >> >>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
Re: Signing off Ignite for export beyond the U.S.
t;> > > >> > > >>> > > Please see similar products in the draft export matrix, >> > > >>> > > >> > > >>> > > >> > > >>> > >> > > >>> >> > > >> > >> https://github.com/apache/ignite/pull/6616/files#diff-1995c8a78832996cb48db91f7550479cR7 >> > > >>> > > >> > > >>> > > >> > > >>> > > We don't ship JDK, but we designed our product to use a >> > > cryptographic >> > > >>> > > feature from this 3rd party product, so we need to follow this >> > > >>> process >> > > >>> > and >> > > >>> > > provide matrix update, add CRYPTO notice (I'll draft it). >> > > >>> > > >> > > >>> > > Other products don't declare all possible JDKs - >> > > >>> > > http://www.apache.org/licenses/exports/#matrix So, probably, >> one >> > > >>> > > declaration of .NET classic (Microsoft) would be enough. >> > > >>> > > >> > > >>> > > Sincerely, >> > > >>> > > Dmitriy Pavlov >> > > >>> > > >> > > >>> > > пн, 17 июн. 2019 г. в 19:11, Pavel Tupitsyn < >> > ptupit...@apache.org >> > > >: >> > > >>> > > >> > > >>> > >> >>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 < >> > > lexw...@gmail.com >> > > >>> > >> > > >>> > >> 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 .
Re: Signing off Ignite for export beyond the U.S.
> > >>> > > Dmitriy Pavlov > > > >>> > > > > > >>> > > пн, 17 июн. 2019 г. в 19:11, Pavel Tupitsyn < > > ptupit...@apache.org > > > >: > > > >>> > > > > > >>> > >> >>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 < > > > lexw...@gmail.com > > > >>> > > > > >>> > >> 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 >
Re: Signing off Ignite for export beyond the U.S.
t; > >>> added to? > > >>> > > >>> As for .NET versions declarations, I'm for the way it handled right > now > > >>> by > > >>> you. Btw, do you know where ASF explains the website build process? > > >>> Failed > > >>> to find it, it's not enough just to update the XML. > > >>> > > >>> Finally, looping in Garrett who can help with the editorial review. > > >>> Garrett, could you please review README.txt from this pull-request? > > >>> > > >>> > > > https://github.com/apache/ignite/pull/6616/files#diff-26fd799ea07494916e9da9b91b2aac64R29 > > >>> > > >>> > > >>> - > > >>> Denis > > >>> > > >>> > > >>> On Tue, Jun 18, 2019 at 5:06 AM Dmitriy Pavlov > > >>> wrote: > > >>> > > >>> > Igniters, > > >>> > > > >>> > please review crypto notice in > > >>> > > > >>> > > > >>> > > > https://github.com/apache/ignite/pull/6616/files#diff-26fd799ea07494916e9da9b91b2aac64R29 > > >>> > > > >>> > Only 2 open questions: about declaring released versions, and about > > >>> > declaring .NET versions (.NET Core & . NET Classic). By default, I > > >>> propose > > >>> > to keep both. > > >>> > > > >>> > Sincerely, > > >>> > Dmitriy Pavlov > > >>> > > > >>> > пн, 17 июн. 2019 г. в 19:24, Dmitriy Pavlov : > > >>> > > > >>> > > Pavel, > > >>> > > > > >>> > > we need to follow the process from > > >>> > > https://www.apache.org/dev/crypto.html#classify > > >>> > > > > >>> > > Please see similar products in the draft export matrix, > > >>> > > > > >>> > > > > >>> > > > >>> > > > https://github.com/apache/ignite/pull/6616/files#diff-1995c8a78832996cb48db91f7550479cR7 > > >>> > > > > >>> > > > > >>> > > We don't ship JDK, but we designed our product to use a > > cryptographic > > >>> > > feature from this 3rd party product, so we need to follow this > > >>> process > > >>> > and > > >>> > > provide matrix update, add CRYPTO notice (I'll draft it). > > >>> > > > > >>> > > Other products don't declare all possible JDKs - > > >>> > > http://www.apache.org/licenses/exports/#matrix So, probably, one > > >>> > > declaration of .NET classic (Microsoft) would be enough. > > >>> > > > > >>> > > Sincerely, > > >>> > > Dmitriy Pavlov > > >>> > > > > >>> > > пн, 17 июн. 2019 г. в 19:11, Pavel Tupitsyn < > ptupit...@apache.org > > >: > > >>> > > > > >>> > >> >>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, > > >>> t
Re: Signing off Ignite for export beyond the U.S.
;>> > >>> > Igniters, > >>> > > >>> > please review crypto notice in > >>> > > >>> > > >>> > https://github.com/apache/ignite/pull/6616/files#diff-26fd799ea07494916e9da9b91b2aac64R29 > >>> > > >>> > Only 2 open questions: about declaring released versions, and about > >>> > declaring .NET versions (.NET Core & . NET Classic). By default, I > >>> propose > >>> > to keep both. > >>> > > >>> > Sincerely, > >>> > Dmitriy Pavlov > >>> > > >>> > пн, 17 июн. 2019 г. в 19:24, Dmitriy Pavlov : > >>> > > >>> > > Pavel, > >>> > > > >>> > > we need to follow the process from > >>> > > https://www.apache.org/dev/crypto.html#classify > >>> > > > >>> > > Please see similar products in the draft export matrix, > >>> > > > >>> > > > >>> > > >>> > https://github.com/apache/ignite/pull/6616/files#diff-1995c8a78832996cb48db91f7550479cR7 > >>> > > > >>> > > > >>> > > We don't ship JDK, but we designed our product to use a > cryptographic > >>> > > feature from this 3rd party product, so we need to follow this > >>> process > >>> > and > >>> > > provide matrix update, add CRYPTO notice (I'll draft it). > >>> > > > >>> > > Other products don't declare all possible JDKs - > >>> > > http://www.apache.org/licenses/exports/#matrix So, probably, one > >>> > > declaration of .NET classic (Microsoft) would be enough. > >>> > > > >>> > > Sincerely, > >>> > > Dmitriy Pavlov > >>> > > > >>> > > пн, 17 июн. 2019 г. в 19:11, Pavel Tupitsyn >: > >>> > > > >>> > >> >>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 < > lexw...@gmail.com > >>> > > >>> > >> 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 > >>> > >> > > >>> > >> > > >>> > >> > > >>> >
Re: Signing off Ignite for export beyond the U.S.
, >>> > > >>> > > >>> > >>> https://github.com/apache/ignite/pull/6616/files#diff-1995c8a78832996cb48db91f7550479cR7 >>> > > >>> > > >>> > > We don't ship JDK, but we designed our product to use a cryptographic >>> > > feature from this 3rd party product, so we need to follow this >>> process >>> > and >>> > > provide matrix update, add CRYPTO notice (I'll draft it). >>> > > >>> > > Other products don't declare all possible JDKs - >>> > > http://www.apache.org/licenses/exports/#matrix So, probably, one >>> > > declaration of .NET classic (Microsoft) would be enough. >>> > > >>> > > Sincerely, >>> > > Dmitriy Pavlov >>> > > >>> > > пн, 17 июн. 2019 г. в 19:11, Pavel Tupitsyn : >>> > > >>> > >> >>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 >> > >>> > >> 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 >>> > >> > *Sent: *Monday, June 17, 2019 4:35 PM >>> > >> > *To: *dev >>> > >> > *Cc: *Denis Magda ; Igor Sapego < >>> > isap...@apache.org>; >>> > >> Pavel >>> > >> > Petroshenko ; Nikolay Izhikov < >>> nizhi...@apache.org> >>> > >> > *Subject: *Re: Signing off Ignite for export beyond the U.S. >>> > >> > >>> > >> > >>> > >> > >>> > >>
Re: Signing off Ignite for export beyond the U.S.
gt; > 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 >> > >> 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 >> > >> > *Sent: *Monday, June 17, 2019 4:35 PM >> > >> > *To: *dev >> > >> > *Cc: *Denis Magda ; Igor Sapego < >> > isap...@apache.org>; >> > >> Pavel >> > >> > Petroshenko ; Nikolay Izhikov < >> nizhi...@apache.org> >> > >> > *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 >> > >> > >> > >> > >> > >> > >> > >> > 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 >> > >> > >> > >> > >> > >>
Re: Signing off Ignite for export beyond the U.S.
>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 > > >> > *Sent: *Monday, June 17, 2019 4:35 PM > > >> > *To: *dev > > >> > *Cc: *Denis Magda ; Igor Sapego < > > isap...@apache.org>; > > >> Pavel > > >> > Petroshenko ; Nikolay Izhikov > > > >> > *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 > > >> > > > >> > > > >> > > > >> > 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: > > >> > > > >
Re: Signing off Ignite for export beyond the U.S.
Dmitriy, I think that it's required to enlist all of the publicly released Ignite versions (available for download from the website). It means that the XML should have the following controlled sources grouped by Ignite versions' ranges. - Ignite 1.0.0 - Ignite 1.5.0-b1: ASF, Oracle, The Eclipse Foundation - Ignite 1.5.0 and later: all of the controller versions listed by you. Not sure about JCraft only. What was the first Ignite version the lib was added to? As for .NET versions declarations, I'm for the way it handled right now by you. Btw, do you know where ASF explains the website build process? Failed to find it, it's not enough just to update the XML. Finally, looping in Garrett who can help with the editorial review. Garrett, could you please review README.txt from this pull-request? https://github.com/apache/ignite/pull/6616/files#diff-26fd799ea07494916e9da9b91b2aac64R29 - Denis On Tue, Jun 18, 2019 at 5:06 AM Dmitriy Pavlov wrote: > Igniters, > > please review crypto notice in > > https://github.com/apache/ignite/pull/6616/files#diff-26fd799ea07494916e9da9b91b2aac64R29 > > Only 2 open questions: about declaring released versions, and about > declaring .NET versions (.NET Core & . NET Classic). By default, I propose > to keep both. > > Sincerely, > Dmitriy Pavlov > > пн, 17 июн. 2019 г. в 19:24, Dmitriy Pavlov : > > > Pavel, > > > > we need to follow the process from > > https://www.apache.org/dev/crypto.html#classify > > > > Please see similar products in the draft export matrix, > > > > > https://github.com/apache/ignite/pull/6616/files#diff-1995c8a78832996cb48db91f7550479cR7 > > > > > > We don't ship JDK, but we designed our product to use a cryptographic > > feature from this 3rd party product, so we need to follow this process > and > > provide matrix update, add CRYPTO notice (I'll draft it). > > > > Other products don't declare all possible JDKs - > > http://www.apache.org/licenses/exports/#matrix So, probably, one > > declaration of .NET classic (Microsoft) would be enough. > > > > Sincerely, > > Dmitriy Pavlov > > > > пн, 17 июн. 2019 г. в 19:11, Pavel Tupitsyn : > > > >> >>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 > >> 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 > >> > *Sent: *Monday, June 17, 2019 4:35 PM > >> > *To: *dev > >> > *Cc: *Denis Magda ; Igor Sapego < > isap...@apache.org>; > >> Pavel > >> > Petroshenko ; N
Re: Signing off Ignite for export beyond the U.S.
Igniters, please review crypto notice in https://github.com/apache/ignite/pull/6616/files#diff-26fd799ea07494916e9da9b91b2aac64R29 Only 2 open questions: about declaring released versions, and about declaring .NET versions (.NET Core & . NET Classic). By default, I propose to keep both. Sincerely, Dmitriy Pavlov пн, 17 июн. 2019 г. в 19:24, Dmitriy Pavlov : > Pavel, > > we need to follow the process from > https://www.apache.org/dev/crypto.html#classify > > Please see similar products in the draft export matrix, > > https://github.com/apache/ignite/pull/6616/files#diff-1995c8a78832996cb48db91f7550479cR7 > > > We don't ship JDK, but we designed our product to use a cryptographic > feature from this 3rd party product, so we need to follow this process and > provide matrix update, add CRYPTO notice (I'll draft it). > > Other products don't declare all possible JDKs - > http://www.apache.org/licenses/exports/#matrix So, probably, one > declaration of .NET classic (Microsoft) would be enough. > > Sincerely, > Dmitriy Pavlov > > пн, 17 июн. 2019 г. в 19:11, Pavel Tupitsyn : > >> >>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 >> 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 >> > *Sent: *Monday, June 17, 2019 4:35 PM >> > *To: *dev >> > *Cc: *Denis Magda ; Igor Sapego ; >> Pavel >> > Petroshenko ; Nikolay Izhikov >> > *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 >> > >> > >> > >> > 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) &
Re: Signing off Ignite for export beyond the U.S.
Pavel, we need to follow the process from https://www.apache.org/dev/crypto.html#classify Please see similar products in the draft export matrix, https://github.com/apache/ignite/pull/6616/files#diff-1995c8a78832996cb48db91f7550479cR7 We don't ship JDK, but we designed our product to use a cryptographic feature from this 3rd party product, so we need to follow this process and provide matrix update, add CRYPTO notice (I'll draft it). Other products don't declare all possible JDKs - http://www.apache.org/licenses/exports/#matrix So, probably, one declaration of .NET classic (Microsoft) would be enough. Sincerely, Dmitriy Pavlov пн, 17 июн. 2019 г. в 19:11, Pavel Tupitsyn : > >>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 > 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 > > *Sent: *Monday, June 17, 2019 4:35 PM > > *To: *dev > > *Cc: *Denis Magda ; Igor Sapego ; > Pavel > > Petroshenko ; Nikolay Izhikov > > *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 > > > > > > > > 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 >
Re: Signing off Ignite for export beyond the U.S.
>>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 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 > *Sent: *Monday, June 17, 2019 4:35 PM > *To: *dev > *Cc: *Denis Magda ; Igor Sapego ; Pavel > Petroshenko ; Nikolay Izhikov > *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 > > > > 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 : > > > > > 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 : > > > > > > > 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/ssl
Re: Signing off Ignite for export beyond the U.S.
Alexander, thank you for your reply. Let's follow the motto: "Show me the code!" Even we don't have any single line of code here. I've created - issue https://issues.apache.org/jira/browse/IGNITE-11932 - a new head with draft content https://gitbox.apache.org/repos/asf?p=ignite.git;a=shortlog;h=refs/heads/ignite-11932 - PR https://github.com/apache/ignite/pull/6616/files For preparing an update to SVN (I don't have karma to update, so Denis I will ask you for an update once we finalize content). Committers are encouraged to update branch directly, everyone else can suggest edits using GitHub. Sincerely, Dmitriy Pavlov пн, 17 июн. 2019 г. в 17:20, Alexandr Shapkin : > >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 > Sent: Monday, June 17, 2019 4:35 PM > To: dev > Cc: Denis Magda; Igor Sapego; Pavel Petroshenko; Nikolay Izhikov > 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 > > 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 : > > > 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 : > > > > > 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? > > >
RE: Signing off Ignite for export beyond the U.S.
>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 Sent: Monday, June 17, 2019 4:35 PM To: dev Cc: Denis Magda; Igor Sapego; Pavel Petroshenko; Nikolay Izhikov 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 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 : > 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 : > > > 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 > > >
Re: Signing off Ignite for export beyond the U.S.
Igniters, One more usage,we need to mention at Export matrix data: <<< JCraft, Inc. title=Provides encryption SSH library href=http://www.jcraft.com/jsch/ >>> One more thing I would like to declare as an open question: 3) Is it possible to setup HTTPs connection to Ignite Rest API? https://apacheignite.readme.io/docs/rest-api If it is possible, then we should add The Eclipse Foundation title=HTTPs support in Jetty (using SSL) href=http://www.eclipse.org/jetty/ BTW, detailed information should be included into CRYPTO notice file like following https://ant.apache.org/ivy/CryptoNotice.html So please provide as much information as it is possible. Sincerely, Dmitriy Pavlov пн, 17 июн. 2019 г. в 16:35, Dmitriy Pavlov : > 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 > > 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 : > >> 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 : >> >> > 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 >> > >> >
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 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 : > 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 : > > > 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 > > >
Re: Signing off Ignite for export beyond the U.S.
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 : > 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 >
Re: Signing off Ignite for export beyond the U.S.
Alexey, Igor, thank you for your replies. I've found one more usage at Java side: It is Amazon AWS S3 Client-side encryption: https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingClientSideEncryption.html See code at: https://github.com/apache/ignite/blob/master/modules/aws/src/main/java/org/apache/ignite/spi/discovery/tcp/ipfinder/s3/encrypt/package-info.java It was contributed under https://issues.apache.org/jira/browse/IGNITE-7054 Sincerely, Dmitriy Pavlov сб, 15 июн. 2019 г. в 00:57, Denis Magda : > 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 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.kosenc...@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 > >> > > >
Re: Signing off Ignite for export beyond the U.S.
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 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.kosenc...@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 >> >
Re: Signing off Ignite for export beyond the U.S.
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.kosenc...@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 >
Re: Signing off Ignite for export beyond the U.S.
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
