Re: [crypto][chimera] Next steps

[Gangumalla, Uma]

>>>and a list of initial commiters/contributors.
>>>>
>>>>2016-02-26 3:24 GMT+01:00 Chen, Haifeng :
>>>>
>>>>> Come back to clear out the codebase and IP concerns.
>>>>>
>>>>> [Benedikt] I still have concerns about the IP, since this seems to
>>>be an
>>>>> Intel codebase.
>>>>> I have checked this. Chimera was developed as Apache 2 License from
>>>>>ground
>>>>> up. Agree with Jochen that the license matters.
>>>>> Internally, this was approved as part of larger open source efforts
>>>on
>>>>> Apache Hadoop and related projects in Intel. We have IP plan
>>>considered
>>>>>as
>>>>> part the open source process.
>>>>>
>>>>> As to the codebase, such as the package name is com.intel prefixed,
>>>it
>>>>>was
>>>>> technical decision when using com.intel.chimera as the package
>>>prefix.
>>>>>We
>>>>> original planned to use org.apache.chimera prefix. But we found that
>>>we
>>>>> couldnot publish org.apache. grouped artifacts to maven central
>>>>>repository,
>>>>> which needs to somewhat ownership for org.apache domain.
>>>>>
>>>>> To resolve the codebase problem, once all things are ready from
>>>Commons,
>>>>> we rename in a branch. And the branched code can be copied into
>>>Commons
>>>>> github as final.
>>>>>
>>>>> Thanks,
>>>>> Haifeng
>>>>>
>>>>>
>>>>> -Original Message-
>>>>> From: Chen, Haifeng [mailto:haifeng.c...@intel.com]
>>>>> Sent: Wednesday, February 24, 2016 12:40 PM
>>>>> To: Commons Developers List 
>>>>> Cc: common-...@hadoop.apache.org
>>>>> Subject: RE: [crypto][chimera] Next steps
>>>>>
>>>>> >> The same should be there with Chimera/Apache Crypto.
>>>>> Yes, current implementation will fallback to JCE Cipher if native is
>>>not
>>>>> available.
>>>>>
>>>>> [Uma] we would fix up IP issues if any sooner. If you see all the
>>>code
>>>>> file license header is with Apache License files.
>>>>> The current repo and package structure there with name Intel. I will
>>>>>check
>>>>> with Haifeng on resolution of this.
>>>>> I will work with this ASAP for clear this out.
>>>>>
>>>>> Thanks,
>>>>> Haifeng
>>>>>
>>>>> -Original Message-
>>>>> From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com]
>>>>> Sent: Wednesday, February 24, 2016 5:13 AM
>>>>> To: Commons Developers List 
>>>>> Cc: common-...@hadoop.apache.org
>>>>> Subject: Re: [crypto][chimera] Next steps
>>>>>
>>>>> Thanks all for the valuable feedbacks and discussions.
>>>>> Here are my replies for some of the questions..
>>>>> [Mark wrote]
>>>>> It depends. I care less about the quality of the code than I do about
>>>>>the
>>>>> community that comes with it / forms around it. A strong community
>>>can
>>>>>fix
>>>>> code issues. Great code can't save a weak community.
>>>>> [uma] Nice point. Fully agreed to it.
>>>>>
>>>>>
>>>>> [Jochen wrote]
>>>>> Therefore, I suggest that you provide at least fallback
>>>implementations
>>>>>in
>>>>> pure Java, which are being used, if the JNI based stuff is not
>>>available
>>>>> (for whatever reason).
>>>>> [Uma] Thank you for the suggestion Jochen, If I understand your point
>>>>> right,  Yes its there in Hadoop when we develop.
>>>>> Here is the JIRA HADOOP-10735 : Fall back AesCtrCryptoCodec
>>>>>implementation
>>>>> from OpenSSL to JCE if non native support.
>>>>>
>>>>> The same should be there with Chimera/Apache Crypto.
>>>>>
>>>>>
>>>>> [Benedikt]
>>>>> I still have concerns about the IP, since this seems to be an Intel
>>>>> codebase. I do not have the necessary experience to say what would be
>>>>>the
>>>>> right way here. My 

Re: [crypto][chimera] Next steps

[Benedikt Ritter]

> >>>Ok. Thanks Benedikt. We would get the proposal document ready soon.
> >>>Also one question, shall we rename the package to org.apache.* in
> >>>Chimera
> >>>git project first before pushing the code to Apache Commons? Or we can
> >>>work here once moved the code?
> >>>What do you suggest? For making package rename, component name should be
> >>>finalized I think.
> >>>
> >>>Does every one ok with "Apache Commons Crypto² ?
> >>>
> >>>Regards,
> >>>Uma
> >>>
> >>>On 2/26/16, 5:11 AM, "Benedikt Ritter"  wrote:
> >>>
> >>>>Okay, so I think the only thing missing before we start the
> >>>integration of
> >>>>the component is a PROPOSAL document, describing the scope of the
> >>>>component
> >>>>and a list of initial commiters/contributors.
> >>>>
> >>>>2016-02-26 3:24 GMT+01:00 Chen, Haifeng :
> >>>>
> >>>>> Come back to clear out the codebase and IP concerns.
> >>>>>
> >>>>> [Benedikt] I still have concerns about the IP, since this seems to
> >>>be an
> >>>>> Intel codebase.
> >>>>> I have checked this. Chimera was developed as Apache 2 License from
> >>>>>ground
> >>>>> up. Agree with Jochen that the license matters.
> >>>>> Internally, this was approved as part of larger open source efforts
> >>>on
> >>>>> Apache Hadoop and related projects in Intel. We have IP plan
> >>>considered
> >>>>>as
> >>>>> part the open source process.
> >>>>>
> >>>>> As to the codebase, such as the package name is com.intel prefixed,
> >>>it
> >>>>>was
> >>>>> technical decision when using com.intel.chimera as the package
> >>>prefix.
> >>>>>We
> >>>>> original planned to use org.apache.chimera prefix. But we found that
> >>>we
> >>>>> couldnot publish org.apache. grouped artifacts to maven central
> >>>>>repository,
> >>>>> which needs to somewhat ownership for org.apache domain.
> >>>>>
> >>>>> To resolve the codebase problem, once all things are ready from
> >>>Commons,
> >>>>> we rename in a branch. And the branched code can be copied into
> >>>Commons
> >>>>> github as final.
> >>>>>
> >>>>> Thanks,
> >>>>> Haifeng
> >>>>>
> >>>>>
> >>>>> -Original Message-
> >>>>> From: Chen, Haifeng [mailto:haifeng.c...@intel.com]
> >>>>> Sent: Wednesday, February 24, 2016 12:40 PM
> >>>>> To: Commons Developers List 
> >>>>> Cc: common-...@hadoop.apache.org
> >>>>> Subject: RE: [crypto][chimera] Next steps
> >>>>>
> >>>>> >> The same should be there with Chimera/Apache Crypto.
> >>>>> Yes, current implementation will fallback to JCE Cipher if native is
> >>>not
> >>>>> available.
> >>>>>
> >>>>> [Uma] we would fix up IP issues if any sooner. If you see all the
> >>>code
> >>>>> file license header is with Apache License files.
> >>>>> The current repo and package structure there with name Intel. I will
> >>>>>check
> >>>>> with Haifeng on resolution of this.
> >>>>> I will work with this ASAP for clear this out.
> >>>>>
> >>>>> Thanks,
> >>>>> Haifeng
> >>>>>
> >>>>> -Original Message-
> >>>>> From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com]
> >>>>> Sent: Wednesday, February 24, 2016 5:13 AM
> >>>>> To: Commons Developers List 
> >>>>> Cc: common-...@hadoop.apache.org
> >>>>> Subject: Re: [crypto][chimera] Next steps
> >>>>>
> >>>>> Thanks all for the valuable feedbacks and discussions.
> >>>>> Here are my replies for some of the questions..
> >>>>> [Mark wrote]
> >>>>> It depends. I care less about the quality of the code than I do about
> >>>>>the
> >>>>> commun

Re: [crypto][chimera] Next steps

[Gangumalla, Uma]

Dear all, Sorry for the delay. Working out on the proposal document, we
will get it posted here soon.

Regards,
Uma


On 2/26/16, 1:26 PM, "Gary Gregory"  wrote:

>I take it the Crypto squared is a typo and that you wanted to close the
>quote.
>
>G
>
>On Fri, Feb 26, 2016 at 12:47 PM, Gangumalla, Uma
>
>wrote:
>
>>
>> Ok. Thanks Benedikt. We would get the proposal document ready soon.
>> Also one question, shall we rename the package to org.apache.* in
>>Chimera
>> git project first before pushing the code to Apache Commons? Or we can
>> work here once moved the code?
>> What do you suggest? For making package rename, component name should be
>> finalized I think.
>>
>> Does every one ok with "Apache Commons Crypto² ?
>>
>> Regards,
>> Uma
>>
>> On 2/26/16, 5:11 AM, "Benedikt Ritter"  wrote:
>>
>> >Okay, so I think the only thing missing before we start the
>>integration of
>> >the component is a PROPOSAL document, describing the scope of the
>> >component
>> >and a list of initial commiters/contributors.
>> >
>> >2016-02-26 3:24 GMT+01:00 Chen, Haifeng :
>> >
>> >> Come back to clear out the codebase and IP concerns.
>> >>
>> >> [Benedikt] I still have concerns about the IP, since this seems to
>>be an
>> >> Intel codebase.
>> >> I have checked this. Chimera was developed as Apache 2 License from
>> >>ground
>> >> up. Agree with Jochen that the license matters.
>> >> Internally, this was approved as part of larger open source efforts
>>on
>> >> Apache Hadoop and related projects in Intel. We have IP plan
>>considered
>> >>as
>> >> part the open source process.
>> >>
>> >> As to the codebase, such as the package name is com.intel prefixed,
>>it
>> >>was
>> >> technical decision when using com.intel.chimera as the package
>>prefix.
>> >>We
>> >> original planned to use org.apache.chimera prefix. But we found that
>>we
>> >> couldnot publish org.apache. grouped artifacts to maven central
>> >>repository,
>> >> which needs to somewhat ownership for org.apache domain.
>> >>
>> >> To resolve the codebase problem, once all things are ready from
>>Commons,
>> >> we rename in a branch. And the branched code can be copied into
>>Commons
>> >> github as final.
>> >>
>> >> Thanks,
>> >> Haifeng
>> >>
>> >>
>> >> -Original Message-
>> >> From: Chen, Haifeng [mailto:haifeng.c...@intel.com]
>> >> Sent: Wednesday, February 24, 2016 12:40 PM
>> >> To: Commons Developers List 
>> >> Cc: common-...@hadoop.apache.org
>> >> Subject: RE: [crypto][chimera] Next steps
>> >>
>> >> >> The same should be there with Chimera/Apache Crypto.
>> >> Yes, current implementation will fallback to JCE Cipher if native is
>>not
>> >> available.
>> >>
>> >> [Uma] we would fix up IP issues if any sooner. If you see all the
>>code
>> >> file license header is with Apache License files.
>> >> The current repo and package structure there with name Intel. I will
>> >>check
>> >> with Haifeng on resolution of this.
>> >> I will work with this ASAP for clear this out.
>> >>
>> >> Thanks,
>> >> Haifeng
>> >>
>> >> -Original Message-
>> >> From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com]
>> >> Sent: Wednesday, February 24, 2016 5:13 AM
>> >> To: Commons Developers List 
>> >> Cc: common-...@hadoop.apache.org
>> >> Subject: Re: [crypto][chimera] Next steps
>> >>
>> >> Thanks all for the valuable feedbacks and discussions.
>> >> Here are my replies for some of the questions..
>> >> [Mark wrote]
>> >> It depends. I care less about the quality of the code than I do about
>> >>the
>> >> community that comes with it / forms around it. A strong community
>>can
>> >>fix
>> >> code issues. Great code can't save a weak community.
>> >> [uma] Nice point. Fully agreed to it.
>> >>
>> >>
>> >> [Jochen wrote]
>> >> Therefore, I suggest that you provide at least fallback
>>implementations
>> >>in
>> >>

Re: [crypto][chimera] Next steps

[Jochen Wiedmann]

On Fri, Feb 26, 2016 at 9:47 PM, Gangumalla, Uma
 wrote:

> Also one question, shall we rename the package to org.apache.* in Chimera
> git project first before pushing the code to Apache Commons? Or we can
> work here once moved the code?
> What do you suggest?

There is no need to do it in advance, However, as your IDE of choice
can most likely do that
semiautomatically, I'd suggest that this should be considered at least
a milestone towards the
first release. Or, in other words: The sooner, the better.

Jochen

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

RE: [crypto][chimera] Next steps

[Chen, Haifeng]

Thanks Bourg.

>> Even if Chimera doesn't implement a JCE provider due to its impractical 
>> nature, do you think it would be possible to reuse the standard Java types 
>> (Cipher, SecureRandom) instead or redefining them? The implementation could 
>> be instantiated directly (Cipher cipher = new OpensslCipher()) instead of 
>> calling Cipher.getInstance().
JCE architecture is quite heavy weight for such abstractions. In JCE design 
rational, the JCE Cipher class is not designed to be inherited or implemented 
by others. It's implementation class for final use and wraps to the under layer 
SPI mechanisms.

>> Another question, will there still be an incentive to use Chimera once Java 
>> 9 with the AES improvements is widely used? Should we consider Chimera as a 
>> temporary solution to the current Java limitations?
There are some still some improvements will not happen in JDK 9 release. For 
example, Openssl GCM will still 4x - 6x faster. Of source optimization is one 
aspect, the stream or io classes build on it are also useful. Also consider 
that the release JDK9 will not available in some time 2017. The wider adoption 
of JDK9 will be much later than that time I guess.

Thanks,
Haifeng

-Original Message-
From: Emmanuel Bourg [mailto:ebo...@apache.org] 
Sent: Friday, February 26, 2016 11:03 PM
To: Commons Developers List 
Cc: common-...@hadoop.apache.org
Subject: Re: [crypto][chimera] Next steps

Le 24/02/2016 03:41, Chen, Haifeng a écrit :

> Hope this information helps. Thanks Bourg for these insightful questions.

It does, thank you for the insights.

Even if Chimera doesn't implement a JCE provider due to its impractical nature, 
do you think it would be possible to reuse the standard Java types (Cipher, 
SecureRandom) instead or redefining them? The implementation could be 
instantiated directly (Cipher cipher = new
OpensslCipher()) instead of calling Cipher.getInstance().

Another question, will there still be an incentive to use Chimera once Java 9 
with the AES improvements is widely used? Should we consider Chimera as a 
temporary solution to the current Java limitations?

Emmanuel Bourg

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [crypto][chimera] Next steps

[Gangumalla, Uma]

Yup. Thanks Gary for noting it. I don’t mean it to be squared :-)

“Apache Commons Crypto”

Also package name to be org.apache.commons.

Regards,
Uma



