[crypto][chimera] Next steps

classic Classic list List threaded Threaded
50 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[crypto][chimera] Next steps

Benedikt Ritter-4
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
Reply | Threaded
Open this post in threaded view
|

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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [crypto][chimera] Next steps

Emmanuel Bourg-3
In reply to this post by Benedikt Ritter-4
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [crypto][chimera] Next steps

garydgregory
In reply to this post by Benedikt Ritter-4
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" <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

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" <[hidden email]> 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" <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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:[hidden email]]
Sent: Sunday, February 21, 2016 3:07 AM
To: Commons Developers List <[hidden email]>
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" <[hidden email]> 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" <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [crypto][chimera] Next steps

garydgregory
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 <[hidden email]>
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:[hidden email]]
> Sent: Sunday, February 21, 2016 3:07 AM
> To: Commons Developers List <[hidden email]>
> 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" <[hidden email]> 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" <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
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
Reply | Threaded
Open this post in threaded view
|

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:[hidden email]]
Sent: Monday, February 22, 2016 11:36 AM
To: Commons Developers List <[hidden email]>
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 <[hidden email]>
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:[hidden email]]
> Sent: Sunday, February 21, 2016 3:07 AM
> To: Commons Developers List <[hidden email]>
> 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" <[hidden email]> 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" <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email] 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

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [crypto][chimera] Next steps

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

Gary

On Sun, Feb 21, 2016 at 10:51 PM, Chen, Haifeng <[hidden email]>
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:[hidden email]]
> Sent: Monday, February 22, 2016 11:36 AM
> To: Commons Developers List <[hidden email]>
> 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 <[hidden email]>
> 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:[hidden email]]
> > Sent: Sunday, February 21, 2016 3:07 AM
> > To: Commons Developers List <[hidden email]>
> > 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" <[hidden email]> 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" <[hidden email]> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> E-Mail: [hidden email] | [hidden email] 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
>



--
E-Mail: [hidden email] | [hidden email]
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
Reply | Threaded
Open this post in threaded view
|

RE: [crypto][chimera] Next steps

Chen, Haifeng
In reply to this post by garydgregory
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 <[hidden email]>
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:[hidden email]]
Sent: Monday, February 22, 2016 11:36 AM
To: Commons Developers List <[hidden email]>
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 <[hidden email]>
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:[hidden email]]
> Sent: Sunday, February 21, 2016 3:07 AM
> To: Commons Developers List <[hidden email]>
> 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" <[hidden email]> 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" <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email] 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

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [crypto][chimera] Next steps

Benedikt Ritter-4
In reply to this post by Benedikt Ritter-4
Hi again,

2016-02-20 12:15 GMT+01:00 Benedikt Ritter <[hidden email]>:

> 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
Reply | Threaded
Open this post in threaded view
|

Re: [crypto][chimera] Next steps

garydgregory
On Feb 21, 2016 11:59 PM, "Benedikt Ritter" <[hidden email]> wrote:
>
> Hi again,
>
> 2016-02-20 12:15 GMT+01:00 Benedikt Ritter <[hidden email]>:
>
> > 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
Reply | Threaded
Open this post in threaded view
|

RE: [crypto][chimera] Next steps

Xu, Cheng A
In reply to this post by garydgregory
Hi Gary,
We use JNI to get to Openssl.

Ferd

-----Original Message-----
From: Gary Gregory [mailto:[hidden email]]
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 <[hidden email]>
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:[hidden email]]
> Sent: Monday, February 22, 2016 11:36 AM
> To: Commons Developers List <[hidden email]>
> 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 <[hidden email]>
> 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:[hidden email]]
> > Sent: Sunday, February 21, 2016 3:07 AM
> > To: Commons Developers List <[hidden email]>
> > 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" <[hidden email]> 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" <[hidden email]> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> E-Mail: [hidden email] | [hidden email] 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
>



--
E-Mail: [hidden email] | [hidden email]
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

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [crypto][chimera] Next steps

Nick Burch-8
In reply to this post by garydgregory
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 <[hidden email]>
> 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:[hidden email]]
>> Sent: Monday, February 22, 2016 11:36 AM
>> To: Commons Developers List <[hidden email]>
>> 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 <[hidden email]>
>> 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:[hidden email]]
>>> Sent: Sunday, February 21, 2016 3:07 AM
>>> To: Commons Developers List <[hidden email]>
>>> 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" <[hidden email]> 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" <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>>
>> --
>> E-Mail: [hidden email] | [hidden email] 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
>>
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [crypto][chimera] Next steps

Colin P. McCabe
In reply to this post by Benedikt Ritter-4
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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [crypto][chimera] Next steps

jochen-2
On Mon, Feb 22, 2016 at 6:28 PM, Colin P. McCabe <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [crypto][chimera] Next steps

Gangumalla, Uma
In reply to this post by 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.
[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" <[hidden email]> 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 <[hidden email]>
>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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [crypto][chimera] Next steps

garydgregory
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 <[hidden email]>
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" <[hidden email]> 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 <[hidden email]>
> >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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
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
Reply | Threaded
Open this post in threaded view
|

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" <[hidden email]> 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
><[hidden email]>
>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" <[hidden email]> 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 <[hidden email]>
>> >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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
>--
>E-Mail: [hidden email] | [hidden email]
>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


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [crypto][chimera] Next steps

garydgregory
On Mon, Feb 22, 2016 at 1:26 PM, Gangumalla, Uma <[hidden email]>
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" <[hidden email]> 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
> ><[hidden email]>
> >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" <[hidden email]> 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 <[hidden email]>
> >> >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: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
> >
> >
> >--
> >E-Mail: [hidden email] | [hidden email]
> >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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
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
123