;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 m
gt;>>> 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.
&g
gt; >>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
>&g
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 advanc
doption
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
ion 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
>>> >>
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--
gt;> 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
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 Ja
g
>
> -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 valu
ommons 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
communit
s 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 w
s 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] Nex
rypto][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 accesse
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 abst
eating 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:
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/dec
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
e/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]
&
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 express
k
>
>> 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-
>
int, 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 ste
heng 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] Nex
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
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
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 a
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 th
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 ab
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
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 c
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 Commo
>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:
>Al
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
>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
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|chime
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
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 bet
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
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
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
> compone
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 c
m: 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.
>
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 Common
essage-
> 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
hanks,
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
:-)
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
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
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...@c
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 expr
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 th
50 matches
Mail list logo