>
>On 2/26/16, 1:26 PM, "Gary Gregory"  wrote:
>
>>I take it the Crypto squared is a typo and that you wanted to close the
>>quote.
>>
>>G
>>
>>On Fri, Feb 26, 2016 at 12:47 PM, Gangumalla, Uma
>>
>>wrote:
>>
>>>
>>> Ok. Thanks Benedikt. We would get the proposal document ready soon.
>>> Also one question, shall we rename the package to org.apache.* in
>>>Chimera
>>> git project first before pushing the code to Apache Commons? Or we can
>>> work here once moved the code?
>>> What do you suggest? For making package rename, component name should
>>>be
>>> finalized I think.
>>>
>>> Does every one ok with "Apache Commons Crypto² ?
>>>
>>> Regards,
>>> Uma
>>>
>>> On 2/26/16, 5:11 AM, "Benedikt Ritter"  wrote:
>>>
>>> >Okay, so I think the only thing missing before we start the
>>>integration of
>>> >the component is a PROPOSAL document, describing the scope of the
>>> >component
>>> >and a list of initial commiters/contributors.
>>> >
>>> >2016-02-26 3:24 GMT+01:00 Chen, Haifeng :
>>> >
>>> >> Come back to clear out the codebase and IP concerns.
>>> >>
>>> >> [Benedikt] I still have concerns about the IP, since this seems to
>>>be an
>>> >> Intel codebase.
>>> >> I have checked this. Chimera was developed as Apache 2 License from
>>> >>ground
>>> >> up. Agree with Jochen that the license matters.
>>> >> Internally, this was approved as part of larger open source efforts
>>>on
>>> >> Apache Hadoop and related projects in Intel. We have IP plan
>>>considered
>>> >>as
>>> >> part the open source process.
>>> >>
>>> >> As to the codebase, such as the package name is com.intel prefixed,
>>>it
>>> >>was
>>> >> technical decision when using com.intel.chimera as the package
>>>prefix.
>>> >>We
>>> >> original planned to use org.apache.chimera prefix. But we found that
>>>we
>>> >> couldnot publish org.apache. grouped artifacts to maven central
>>> >>repository,
>>> >> which needs to somewhat ownership for org.apache domain.
>>> >>
>>> >> To resolve the codebase problem, once all things are ready from
>>>Commons,
>>> >> we rename in a branch. And the branched code can be copied into
>>>Commons
>>> >> github as final.
>>> >>
>>> >> Thanks,
>>> >> Haifeng
>>> >>
>>> >>
>>> >> -Original Message-
>>> >> From: Chen, Haifeng [mailto:haifeng.c...@intel.com]
>>> >> Sent: Wednesday, February 24, 2016 12:40 PM
>>> >> To: Commons Developers List 
>>> >> Cc: common-...@hadoop.apache.org
>>> >> Subject: RE: [crypto][chimera] Next steps
>>> >>
>>> >> >> The same should be there with Chimera/Apache Crypto.
>>> >> Yes, current implementation will fallback to JCE Cipher if native is
>>>not
>>> >> available.
>>> >>
>>> >> [Uma] we would fix up IP issues if any sooner. If you see all the
>>>code
>>> >> file license header is with Apache License files.
>>> >> The current repo and package structure there with name Intel. I will
>>> >>check
>>> >> with Haifeng on resolution of this.
>>> >> I will work with this ASAP for clear this out.
>>> >>
>>> >> Thanks,
>>> >> Haifeng
>>> >>
>>> >> -Original Message-
>>> >> From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com]
>>> >> Sent: Wednesday, February 24, 2016 5:13 AM
>>> >> To: Commons Developers List 
>>> >> Cc: common-...@hadoop.apache.org
>>> >> Subject: Re: [crypto][chimera] Next steps
>>> >>
>>> >> Thanks all for the valuable feedbacks and discussions.
>>> >> Here are my replies for some of the questions..
>>> >> [Mark wrote]
>>> >> It depends. I care less about the quality of the code than I do
>

Re: [crypto][chimera] Next steps

[Gary Gregory]

I take it the Crypto squared is a typo and that you wanted to close the
quote.

G

On Fri, Feb 26, 2016 at 12:47 PM, Gangumalla, Uma 
wrote:

>
> Ok. Thanks Benedikt. We would get the proposal document ready soon.
> Also one question, shall we rename the package to org.apache.* in Chimera
> git project first before pushing the code to Apache Commons? Or we can
> work here once moved the code?
> What do you suggest? For making package rename, component name should be
> finalized I think.
>
> Does every one ok with "Apache Commons Crypto² ?
>
> Regards,
> Uma
>
> On 2/26/16, 5:11 AM, "Benedikt Ritter"  wrote:
>
> >Okay, so I think the only thing missing before we start the integration of
> >the component is a PROPOSAL document, describing the scope of the
> >component
> >and a list of initial commiters/contributors.
> >
> >2016-02-26 3:24 GMT+01:00 Chen, Haifeng :
> >
> >> Come back to clear out the codebase and IP concerns.
> >>
> >> [Benedikt] I still have concerns about the IP, since this seems to be an
> >> Intel codebase.
> >> I have checked this. Chimera was developed as Apache 2 License from
> >>ground
> >> up. Agree with Jochen that the license matters.
> >> Internally, this was approved as part of larger open source efforts on
> >> Apache Hadoop and related projects in Intel. We have IP plan considered
> >>as
> >> part the open source process.
> >>
> >> As to the codebase, such as the package name is com.intel prefixed, it
> >>was
> >> technical decision when using com.intel.chimera as the package prefix.
> >>We
> >> original planned to use org.apache.chimera prefix. But we found that we
> >> couldnot publish org.apache. grouped artifacts to maven central
> >>repository,
> >> which needs to somewhat ownership for org.apache domain.
> >>
> >> To resolve the codebase problem, once all things are ready from Commons,
> >> we rename in a branch. And the branched code can be copied into Commons
> >> github as final.
> >>
> >> Thanks,
> >> Haifeng
> >>
> >>
> >> -Original Message-
> >> From: Chen, Haifeng [mailto:haifeng.c...@intel.com]
> >> Sent: Wednesday, February 24, 2016 12:40 PM
> >> To: Commons Developers List 
> >> Cc: common-...@hadoop.apache.org
> >> Subject: RE: [crypto][chimera] Next steps
> >>
> >> >> The same should be there with Chimera/Apache Crypto.
> >> Yes, current implementation will fallback to JCE Cipher if native is not
> >> available.
> >>
> >> [Uma] we would fix up IP issues if any sooner. If you see all the code
> >> file license header is with Apache License files.
> >> The current repo and package structure there with name Intel. I will
> >>check
> >> with Haifeng on resolution of this.
> >> I will work with this ASAP for clear this out.
> >>
> >> Thanks,
> >> Haifeng
> >>
> >> -Original Message-
> >> From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com]
> >> Sent: Wednesday, February 24, 2016 5:13 AM
> >> To: Commons Developers List 
> >> Cc: common-...@hadoop.apache.org
> >> Subject: Re: [crypto][chimera] Next steps
> >>
> >> Thanks all for the valuable feedbacks and discussions.
> >> Here are my replies for some of the questions..
> >> [Mark wrote]
> >> It depends. I care less about the quality of the code than I do about
> >>the
> >> community that comes with it / forms around it. A strong community can
> >>fix
> >> code issues. Great code can't save a weak community.
> >> [uma] Nice point. Fully agreed to it.
> >>
> >>
> >> [Jochen wrote]
> >> Therefore, I suggest that you provide at least fallback implementations
> >>in
> >> pure Java, which are being used, if the JNI based stuff is not available
> >> (for whatever reason).
> >> [Uma] Thank you for the suggestion Jochen, If I understand your point
> >> right,  Yes its there in Hadoop when we develop.
> >> Here is the JIRA HADOOP-10735 : Fall back AesCtrCryptoCodec
> >>implementation
> >> from OpenSSL to JCE if non native support.
> >>
> >> The same should be there with Chimera/Apache Crypto.
> >>
> >>
> >> [Benedikt]
> >> I still have concerns about the IP, since this seems to be an Intel
> >> codebase. I do not have the necessary experienc

Re: [crypto][chimera] Next steps

[Gangumalla, Uma]

Ok. Thanks Benedikt. We would get the proposal document ready soon.
Also one question, shall we rename the package to org.apache.* in Chimera
git project first before pushing the code to Apache Commons? Or we can
work here once moved the code?
What do you suggest? For making package rename, component name should be
finalized I think. 

Does every one ok with "Apache Commons Crypto² ?

Regards,
Uma 

On 2/26/16, 5:11 AM, "Benedikt Ritter"  wrote:

>Okay, so I think the only thing missing before we start the integration of
>the component is a PROPOSAL document, describing the scope of the
>component
>and a list of initial commiters/contributors.
>
>2016-02-26 3:24 GMT+01:00 Chen, Haifeng :
>
>> Come back to clear out the codebase and IP concerns.
>>
>> [Benedikt] I still have concerns about the IP, since this seems to be an
>> Intel codebase.
>> I have checked this. Chimera was developed as Apache 2 License from
>>ground
>> up. Agree with Jochen that the license matters.
>> Internally, this was approved as part of larger open source efforts on
>> Apache Hadoop and related projects in Intel. We have IP plan considered
>>as
>> part the open source process.
>>
>> As to the codebase, such as the package name is com.intel prefixed, it
>>was
>> technical decision when using com.intel.chimera as the package prefix.
>>We
>> original planned to use org.apache.chimera prefix. But we found that we
>> couldnot publish org.apache. grouped artifacts to maven central
>>repository,
>> which needs to somewhat ownership for org.apache domain.
>>
>> To resolve the codebase problem, once all things are ready from Commons,
>> we rename in a branch. And the branched code can be copied into Commons
>> github as final.
>>
>> Thanks,
>> Haifeng
>>
>>
>> -Original Message-
>> From: Chen, Haifeng [mailto:haifeng.c...@intel.com]
>> Sent: Wednesday, February 24, 2016 12:40 PM
>> To: Commons Developers List 
>> Cc: common-...@hadoop.apache.org
>> Subject: RE: [crypto][chimera] Next steps
>>
>> >> The same should be there with Chimera/Apache Crypto.
>> Yes, current implementation will fallback to JCE Cipher if native is not
>> available.
>>
>> [Uma] we would fix up IP issues if any sooner. If you see all the code
>> file license header is with Apache License files.
>> The current repo and package structure there with name Intel. I will
>>check
>> with Haifeng on resolution of this.
>> I will work with this ASAP for clear this out.
>>
>> Thanks,
>> Haifeng
>>
>> -Original Message-
>> From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com]
>> Sent: Wednesday, February 24, 2016 5:13 AM
>> To: Commons Developers List 
>> Cc: common-...@hadoop.apache.org
>> Subject: Re: [crypto][chimera] Next steps
>>
>> Thanks all for the valuable feedbacks and discussions.
>> Here are my replies for some of the questions..
>> [Mark wrote]
>> It depends. I care less about the quality of the code than I do about
>>the
>> community that comes with it / forms around it. A strong community can
>>fix
>> code issues. Great code can't save a weak community.
>> [uma] Nice point. Fully agreed to it.
>>
>>
>> [Jochen wrote]
>> Therefore, I suggest that you provide at least fallback implementations
>>in
>> pure Java, which are being used, if the JNI based stuff is not available
>> (for whatever reason).
>> [Uma] Thank you for the suggestion Jochen, If I understand your point
>> right,  Yes its there in Hadoop when we develop.
>> Here is the JIRA HADOOP-10735 : Fall back AesCtrCryptoCodec
>>implementation
>> from OpenSSL to JCE if non native support.
>>
>> The same should be there with Chimera/Apache Crypto.
>>
>>
>> [Benedikt]
>> I still have concerns about the IP, since this seems to be an Intel
>> codebase. I do not have the necessary experience to say what would be
>>the
>> right way here. My gut feeling tells me, that we should go through the
>> incubator. WDYT?
>> And [Jochen wrote]
>> "An Intel codebase" is not a problem as such. Question is: "Available
>> under what license?"
>>
>> [Uma] we would fix up IP issues if any sooner. If you see all the code
>> file license header is with Apache License files.
>> The current repo and package structure there with name Intel. I will
>>check
>> with Haifeng on resolution of this.
>>
>>
>> [Jochen wrote]
>> So, have the Chimera project attempt t

Re: [crypto][chimera] Next steps

[Emmanuel Bourg]

Le 24/02/2016 03:41, Chen, Haifeng a écrit :

> Hope this information helps. Thanks Bourg for these insightful questions.

It does, thank you for the insights.

Even if Chimera doesn't implement a JCE provider due to its impractical
nature, do you think it would be possible to reuse the standard Java
types (Cipher, SecureRandom) instead or redefining them? The
implementation could be instantiated directly (Cipher cipher = new
OpensslCipher()) instead of calling Cipher.getInstance().

Another question, will there still be an incentive to use Chimera once
Java 9 with the AES improvements is widely used? Should we consider
Chimera as a temporary solution to the current Java limitations?

Emmanuel Bourg

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [crypto][chimera] Next steps

[Benedikt Ritter]

Okay, so I think the only thing missing before we start the integration of
the component is a PROPOSAL document, describing the scope of the component
and a list of initial commiters/contributors.

2016-02-26 3:24 GMT+01:00 Chen, Haifeng :

> Come back to clear out the codebase and IP concerns.
>
> [Benedikt] I still have concerns about the IP, since this seems to be an
> Intel codebase.
> I have checked this. Chimera was developed as Apache 2 License from ground
> up. Agree with Jochen that the license matters.
> Internally, this was approved as part of larger open source efforts on
> Apache Hadoop and related projects in Intel. We have IP plan considered as
> part the open source process.
>
> As to the codebase, such as the package name is com.intel prefixed, it was
> technical decision when using com.intel.chimera as the package prefix. We
> original planned to use org.apache.chimera prefix. But we found that we
> couldnot publish org.apache. grouped artifacts to maven central repository,
> which needs to somewhat ownership for org.apache domain.
>
> To resolve the codebase problem, once all things are ready from Commons,
> we rename in a branch. And the branched code can be copied into Commons
> github as final.
>
> Thanks,
> Haifeng
>
>
> -Original Message-
> From: Chen, Haifeng [mailto:haifeng.c...@intel.com]
> Sent: Wednesday, February 24, 2016 12:40 PM
> To: Commons Developers List 
> Cc: common-...@hadoop.apache.org
> Subject: RE: [crypto][chimera] Next steps
>
> >> The same should be there with Chimera/Apache Crypto.
> Yes, current implementation will fallback to JCE Cipher if native is not
> available.
>
> [Uma] we would fix up IP issues if any sooner. If you see all the code
> file license header is with Apache License files.
> The current repo and package structure there with name Intel. I will check
> with Haifeng on resolution of this.
> I will work with this ASAP for clear this out.
>
> Thanks,
> Haifeng
>
> -Original Message-
> From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com]
> Sent: Wednesday, February 24, 2016 5:13 AM
> To: Commons Developers List 
> Cc: common-...@hadoop.apache.org
> Subject: Re: [crypto][chimera] Next steps
>
> Thanks all for the valuable feedbacks and discussions.
> Here are my replies for some of the questions..
> [Mark wrote]
> It depends. I care less about the quality of the code than I do about the
> community that comes with it / forms around it. A strong community can fix
> code issues. Great code can't save a weak community.
> [uma] Nice point. Fully agreed to it.
>
>
> [Jochen wrote]
> Therefore, I suggest that you provide at least fallback implementations in
> pure Java, which are being used, if the JNI based stuff is not available
> (for whatever reason).
> [Uma] Thank you for the suggestion Jochen, If I understand your point
> right,  Yes its there in Hadoop when we develop.
> Here is the JIRA HADOOP-10735 : Fall back AesCtrCryptoCodec implementation
> from OpenSSL to JCE if non native support.
>
> The same should be there with Chimera/Apache Crypto.
>
>
> [Benedikt]
> I still have concerns about the IP, since this seems to be an Intel
> codebase. I do not have the necessary experience to say what would be the
> right way here. My gut feeling tells me, that we should go through the
> incubator. WDYT?
> And [Jochen wrote]
> "An Intel codebase" is not a problem as such. Question is: "Available
> under what license?"
>
> [Uma] we would fix up IP issues if any sooner. If you see all the code
> file license header is with Apache License files.
> The current repo and package structure there with name Intel. I will check
> with Haifeng on resolution of this.
>
>
> [Jochen wrote]
> So, have the Chimera project attempt to resolve them quickly. If
> possible: Fine. If not: We still have the Incubator as a possibility.
> [Uma] Agree. We would resolve on this points in sooner.
>
>
> Regards,
> Uma
>
>
> On 2/23/16, 1:18 AM, "Mark Thomas"  wrote:
>
> >On 23/02/2016 09:12, sebb wrote:
> >> On 23 February 2016 at 07:34, Benedikt Ritter 
> >>wrote:
> >>> I'm confused. None of the other PMC members has expressed whether he
> >>>or she  want's the see Chimera/crypto joining Apache Commons, yet
> >>>we're already  discussing how JNI bindings should be handled.
> >>>
> >>> I'd like to see:
> >>> 1) a clear statement whether Chimera/crypto should become part of
> >>>Apache  Commons. Do we need a vote for that?
> >>
> >> Yes, of course.
> >>
> >> However that d

RE: [crypto][chimera] Next steps

[Chen, Haifeng]

Come back to clear out the codebase and IP concerns.

[Benedikt] I still have concerns about the IP, since this seems to be an Intel 
codebase.
I have checked this. Chimera was developed as Apache 2 License from ground up. 
Agree with Jochen that the license matters.
Internally, this was approved as part of larger open source efforts on Apache 
Hadoop and related projects in Intel. We have IP plan considered as part the 
open source process.

As to the codebase, such as the package name is com.intel prefixed, it was 
technical decision when using com.intel.chimera as the package prefix. We 
original planned to use org.apache.chimera prefix. But we found that we 
couldnot publish org.apache. grouped artifacts to maven central repository, 
which needs to somewhat ownership for org.apache domain.

To resolve the codebase problem, once all things are ready from Commons, we 
rename in a branch. And the branched code can be copied into Commons github as 
final. 

Thanks,
Haifeng


-Original Message-
From: Chen, Haifeng [mailto:haifeng.c...@intel.com] 
Sent: Wednesday, February 24, 2016 12:40 PM
To: Commons Developers List 
Cc: common-...@hadoop.apache.org
Subject: RE: [crypto][chimera] Next steps

>> The same should be there with Chimera/Apache Crypto.
Yes, current implementation will fallback to JCE Cipher if native is not 
available.

[Uma] we would fix up IP issues if any sooner. If you see all the code file 
license header is with Apache License files.
The current repo and package structure there with name Intel. I will check with 
Haifeng on resolution of this.
I will work with this ASAP for clear this out.

Thanks,
Haifeng

-Original Message-
From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com]
Sent: Wednesday, February 24, 2016 5:13 AM
To: Commons Developers List 
Cc: common-...@hadoop.apache.org
Subject: Re: [crypto][chimera] Next steps

Thanks all for the valuable feedbacks and discussions.
Here are my replies for some of the questions..
[Mark wrote]
It depends. I care less about the quality of the code than I do about the 
community that comes with it / forms around it. A strong community can fix code 
issues. Great code can't save a weak community.
[uma] Nice point. Fully agreed to it.


[Jochen wrote]
Therefore, I suggest that you provide at least fallback implementations in pure 
Java, which are being used, if the JNI based stuff is not available (for 
whatever reason).
[Uma] Thank you for the suggestion Jochen, If I understand your point right,  
Yes its there in Hadoop when we develop.
Here is the JIRA HADOOP-10735 : Fall back AesCtrCryptoCodec implementation from 
OpenSSL to JCE if non native support.

The same should be there with Chimera/Apache Crypto.


[Benedikt]
I still have concerns about the IP, since this seems to be an Intel codebase. I 
do not have the necessary experience to say what would be the right way here. 
My gut feeling tells me, that we should go through the incubator. WDYT?
And [Jochen wrote]
"An Intel codebase" is not a problem as such. Question is: "Available under 
what license?"

[Uma] we would fix up IP issues if any sooner. If you see all the code file 
license header is with Apache License files.
The current repo and package structure there with name Intel. I will check with 
Haifeng on resolution of this.


[Jochen wrote]
So, have the Chimera project attempt to resolve them quickly. If
possible: Fine. If not: We still have the Incubator as a possibility.
[Uma] Agree. We would resolve on this points in sooner.


Regards,
Uma

 
On 2/23/16, 1:18 AM, "Mark Thomas"  wrote:

>On 23/02/2016 09:12, sebb wrote:
>> On 23 February 2016 at 07:34, Benedikt Ritter 
>>wrote:
>>> I'm confused. None of the other PMC members has expressed whether he 
>>>or she  want's the see Chimera/crypto joining Apache Commons, yet 
>>>we're already  discussing how JNI bindings should be handled.
>>>
>>> I'd like to see:
>>> 1) a clear statement whether Chimera/crypto should become part of 
>>>Apache  Commons. Do we need a vote for that?
>> 
>> Yes, of course.
>> 
>> However that decision clearly depends on at least some of the design 
>> aspects of the code.
>> If it were written entirely in C or Fortran, it would not be a 
>> suitable candidate.
>> 
>>> 2) Discuss a plan on how to do that (I've described a possible plan
>>>[1])
>>> 3) After that is clear: discuss design details regarding the component.
>> 
>> Some design details impact on the decision.
>> 
>> Indeed even for pure Java code the code quality has a bearing on 
>> whether Commons would/could want to take it.
>> Would we want a large code base with no unit-tests, no build 
>> mechanism, and no comments?
>
>It depends. I care less about the quality o

RE: [crypto][chimera] Next steps

[Chen, Haifeng]

>> The same should be there with Chimera/Apache Crypto.
Yes, current implementation will fallback to JCE Cipher if native is not 
available.

[Uma] we would fix up IP issues if any sooner. If you see all the code file 
license header is with Apache License files.
The current repo and package structure there with name Intel. I will check with 
Haifeng on resolution of this.
I will work with this ASAP for clear this out.

Thanks,
Haifeng

-Original Message-
From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com] 
Sent: Wednesday, February 24, 2016 5:13 AM
To: Commons Developers List 
Cc: common-...@hadoop.apache.org
Subject: Re: [crypto][chimera] Next steps

Thanks all for the valuable feedbacks and discussions.
Here are my replies for some of the questions..
[Mark wrote]
It depends. I care less about the quality of the code than I do about the 
community that comes with it / forms around it. A strong community can fix code 
issues. Great code can't save a weak community.
[uma] Nice point. Fully agreed to it.


[Jochen wrote]
Therefore, I suggest that you provide at least fallback implementations in pure 
Java, which are being used, if the JNI based stuff is not available (for 
whatever reason).
[Uma] Thank you for the suggestion Jochen, If I understand your point right,  
Yes its there in Hadoop when we develop.
Here is the JIRA HADOOP-10735 : Fall back AesCtrCryptoCodec implementation from 
OpenSSL to JCE if non native support.

The same should be there with Chimera/Apache Crypto.


[Benedikt]
I still have concerns about the IP, since this seems to be an Intel codebase. I 
do not have the necessary experience to say what would be the right way here. 
My gut feeling tells me, that we should go through the incubator. WDYT?
And [Jochen wrote]
"An Intel codebase" is not a problem as such. Question is: "Available under 
what license?"

[Uma] we would fix up IP issues if any sooner. If you see all the code file 
license header is with Apache License files.
The current repo and package structure there with name Intel. I will check with 
Haifeng on resolution of this.


[Jochen wrote]
So, have the Chimera project attempt to resolve them quickly. If
possible: Fine. If not: We still have the Incubator as a possibility.
[Uma] Agree. We would resolve on this points in sooner.


Regards,
Uma

 
On 2/23/16, 1:18 AM, "Mark Thomas"  wrote:

>On 23/02/2016 09:12, sebb wrote:
>> On 23 February 2016 at 07:34, Benedikt Ritter 
>>wrote:
>>> I'm confused. None of the other PMC members has expressed whether he 
>>>or she  want's the see Chimera/crypto joining Apache Commons, yet 
>>>we're already  discussing how JNI bindings should be handled.
>>>
>>> I'd like to see:
>>> 1) a clear statement whether Chimera/crypto should become part of 
>>>Apache  Commons. Do we need a vote for that?
>> 
>> Yes, of course.
>> 
>> However that decision clearly depends on at least some of the design 
>> aspects of the code.
>> If it were written entirely in C or Fortran, it would not be a 
>> suitable candidate.
>> 
>>> 2) Discuss a plan on how to do that (I've described a possible plan
>>>[1])
>>> 3) After that is clear: discuss design details regarding the component.
>> 
>> Some design details impact on the decision.
>> 
>> Indeed even for pure Java code the code quality has a bearing on 
>> whether Commons would/could want to take it.
>> Would we want a large code base with no unit-tests, no build 
>> mechanism, and no comments?
>
>It depends. I care less about the quality of the code than I do about 
>the community that comes with it / forms around it. A strong community 
>can fix code issues. Great code can't save a weak community.
>
>How about creating a new sandbox component, let folks start work and 
>see how the community develops?
>
>Mark
>
>
>> 
>>> Thanks! :-)
>>> Benedikt
>>>
>>> [1] http://markmail.org/message/74j4el6bpfpt4evs
>>>
>>> 2016-02-23 3:03 GMT+01:00 Xu, Cheng A :
>>>
>>>> At this point, it has just Java interfaces only.
>>>>
>>>> -Original Message-
>>>> From: Colin P. McCabe [mailto:cmcc...@apache.org]
>>>> Sent: Tuesday, February 23, 2016 1:29 AM
>>>> To: Hadoop Common
>>>> Cc: Commons Developers List
>>>> Subject: Re: [crypto][chimera] Next steps
>>>>
>>>> I would highly recommend shading this library when it is used in 
>>>> Hadoop and/or Spark, to prevent version skew problems between 
>>>> Hadoop and Spark like we have had in the past.
>>>>
>>>> What is the strategy for h

RE: [crypto][chimera] Next steps

[Chen, Haifeng]

Thanks Bourg for these questions.

>> Sorry if it sounds naive, but why not accessing the OpenSSL functions 
>> through a JCE provider instead of building an abstraction layer on top of 
>> another abstraction layer (JCE). The Apache JuiCE project was an attempt to 
>> implement this idea a few years ago [1]. With an OpenSSL based JCE provider 
>> the CryptoInput/OutputStream could probably be replaced by 
>> javax.crypto.CipherInput/OutputStream. As for the secure random part the 
>> standard java.security.SecureRandomSpi mechanism could be used to provide an 
>> OpenSSL based implementation.
>> What do you think?
This is not naïve and very valid questions. We actually struggled a long time 
on these points from Bourg. We in Intel was driving the community to get the 
full use of hardware acceleration in encryption for a long time. We tried that 
way before. Diceros (https://github.com/intel-hadoop/diceros) project is 
exactly like what you mentioned. It provides OpenSSL based JCE provider as well 
as Secure Random SPI.

Technically and architecturally, this approach is nicely fit what the JCE 
architecture targets to do. But a JCE Provider needs to be officially 
certificated and signed, which can only be built and distributed by the 
specific organization such as Intel. This will prevent its adoption in the open 
source community who put much their trust on Apache open source. The developer 
cannot build their own version unless they have Oracle certificated private 
key. Another issue of this approach is the need for user to configure their JRE 
environment with the new JCE provider through java.security file (Although this 
can be overcome technically by dynamic register).

While Chimera approach is similar to JCE approach technically but instead as a 
JCD provider, it acts as a "reference it and use" library. 

This second value proposition for Chimera is for its stream layer and its 
abstraction of Input and Output interface. Bourg mentioned javax CipherInput 
and CipherOutputStream. The layer will support Stream, Channel input out of box 
and can be easily extended with new Input and Output sources. We also see the 
importance of CTR mode which provides advanced characteristics such as random 
seek features on crypto streams. This is very important for big data encryption 
such HDFS which needs to read at the random positions. In this layer, other 
valuable things can be added when needed. The utility library is needed in 
these area in Apache Commons whose development, enhancement and release will be 
much agile than JDK improve its classes.

>> Another dumb question, isn't AES-NI enabled by default in Java 8 nowadays 
>> [2]? Do you still get a significant speed up with Chimera in this case? If 
>> so I think contributing the improvements to OpenJDK would be a good idea 
>> too, this will benefit everyone in the next Java releases.
This is a very good question. JDK 6 is not optimized. JDK 7 and JDK 8 is 
partial optimized for some modes. We can see 17x throughput improvement for 
AES/CTR mode. 5x - 6x speedup for GCM mode. 

>> If so I think contributing the improvements to OpenJDK would be a good idea 
>> too, this will benefit everyone in the next Java releases.
Exactly, we have been working with Oracle team to bring these optimizations in 
latest JDK development. In Jan 2016, we committed the optimization on CTR to 
OpenJDK. (https://bugs.openjdk.java.net/browse/JDK-8143925)


Hope this information helps. Thanks Bourg for these insightful questions.

Thanks,
Haifeng

-Original Message-
From: Emmanuel Bourg [mailto:emmanuel.bo...@gmail.com] On Behalf Of Emmanuel 
Bourg
Sent: Tuesday, February 23, 2016 6:53 PM
To: Commons Developers List 
Cc: common-...@hadoop.apache.org
Subject: Re: [crypto][chimera] Next steps

Hi all,

I got a quick look at the Chimera code. If I understand well it consists in:
- a native interface to the OpenSSL AES & secure random functions
- an abstraction layer to use the JCE or OpenSSL AES implementation
- an abstraction layer to use the JCE or OpenSSL secure random
- encrypting/decrypting input/output streams

Sorry if it sounds naive, but why not accessing the OpenSSL functions through a 
JCE provider instead of building an abstraction layer on top of another 
abstraction layer (JCE). The Apache JuiCE project was an attempt to implement 
this idea a few years ago [1]. With an OpenSSL based JCE provider the 
CryptoInput/OutputStream could probably be replaced by 
javax.crypto.CipherInput/OutputStream. As for the secure random part the 
standard java.security.SecureRandomSpi mechanism could be used to provide an 
OpenSSL based implementation.

What do you think?

Another dumb question, isn't AES-NI enabled by default in Java 8 nowadays [2]? 
Do you still get a significant speed up with Chimera in this case? If so I 
think contributing the improvemen

RE: [crypto][chimera] Next steps

[Xu, Cheng A]

Yes, we have implementations for both JCE cipher and Openssl Cipher. It's 
configurable for user.

-Original Message-
From: Jochen Wiedmann [mailto:jochen.wiedm...@gmail.com] 
Sent: Tuesday, February 23, 2016 5:40 PM
To: Commons Developers List
Cc: Hadoop Common
Subject: Re: [crypto][chimera] Next steps

On Tue, Feb 23, 2016 at 12:14 AM, Colin P. McCabe  wrote:

> Many CPUs come with built-in support for certain cryptographic and/or
> hash/checksum-related primitives.  For example, modern x86 CPUs have
> CRC32C implemented in hardware.  Currently, this must be accessed via
> inline assembly expressed in JNI.  It is worth it... at least in the
> case of checksumming, you often see 5x or 10x reductions in the amount
> of CPU used.  The gains for moving from pure Java to using the openSSL
> AES functions are similar.  Perhaps someday Java will gain native
> support for these features.  Until that point, though, JNI will be
> necessary to get reasonable performance on modern hardware.

Okay, I understand that you intend to give as good performance as possible.

However, keep in mind that "The thing works." is much more important
to users. And a dependency on JNI is a prime reason for failure to
work.

Therefore, I suggest that you provide at least fallback
implementations in pure Java, which are being used, if the JNI based
stuff is not available (for whatever reason).

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [crypto][chimera] Next steps

[Gary Gregory]

On Tue, Feb 23, 2016 at 2:53 AM, Emmanuel Bourg  wrote:

> Hi all,
>
> I got a quick look at the Chimera code. If I understand well it consists
> in:
> - a native interface to the OpenSSL AES & secure random functions
> - an abstraction layer to use the JCE or OpenSSL AES implementation
> - an abstraction layer to use the JCE or OpenSSL secure random
> - encrypting/decrypting input/output streams
>
> Sorry if it sounds naive, but why not accessing the OpenSSL functions
> through a JCE provider instead of building an abstraction layer on top
> of another abstraction layer (JCE). The Apache JuiCE project was an
> attempt to implement this idea a few years ago [1]. With an OpenSSL
> based JCE provider the CryptoInput/OutputStream could probably be
> replaced by javax.crypto.CipherInput/OutputStream. As for the secure
> random part the standard java.security.SecureRandomSpi mechanism could
> be used to provide an OpenSSL based implementation.
>
> What do you think?
>

Great questions! Looking forward to a reply...

Gary


>
> Another dumb question, isn't AES-NI enabled by default in Java 8
> nowadays [2]? Do you still get a significant speed up with Chimera in
> this case? If so I think contributing the improvements to OpenJDK would
> be a good idea too, this will benefit everyone in the next Java releases.
>
> Emmanuel Bourg
>
> [1] http://incubator.apache.org/projects/juice.html
> [2] http://openjdk.java.net/jeps/164
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [crypto][chimera] Next steps

[Gangumalla, Uma]

Thanks all for the valuable feedbacks and discussions.
Here are my replies for some of the questions..
[Mark wrote]
It depends. I care less about the quality of the code than I do about
the community that comes with it / forms around it. A strong community
can fix code issues. Great code can't save a weak community.
[uma] Nice point. Fully agreed to it.


[Jochen wrote]
Therefore, I suggest that you provide at least fallback
implementations in pure Java, which are being used, if the JNI based
stuff is not available (for whatever reason).
[Uma] Thank you for the suggestion Jochen, If I understand your point
right,  Yes its there in Hadoop when we develop.
Here is the JIRA HADOOP-10735 : Fall back AesCtrCryptoCodec implementation
from OpenSSL to JCE if non native support.

The same should be there with Chimera/Apache Crypto.


[Benedikt]
I still have concerns about the IP, since this seems to be an Intel
codebase. I do not have the necessary experience to say what would be the
right way here. My gut feeling tells me, that we should go through the
incubator. WDYT?
And [Jochen wrote]
"An Intel codebase" is not a problem as such. Question is: "Available
under what license?"

[Uma] we would fix up IP issues if any sooner. If you see all the code
file license header is with Apache License files.
The current repo and package structure there with name Intel. I will check
with Haifeng on resolution of this.


[Jochen wrote]
So, have the Chimera project attempt to resolve them quickly. If
possible: Fine. If not: We still have the Incubator as a possibility.
[Uma] Agree. We would resolve on this points in sooner.


Regards,
Uma

 
On 2/23/16, 1:18 AM, "Mark Thomas"  wrote:

>On 23/02/2016 09:12, sebb wrote:
>> On 23 February 2016 at 07:34, Benedikt Ritter 
>>wrote:
>>> I'm confused. None of the other PMC members has expressed whether he
>>>or she
>>> want's the see Chimera/crypto joining Apache Commons, yet we're already
>>> discussing how JNI bindings should be handled.
>>>
>>> I'd like to see:
>>> 1) a clear statement whether Chimera/crypto should become part of
>>>Apache
>>> Commons. Do we need a vote for that?
>> 
>> Yes, of course.
>> 
>> However that decision clearly depends on at least some of the design
>> aspects of the code.
>> If it were written entirely in C or Fortran, it would not be a
>> suitable candidate.
>> 
>>> 2) Discuss a plan on how to do that (I've described a possible plan
>>>[1])
>>> 3) After that is clear: discuss design details regarding the component.
>> 
>> Some design details impact on the decision.
>> 
>> Indeed even for pure Java code the code quality has a bearing on
>> whether Commons would/could want to take it.
>> Would we want a large code base with no unit-tests, no build
>> mechanism, and no comments?
>
>It depends. I care less about the quality of the code than I do about
>the community that comes with it / forms around it. A strong community
>can fix code issues. Great code can't save a weak community.
>
>How about creating a new sandbox component, let folks start work and see
>how the community develops?
>
>Mark
>
>
>> 
>>> Thanks! :-)
>>> Benedikt
>>>
>>> [1] http://markmail.org/message/74j4el6bpfpt4evs
>>>
>>> 2016-02-23 3:03 GMT+01:00 Xu, Cheng A :
>>>
>>>> At this point, it has just Java interfaces only.
>>>>
>>>> -Original Message-
>>>> From: Colin P. McCabe [mailto:cmcc...@apache.org]
>>>> Sent: Tuesday, February 23, 2016 1:29 AM
>>>> To: Hadoop Common
>>>> Cc: Commons Developers List
>>>> Subject: Re: [crypto][chimera] Next steps
>>>>
>>>> I would highly recommend shading this library when it is used in
>>>> Hadoop and/or Spark, to prevent version skew problems between Hadoop
>>>> and Spark like we have had in the past.
>>>>
>>>> What is the strategy for handling JNI components?  I think at a
>>>> minimum, we should include the version number in the native library
>>>> name to avoid problems when deploying multiple versions of Chimera.
>>>> This is something that has been problematic in Hadoop with
>>>> libhadoop.so.
>>>>
>>>> Is this library going to have Scala interfaces as well as Java ones,
>>>> or just Java?
>>>>
>>>> cheers,
>>>> Colin
>>>>
>>>> On Sat, Feb 20, 2016 at 3:15 AM, Benedikt Ritter 
>>>> wrote:
>>>>> Hi,
>>>>>
>>&

Re: [crypto][chimera] Next steps

[Emmanuel Bourg]

Hi all,

I got a quick look at the Chimera code. If I understand well it consists in:
- a native interface to the OpenSSL AES & secure random functions
- an abstraction layer to use the JCE or OpenSSL AES implementation
- an abstraction layer to use the JCE or OpenSSL secure random
- encrypting/decrypting input/output streams

Sorry if it sounds naive, but why not accessing the OpenSSL functions
through a JCE provider instead of building an abstraction layer on top
of another abstraction layer (JCE). The Apache JuiCE project was an
attempt to implement this idea a few years ago [1]. With an OpenSSL
based JCE provider the CryptoInput/OutputStream could probably be
replaced by javax.crypto.CipherInput/OutputStream. As for the secure
random part the standard java.security.SecureRandomSpi mechanism could
be used to provide an OpenSSL based implementation.

What do you think?

Another dumb question, isn't AES-NI enabled by default in Java 8
nowadays [2]? Do you still get a significant speed up with Chimera in
this case? If so I think contributing the improvements to OpenJDK would
be a good idea too, this will benefit everyone in the next Java releases.

Emmanuel Bourg

[1] http://incubator.apache.org/projects/juice.html
[2] http://openjdk.java.net/jeps/164


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [crypto][chimera] Next steps

[Jochen Wiedmann]

On Tue, Feb 23, 2016 at 10:47 AM, Benedikt Ritter  wrote:

> I still have concerns about the IP, since this seems to be an Intel
> codebase. I do not have the necessary experience to say what would be the
> right way here. My gut feeling tells me, that we should go through the
> incubator. WDYT?

A possible solution. OTOH: These concerns must be resolved, either
way. So, have the Chimera project attempt to resolve them quickly. If
possible: Fine. If not: We still have the Incubator as a possibility.

For now, the important part seems to me that you explain, what these
concerns are?
"An Intel codebase" is not a problem as such. Question is: "Available
under what license?"

Jochen


http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [crypto][chimera] Next steps

[Benedikt Ritter]

2016-02-23 10:18 GMT+01:00 Mark Thomas :

> On 23/02/2016 09:12, sebb wrote:
> > On 23 February 2016 at 07:34, Benedikt Ritter 
> wrote:
> >> I'm confused. None of the other PMC members has expressed whether he or
> she
> >> want's the see Chimera/crypto joining Apache Commons, yet we're already
> >> discussing how JNI bindings should be handled.
> >>
> >> I'd like to see:
> >> 1) a clear statement whether Chimera/crypto should become part of Apache
> >> Commons. Do we need a vote for that?
> >
> > Yes, of course.
> >
> > However that decision clearly depends on at least some of the design
> > aspects of the code.
> > If it were written entirely in C or Fortran, it would not be a
> > suitable candidate.
> >
> >> 2) Discuss a plan on how to do that (I've described a possible plan [1])
> >> 3) After that is clear: discuss design details regarding the component.
> >
> > Some design details impact on the decision.
> >
> > Indeed even for pure Java code the code quality has a bearing on
> > whether Commons would/could want to take it.
> > Would we want a large code base with no unit-tests, no build
> > mechanism, and no comments?
>
> It depends. I care less about the quality of the code than I do about
> the community that comes with it / forms around it. A strong community
> can fix code issues. Great code can't save a weak community.
>
> How about creating a new sandbox component, let folks start work and see
> how the community develops?
>

I still have concerns about the IP, since this seems to be an Intel
codebase. I do not have the necessary experience to say what would be the
right way here. My gut feeling tells me, that we should go through the
incubator. WDYT?

Regards,
Benedikt


>
> Mark
>
>
> >
> >> Thanks! :-)
> >> Benedikt
> >>
> >> [1] http://markmail.org/message/74j4el6bpfpt4evs
> >>
> >> 2016-02-23 3:03 GMT+01:00 Xu, Cheng A :
> >>
> >>> At this point, it has just Java interfaces only.
> >>>
> >>> -Original Message-
> >>> From: Colin P. McCabe [mailto:cmcc...@apache.org]
> >>> Sent: Tuesday, February 23, 2016 1:29 AM
> >>> To: Hadoop Common
> >>> Cc: Commons Developers List
> >>> Subject: Re: [crypto][chimera] Next steps
> >>>
> >>> I would highly recommend shading this library when it is used in
> >>> Hadoop and/or Spark, to prevent version skew problems between Hadoop
> >>> and Spark like we have had in the past.
> >>>
> >>> What is the strategy for handling JNI components?  I think at a
> >>> minimum, we should include the version number in the native library
> >>> name to avoid problems when deploying multiple versions of Chimera.
> >>> This is something that has been problematic in Hadoop with
> >>> libhadoop.so.
> >>>
> >>> Is this library going to have Scala interfaces as well as Java ones,
> >>> or just Java?
> >>>
> >>> cheers,
> >>> Colin
> >>>
> >>> On Sat, Feb 20, 2016 at 3:15 AM, Benedikt Ritter 
> >>> wrote:
> >>>> Hi,
> >>>>
> >>>> I'd like to discuss the next steps for moving the Chimera component to
> >>>> Apache Commons. So far, none of the other PMC members has expressed
> his
> >>> or
> >>>> her thoughts about this. If nobody brings up objections about moving
> the
> >>>> component to Apache Commons, I'm assuming lazy consensus about this.
> >>>>
> >>>> So the next steps would be:
> >>>> - decide on a name for the new component (my proposal was Apache
> Commons
> >>>> Crypto)
> >>>> - move code to an Apache repo (probably git?!)
> >>>> - request a Jira project
> >>>> - setup maven build
> >>>> - setup project website
> >>>> - work on an initial release under Apache Commons coordinates
> >>>>
> >>>> Anything missing?
> >>>>
> >>>> Regards,
> >>>> Benedikt
> >>>>
> >>>> --
> >>>> http://home.apache.org/~britter/
> >>>> http://twitter.com/BenediktRitter
> >>>> http://github.com/britter
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>>
> >>>
> >>
> >>
> >> --
> >> http://home.apache.org/~britter/
> >> http://twitter.com/BenediktRitter
> >> http://github.com/britter
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
http://home.apache.org/~britter/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: [crypto][chimera] Next steps

[Jochen Wiedmann]

On Tue, Feb 23, 2016 at 12:14 AM, Colin P. McCabe  wrote:

> Many CPUs come with built-in support for certain cryptographic and/or
> hash/checksum-related primitives.  For example, modern x86 CPUs have
> CRC32C implemented in hardware.  Currently, this must be accessed via
> inline assembly expressed in JNI.  It is worth it... at least in the
> case of checksumming, you often see 5x or 10x reductions in the amount
> of CPU used.  The gains for moving from pure Java to using the openSSL
> AES functions are similar.  Perhaps someday Java will gain native
> support for these features.  Until that point, though, JNI will be
> necessary to get reasonable performance on modern hardware.

Okay, I understand that you intend to give as good performance as possible.

However, keep in mind that "The thing works." is much more important
to users. And a dependency on JNI is a prime reason for failure to
work.

Therefore, I suggest that you provide at least fallback
implementations in pure Java, which are being used, if the JNI based
stuff is not available (for whatever reason).

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [crypto][chimera] Next steps

[Mark Thomas]

On 23/02/2016 09:12, sebb wrote:
> On 23 February 2016 at 07:34, Benedikt Ritter  wrote:
>> I'm confused. None of the other PMC members has expressed whether he or she
>> want's the see Chimera/crypto joining Apache Commons, yet we're already
>> discussing how JNI bindings should be handled.
>>
>> I'd like to see:
>> 1) a clear statement whether Chimera/crypto should become part of Apache
>> Commons. Do we need a vote for that?
> 
> Yes, of course.
> 
> However that decision clearly depends on at least some of the design
> aspects of the code.
> If it were written entirely in C or Fortran, it would not be a
> suitable candidate.
> 
>> 2) Discuss a plan on how to do that (I've described a possible plan [1])
>> 3) After that is clear: discuss design details regarding the component.
> 
> Some design details impact on the decision.
> 
> Indeed even for pure Java code the code quality has a bearing on
> whether Commons would/could want to take it.
> Would we want a large code base with no unit-tests, no build
> mechanism, and no comments?

It depends. I care less about the quality of the code than I do about
the community that comes with it / forms around it. A strong community
can fix code issues. Great code can't save a weak community.

How about creating a new sandbox component, let folks start work and see
how the community develops?

Mark


> 
>> Thanks! :-)
>> Benedikt
>>
>> [1] http://markmail.org/message/74j4el6bpfpt4evs
>>
>> 2016-02-23 3:03 GMT+01:00 Xu, Cheng A :
>>
>>> At this point, it has just Java interfaces only.
>>>
>>> -----Original Message-
>>> From: Colin P. McCabe [mailto:cmcc...@apache.org]
>>> Sent: Tuesday, February 23, 2016 1:29 AM
>>> To: Hadoop Common
>>> Cc: Commons Developers List
>>> Subject: Re: [crypto][chimera] Next steps
>>>
>>> I would highly recommend shading this library when it is used in
>>> Hadoop and/or Spark, to prevent version skew problems between Hadoop
>>> and Spark like we have had in the past.
>>>
>>> What is the strategy for handling JNI components?  I think at a
>>> minimum, we should include the version number in the native library
>>> name to avoid problems when deploying multiple versions of Chimera.
>>> This is something that has been problematic in Hadoop with
>>> libhadoop.so.
>>>
>>> Is this library going to have Scala interfaces as well as Java ones,
>>> or just Java?
>>>
>>> cheers,
>>> Colin
>>>
>>> On Sat, Feb 20, 2016 at 3:15 AM, Benedikt Ritter 
>>> wrote:
>>>> Hi,
>>>>
>>>> I'd like to discuss the next steps for moving the Chimera component to
>>>> Apache Commons. So far, none of the other PMC members has expressed his
>>> or
>>>> her thoughts about this. If nobody brings up objections about moving the
>>>> component to Apache Commons, I'm assuming lazy consensus about this.
>>>>
>>>> So the next steps would be:
>>>> - decide on a name for the new component (my proposal was Apache Commons
>>>> Crypto)
>>>> - move code to an Apache repo (probably git?!)
>>>> - request a Jira project
>>>> - setup maven build
>>>> - setup project website
>>>> - work on an initial release under Apache Commons coordinates
>>>>
>>>> Anything missing?
>>>>
>>>> Regards,
>>>> Benedikt
>>>>
>>>> --
>>>> http://home.apache.org/~britter/
>>>> http://twitter.com/BenediktRitter
>>>> http://github.com/britter
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>
>>
>> --
>> http://home.apache.org/~britter/
>> http://twitter.com/BenediktRitter
>> http://github.com/britter
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [crypto][chimera] Next steps

[sebb]

On 23 February 2016 at 07:34, Benedikt Ritter  wrote:
> I'm confused. None of the other PMC members has expressed whether he or she
> want's the see Chimera/crypto joining Apache Commons, yet we're already
> discussing how JNI bindings should be handled.
>
> I'd like to see:
> 1) a clear statement whether Chimera/crypto should become part of Apache
> Commons. Do we need a vote for that?

Yes, of course.

However that decision clearly depends on at least some of the design
aspects of the code.
If it were written entirely in C or Fortran, it would not be a
suitable candidate.

> 2) Discuss a plan on how to do that (I've described a possible plan [1])
> 3) After that is clear: discuss design details regarding the component.

Some design details impact on the decision.

Indeed even for pure Java code the code quality has a bearing on
whether Commons would/could want to take it.
Would we want a large code base with no unit-tests, no build
mechanism, and no comments?

> Thanks! :-)
> Benedikt
>
> [1] http://markmail.org/message/74j4el6bpfpt4evs
>
> 2016-02-23 3:03 GMT+01:00 Xu, Cheng A :
>
>> At this point, it has just Java interfaces only.
>>
>> -Original Message-
>> From: Colin P. McCabe [mailto:cmcc...@apache.org]
>> Sent: Tuesday, February 23, 2016 1:29 AM
>> To: Hadoop Common
>> Cc: Commons Developers List
>> Subject: Re: [crypto][chimera] Next steps
>>
>> I would highly recommend shading this library when it is used in
>> Hadoop and/or Spark, to prevent version skew problems between Hadoop
>> and Spark like we have had in the past.
>>
>> What is the strategy for handling JNI components?  I think at a
>> minimum, we should include the version number in the native library
>> name to avoid problems when deploying multiple versions of Chimera.
>> This is something that has been problematic in Hadoop with
>> libhadoop.so.
>>
>> Is this library going to have Scala interfaces as well as Java ones,
>> or just Java?
>>
>> cheers,
>> Colin
>>
>> On Sat, Feb 20, 2016 at 3:15 AM, Benedikt Ritter 
>> wrote:
>> > Hi,
>> >
>> > I'd like to discuss the next steps for moving the Chimera component to
>> > Apache Commons. So far, none of the other PMC members has expressed his
>> or
>> > her thoughts about this. If nobody brings up objections about moving the
>> > component to Apache Commons, I'm assuming lazy consensus about this.
>> >
>> > So the next steps would be:
>> > - decide on a name for the new component (my proposal was Apache Commons
>> > Crypto)
>> > - move code to an Apache repo (probably git?!)
>> > - request a Jira project
>> > - setup maven build
>> > - setup project website
>> > - work on an initial release under Apache Commons coordinates
>> >
>> > Anything missing?
>> >
>> > Regards,
>> > Benedikt
>> >
>> > --
>> > http://home.apache.org/~britter/
>> > http://twitter.com/BenediktRitter
>> > http://github.com/britter
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> --
> http://home.apache.org/~britter/
> http://twitter.com/BenediktRitter
> http://github.com/britter

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [crypto][chimera] Next steps

[Benedikt Ritter]

I'm confused. None of the other PMC members has expressed whether he or she
want's the see Chimera/crypto joining Apache Commons, yet we're already
discussing how JNI bindings should be handled.

I'd like to see:
1) a clear statement whether Chimera/crypto should become part of Apache
Commons. Do we need a vote for that?
2) Discuss a plan on how to do that (I've described a possible plan [1])
3) After that is clear: discuss design details regarding the component.

Thanks! :-)
Benedikt

[1] http://markmail.org/message/74j4el6bpfpt4evs

2016-02-23 3:03 GMT+01:00 Xu, Cheng A :

> At this point, it has just Java interfaces only.
>
> -Original Message-
> From: Colin P. McCabe [mailto:cmcc...@apache.org]
> Sent: Tuesday, February 23, 2016 1:29 AM
> To: Hadoop Common
> Cc: Commons Developers List
> Subject: Re: [crypto][chimera] Next steps
>
> I would highly recommend shading this library when it is used in
> Hadoop and/or Spark, to prevent version skew problems between Hadoop
> and Spark like we have had in the past.
>
> What is the strategy for handling JNI components?  I think at a
> minimum, we should include the version number in the native library
> name to avoid problems when deploying multiple versions of Chimera.
> This is something that has been problematic in Hadoop with
> libhadoop.so.
>
> Is this library going to have Scala interfaces as well as Java ones,
> or just Java?
>
> cheers,
> Colin
>
> On Sat, Feb 20, 2016 at 3:15 AM, Benedikt Ritter 
> wrote:
> > Hi,
> >
> > I'd like to discuss the next steps for moving the Chimera component to
> > Apache Commons. So far, none of the other PMC members has expressed his
> or
> > her thoughts about this. If nobody brings up objections about moving the
> > component to Apache Commons, I'm assuming lazy consensus about this.
> >
> > So the next steps would be:
> > - decide on a name for the new component (my proposal was Apache Commons
> > Crypto)
> > - move code to an Apache repo (probably git?!)
> > - request a Jira project
> > - setup maven build
> > - setup project website
> > - work on an initial release under Apache Commons coordinates
> >
> > Anything missing?
> >
> > Regards,
> > Benedikt
> >
> > --
> > http://home.apache.org/~britter/
> > http://twitter.com/BenediktRitter
> > http://github.com/britter
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
http://home.apache.org/~britter/
http://twitter.com/BenediktRitter
http://github.com/britter

RE: [crypto][chimera] Next steps

[Xu, Cheng A]

At this point, it has just Java interfaces only.

-Original Message-
From: Colin P. McCabe [mailto:cmcc...@apache.org] 
Sent: Tuesday, February 23, 2016 1:29 AM
To: Hadoop Common
Cc: Commons Developers List
Subject: Re: [crypto][chimera] Next steps

I would highly recommend shading this library when it is used in
Hadoop and/or Spark, to prevent version skew problems between Hadoop
and Spark like we have had in the past.

What is the strategy for handling JNI components?  I think at a
minimum, we should include the version number in the native library
name to avoid problems when deploying multiple versions of Chimera.
This is something that has been problematic in Hadoop with
libhadoop.so.

Is this library going to have Scala interfaces as well as Java ones,
or just Java?

cheers,
Colin

On Sat, Feb 20, 2016 at 3:15 AM, Benedikt Ritter  wrote:
> Hi,
>
> I'd like to discuss the next steps for moving the Chimera component to
> Apache Commons. So far, none of the other PMC members has expressed his or
> her thoughts about this. If nobody brings up objections about moving the
> component to Apache Commons, I'm assuming lazy consensus about this.
>
> So the next steps would be:
> - decide on a name for the new component (my proposal was Apache Commons
> Crypto)
> - move code to an Apache repo (probably git?!)
> - request a Jira project
> - setup maven build
> - setup project website
> - work on an initial release under Apache Commons coordinates
>
> Anything missing?
>
> Regards,
> Benedikt
>
> --
> http://home.apache.org/~britter/
> http://twitter.com/BenediktRitter
> http://github.com/britter

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [crypto][chimera] Next steps

[sebb]

On 22 February 2016 at 23:43, James Carman  wrote:
> Still not a fan. My vote stands

I'm inclined to agree with James here.

> On Mon, Feb 22, 2016 at 6:37 PM Gary Gregory  wrote:
>
>> We already have commons-daemon that has C bits.

Have you tried building it?

>>
>> Gary
>> On Feb 22, 2016 3:27 PM, "James Carman" 
>> wrote:
>>
>> > Not a big fan of introducing JNI-based library to Commons. I'm -0
>> >
>> > On Sat, Feb 20, 2016 at 6:15 AM Benedikt Ritter 
>> > wrote:
>> >
>> > > Hi,
>> > >
>> > > I'd like to discuss the next steps for moving the Chimera component to
>> > > Apache Commons. So far, none of the other PMC members has expressed his
>> > or
>> > > her thoughts about this. If nobody brings up objections about moving
>> the
>> > > component to Apache Commons, I'm assuming lazy consensus about this.
>> > >
>> > > So the next steps would be:
>> > > - decide on a name for the new component (my proposal was Apache
>> Commons
>> > > Crypto)
>> > > - move code to an Apache repo (probably git?!)
>> > > - request a Jira project
>> > > - setup maven build
>> > > - setup project website
>> > > - work on an initial release under Apache Commons coordinates
>> > >
>> > > Anything missing?
>> > >
>> > > Regards,
>> > > Benedikt
>> > >
>> > > --
>> > > http://home.apache.org/~britter/
>> > > http://twitter.com/BenediktRitter
>> > > http://github.com/britter
>> > >
>> >
>>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [crypto][chimera] Next steps

[James Carman]

Still not a fan. My vote stands
On Mon, Feb 22, 2016 at 6:37 PM Gary Gregory  wrote:

> We already have commons-daemon that has C bits.
>
> Gary
> On Feb 22, 2016 3:27 PM, "James Carman" 
> wrote:
>
> > Not a big fan of introducing JNI-based library to Commons. I'm -0
> >
> > On Sat, Feb 20, 2016 at 6:15 AM Benedikt Ritter 
> > wrote:
> >
> > > Hi,
> > >
> > > I'd like to discuss the next steps for moving the Chimera component to
> > > Apache Commons. So far, none of the other PMC members has expressed his
> > or
> > > her thoughts about this. If nobody brings up objections about moving
> the
> > > component to Apache Commons, I'm assuming lazy consensus about this.
> > >
> > > So the next steps would be:
> > > - decide on a name for the new component (my proposal was Apache
> Commons
> > > Crypto)
> > > - move code to an Apache repo (probably git?!)
> > > - request a Jira project
> > > - setup maven build
> > > - setup project website
> > > - work on an initial release under Apache Commons coordinates
> > >
> > > Anything missing?
> > >
> > > Regards,
> > > Benedikt
> > >
> > > --
> > > http://home.apache.org/~britter/
> > > http://twitter.com/BenediktRitter
> > > http://github.com/britter
> > >
> >
>

Re: [crypto][chimera] Next steps

[Gary Gregory]

We already have commons-daemon that has C bits.

Gary
On Feb 22, 2016 3:27 PM, "James Carman"  wrote:

> Not a big fan of introducing JNI-based library to Commons. I'm -0
>
> On Sat, Feb 20, 2016 at 6:15 AM Benedikt Ritter 
> wrote:
>
> > Hi,
> >
> > I'd like to discuss the next steps for moving the Chimera component to
> > Apache Commons. So far, none of the other PMC members has expressed his
> or
> > her thoughts about this. If nobody brings up objections about moving the
> > component to Apache Commons, I'm assuming lazy consensus about this.
> >
> > So the next steps would be:
> > - decide on a name for the new component (my proposal was Apache Commons
> > Crypto)
> > - move code to an Apache repo (probably git?!)
> > - request a Jira project
> > - setup maven build
> > - setup project website
> > - work on an initial release under Apache Commons coordinates
> >
> > Anything missing?
> >
> > Regards,
> > Benedikt
> >
> > --
> > http://home.apache.org/~britter/
> > http://twitter.com/BenediktRitter
> > http://github.com/britter
> >
>

Re: [crypto][chimera] Next steps

[James Carman]

Not a big fan of introducing JNI-based library to Commons. I'm -0

On Sat, Feb 20, 2016 at 6:15 AM Benedikt Ritter  wrote:

> Hi,
>
> I'd like to discuss the next steps for moving the Chimera component to
> Apache Commons. So far, none of the other PMC members has expressed his or
> her thoughts about this. If nobody brings up objections about moving the
> component to Apache Commons, I'm assuming lazy consensus about this.
>
> So the next steps would be:
> - decide on a name for the new component (my proposal was Apache Commons
> Crypto)
> - move code to an Apache repo (probably git?!)
> - request a Jira project
> - setup maven build
> - setup project website
> - work on an initial release under Apache Commons coordinates
>
> Anything missing?
>
> Regards,
> Benedikt
>
> --
> http://home.apache.org/~britter/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>

Re: [crypto][chimera] Next steps

[Gary Gregory]

Checksum via JNI should be done in the commons-codec project.

Gary
On Feb 22, 2016 3:14 PM, "Colin P. McCabe"  wrote:

> Hi Jochen,
>
> Many CPUs come with built-in support for certain cryptographic and/or
> hash/checksum-related primitives.  For example, modern x86 CPUs have
> CRC32C implemented in hardware.  Currently, this must be accessed via
> inline assembly expressed in JNI.  It is worth it... at least in the
> case of checksumming, you often see 5x or 10x reductions in the amount
> of CPU used.  The gains for moving from pure Java to using the openSSL
> AES functions are similar.  Perhaps someday Java will gain native
> support for these features.  Until that point, though, JNI will be
> necessary to get reasonable performance on modern hardware.
>
> best,
> Colin
>
> On Mon, Feb 22, 2016 at 10:02 AM, Jochen Wiedmann
>  wrote:
> > On Mon, Feb 22, 2016 at 6:28 PM, Colin P. McCabe 
> wrote:
> >
> >> What is the strategy for handling JNI components?
> >
> > Wrong question, IMO. Should better be: What are the reasons for using
> > JNI components? Couldn't they be replaced? If so, that would very much
> > enhance the long term prospects of crypto|chimera|whatever.
> >
> > Jochen
> >
> > --
> > The next time you hear: "Don't reinvent the wheel!"
> >
> >
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [crypto][chimera] Next steps

[Colin P. McCabe]

Hi Jochen,

Many CPUs come with built-in support for certain cryptographic and/or
hash/checksum-related primitives.  For example, modern x86 CPUs have
CRC32C implemented in hardware.  Currently, this must be accessed via
inline assembly expressed in JNI.  It is worth it... at least in the
case of checksumming, you often see 5x or 10x reductions in the amount
of CPU used.  The gains for moving from pure Java to using the openSSL
AES functions are similar.  Perhaps someday Java will gain native
support for these features.  Until that point, though, JNI will be
necessary to get reasonable performance on modern hardware.

best,
Colin

On Mon, Feb 22, 2016 at 10:02 AM, Jochen Wiedmann
 wrote:
> On Mon, Feb 22, 2016 at 6:28 PM, Colin P. McCabe  wrote:
>
>> What is the strategy for handling JNI components?
>
> Wrong question, IMO. Should better be: What are the reasons for using
> JNI components? Couldn't they be replaced? If so, that would very much
> enhance the long term prospects of crypto|chimera|whatever.
>
> Jochen
>
> --
> The next time you hear: "Don't reinvent the wheel!"
>
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [crypto][chimera] Next steps

[Gary Gregory]

On Mon, Feb 22, 2016 at 1:26 PM, Gangumalla, Uma 
wrote:

>
> >All files should follow the Commons Maven naming scheme to make it easy to
> >reach from Maven, Ivy and so on.
> >This will be commons-crypto-1.0.jar for example.
> Sure. Thanks Gary. We will follow the naming convention here from Commons.
>

For jar files, this will happen automatically if you follow the Commons
Maven conventions. For .dll and .so files, you/we'll have to adjust the
make files, unless there is a smarter way.

Gary


> Regards,
> Uma
>
> On 2/22/16, 1:20 PM, "Gary Gregory"  wrote:
>
> >All files should follow the Commons Maven naming scheme to make it easy to
> >reach from Maven, Ivy and so on.
> >
> >This will be commons-crypto-1.0.jar for example.
> >
> >Gary
> >
> >On Mon, Feb 22, 2016 at 1:06 PM, Gangumalla, Uma
> >
> >wrote:
> >
> >> >I would highly recommend shading this library when it is used in
> >> Hadoop and/or Spark, to prevent version skew problems between Hadoop
> >> and Spark like we have had in the past.
> >> [uma]Ha. This avoids multiple jars versions issues. Agreed IMO.
> >>
> >> >I think at a
> >> minimum, we should include the version number in the native library
> >> name to avoid problems when deploying multiple versions of Chimera.
> >> This is something that has been problematic in Hadoop with
> >> libhadoop.so.
> >> [uma]I think this is very valid suggestion. We can maintain version
> >>number
> >> with native lib. Also here target is to bundle libchimera.so along with
> >> jars. Ideally it should be less confusion, but its good idea to have
> >> version number along.
> >>
> >> >Is this library going to have Scala interfaces as well as Java ones,
> >> or just Java?
> >> [uma] Currently it is focussing on java. If there is a demand for Scala
> >> specifically may be we can think on that.
> >>
> >> Regards,
> >> Uma
> >>
> >> On 2/22/16, 9:28 AM, "Colin P. McCabe"  wrote:
> >>
> >> >I would highly recommend shading this library when it is used in
> >> >Hadoop and/or Spark, to prevent version skew problems between Hadoop
> >> >and Spark like we have had in the past.
> >> >
> >> >What is the strategy for handling JNI components?  I think at a
> >> >minimum, we should include the version number in the native library
> >> >name to avoid problems when deploying multiple versions of Chimera.
> >> >This is something that has been problematic in Hadoop with
> >> >libhadoop.so.
> >> >
> >> >Is this library going to have Scala interfaces as well as Java ones,
> >> >or just Java?
> >> >
> >> >cheers,
> >> >Colin
> >> >
> >> >On Sat, Feb 20, 2016 at 3:15 AM, Benedikt Ritter 
> >> >wrote:
> >> >> Hi,
> >> >>
> >> >> I'd like to discuss the next steps for moving the Chimera component
> >>to
> >> >> Apache Commons. So far, none of the other PMC members has expressed
> >>his
> >> >>or
> >> >> her thoughts about this. If nobody brings up objections about moving
> >>the
> >> >> component to Apache Commons, I'm assuming lazy consensus about this.
> >> >>
> >> >> So the next steps would be:
> >> >> - decide on a name for the new component (my proposal was Apache
> >>Commons
> >> >> Crypto)
> >> >> - move code to an Apache repo (probably git?!)
> >> >> - request a Jira project
> >> >> - setup maven build
> >> >> - setup project website
> >> >> - work on an initial release under Apache Commons coordinates
> >> >>
> >> >> Anything missing?
> >> >>
> >> >> Regards,
> >> >> Benedikt
> >> >>
> >> >> --
> >> >> http://home.apache.org/~britter/
> >> >> http://twitter.com/BenediktRitter
> >> >> http://github.com/britter
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>
> >
> >
> >--
> >E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> >Java Persistence with Hibernate, Second Edition
> >
> >JUnit in Action, Second Edition 
> >Spring Batch in Action 
> >Blog: http://garygregory.wordpress.com
> >Home: http://garygregory.com/
> >Tweet! http://twitter.com/GaryGregory
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [crypto][chimera] Next steps

[Gangumalla, Uma]

>All files should follow the Commons Maven naming scheme to make it easy to
>reach from Maven, Ivy and so on.
>This will be commons-crypto-1.0.jar for example.
Sure. Thanks Gary. We will follow the naming convention here from Commons.

Regards,
Uma

On 2/22/16, 1:20 PM, "Gary Gregory"  wrote:

>All files should follow the Commons Maven naming scheme to make it easy to
>reach from Maven, Ivy and so on.
>
>This will be commons-crypto-1.0.jar for example.
>
>Gary
>
>On Mon, Feb 22, 2016 at 1:06 PM, Gangumalla, Uma
>
>wrote:
>
>> >I would highly recommend shading this library when it is used in
>> Hadoop and/or Spark, to prevent version skew problems between Hadoop
>> and Spark like we have had in the past.
>> [uma]Ha. This avoids multiple jars versions issues. Agreed IMO.
>>
>> >I think at a
>> minimum, we should include the version number in the native library
>> name to avoid problems when deploying multiple versions of Chimera.
>> This is something that has been problematic in Hadoop with
>> libhadoop.so.
>> [uma]I think this is very valid suggestion. We can maintain version
>>number
>> with native lib. Also here target is to bundle libchimera.so along with
>> jars. Ideally it should be less confusion, but its good idea to have
>> version number along.
>>
>> >Is this library going to have Scala interfaces as well as Java ones,
>> or just Java?
>> [uma] Currently it is focussing on java. If there is a demand for Scala
>> specifically may be we can think on that.
>>
>> Regards,
>> Uma
>>
>> On 2/22/16, 9:28 AM, "Colin P. McCabe"  wrote:
>>
>> >I would highly recommend shading this library when it is used in
>> >Hadoop and/or Spark, to prevent version skew problems between Hadoop
>> >and Spark like we have had in the past.
>> >
>> >What is the strategy for handling JNI components?  I think at a
>> >minimum, we should include the version number in the native library
>> >name to avoid problems when deploying multiple versions of Chimera.
>> >This is something that has been problematic in Hadoop with
>> >libhadoop.so.
>> >
>> >Is this library going to have Scala interfaces as well as Java ones,
>> >or just Java?
>> >
>> >cheers,
>> >Colin
>> >
>> >On Sat, Feb 20, 2016 at 3:15 AM, Benedikt Ritter 
>> >wrote:
>> >> Hi,
>> >>
>> >> I'd like to discuss the next steps for moving the Chimera component
>>to
>> >> Apache Commons. So far, none of the other PMC members has expressed
>>his
>> >>or
>> >> her thoughts about this. If nobody brings up objections about moving
>>the
>> >> component to Apache Commons, I'm assuming lazy consensus about this.
>> >>
>> >> So the next steps would be:
>> >> - decide on a name for the new component (my proposal was Apache
>>Commons
>> >> Crypto)
>> >> - move code to an Apache repo (probably git?!)
>> >> - request a Jira project
>> >> - setup maven build
>> >> - setup project website
>> >> - work on an initial release under Apache Commons coordinates
>> >>
>> >> Anything missing?
>> >>
>> >> Regards,
>> >> Benedikt
>> >>
>> >> --
>> >> http://home.apache.org/~britter/
>> >> http://twitter.com/BenediktRitter
>> >> http://github.com/britter
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
>-- 
>E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>Java Persistence with Hibernate, Second Edition
>
>JUnit in Action, Second Edition 
>Spring Batch in Action 
>Blog: http://garygregory.wordpress.com
>Home: http://garygregory.com/
>Tweet! http://twitter.com/GaryGregory


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [crypto][chimera] Next steps

[Gary Gregory]

All files should follow the Commons Maven naming scheme to make it easy to
reach from Maven, Ivy and so on.

This will be commons-crypto-1.0.jar for example.

Gary

On Mon, Feb 22, 2016 at 1:06 PM, Gangumalla, Uma 
wrote:

> >I would highly recommend shading this library when it is used in
> Hadoop and/or Spark, to prevent version skew problems between Hadoop
> and Spark like we have had in the past.
> [uma]Ha. This avoids multiple jars versions issues. Agreed IMO.
>
> >I think at a
> minimum, we should include the version number in the native library
> name to avoid problems when deploying multiple versions of Chimera.
> This is something that has been problematic in Hadoop with
> libhadoop.so.
> [uma]I think this is very valid suggestion. We can maintain version number
> with native lib. Also here target is to bundle libchimera.so along with
> jars. Ideally it should be less confusion, but its good idea to have
> version number along.
>
> >Is this library going to have Scala interfaces as well as Java ones,
> or just Java?
> [uma] Currently it is focussing on java. If there is a demand for Scala
> specifically may be we can think on that.
>
> Regards,
> Uma
>
> On 2/22/16, 9:28 AM, "Colin P. McCabe"  wrote:
>
> >I would highly recommend shading this library when it is used in
> >Hadoop and/or Spark, to prevent version skew problems between Hadoop
> >and Spark like we have had in the past.
> >
> >What is the strategy for handling JNI components?  I think at a
> >minimum, we should include the version number in the native library
> >name to avoid problems when deploying multiple versions of Chimera.
> >This is something that has been problematic in Hadoop with
> >libhadoop.so.
> >
> >Is this library going to have Scala interfaces as well as Java ones,
> >or just Java?
> >
> >cheers,
> >Colin
> >
> >On Sat, Feb 20, 2016 at 3:15 AM, Benedikt Ritter 
> >wrote:
> >> Hi,
> >>
> >> I'd like to discuss the next steps for moving the Chimera component to
> >> Apache Commons. So far, none of the other PMC members has expressed his
> >>or
> >> her thoughts about this. If nobody brings up objections about moving the
> >> component to Apache Commons, I'm assuming lazy consensus about this.
> >>
> >> So the next steps would be:
> >> - decide on a name for the new component (my proposal was Apache Commons
> >> Crypto)
> >> - move code to an Apache repo (probably git?!)
> >> - request a Jira project
> >> - setup maven build
> >> - setup project website
> >> - work on an initial release under Apache Commons coordinates
> >>
> >> Anything missing?
> >>
> >> Regards,
> >> Benedikt
> >>
> >> --
> >> http://home.apache.org/~britter/
> >> http://twitter.com/BenediktRitter
> >> http://github.com/britter
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [crypto][chimera] Next steps

[Gangumalla, Uma]

>I would highly recommend shading this library when it is used in
Hadoop and/or Spark, to prevent version skew problems between Hadoop
and Spark like we have had in the past.
[uma]Ha. This avoids multiple jars versions issues. Agreed IMO.

>I think at a
minimum, we should include the version number in the native library
name to avoid problems when deploying multiple versions of Chimera.
This is something that has been problematic in Hadoop with
libhadoop.so.
[uma]I think this is very valid suggestion. We can maintain version number
with native lib. Also here target is to bundle libchimera.so along with
jars. Ideally it should be less confusion, but its good idea to have
version number along.

>Is this library going to have Scala interfaces as well as Java ones,
or just Java?
[uma] Currently it is focussing on java. If there is a demand for Scala
specifically may be we can think on that.

Regards,
Uma

On 2/22/16, 9:28 AM, "Colin P. McCabe"  wrote:

>I would highly recommend shading this library when it is used in
>Hadoop and/or Spark, to prevent version skew problems between Hadoop
>and Spark like we have had in the past.
>
>What is the strategy for handling JNI components?  I think at a
>minimum, we should include the version number in the native library
>name to avoid problems when deploying multiple versions of Chimera.
>This is something that has been problematic in Hadoop with
>libhadoop.so.
>
>Is this library going to have Scala interfaces as well as Java ones,
>or just Java?
>
>cheers,
>Colin
>
>On Sat, Feb 20, 2016 at 3:15 AM, Benedikt Ritter 
>wrote:
>> Hi,
>>
>> I'd like to discuss the next steps for moving the Chimera component to
>> Apache Commons. So far, none of the other PMC members has expressed his
>>or
>> her thoughts about this. If nobody brings up objections about moving the
>> component to Apache Commons, I'm assuming lazy consensus about this.
>>
>> So the next steps would be:
>> - decide on a name for the new component (my proposal was Apache Commons
>> Crypto)
>> - move code to an Apache repo (probably git?!)
>> - request a Jira project
>> - setup maven build
>> - setup project website
>> - work on an initial release under Apache Commons coordinates
>>
>> Anything missing?
>>
>> Regards,
>> Benedikt
>>
>> --
>> http://home.apache.org/~britter/
>> http://twitter.com/BenediktRitter
>> http://github.com/britter


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [crypto][chimera] Next steps

[Jochen Wiedmann]

On Mon, Feb 22, 2016 at 6:28 PM, Colin P. McCabe  wrote:

> What is the strategy for handling JNI components?

Wrong question, IMO. Should better be: What are the reasons for using
JNI components? Couldn't they be replaced? If so, that would very much
enhance the long term prospects of crypto|chimera|whatever.

Jochen

-- 
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [crypto][chimera] Next steps

[Colin P. McCabe]

I would highly recommend shading this library when it is used in
Hadoop and/or Spark, to prevent version skew problems between Hadoop
and Spark like we have had in the past.

What is the strategy for handling JNI components?  I think at a
minimum, we should include the version number in the native library
name to avoid problems when deploying multiple versions of Chimera.
This is something that has been problematic in Hadoop with
libhadoop.so.

Is this library going to have Scala interfaces as well as Java ones,
or just Java?

cheers,
Colin

On Sat, Feb 20, 2016 at 3:15 AM, Benedikt Ritter  wrote:
> Hi,
>
> I'd like to discuss the next steps for moving the Chimera component to
> Apache Commons. So far, none of the other PMC members has expressed his or
> her thoughts about this. If nobody brings up objections about moving the
> component to Apache Commons, I'm assuming lazy consensus about this.
>
> So the next steps would be:
> - decide on a name for the new component (my proposal was Apache Commons
> Crypto)
> - move code to an Apache repo (probably git?!)
> - request a Jira project
> - setup maven build
> - setup project website
> - work on an initial release under Apache Commons coordinates
>
> Anything missing?
>
> Regards,
> Benedikt
>
> --
> http://home.apache.org/~britter/
> http://twitter.com/BenediktRitter
> http://github.com/britter

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [crypto][chimera] Next steps

[Nick Burch]

On Sun, 21 Feb 2016, Gary Gregory wrote:

Curious: How to you get to OpenSSL, JNI? JNA?


I know that Tomcat has done quite a bit of work around pulling in OpenSSL 
in order to do SNI and ALPN. Mark Thomas gave a good talk on it at 
ApacheCon last year, slides are at:

http://events.linuxfoundation.org/sites/events/files/slides/2015-09-24-HTTP2%20and%20Java.pdf

No idea if that approach would be of use for this, but though I'd flag it 
up in case people didn't know about the work Tomcat have been doing in the 
same sort of area!


Nick


On Sun, Feb 21, 2016 at 10:51 PM, Chen, Haifeng 
wrote:


Thanks Gary.


Would Commons Crypto focus only on AES? If so, Commons Crypto AES or

Commons AES would be a better name.
Currently, this module supports only AES modes. To help folks with
information for making decision, a little further clarification from me may
help.

The project doesn't implement directly the cryptographic algorithms. It
provides:
1.  It provides a thin layer of Cipher to abstract the under-layer Cipher
implementations. (currently support JCE Cipher or OpenSSL Cipher
implementations). This is for optimization purposes, for example OpenSSL
Cipher implementation provides 17+x performance for AES/CTR comparing with
JDK 6 and 5x comparing JDK 7/8.
2.  It provides a layer of stream and channel implementations abstracting
Input source and Output target utilizing the Cipher layer. The layer can be
used easily by applications that needs to encrypt/decrypt data streams or
channels.
3.  Additionally, it provides a secure random utility classes to help
generate TRUE random numbers for key generation.

While there is no technical barrier for it to support other algorithms
such as RC4 through JCE or OpenSSL. Just depends how widely this is
required.

Thanks,
Haifeng

-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com]
Sent: Monday, February 22, 2016 11:36 AM
To: Commons Developers List 
Subject: Re: [crypto][chimera] Next steps

Would Commons Crypto focus only on AES? If so, Commons Crypto AES or
Commons AES would be a better name.

Gary

On Sun, Feb 21, 2016 at 6:28 PM, Chen, Haifeng 
wrote:


Thanks Benedikt, Uma, Gary, Ole, and Emmanuel Bourg for your support!
It's great to have Chimera to be part of Apache Commons.


[ Emmanuel Bourg] Define the scope of the project? Do we go after
Bouncy

Castle and aim for an equivalent feature set?
Agree to make a clear scope of the project. The original Chimera scope
is not go after a Bouncy Castle style of library. It targets the gap
between the application and the under cipher implementations. For
example, applications uses a lot of InputStream/OutputStream or
Channel concepts to read / write a stream of data. Application can
share these Crypto streams/channel implementations abstracting various

input and output types.

Chimera also targets to very important performance optimizations on
AES which is used worldwide. I suggest this module to be still
lightweight and clear in involving, which is the same ideology of Apache

Commons.



[Uma] Here I would like to introduce Haifeng, who lead the efforts
in

Chimera github project.
Thanks Uma for introduction.


[Uma] Me and Haifeng had some discussion yesterday for the list to
get

commit prevs. May be he could probably get list. Then I think Commons
PMC can make a decision on it.
Chimera has 5 long standing contributors on github. We can also invite
those who contributed the HDFS encryption feature (HDFS-6134 and
HADOOP-10150) to continue participate the involution of this project
if they want.

Thanks,
Haifeng

-Original Message-
From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com]
Sent: Sunday, February 21, 2016 3:07 AM
To: Commons Developers List 
Subject: Re: [crypto][chimera] Next steps

Hi Benedikt,

 Thank you for the Next steps discussion. I thought of pinging you on
this
:-)

 Here I would like to introduce Haifeng, who lead the efforts in
Chimera github project.

I think Apache Commons Crypto looks good and self descriptive IMO.
 I am +1

Me and Haifeng had some discussion yesterday for the list to get
commit prevs. May be he could probably get list. Then I think Commons
PMC can make a decision on it.



move code to an Apache repo (probably git?!)

+1 for git


- setup maven build

If this point is just about maven build alone, then we should set up
Jenkins CI build boat as well right, may be we can add this point?

Regards,
Uma

On 2/20/16, 8:29 AM, "Gary Gregory"  wrote:


Who are the committers comming along for this component?

Do we have enough of them?

I like Apache Commons Crypto.

Gary
On Feb 20, 2016 3:15 AM, "Benedikt Ritter"  wrote:


Hi,

I'd like to discuss the next steps for moving the Chimera component
to  Apache Commons. So far, none of the other PMC members has
expressed his or  her thoughts about this. If nobody brings up
objections about moving the  component to Apache Commons, I'm
assuming lazy

RE: [crypto][chimera] Next steps

[Xu, Cheng A]

Hi Gary,
We use JNI to get to Openssl.

Ferd

-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com] 
Sent: Monday, February 22, 2016 2:57 PM
To: Commons Developers List
Subject: Re: [crypto][chimera] Next steps

Curious: How to you get to OpenSSL, JNI? JNA?

Gary

On Sun, Feb 21, 2016 at 10:51 PM, Chen, Haifeng 
wrote:

> Thanks Gary.
>
> >> Would Commons Crypto focus only on AES? If so, Commons Crypto AES or
> Commons AES would be a better name.
> Currently, this module supports only AES modes. To help folks with
> information for making decision, a little further clarification from me may
> help.
>
> The project doesn't implement directly the cryptographic algorithms. It
> provides:
> 1.  It provides a thin layer of Cipher to abstract the under-layer Cipher
> implementations. (currently support JCE Cipher or OpenSSL Cipher
> implementations). This is for optimization purposes, for example OpenSSL
> Cipher implementation provides 17+x performance for AES/CTR comparing with
> JDK 6 and 5x comparing JDK 7/8.
> 2.  It provides a layer of stream and channel implementations abstracting
> Input source and Output target utilizing the Cipher layer. The layer can be
> used easily by applications that needs to encrypt/decrypt data streams or
> channels.
> 3.  Additionally, it provides a secure random utility classes to help
> generate TRUE random numbers for key generation.
>
> While there is no technical barrier for it to support other algorithms
> such as RC4 through JCE or OpenSSL. Just depends how widely this is
> required.
>
> Thanks,
> Haifeng
>
> -Original Message-
> From: Gary Gregory [mailto:garydgreg...@gmail.com]
> Sent: Monday, February 22, 2016 11:36 AM
> To: Commons Developers List 
> Subject: Re: [crypto][chimera] Next steps
>
> Would Commons Crypto focus only on AES? If so, Commons Crypto AES or
> Commons AES would be a better name.
>
> Gary
>
> On Sun, Feb 21, 2016 at 6:28 PM, Chen, Haifeng 
> wrote:
>
> > Thanks Benedikt, Uma, Gary, Ole, and Emmanuel Bourg for your support!
> > It's great to have Chimera to be part of Apache Commons.
> >
> > >>[ Emmanuel Bourg] Define the scope of the project? Do we go after
> > >>Bouncy
> > Castle and aim for an equivalent feature set?
> > Agree to make a clear scope of the project. The original Chimera scope
> > is not go after a Bouncy Castle style of library. It targets the gap
> > between the application and the under cipher implementations. For
> > example, applications uses a lot of InputStream/OutputStream or
> > Channel concepts to read / write a stream of data. Application can
> > share these Crypto streams/channel implementations abstracting various
> input and output types.
> > Chimera also targets to very important performance optimizations on
> > AES which is used worldwide. I suggest this module to be still
> > lightweight and clear in involving, which is the same ideology of Apache
> Commons.
> >
> > >> [Uma] Here I would like to introduce Haifeng, who lead the efforts
> > >> in
> > Chimera github project.
> > Thanks Uma for introduction.
> >
> > >> [Uma] Me and Haifeng had some discussion yesterday for the list to
> > >> get
> > commit prevs. May be he could probably get list. Then I think Commons
> > PMC can make a decision on it.
> > Chimera has 5 long standing contributors on github. We can also invite
> > those who contributed the HDFS encryption feature (HDFS-6134 and
> > HADOOP-10150) to continue participate the involution of this project
> > if they want.
> >
> > Thanks,
> > Haifeng
> >
> > -Original Message-
> > From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com]
> > Sent: Sunday, February 21, 2016 3:07 AM
> > To: Commons Developers List 
> > Subject: Re: [crypto][chimera] Next steps
> >
> > Hi Benedikt,
> >
> >  Thank you for the Next steps discussion. I thought of pinging you on
> > this
> > :-)
> >
> >  Here I would like to introduce Haifeng, who lead the efforts in
> > Chimera github project.
> >
> > I think Apache Commons Crypto looks good and self descriptive IMO.
> >  I am +1
> >
> > Me and Haifeng had some discussion yesterday for the list to get
> > commit prevs. May be he could probably get list. Then I think Commons
> > PMC can make a decision on it.
> >
> >
> > >move code to an Apache repo (probably git?!)
> > +1 for git
> >
> > >- setup maven build
> > If this point is just about maven build alone, then we should set up
> >

Re: [crypto][chimera] Next steps

[Gary Gregory]

On Feb 21, 2016 11:59 PM, "Benedikt Ritter"  wrote:
>
> Hi again,
>
> 2016-02-20 12:15 GMT+01:00 Benedikt Ritter :
>
> > Hi,
> >
> > I'd like to discuss the next steps for moving the Chimera component to
> > Apache Commons. So far, none of the other PMC members has expressed his
or
> > her thoughts about this. If nobody brings up objections about moving the
> > component to Apache Commons, I'm assuming lazy consensus about this.
> >
> > So the next steps would be:
> > - decide on a name for the new component (my proposal was Apache Commons
> > Crypto)
> > - move code to an Apache repo (probably git?!)
> > - request a Jira project
> > - setup maven build
> > - setup project website
> > - work on an initial release under Apache Commons coordinates
> >
> > Anything missing?
> >
>
> Given the recent discussion, I'd like to update to above list:
>
> - Define the scope of the new Component (in our wiki? in the repo on
> github?)
> - Define the group of initial committers
> - Decide on a name
> - Think about IP clearance - The code seems to belong to Intel. What do we
> have to do to move the code the the ASF? Go through the Incubator?
> - Move code to Apache Commons
> - request Jira project
> - setup maven build
> - setup project website
> - work on an initial release
>
> Thoughts?

Set up CI build.

Gary

> Benedikt
>
>
> >
> > Regards,
> > Benedikt
> >
> > --
> > http://home.apache.org/~britter/
> > http://twitter.com/BenediktRitter
> > http://github.com/britter
> >
>
>
>
> --
> http://home.apache.org/~britter/
> http://twitter.com/BenediktRitter
> http://github.com/britter

Re: [crypto][chimera] Next steps

[Benedikt Ritter]

Hi again,

2016-02-20 12:15 GMT+01:00 Benedikt Ritter :

> Hi,
>
> I'd like to discuss the next steps for moving the Chimera component to
> Apache Commons. So far, none of the other PMC members has expressed his or
> her thoughts about this. If nobody brings up objections about moving the
> component to Apache Commons, I'm assuming lazy consensus about this.
>
> So the next steps would be:
> - decide on a name for the new component (my proposal was Apache Commons
> Crypto)
> - move code to an Apache repo (probably git?!)
> - request a Jira project
> - setup maven build
> - setup project website
> - work on an initial release under Apache Commons coordinates
>
> Anything missing?
>

Given the recent discussion, I'd like to update to above list:

- Define the scope of the new Component (in our wiki? in the repo on
github?)
- Define the group of initial committers
- Decide on a name
- Think about IP clearance - The code seems to belong to Intel. What do we
have to do to move the code the the ASF? Go through the Incubator?
- Move code to Apache Commons
- request Jira project
- setup maven build
- setup project website
- work on an initial release

Thoughts?
Benedikt


>
> Regards,
> Benedikt
>
> --
> http://home.apache.org/~britter/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>



-- 
http://home.apache.org/~britter/
http://twitter.com/BenediktRitter
http://github.com/britter

RE: [crypto][chimera] Next steps

[Chen, Haifeng]

Given the current scope and if we don't see significant value adding other 
algorithms, Commons Crypto AES or Commons AES does be a better descriptive name.

Thanks,
Haifeng

-Original Message-
From: Chen, Haifeng 
Sent: Monday, February 22, 2016 2:52 PM
To: Commons Developers List 
Subject: RE: [crypto][chimera] Next steps

Thanks Gary.

>> Would Commons Crypto focus only on AES? If so, Commons Crypto AES or Commons 
>> AES would be a better name.
Currently, this module supports only AES modes. To help folks with information 
for making decision, a little further clarification from me may help. 

The project doesn't implement directly the cryptographic algorithms. It 
provides:
1.  It provides a thin layer of Cipher to abstract the under-layer Cipher 
implementations. (currently support JCE Cipher or OpenSSL Cipher 
implementations). This is for optimization purposes, for example OpenSSL Cipher 
implementation provides 17+x performance for AES/CTR comparing with JDK 6 and 
5x comparing JDK 7/8.
2.  It provides a layer of stream and channel implementations abstracting Input 
source and Output target utilizing the Cipher layer. The layer can be used 
easily by applications that needs to encrypt/decrypt data streams or channels.
3.  Additionally, it provides a secure random utility classes to help generate 
TRUE random numbers for key generation. 

While there is no technical barrier for it to support other algorithms such as 
RC4 through JCE or OpenSSL. Just depends how widely this is required.

Thanks,
Haifeng

-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com]
Sent: Monday, February 22, 2016 11:36 AM
To: Commons Developers List 
Subject: Re: [crypto][chimera] Next steps

Would Commons Crypto focus only on AES? If so, Commons Crypto AES or Commons 
AES would be a better name.

Gary

On Sun, Feb 21, 2016 at 6:28 PM, Chen, Haifeng 
wrote:

> Thanks Benedikt, Uma, Gary, Ole, and Emmanuel Bourg for your support! 
> It's great to have Chimera to be part of Apache Commons.
>
> >>[ Emmanuel Bourg] Define the scope of the project? Do we go after 
> >>Bouncy
> Castle and aim for an equivalent feature set?
> Agree to make a clear scope of the project. The original Chimera scope 
> is not go after a Bouncy Castle style of library. It targets the gap 
> between the application and the under cipher implementations. For 
> example, applications uses a lot of InputStream/OutputStream or 
> Channel concepts to read / write a stream of data. Application can 
> share these Crypto streams/channel implementations abstracting various input 
> and output types.
> Chimera also targets to very important performance optimizations on 
> AES which is used worldwide. I suggest this module to be still 
> lightweight and clear in involving, which is the same ideology of Apache 
> Commons.
>
> >> [Uma] Here I would like to introduce Haifeng, who lead the efforts 
> >> in
> Chimera github project.
> Thanks Uma for introduction.
>
> >> [Uma] Me and Haifeng had some discussion yesterday for the list to 
> >> get
> commit prevs. May be he could probably get list. Then I think Commons 
> PMC can make a decision on it.
> Chimera has 5 long standing contributors on github. We can also invite 
> those who contributed the HDFS encryption feature (HDFS-6134 and
> HADOOP-10150) to continue participate the involution of this project 
> if they want.
>
> Thanks,
> Haifeng
>
> -----Original Message-----
> From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com]
> Sent: Sunday, February 21, 2016 3:07 AM
> To: Commons Developers List 
> Subject: Re: [crypto][chimera] Next steps
>
> Hi Benedikt,
>
>  Thank you for the Next steps discussion. I thought of pinging you on 
> this
> :-)
>
>  Here I would like to introduce Haifeng, who lead the efforts in 
> Chimera github project.
>
> I think Apache Commons Crypto looks good and self descriptive IMO.
>  I am +1
>
> Me and Haifeng had some discussion yesterday for the list to get 
> commit prevs. May be he could probably get list. Then I think Commons 
> PMC can make a decision on it.
>
>
> >move code to an Apache repo (probably git?!)
> +1 for git
>
> >- setup maven build
> If this point is just about maven build alone, then we should set up 
> Jenkins CI build boat as well right, may be we can add this point?
>
> Regards,
> Uma
>
> On 2/20/16, 8:29 AM, "Gary Gregory"  wrote:
>
> >Who are the committers comming along for this component?
> >
> >Do we have enough of them?
> >
> >I like Apache Commons Crypto.
> >
> >Gary
> >On Feb 20, 2016 3:15 AM, "Benedikt Ritter"  wrote:
> >
> >> Hi,
> >>
> >> I&#x

Re: [crypto][chimera] Next steps

[Gary Gregory]

Curious: How to you get to OpenSSL, JNI? JNA?

Gary

On Sun, Feb 21, 2016 at 10:51 PM, Chen, Haifeng 
wrote:

> Thanks Gary.
>
> >> Would Commons Crypto focus only on AES? If so, Commons Crypto AES or
> Commons AES would be a better name.
> Currently, this module supports only AES modes. To help folks with
> information for making decision, a little further clarification from me may
> help.
>
> The project doesn't implement directly the cryptographic algorithms. It
> provides:
> 1.  It provides a thin layer of Cipher to abstract the under-layer Cipher
> implementations. (currently support JCE Cipher or OpenSSL Cipher
> implementations). This is for optimization purposes, for example OpenSSL
> Cipher implementation provides 17+x performance for AES/CTR comparing with
> JDK 6 and 5x comparing JDK 7/8.
> 2.  It provides a layer of stream and channel implementations abstracting
> Input source and Output target utilizing the Cipher layer. The layer can be
> used easily by applications that needs to encrypt/decrypt data streams or
> channels.
> 3.  Additionally, it provides a secure random utility classes to help
> generate TRUE random numbers for key generation.
>
> While there is no technical barrier for it to support other algorithms
> such as RC4 through JCE or OpenSSL. Just depends how widely this is
> required.
>
> Thanks,
> Haifeng
>
> -Original Message-
> From: Gary Gregory [mailto:garydgreg...@gmail.com]
> Sent: Monday, February 22, 2016 11:36 AM
> To: Commons Developers List 
> Subject: Re: [crypto][chimera] Next steps
>
> Would Commons Crypto focus only on AES? If so, Commons Crypto AES or
> Commons AES would be a better name.
>
> Gary
>
> On Sun, Feb 21, 2016 at 6:28 PM, Chen, Haifeng 
> wrote:
>
> > Thanks Benedikt, Uma, Gary, Ole, and Emmanuel Bourg for your support!
> > It's great to have Chimera to be part of Apache Commons.
> >
> > >>[ Emmanuel Bourg] Define the scope of the project? Do we go after
> > >>Bouncy
> > Castle and aim for an equivalent feature set?
> > Agree to make a clear scope of the project. The original Chimera scope
> > is not go after a Bouncy Castle style of library. It targets the gap
> > between the application and the under cipher implementations. For
> > example, applications uses a lot of InputStream/OutputStream or
> > Channel concepts to read / write a stream of data. Application can
> > share these Crypto streams/channel implementations abstracting various
> input and output types.
> > Chimera also targets to very important performance optimizations on
> > AES which is used worldwide. I suggest this module to be still
> > lightweight and clear in involving, which is the same ideology of Apache
> Commons.
> >
> > >> [Uma] Here I would like to introduce Haifeng, who lead the efforts
> > >> in
> > Chimera github project.
> > Thanks Uma for introduction.
> >
> > >> [Uma] Me and Haifeng had some discussion yesterday for the list to
> > >> get
> > commit prevs. May be he could probably get list. Then I think Commons
> > PMC can make a decision on it.
> > Chimera has 5 long standing contributors on github. We can also invite
> > those who contributed the HDFS encryption feature (HDFS-6134 and
> > HADOOP-10150) to continue participate the involution of this project
> > if they want.
> >
> > Thanks,
> > Haifeng
> >
> > -Original Message-
> > From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com]
> > Sent: Sunday, February 21, 2016 3:07 AM
> > To: Commons Developers List 
> > Subject: Re: [crypto][chimera] Next steps
> >
> > Hi Benedikt,
> >
> >  Thank you for the Next steps discussion. I thought of pinging you on
> > this
> > :-)
> >
> >  Here I would like to introduce Haifeng, who lead the efforts in
> > Chimera github project.
> >
> > I think Apache Commons Crypto looks good and self descriptive IMO.
> >  I am +1
> >
> > Me and Haifeng had some discussion yesterday for the list to get
> > commit prevs. May be he could probably get list. Then I think Commons
> > PMC can make a decision on it.
> >
> >
> > >move code to an Apache repo (probably git?!)
> > +1 for git
> >
> > >- setup maven build
> > If this point is just about maven build alone, then we should set up
> > Jenkins CI build boat as well right, may be we can add this point?
> >
> > Regards,
> > Uma
> >
> > On 2/20/16, 8:29 AM, "Gary Gregory"  wrote:
> >
> > >Who are the committers comm

RE: [crypto][chimera] Next steps

[Chen, Haifeng]

Thanks Gary.

>> Would Commons Crypto focus only on AES? If so, Commons Crypto AES or Commons 
>> AES would be a better name.
Currently, this module supports only AES modes. To help folks with information 
for making decision, a little further clarification from me may help. 

The project doesn't implement directly the cryptographic algorithms. It 
provides:
1.  It provides a thin layer of Cipher to abstract the under-layer Cipher 
implementations. (currently support JCE Cipher or OpenSSL Cipher 
implementations). This is for optimization purposes, for example OpenSSL Cipher 
implementation provides 17+x performance for AES/CTR comparing with JDK 6 and 
5x comparing JDK 7/8.
2.  It provides a layer of stream and channel implementations abstracting Input 
source and Output target utilizing the Cipher layer. The layer can be used 
easily by applications that needs to encrypt/decrypt data streams or channels.
3.  Additionally, it provides a secure random utility classes to help generate 
TRUE random numbers for key generation. 

While there is no technical barrier for it to support other algorithms such as 
RC4 through JCE or OpenSSL. Just depends how widely this is required.

Thanks,
Haifeng

-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com] 
Sent: Monday, February 22, 2016 11:36 AM
To: Commons Developers List 
Subject: Re: [crypto][chimera] Next steps

Would Commons Crypto focus only on AES? If so, Commons Crypto AES or Commons 
AES would be a better name.

Gary

On Sun, Feb 21, 2016 at 6:28 PM, Chen, Haifeng 
wrote:

> Thanks Benedikt, Uma, Gary, Ole, and Emmanuel Bourg for your support! 
> It's great to have Chimera to be part of Apache Commons.
>
> >>[ Emmanuel Bourg] Define the scope of the project? Do we go after 
> >>Bouncy
> Castle and aim for an equivalent feature set?
> Agree to make a clear scope of the project. The original Chimera scope 
> is not go after a Bouncy Castle style of library. It targets the gap 
> between the application and the under cipher implementations. For 
> example, applications uses a lot of InputStream/OutputStream or 
> Channel concepts to read / write a stream of data. Application can 
> share these Crypto streams/channel implementations abstracting various input 
> and output types.
> Chimera also targets to very important performance optimizations on 
> AES which is used worldwide. I suggest this module to be still 
> lightweight and clear in involving, which is the same ideology of Apache 
> Commons.
>
> >> [Uma] Here I would like to introduce Haifeng, who lead the efforts 
> >> in
> Chimera github project.
> Thanks Uma for introduction.
>
> >> [Uma] Me and Haifeng had some discussion yesterday for the list to 
> >> get
> commit prevs. May be he could probably get list. Then I think Commons 
> PMC can make a decision on it.
> Chimera has 5 long standing contributors on github. We can also invite 
> those who contributed the HDFS encryption feature (HDFS-6134 and
> HADOOP-10150) to continue participate the involution of this project 
> if they want.
>
> Thanks,
> Haifeng
>
> -Original Message-----
> From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com]
> Sent: Sunday, February 21, 2016 3:07 AM
> To: Commons Developers List 
> Subject: Re: [crypto][chimera] Next steps
>
> Hi Benedikt,
>
>  Thank you for the Next steps discussion. I thought of pinging you on 
> this
> :-)
>
>  Here I would like to introduce Haifeng, who lead the efforts in 
> Chimera github project.
>
> I think Apache Commons Crypto looks good and self descriptive IMO.
>  I am +1
>
> Me and Haifeng had some discussion yesterday for the list to get 
> commit prevs. May be he could probably get list. Then I think Commons 
> PMC can make a decision on it.
>
>
> >move code to an Apache repo (probably git?!)
> +1 for git
>
> >- setup maven build
> If this point is just about maven build alone, then we should set up 
> Jenkins CI build boat as well right, may be we can add this point?
>
> Regards,
> Uma
>
> On 2/20/16, 8:29 AM, "Gary Gregory"  wrote:
>
> >Who are the committers comming along for this component?
> >
> >Do we have enough of them?
> >
> >I like Apache Commons Crypto.
> >
> >Gary
> >On Feb 20, 2016 3:15 AM, "Benedikt Ritter"  wrote:
> >
> >> Hi,
> >>
> >> I'd like to discuss the next steps for moving the Chimera component 
> >>to  Apache Commons. So far, none of the other PMC members has 
> >>expressed his or  her thoughts about this. If nobody brings up 
> >>objections about moving the  component to Apache Commons, I'm 
> >>assuming lazy

Re: [crypto][chimera] Next steps

[Gary Gregory]

Would Commons Crypto focus only on AES? If so, Commons Crypto AES or Commons
AES would be a better name.

Gary

On Sun, Feb 21, 2016 at 6:28 PM, Chen, Haifeng 
wrote:

> Thanks Benedikt, Uma, Gary, Ole, and Emmanuel Bourg for your support! It's
> great to have Chimera to be part of Apache Commons.
>
> >>[ Emmanuel Bourg] Define the scope of the project? Do we go after Bouncy
> Castle and aim for an equivalent feature set?
> Agree to make a clear scope of the project. The original Chimera scope is
> not go after a Bouncy Castle style of library. It targets the gap between
> the application and the under cipher implementations. For example,
> applications uses a lot of InputStream/OutputStream or Channel concepts to
> read / write a stream of data. Application can share these Crypto
> streams/channel implementations abstracting various input and output types.
> Chimera also targets to very important performance optimizations on AES
> which is used worldwide. I suggest this module to be still lightweight and
> clear in involving, which is the same ideology of Apache Commons.
>
> >> [Uma] Here I would like to introduce Haifeng, who lead the efforts in
> Chimera github project.
> Thanks Uma for introduction.
>
> >> [Uma] Me and Haifeng had some discussion yesterday for the list to get
> commit prevs. May be he could probably get list. Then I think Commons PMC
> can make a decision on it.
> Chimera has 5 long standing contributors on github. We can also invite
> those who contributed the HDFS encryption feature (HDFS-6134 and
> HADOOP-10150) to continue participate the involution of this project if
> they want.
>
> Thanks,
> Haifeng
>
> -Original Message-
> From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com]
> Sent: Sunday, February 21, 2016 3:07 AM
> To: Commons Developers List 
> Subject: Re: [crypto][chimera] Next steps
>
> Hi Benedikt,
>
>  Thank you for the Next steps discussion. I thought of pinging you on this
> :-)
>
>  Here I would like to introduce Haifeng, who lead the efforts in Chimera
> github project.
>
> I think Apache Commons Crypto looks good and self descriptive IMO.
>  I am +1
>
> Me and Haifeng had some discussion yesterday for the list to get commit
> prevs. May be he could probably get list. Then I think Commons PMC can make
> a decision on it.
>
>
> >move code to an Apache repo (probably git?!)
> +1 for git
>
> >- setup maven build
> If this point is just about maven build alone, then we should set up
> Jenkins CI build boat as well right, may be we can add this point?
>
> Regards,
> Uma
>
> On 2/20/16, 8:29 AM, "Gary Gregory"  wrote:
>
> >Who are the committers comming along for this component?
> >
> >Do we have enough of them?
> >
> >I like Apache Commons Crypto.
> >
> >Gary
> >On Feb 20, 2016 3:15 AM, "Benedikt Ritter"  wrote:
> >
> >> Hi,
> >>
> >> I'd like to discuss the next steps for moving the Chimera component
> >>to  Apache Commons. So far, none of the other PMC members has
> >>expressed his or  her thoughts about this. If nobody brings up
> >>objections about moving the  component to Apache Commons, I'm assuming
> >>lazy consensus about this.
> >>
> >> So the next steps would be:
> >> - decide on a name for the new component (my proposal was Apache
> >> Commons
> >> Crypto)
> >> - move code to an Apache repo (probably git?!)
> >> - request a Jira project
> >> - setup maven build
> >> - setup project website
> >> - work on an initial release under Apache Commons coordinates
> >>
> >> Anything missing?
> >>
> >> Regards,
> >> Benedikt
> >>
> >> --
> >> http://home.apache.org/~britter/
> >> http://twitter.com/BenediktRitter
> >> http://github.com/britter
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

RE: [crypto][chimera] Next steps

[Chen, Haifeng]

Thanks Benedikt, Uma, Gary, Ole, and Emmanuel Bourg for your support! It's 
great to have Chimera to be part of Apache Commons. 

>>[ Emmanuel Bourg] Define the scope of the project? Do we go after Bouncy 
>>Castle and aim for an equivalent feature set?
Agree to make a clear scope of the project. The original Chimera scope is not 
go after a Bouncy Castle style of library. It targets the gap between the 
application and the under cipher implementations. For example, applications 
uses a lot of InputStream/OutputStream or Channel concepts to read / write a 
stream of data. Application can share these Crypto streams/channel 
implementations abstracting various input and output types. Chimera also 
targets to very important performance optimizations on AES which is used 
worldwide. I suggest this module to be still lightweight and clear in 
involving, which is the same ideology of Apache Commons.

>> [Uma] Here I would like to introduce Haifeng, who lead the efforts in 
>> Chimera github project.
Thanks Uma for introduction.

>> [Uma] Me and Haifeng had some discussion yesterday for the list to get 
>> commit prevs. May be he could probably get list. Then I think Commons PMC 
>> can make a decision on it.
Chimera has 5 long standing contributors on github. We can also invite those 
who contributed the HDFS encryption feature (HDFS-6134 and HADOOP-10150) to 
continue participate the involution of this project if they want.

Thanks,
Haifeng

-Original Message-
From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com] 
Sent: Sunday, February 21, 2016 3:07 AM
To: Commons Developers List 
Subject: Re: [crypto][chimera] Next steps

Hi Benedikt,

 Thank you for the Next steps discussion. I thought of pinging you on this
:-)
  
 Here I would like to introduce Haifeng, who lead the efforts in Chimera github 
project. 
 
I think Apache Commons Crypto looks good and self descriptive IMO.
 I am +1

Me and Haifeng had some discussion yesterday for the list to get commit prevs. 
May be he could probably get list. Then I think Commons PMC can make a decision 
on it.


>move code to an Apache repo (probably git?!)
+1 for git

>- setup maven build
If this point is just about maven build alone, then we should set up Jenkins CI 
build boat as well right, may be we can add this point?

Regards,
Uma 

On 2/20/16, 8:29 AM, "Gary Gregory"  wrote:

>Who are the committers comming along for this component?
>
>Do we have enough of them?
>
>I like Apache Commons Crypto.
>
>Gary
>On Feb 20, 2016 3:15 AM, "Benedikt Ritter"  wrote:
>
>> Hi,
>>
>> I'd like to discuss the next steps for moving the Chimera component 
>>to  Apache Commons. So far, none of the other PMC members has 
>>expressed his or  her thoughts about this. If nobody brings up 
>>objections about moving the  component to Apache Commons, I'm assuming 
>>lazy consensus about this.
>>
>> So the next steps would be:
>> - decide on a name for the new component (my proposal was Apache 
>> Commons
>> Crypto)
>> - move code to an Apache repo (probably git?!)
>> - request a Jira project
>> - setup maven build
>> - setup project website
>> - work on an initial release under Apache Commons coordinates
>>
>> Anything missing?
>>
>> Regards,
>> Benedikt
>>
>> --
>> http://home.apache.org/~britter/
>> http://twitter.com/BenediktRitter
>> http://github.com/britter
>>


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [crypto][chimera] Next steps

[Gangumalla, Uma]

Hi Benedikt,

 Thank you for the Next steps discussion. I thought of pinging you on this
:-)
  
 Here I would like to introduce Haifeng, who lead the efforts in Chimera
github project. 
 
I think Apache Commons Crypto looks good and self descriptive IMO.
 I am +1

Me and Haifeng had some discussion yesterday for the list to get commit
prevs. May be he could probably get list. Then I think Commons PMC can
make a decision on it.


>move code to an Apache repo (probably git?!)
+1 for git

>- setup maven build
If this point is just about maven build alone, then we should set up
Jenkins CI build boat as well right, may be we can add this point?

Regards,
Uma 

On 2/20/16, 8:29 AM, "Gary Gregory"  wrote:

>Who are the committers comming along for this component?
>
>Do we have enough of them?
>
>I like Apache Commons Crypto.
>
>Gary
>On Feb 20, 2016 3:15 AM, "Benedikt Ritter"  wrote:
>
>> Hi,
>>
>> I'd like to discuss the next steps for moving the Chimera component to
>> Apache Commons. So far, none of the other PMC members has expressed his
>>or
>> her thoughts about this. If nobody brings up objections about moving the
>> component to Apache Commons, I'm assuming lazy consensus about this.
>>
>> So the next steps would be:
>> - decide on a name for the new component (my proposal was Apache Commons
>> Crypto)
>> - move code to an Apache repo (probably git?!)
>> - request a Jira project
>> - setup maven build
>> - setup project website
>> - work on an initial release under Apache Commons coordinates
>>
>> Anything missing?
>>
>> Regards,
>> Benedikt
>>
>> --
>> http://home.apache.org/~britter/
>> http://twitter.com/BenediktRitter
>> http://github.com/britter
>>


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [crypto][chimera] Next steps

[Gary Gregory]

Who are the committers comming along for this component?

Do we have enough of them?

I like Apache Commons Crypto.

Gary
On Feb 20, 2016 3:15 AM, "Benedikt Ritter"  wrote:

> Hi,
>
> I'd like to discuss the next steps for moving the Chimera component to
> Apache Commons. So far, none of the other PMC members has expressed his or
> her thoughts about this. If nobody brings up objections about moving the
> component to Apache Commons, I'm assuming lazy consensus about this.
>
> So the next steps would be:
> - decide on a name for the new component (my proposal was Apache Commons
> Crypto)
> - move code to an Apache repo (probably git?!)
> - request a Jira project
> - setup maven build
> - setup project website
> - work on an initial release under Apache Commons coordinates
>
> Anything missing?
>
> Regards,
> Benedikt
>
> --
> http://home.apache.org/~britter/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>

Re: [crypto][chimera] Next steps

[Emmanuel Bourg]

Le 20/02/2016 12:15, Benedikt Ritter a écrit :

> Anything missing?

Define the scope of the project? Do we go after Bouncy Castle and aim
for an equivalent feature set?

Emmanuel Bourg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [crypto][chimera] Next steps

[Ole Ersoy]

Hi Benedikt,

I think it would be better for the projects health if it uses github issues 
only.

Cheers,
Ole


On 02/20/2016 05:15 AM, Benedikt Ritter wrote:

Hi,

I'd like to discuss the next steps for moving the Chimera component to
Apache Commons. So far, none of the other PMC members has expressed his or
her thoughts about this. If nobody brings up objections about moving the
component to Apache Commons, I'm assuming lazy consensus about this.

So the next steps would be:
- decide on a name for the new component (my proposal was Apache Commons
Crypto)
- move code to an Apache repo (probably git?!)
- request a Jira project
- setup maven build
- setup project website
- work on an initial release under Apache Commons coordinates

Anything missing?

Regards,
Benedikt




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[crypto][chimera] Next steps

[Benedikt Ritter]

Hi,

I'd like to discuss the next steps for moving the Chimera component to
Apache Commons. So far, none of the other PMC members has expressed his or
her thoughts about this. If nobody brings up objections about moving the
component to Apache Commons, I'm assuming lazy consensus about this.

So the next steps would be:
- decide on a name for the new component (my proposal was Apache Commons
Crypto)
- move code to an Apache repo (probably git?!)
- request a Jira project
- setup maven build
- setup project website
- work on an initial release under Apache Commons coordinates

Anything missing?

Regards,
Benedikt

-- 
http://home.apache.org/~britter/
http://twitter.com/BenediktRitter
http://github.com/britter