You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@commons.apache.org by Benedikt Ritter <br...@apache.org> on 2016/02/20 12:15:19 UTC

[crypto][chimera] Next steps

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

Posted by "Chen, Haifeng" <ha...@intel.com>.

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:ebourg@apache.org] 
Sent: Friday, February 26, 2016 11:03 PM
To: Commons Developers List <de...@commons.apache.org>
Cc: common-dev@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

RE: [crypto][chimera] Next steps

Posted by "Chen, Haifeng" <ha...@intel.com>.

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:ebourg@apache.org] 
Sent: Friday, February 26, 2016 11:03 PM
To: Commons Developers List <de...@commons.apache.org>
Cc: common-dev@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [crypto][chimera] Next steps

Posted by Emmanuel Bourg <eb...@apache.org>.

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

Re: [crypto][chimera] Next steps

Posted by Emmanuel Bourg <eb...@apache.org>.

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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

RE: [crypto][chimera] Next steps

Posted by "Chen, Haifeng" <ha...@intel.com>.

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.bourg@gmail.com] On Behalf Of Emmanuel Bourg
Sent: Tuesday, February 23, 2016 6:53 PM
To: Commons Developers List <de...@commons.apache.org>
Cc: common-dev@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 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

RE: [crypto][chimera] Next steps

Posted by "Chen, Haifeng" <ha...@intel.com>.

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.bourg@gmail.com] On Behalf Of Emmanuel Bourg
Sent: Tuesday, February 23, 2016 6:53 PM
To: Commons Developers List <de...@commons.apache.org>
Cc: common-dev@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 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [crypto][chimera] Next steps

Posted by Gary Gregory <ga...@gmail.com>.

On Tue, Feb 23, 2016 at 2:53 AM, Emmanuel Bourg <eb...@apache.org> 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@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

Posted by Gary Gregory <ga...@gmail.com>.

On Tue, Feb 23, 2016 at 2:53 AM, Emmanuel Bourg <eb...@apache.org> 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@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

Posted by Emmanuel Bourg <eb...@apache.org>.

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

Re: [crypto][chimera] Next steps

Posted by Emmanuel Bourg <eb...@apache.org>.

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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [crypto][chimera] Next steps

Posted by Emmanuel Bourg <eb...@apache.org>.

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

Re: [crypto][chimera] Next steps

Posted by Gary Gregory <ga...@gmail.com>.

On Feb 21, 2016 11:59 PM, "Benedikt Ritter" <br...@apache.org> wrote:
>
> Hi again,
>
> 2016-02-20 12:15 GMT+01:00 Benedikt Ritter <br...@apache.org>:
>
> > 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

Posted by Gary Gregory <ga...@gmail.com>.

On Feb 21, 2016 11:59 PM, "Benedikt Ritter" <br...@apache.org> wrote:
>
> Hi again,
>
> 2016-02-20 12:15 GMT+01:00 Benedikt Ritter <br...@apache.org>:
>
> > 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

Posted by Benedikt Ritter <br...@apache.org>.

Hi again,

2016-02-20 12:15 GMT+01:00 Benedikt Ritter <br...@apache.org>:

> 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

Posted by Emmanuel Bourg <eb...@apache.org>.

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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [crypto][chimera] Next steps

Posted by Benedikt Ritter <br...@apache.org>.

Hi again,

2016-02-20 12:15 GMT+01:00 Benedikt Ritter <br...@apache.org>:

> 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

Posted by sebb <se...@gmail.com>.

On 22 February 2016 at 23:43, James Carman <ja...@carmanconsulting.com> 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 <ga...@gmail.com> 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" <ja...@carmanconsulting.com>
>> 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 <br...@apache.org>
>> > 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [crypto][chimera] Next steps

Posted by James Carman <ja...@carmanconsulting.com>.

Still not a fan. My vote stands
On Mon, Feb 22, 2016 at 6:37 PM Gary Gregory <ga...@gmail.com> wrote:

> We already have commons-daemon that has C bits.
>
> Gary
> On Feb 22, 2016 3:27 PM, "James Carman" <ja...@carmanconsulting.com>
> 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 <br...@apache.org>
> > 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

Posted by Gary Gregory <ga...@gmail.com>.

We already have commons-daemon that has C bits.

Gary
On Feb 22, 2016 3:27 PM, "James Carman" <ja...@carmanconsulting.com> 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 <br...@apache.org>
> 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

Posted by James Carman <ja...@carmanconsulting.com>.

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 <br...@apache.org> 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

Posted by Jochen Wiedmann <jo...@gmail.com>.

On Tue, Feb 23, 2016 at 10:47 AM, Benedikt Ritter <br...@apache.org> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [crypto][chimera] Next steps

Posted by Benedikt Ritter <br...@apache.org>.

2016-02-23 10:18 GMT+01:00 Mark Thomas <ma...@apache.org>:

> On 23/02/2016 09:12, sebb wrote:
> > On 23 February 2016 at 07:34, Benedikt Ritter <br...@apache.org>
> 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 <ch...@intel.com>:
> >>
> >>> At this point, it has just Java interfaces only.
> >>>
> >>> -----Original Message-----
> >>> From: Colin P. McCabe [mailto:cmccabe@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 <br...@apache.org>
> >>> 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-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >>
> >>
> >> --
> >> http://home.apache.org/~britter/
> >> http://twitter.com/BenediktRitter
> >> http://github.com/britter
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


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

Re: [crypto][chimera] Next steps

Posted by Benedikt Ritter <br...@apache.org>.

Hi,

Gangumalla, Uma <um...@intel.com> schrieb am Do., 17. März 2016 um
07:30 Uhr:

>
> Dear All,
>
> Please find the proposal document text for Apache Commons Crypto project
> below and the same has been committed at Chimera project home folder [1] .
>
> Please provide your feedbacks and let me know if anything else need to
> cover in this document.
>
> Thanks a lot for the help and support so far.
>

Thank you!

I think we should leave this open for discussion for a few days. If nobody
objects within, say 72 hours, I'll start a vote for accepting Chimera as
new Apache Commons component.

Regards,
Benedikt


>
> [1]  https://github.com/intel-hadoop/chimera/blob/master/PROPOSAL.html
> <https://github.com/intel-hadoop/chimera/blob/master/PROPOSAL.html
> >https://
> github.com/intel-hadoop/chimera/blob/master/PROPOSAL.html>
>
>
> <PROPOSAL TEXT STARTS>
>
>
> Proposal for Apache Commons Crypto Package
>
> (0) Rationale
>
> Providing Java based optimized and high performance cryptographic IO
> streams for the applications who wants to implement the data encryption.
> It also provides cipher level API to use. It does provide the openssl API
> integration and provide the fallback mechanism to use JCE when openssl
> library unavailable.
> (Note: Please note that Commons Crypto doesn’t implement the cryptographic
> algorithm such as AES directly. It wraps to Openssl or JCE which implement
> algorithms.)
>
> (1) Scope of the Package
>
> This proposal is to create a package of cryptographic IO classes with the
> integration of Openssl library.
> It focuses on AES-NI optimizations mainly and it can be extended to other
> algorithms based on demand from the users later.
>
> (1.5) Interaction With Other Packages
>
> Commons Crypto relies on standard JDK 7 (or later) APIs for production
> deployment and on OpenSSL 1.0.1c devl libraries.
> It utilizes the JUnit unit testing framework, but this is of interest only
> to developers of the component.
> The functionality provided by Commons Crypto is currently in use by Apache
> Hadoop and Apache Spark, and both of those communities
> have expressed interest in changing their dependency to be on the central
> Commons Crypto package once it exists.
>
> (2) Initial Source of the Package
>
> The initial classes came from the Apache Hadoop.
> The proposed package name for the new component is
> org.apache.commons.crypto.
>
> (3) Required Apache Commons Resources
>
> * Git Repository - New repository commons-crypto
> * Mailing List - Discussions will take place on the general
> dev@commons.apache.org mailing list.
>   To help list subscribers identify messages of interest, it is suggested
> that the message subject of messages about this component be prefixed with
> [Crypto].
> * JIRA - New component "Crypto" under the "Commons" project.
> * Confluence FAQ - New category "commons-crypto" (when available).
>
> (4) Initial Committers (Names in alphabetical order)
>
> * Aaron T. Myers (atm@apache.org, Apache Hadoop PMC, one of the original
> Crypto dev team in Apache Hadoop)
> * Andrew Wang (wang@apache.org, Apache Hadoop PMC, one of the original
> Crypto dev team in Apache Hadoop)
> * Chris Nauroth (cnauroth@apache.org, Apache Hadoop PMC and active
> reviewer)
> * Colin P. McCabe (cmccabe@apache.org, Apache Hadoop PMC, one of the
> original Crypto dev team in Apache Hadoop)
> * Dapeng Sun (sdp@apache.org, Apache Sentry Committer, Chimera
> contributor)
> * Dian Fu (dianfu@apache.org, Apache Sqoop Committer, Chimera contributor)
> * Dong Chen (dongc@apache.org, Apache Hive Committer,interested on
> Chimera)
> * Ferdinand Xu (xuf@apache.org, Apache Hive Committer, Chimera
> contributor)
> * Haifeng Chen (haifengchen@apache.org, Chimera lead and code contributor)
> * Marcelo Vanzin (Apache Spark Committer, Chimera contributor)
> * Uma Maheswara Rao G (umamahesh@apache.org, Apache Hadoop PMC, One of the
> original Crypto dev/review team in Apache Hadoop)
> * Yi Liu (yliu@apache.org, Apache Hadoop PMC, One of the original Crypto
> dev/review team in Apache Hadoop)
>
>
> <PROPOSAL TEXT ENDS>
>
>
> Regards,
> Uma
>
> On 3/7/16, 5:20 PM, "Gangumalla, Uma" <um...@intel.com> wrote:
>
> >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" <ga...@gmail.com> 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
> >><um...@intel.com>
> >>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" <br...@apache.org> 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 <ha...@intel.com>:
> >>>>
> >>>>> 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.chen@intel.com]
> >>>>> Sent: Wednesday, February 24, 2016 12:40 PM
> >>>>> To: Commons Developers List <de...@commons.apache.org>
> >>>>> Cc: common-dev@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.gangumalla@intel.com]
> >>>>> Sent: Wednesday, February 24, 2016 5:13 AM
> >>>>> To: Commons Developers List <de...@commons.apache.org>
> >>>>> Cc: common-dev@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" <ma...@apache.org> wrote:
> >>>>>
> >>>>> >On 23/02/2016 09:12, sebb wrote:
> >>>>> >> On 23 February 2016 at 07:34, Benedikt Ritter <britter@apache.org
> >
> >>>>> >>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 <ch...@intel.com>:
> >>>>> >>>
> >>>>> >>>> At this point, it has just Java interfaces only.
> >>>>> >>>>
> >>>>> >>>> -----Original Message-----
> >>>>> >>>> From: Colin P. McCabe [mailto:cmccabe@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
> >>>>> >>>> <br...@apache.org>
> >>>>> >>>> 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-unsubscribe@commons.apache.org
> >>><ma...@commons.apache.org>
> >>>>> >>>> For additional commands, e-mail:
> >>>dev-help@commons.apache.org <ma...@commons.apache.org>
> >>>>> >>>>
> >>>>> >>>>
> >>>>> >>>
> >>>>> >>>
> >>>>> >>> --
> >>>>> >>> http://home.apache.org/~britter/
> >>>>> >>> http://twitter.com/BenediktRitter
> >>>>> >>> http://github.com/britter
> >>>>> >>
> >>>>> >>
> >>>---------------------------------------------------------------------
> >>>>> >> To unsubscribe, e-mail:
> >>>dev-unsubscribe@commons.apache.org
> >>><ma...@commons.apache.org>
> >>>>> >> For additional commands, e-mail:
> >>>dev-help@commons.apache.org <ma...@commons.apache.org>
> >>>>> >>
> >>>>> >
> >>>>> >
> >>>>>
> >>>>---------------------------------------------------------------------
> >>>>> >To unsubscribe, e-mail:
> >>>dev-unsubscribe@commons.apache.org
> >>><ma...@commons.apache.org>
> >>>>> >For additional commands, e-mail:
> >>>dev-help@commons.apache.org <ma...@commons.apache.org>
> >>>>> >
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail:
> >>>dev-unsubscribe@commons.apache.org
> >>><ma...@commons.apache.org>
> >>>>> For additional commands, e-mail:
> >>>dev-help@commons.apache.org <ma...@commons.apache.org>
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail:
> >>>dev-unsubscribe@commons.apache.org
> >>><ma...@commons.apache.org>
> >>>>> For additional commands, e-mail:
> >>>dev-help@commons.apache.org <ma...@commons.apache.org>
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail:
> >>>dev-unsubscribe@commons.apache.org
> >>><ma...@commons.apache.org>
> >>>>> For additional commands, e-mail:
> >>>dev-help@commons.apache.org <ma...@commons.apache.org>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>--
> >>>>http://home.apache.org/~britter/
> >>>>http://twitter.com/BenediktRitter
> >>>>http://github.com/britter
> >>>
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail:
> >>>dev-unsubscribe@commons.apache.org
> >>><ma...@commons.apache.org>
> >>>For additional commands, e-mail:
> >>>dev-help@commons.apache.org <ma...@commons.apache.org>
> >>>
> >>>
> >>
> >>
> >>--
> >>E-Mail: garydgregory@gmail.com |
> >>ggregory@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
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail:
> >dev-unsubscribe@commons.apache.org
> ><ma...@commons.apache.org>
> >For additional commands, e-mail:
> >dev-help@commons.apache.org <ma...@commons.apache.org>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

Re: [crypto][chimera] Next steps

Posted by "Gangumalla, Uma" <um...@intel.com>.

Dear All,

Please find the proposal document text for Apache Commons Crypto project
below and the same has been committed at Chimera project home folder [1] .

Please provide your feedbacks and let me know if anything else need to
cover in this document.

Thanks a lot for the help and support so far.

[1]  https://github.com/intel-hadoop/chimera/blob/master/PROPOSAL.html
<https://github.com/intel-hadoop/chimera/blob/master/PROPOSAL.html>https://
github.com/intel-hadoop/chimera/blob/master/PROPOSAL.html>


<PROPOSAL TEXT STARTS>


Proposal for Apache Commons Crypto Package

(0) Rationale

Providing Java based optimized and high performance cryptographic IO
streams for the applications who wants to implement the data encryption.
It also provides cipher level API to use. It does provide the openssl API
integration and provide the fallback mechanism to use JCE when openssl
library unavailable.
(Note: Please note that Commons Crypto doesn’t implement the cryptographic
algorithm such as AES directly. It wraps to Openssl or JCE which implement
algorithms.)

(1) Scope of the Package

This proposal is to create a package of cryptographic IO classes with the
integration of Openssl library.
It focuses on AES-NI optimizations mainly and it can be extended to other
algorithms based on demand from the users later.

(1.5) Interaction With Other Packages

Commons Crypto relies on standard JDK 7 (or later) APIs for production
deployment and on OpenSSL 1.0.1c devl libraries.
It utilizes the JUnit unit testing framework, but this is of interest only
to developers of the component.
The functionality provided by Commons Crypto is currently in use by Apache
Hadoop and Apache Spark, and both of those communities
have expressed interest in changing their dependency to be on the central
Commons Crypto package once it exists.

(2) Initial Source of the Package

The initial classes came from the Apache Hadoop.
The proposed package name for the new component is
org.apache.commons.crypto.

(3) Required Apache Commons Resources

* Git Repository - New repository commons-crypto
* Mailing List - Discussions will take place on the general
dev@commons.apache.org mailing list.
  To help list subscribers identify messages of interest, it is suggested
that the message subject of messages about this component be prefixed with
[Crypto].
* JIRA - New component "Crypto" under the "Commons" project.
* Confluence FAQ - New category "commons-crypto" (when available).

(4) Initial Committers (Names in alphabetical order)

* Aaron T. Myers (atm@apache.org, Apache Hadoop PMC, one of the original
Crypto dev team in Apache Hadoop)
* Andrew Wang (wang@apache.org, Apache Hadoop PMC, one of the original
Crypto dev team in Apache Hadoop)
* Chris Nauroth (cnauroth@apache.org, Apache Hadoop PMC and active
reviewer)
* Colin P. McCabe (cmccabe@apache.org, Apache Hadoop PMC, one of the
original Crypto dev team in Apache Hadoop)
* Dapeng Sun (sdp@apache.org, Apache Sentry Committer, Chimera contributor)
* Dian Fu (dianfu@apache.org, Apache Sqoop Committer, Chimera contributor)
* Dong Chen (dongc@apache.org, Apache Hive Committer,interested on Chimera)
* Ferdinand Xu (xuf@apache.org, Apache Hive Committer, Chimera contributor)
* Haifeng Chen (haifengchen@apache.org, Chimera lead and code contributor)
* Marcelo Vanzin (Apache Spark Committer, Chimera contributor)
* Uma Maheswara Rao G (umamahesh@apache.org, Apache Hadoop PMC, One of the
original Crypto dev/review team in Apache Hadoop)
* Yi Liu (yliu@apache.org, Apache Hadoop PMC, One of the original Crypto
dev/review team in Apache Hadoop)


<PROPOSAL TEXT ENDS>


Regards,
Uma

On 3/7/16, 5:20 PM, "Gangumalla, Uma" <um...@intel.com> wrote:

>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" <ga...@gmail.com> 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
>><um...@intel.com>
>>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" <br...@apache.org> 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 <ha...@intel.com>:
>>>>
>>>>> 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.chen@intel.com]
>>>>> Sent: Wednesday, February 24, 2016 12:40 PM
>>>>> To: Commons Developers List <de...@commons.apache.org>
>>>>> Cc: common-dev@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.gangumalla@intel.com]
>>>>> Sent: Wednesday, February 24, 2016 5:13 AM
>>>>> To: Commons Developers List <de...@commons.apache.org>
>>>>> Cc: common-dev@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" <ma...@apache.org> wrote:
>>>>>
>>>>> >On 23/02/2016 09:12, sebb wrote:
>>>>> >> On 23 February 2016 at 07:34, Benedikt Ritter <br...@apache.org>
>>>>> >>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 <ch...@intel.com>:
>>>>> >>>
>>>>> >>>> At this point, it has just Java interfaces only.
>>>>> >>>>
>>>>> >>>> -----Original Message-----
>>>>> >>>> From: Colin P. McCabe [mailto:cmccabe@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
>>>>> >>>> <br...@apache.org>
>>>>> >>>> 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-unsubscribe@commons.apache.org
>>><ma...@commons.apache.org>
>>>>> >>>> For additional commands, e-mail:
>>>dev-help@commons.apache.org <ma...@commons.apache.org>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>
>>>>> >>>
>>>>> >>> --
>>>>> >>> http://home.apache.org/~britter/
>>>>> >>> http://twitter.com/BenediktRitter
>>>>> >>> http://github.com/britter
>>>>> >>
>>>>> >> 
>>>---------------------------------------------------------------------
>>>>> >> To unsubscribe, e-mail:
>>>dev-unsubscribe@commons.apache.org
>>><ma...@commons.apache.org>
>>>>> >> For additional commands, e-mail:
>>>dev-help@commons.apache.org <ma...@commons.apache.org>
>>>>> >>
>>>>> >
>>>>> >
>>>>> 
>>>>---------------------------------------------------------------------
>>>>> >To unsubscribe, e-mail:
>>>dev-unsubscribe@commons.apache.org
>>><ma...@commons.apache.org>
>>>>> >For additional commands, e-mail:
>>>dev-help@commons.apache.org <ma...@commons.apache.org>
>>>>> >
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:
>>>dev-unsubscribe@commons.apache.org
>>><ma...@commons.apache.org>
>>>>> For additional commands, e-mail:
>>>dev-help@commons.apache.org <ma...@commons.apache.org>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:
>>>dev-unsubscribe@commons.apache.org
>>><ma...@commons.apache.org>
>>>>> For additional commands, e-mail:
>>>dev-help@commons.apache.org <ma...@commons.apache.org>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:
>>>dev-unsubscribe@commons.apache.org
>>><ma...@commons.apache.org>
>>>>> For additional commands, e-mail:
>>>dev-help@commons.apache.org <ma...@commons.apache.org>
>>>>>
>>>>>
>>>>
>>>>
>>>>--
>>>>http://home.apache.org/~britter/
>>>>http://twitter.com/BenediktRitter
>>>>http://github.com/britter
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail:
>>>dev-unsubscribe@commons.apache.org
>>><ma...@commons.apache.org>
>>>For additional commands, e-mail:
>>>dev-help@commons.apache.org <ma...@commons.apache.org>
>>>
>>>
>>
>>
>>-- 
>>E-Mail: garydgregory@gmail.com |
>>ggregory@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
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail:
>dev-unsubscribe@commons.apache.org
><ma...@commons.apache.org>
>For additional commands, e-mail:
>dev-help@commons.apache.org <ma...@commons.apache.org>


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

Re: [crypto][chimera] Next steps

Posted by "Gangumalla, Uma" <um...@intel.com>.

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" <ga...@gmail.com> 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
><um...@intel.com>
>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" <br...@apache.org> 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 <ha...@intel.com>:
>> >
>> >> 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.chen@intel.com]
>> >> Sent: Wednesday, February 24, 2016 12:40 PM
>> >> To: Commons Developers List <de...@commons.apache.org>
>> >> Cc: common-dev@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.gangumalla@intel.com]
>> >> Sent: Wednesday, February 24, 2016 5:13 AM
>> >> To: Commons Developers List <de...@commons.apache.org>
>> >> Cc: common-dev@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" <ma...@apache.org> wrote:
>> >>
>> >> >On 23/02/2016 09:12, sebb wrote:
>> >> >> On 23 February 2016 at 07:34, Benedikt Ritter <br...@apache.org>
>> >> >>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 <ch...@intel.com>:
>> >> >>>
>> >> >>>> At this point, it has just Java interfaces only.
>> >> >>>>
>> >> >>>> -----Original Message-----
>> >> >>>> From: Colin P. McCabe [mailto:cmccabe@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
>> >> >>>> <br...@apache.org>
>> >> >>>> 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-unsubscribe@commons.apache.org
>> >> >>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >> >>>>
>> >> >>>>
>> >> >>>
>> >> >>>
>> >> >>> --
>> >> >>> http://home.apache.org/~britter/
>> >> >>> http://twitter.com/BenediktRitter
>> >> >>> http://github.com/britter
>> >> >>
>> >> >> 
>>---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >> >>
>> >> >
>> >> >
>> >> 
>>>---------------------------------------------------------------------
>> >> >To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> >For additional commands, e-mail: dev-help@commons.apache.org
>> >> >
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >>
>> >>
>> >
>> >
>> >--
>> >http://home.apache.org/~britter/
>> >http://twitter.com/BenediktRitter
>> >http://github.com/britter
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
>-- 
>E-Mail: garydgregory@gmail.com | ggregory@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


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

Re: [crypto][chimera] Next steps

Posted by "Gangumalla, Uma" <um...@intel.com>.

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.<component name>

Regards,
Uma



>
>On 2/26/16, 1:26 PM, "Gary Gregory" <ga...@gmail.com> 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
>><um...@intel.com>
>>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" <br...@apache.org> 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 <ha...@intel.com>:
>>> >
>>> >> 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.chen@intel.com]
>>> >> Sent: Wednesday, February 24, 2016 12:40 PM
>>> >> To: Commons Developers List <de...@commons.apache.org>
>>> >> Cc: common-dev@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.gangumalla@intel.com]
>>> >> Sent: Wednesday, February 24, 2016 5:13 AM
>>> >> To: Commons Developers List <de...@commons.apache.org>
>>> >> Cc: common-dev@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" <ma...@apache.org> wrote:
>>> >>
>>> >> >On 23/02/2016 09:12, sebb wrote:
>>> >> >> On 23 February 2016 at 07:34, Benedikt Ritter
>>><br...@apache.org>
>>> >> >>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 <ch...@intel.com>:
>>> >> >>>
>>> >> >>>> At this point, it has just Java interfaces only.
>>> >> >>>>
>>> >> >>>> -----Original Message-----
>>> >> >>>> From: Colin P. McCabe [mailto:cmccabe@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
>>> >> >>>> <br...@apache.org>
>>> >> >>>> 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-unsubscribe@commons.apache.org
>>> >> >>>> For additional commands, e-mail: dev-help@commons.apache.org
>>> >> >>>>
>>> >> >>>>
>>> >> >>>
>>> >> >>>
>>> >> >>> --
>>> >> >>> http://home.apache.org/~britter/
>>> >> >>> http://twitter.com/BenediktRitter
>>> >> >>> http://github.com/britter
>>> >> >>
>>> >> >> 
>>>---------------------------------------------------------------------
>>> >> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> >> >> For additional commands, e-mail: dev-help@commons.apache.org
>>> >> >>
>>> >> >
>>> >> >
>>> >> 
>>>>---------------------------------------------------------------------
>>> >> >To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> >> >For additional commands, e-mail: dev-help@commons.apache.org
>>> >> >
>>> >>
>>> >>
>>> >> 
>>>---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> >> For additional commands, e-mail: dev-help@commons.apache.org
>>> >>
>>> >>
>>> >> 
>>>---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> >> For additional commands, e-mail: dev-help@commons.apache.org
>>> >>
>>> >>
>>> >> 
>>>---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> >> For additional commands, e-mail: dev-help@commons.apache.org
>>> >>
>>> >>
>>> >
>>> >
>>> >--
>>> >http://home.apache.org/~britter/
>>> >http://twitter.com/BenediktRitter
>>> >http://github.com/britter
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>>-- 
>>E-Mail: garydgregory@gmail.com | ggregory@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

Posted by Gary Gregory <ga...@gmail.com>.

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 <um...@intel.com>
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" <br...@apache.org> 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 <ha...@intel.com>:
> >
> >> 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.chen@intel.com]
> >> Sent: Wednesday, February 24, 2016 12:40 PM
> >> To: Commons Developers List <de...@commons.apache.org>
> >> Cc: common-dev@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.gangumalla@intel.com]
> >> Sent: Wednesday, February 24, 2016 5:13 AM
> >> To: Commons Developers List <de...@commons.apache.org>
> >> Cc: common-dev@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" <ma...@apache.org> wrote:
> >>
> >> >On 23/02/2016 09:12, sebb wrote:
> >> >> On 23 February 2016 at 07:34, Benedikt Ritter <br...@apache.org>
> >> >>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 <ch...@intel.com>:
> >> >>>
> >> >>>> At this point, it has just Java interfaces only.
> >> >>>>
> >> >>>> -----Original Message-----
> >> >>>> From: Colin P. McCabe [mailto:cmccabe@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
> >> >>>> <br...@apache.org>
> >> >>>> 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-unsubscribe@commons.apache.org
> >> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> >> >>>>
> >> >>>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> http://home.apache.org/~britter/
> >> >>> http://twitter.com/BenediktRitter
> >> >>> http://github.com/britter
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> >> For additional commands, e-mail: dev-help@commons.apache.org
> >> >>
> >> >
> >> >
> >> >---------------------------------------------------------------------
> >> >To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> >For additional commands, e-mail: dev-help@commons.apache.org
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
> >--
> >http://home.apache.org/~britter/
> >http://twitter.com/BenediktRitter
> >http://github.com/britter
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@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

Posted by Jochen Wiedmann <jo...@gmail.com>.

On Fri, Feb 26, 2016 at 9:47 PM, Gangumalla, Uma
<um...@intel.com> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [crypto][chimera] Next steps

Posted by "Gangumalla, Uma" <um...@intel.com>.

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" <br...@apache.org> 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 <ha...@intel.com>:
>
>> 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.chen@intel.com]
>> Sent: Wednesday, February 24, 2016 12:40 PM
>> To: Commons Developers List <de...@commons.apache.org>
>> Cc: common-dev@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.gangumalla@intel.com]
>> Sent: Wednesday, February 24, 2016 5:13 AM
>> To: Commons Developers List <de...@commons.apache.org>
>> Cc: common-dev@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" <ma...@apache.org> wrote:
>>
>> >On 23/02/2016 09:12, sebb wrote:
>> >> On 23 February 2016 at 07:34, Benedikt Ritter <br...@apache.org>
>> >>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 <ch...@intel.com>:
>> >>>
>> >>>> At this point, it has just Java interfaces only.
>> >>>>
>> >>>> -----Original Message-----
>> >>>> From: Colin P. McCabe [mailto:cmccabe@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
>> >>>> <br...@apache.org>
>> >>>> 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-unsubscribe@commons.apache.org
>> >>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>> --
>> >>> http://home.apache.org/~britter/
>> >>> http://twitter.com/BenediktRitter
>> >>> http://github.com/britter
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >>
>> >
>> >
>> >---------------------------------------------------------------------
>> >To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >For additional commands, e-mail: dev-help@commons.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
>-- 
>http://home.apache.org/~britter/
>http://twitter.com/BenediktRitter
>http://github.com/britter


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

Re: [crypto][chimera] Next steps

Posted by Benedikt Ritter <br...@apache.org>.

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 <ha...@intel.com>:

> 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.chen@intel.com]
> Sent: Wednesday, February 24, 2016 12:40 PM
> To: Commons Developers List <de...@commons.apache.org>
> Cc: common-dev@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.gangumalla@intel.com]
> Sent: Wednesday, February 24, 2016 5:13 AM
> To: Commons Developers List <de...@commons.apache.org>
> Cc: common-dev@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" <ma...@apache.org> wrote:
>
> >On 23/02/2016 09:12, sebb wrote:
> >> On 23 February 2016 at 07:34, Benedikt Ritter <br...@apache.org>
> >>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 <ch...@intel.com>:
> >>>
> >>>> At this point, it has just Java interfaces only.
> >>>>
> >>>> -----Original Message-----
> >>>> From: Colin P. McCabe [mailto:cmccabe@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
> >>>> <br...@apache.org>
> >>>> 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-unsubscribe@commons.apache.org
> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> http://home.apache.org/~britter/
> >>> http://twitter.com/BenediktRitter
> >>> http://github.com/britter
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >For additional commands, e-mail: dev-help@commons.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


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

RE: [crypto][chimera] Next steps

Posted by "Chen, Haifeng" <ha...@intel.com>.

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.chen@intel.com] 
Sent: Wednesday, February 24, 2016 12:40 PM
To: Commons Developers List <de...@commons.apache.org>
Cc: common-dev@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.gangumalla@intel.com]
Sent: Wednesday, February 24, 2016 5:13 AM
To: Commons Developers List <de...@commons.apache.org>
Cc: common-dev@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" <ma...@apache.org> wrote:

>On 23/02/2016 09:12, sebb wrote:
>> On 23 February 2016 at 07:34, Benedikt Ritter <br...@apache.org>
>>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 <ch...@intel.com>:
>>>
>>>> At this point, it has just Java interfaces only.
>>>>
>>>> -----Original Message-----
>>>> From: Colin P. McCabe [mailto:cmccabe@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 
>>>> <br...@apache.org>
>>>> 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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> http://home.apache.org/~britter/
>>> http://twitter.com/BenediktRitter
>>> http://github.com/britter
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>> 
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>For additional commands, e-mail: dev-help@commons.apache.org
>

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

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

RE: [crypto][chimera] Next steps

Posted by "Chen, Haifeng" <ha...@intel.com>.

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.chen@intel.com] 
Sent: Wednesday, February 24, 2016 12:40 PM
To: Commons Developers List <de...@commons.apache.org>
Cc: common-dev@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.gangumalla@intel.com]
Sent: Wednesday, February 24, 2016 5:13 AM
To: Commons Developers List <de...@commons.apache.org>
Cc: common-dev@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" <ma...@apache.org> wrote:

>On 23/02/2016 09:12, sebb wrote:
>> On 23 February 2016 at 07:34, Benedikt Ritter <br...@apache.org>
>>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 <ch...@intel.com>:
>>>
>>>> At this point, it has just Java interfaces only.
>>>>
>>>> -----Original Message-----
>>>> From: Colin P. McCabe [mailto:cmccabe@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 
>>>> <br...@apache.org>
>>>> 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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> http://home.apache.org/~britter/
>>> http://twitter.com/BenediktRitter
>>> http://github.com/britter
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>> 
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>For additional commands, e-mail: dev-help@commons.apache.org
>

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

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

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

RE: [crypto][chimera] Next steps

Posted by "Chen, Haifeng" <ha...@intel.com>.

>> 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.gangumalla@intel.com] 
Sent: Wednesday, February 24, 2016 5:13 AM
To: Commons Developers List <de...@commons.apache.org>
Cc: common-dev@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" <ma...@apache.org> wrote:

>On 23/02/2016 09:12, sebb wrote:
>> On 23 February 2016 at 07:34, Benedikt Ritter <br...@apache.org>
>>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 <ch...@intel.com>:
>>>
>>>> At this point, it has just Java interfaces only.
>>>>
>>>> -----Original Message-----
>>>> From: Colin P. McCabe [mailto:cmccabe@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 
>>>> <br...@apache.org>
>>>> 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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> http://home.apache.org/~britter/
>>> http://twitter.com/BenediktRitter
>>> http://github.com/britter
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>> 
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>For additional commands, e-mail: dev-help@commons.apache.org
>


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


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

RE: [crypto][chimera] Next steps

Posted by "Chen, Haifeng" <ha...@intel.com>.

>> 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.gangumalla@intel.com] 
Sent: Wednesday, February 24, 2016 5:13 AM
To: Commons Developers List <de...@commons.apache.org>
Cc: common-dev@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" <ma...@apache.org> wrote:

>On 23/02/2016 09:12, sebb wrote:
>> On 23 February 2016 at 07:34, Benedikt Ritter <br...@apache.org>
>>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 <ch...@intel.com>:
>>>
>>>> At this point, it has just Java interfaces only.
>>>>
>>>> -----Original Message-----
>>>> From: Colin P. McCabe [mailto:cmccabe@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 
>>>> <br...@apache.org>
>>>> 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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> http://home.apache.org/~britter/
>>> http://twitter.com/BenediktRitter
>>> http://github.com/britter
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>> 
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>For additional commands, e-mail: dev-help@commons.apache.org
>


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

Re: [crypto][chimera] Next steps

Posted by "Gangumalla, Uma" <um...@intel.com>.

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" <ma...@apache.org> wrote:

>On 23/02/2016 09:12, sebb wrote:
>> On 23 February 2016 at 07:34, Benedikt Ritter <br...@apache.org>
>>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 <ch...@intel.com>:
>>>
>>>> At this point, it has just Java interfaces only.
>>>>
>>>> -----Original Message-----
>>>> From: Colin P. McCabe [mailto:cmccabe@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 <br...@apache.org>
>>>> 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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> http://home.apache.org/~britter/
>>> http://twitter.com/BenediktRitter
>>> http://github.com/britter
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>> 
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>For additional commands, e-mail: dev-help@commons.apache.org
>

Re: [crypto][chimera] Next steps

Posted by "Gangumalla, Uma" <um...@intel.com>.

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" <ma...@apache.org> wrote:

>On 23/02/2016 09:12, sebb wrote:
>> On 23 February 2016 at 07:34, Benedikt Ritter <br...@apache.org>
>>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 <ch...@intel.com>:
>>>
>>>> At this point, it has just Java interfaces only.
>>>>
>>>> -----Original Message-----
>>>> From: Colin P. McCabe [mailto:cmccabe@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 <br...@apache.org>
>>>> 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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> http://home.apache.org/~britter/
>>> http://twitter.com/BenediktRitter
>>> http://github.com/britter
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>> 
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>For additional commands, e-mail: dev-help@commons.apache.org
>


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

Re: [crypto][chimera] Next steps

Posted by Mark Thomas <ma...@apache.org>.

On 23/02/2016 09:12, sebb wrote:
> On 23 February 2016 at 07:34, Benedikt Ritter <br...@apache.org> 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 <ch...@intel.com>:
>>
>>> At this point, it has just Java interfaces only.
>>>
>>> -----Original Message-----
>>> From: Colin P. McCabe [mailto:cmccabe@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 <br...@apache.org>
>>> 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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> --
>> http://home.apache.org/~britter/
>> http://twitter.com/BenediktRitter
>> http://github.com/britter
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


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

Re: [crypto][chimera] Next steps

Posted by sebb <se...@gmail.com>.

On 23 February 2016 at 07:34, Benedikt Ritter <br...@apache.org> 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 <ch...@intel.com>:
>
>> At this point, it has just Java interfaces only.
>>
>> -----Original Message-----
>> From: Colin P. McCabe [mailto:cmccabe@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 <br...@apache.org>
>> 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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> http://home.apache.org/~britter/
> http://twitter.com/BenediktRitter
> http://github.com/britter

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

Re: [crypto][chimera] Next steps

Posted by sebb <se...@gmail.com>.

On 23 February 2016 at 07:34, Benedikt Ritter <br...@apache.org> 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 <ch...@intel.com>:
>
>> At this point, it has just Java interfaces only.
>>
>> -----Original Message-----
>> From: Colin P. McCabe [mailto:cmccabe@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 <br...@apache.org>
>> 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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> http://home.apache.org/~britter/
> http://twitter.com/BenediktRitter
> http://github.com/britter

Re: [crypto][chimera] Next steps

Posted by Benedikt Ritter <br...@apache.org>.

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 <ch...@intel.com>:

> At this point, it has just Java interfaces only.
>
> -----Original Message-----
> From: Colin P. McCabe [mailto:cmccabe@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 <br...@apache.org>
> 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


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

Re: [crypto][chimera] Next steps

Posted by Benedikt Ritter <br...@apache.org>.

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 <ch...@intel.com>:

> At this point, it has just Java interfaces only.
>
> -----Original Message-----
> From: Colin P. McCabe [mailto:cmccabe@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 <br...@apache.org>
> 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


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

RE: [crypto][chimera] Next steps

Posted by "Xu, Cheng A" <ch...@intel.com>.

At this point, it has just Java interfaces only.

-----Original Message-----
From: Colin P. McCabe [mailto:cmccabe@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 <br...@apache.org> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

RE: [crypto][chimera] Next steps

Posted by "Xu, Cheng A" <ch...@intel.com>.

At this point, it has just Java interfaces only.

-----Original Message-----
From: Colin P. McCabe [mailto:cmccabe@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 <br...@apache.org> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [crypto][chimera] Next steps

Posted by Gary Gregory <ga...@gmail.com>.

On Mon, Feb 22, 2016 at 1:26 PM, Gangumalla, Uma <um...@intel.com>
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" <ga...@gmail.com> 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
> ><um...@intel.com>
> >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" <cm...@apache.org> 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 <br...@apache.org>
> >> >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-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
> >--
> >E-Mail: garydgregory@gmail.com | ggregory@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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@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

Posted by Gary Gregory <ga...@gmail.com>.

On Mon, Feb 22, 2016 at 1:26 PM, Gangumalla, Uma <um...@intel.com>
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" <ga...@gmail.com> 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
> ><um...@intel.com>
> >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" <cm...@apache.org> 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 <br...@apache.org>
> >> >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-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
> >--
> >E-Mail: garydgregory@gmail.com | ggregory@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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@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

Posted by "Gangumalla, Uma" <um...@intel.com>.

>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" <ga...@gmail.com> 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
><um...@intel.com>
>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" <cm...@apache.org> 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 <br...@apache.org>
>> >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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
>-- 
>E-Mail: garydgregory@gmail.com | ggregory@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


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

Re: [crypto][chimera] Next steps

Posted by "Gangumalla, Uma" <um...@intel.com>.

>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" <ga...@gmail.com> 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
><um...@intel.com>
>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" <cm...@apache.org> 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 <br...@apache.org>
>> >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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
>-- 
>E-Mail: garydgregory@gmail.com | ggregory@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

Posted by Gary Gregory <ga...@gmail.com>.

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 <um...@intel.com>
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" <cm...@apache.org> 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 <br...@apache.org>
> >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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@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

Posted by Gary Gregory <ga...@gmail.com>.

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 <um...@intel.com>
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" <cm...@apache.org> 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 <br...@apache.org>
> >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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@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

Posted by "Gangumalla, Uma" <um...@intel.com>.

>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" <cm...@apache.org> 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 <br...@apache.org>
>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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [crypto][chimera] Next steps

Posted by "Colin P. McCabe" <cm...@apache.org>.

On Mon, Feb 22, 2016 at 2:20 PM, Steve Loughran <st...@hortonworks.com> wrote:
>
>> On 22 Feb 2016, at 17:28, Colin P. McCabe <cm...@apache.org> 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.
>>
>
>
> you can't shade JNI or isolate in classloaders

That is why I suggested a two-part strategy: shading the Java parts,
and versioning the C parts.

best,
Colin


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

Re: [crypto][chimera] Next steps

Posted by Steve Loughran <st...@hortonworks.com>.

> On 22 Feb 2016, at 17:28, Colin P. McCabe <cm...@apache.org> 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.
> 


you can't shade JNI or isolate in classloaders

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

Re: [crypto][chimera] Next steps

Posted by "Gangumalla, Uma" <um...@intel.com>.

>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" <cm...@apache.org> 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 <br...@apache.org>
>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

Posted by "Xu, Cheng A" <ch...@intel.com>.

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

-----Original Message-----
From: Jochen Wiedmann [mailto:jochen.wiedmann@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 <cm...@apache.org> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

RE: [crypto][chimera] Next steps

Posted by "Xu, Cheng A" <ch...@intel.com>.

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

-----Original Message-----
From: Jochen Wiedmann [mailto:jochen.wiedmann@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 <cm...@apache.org> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [crypto][chimera] Next steps

Posted by Jochen Wiedmann <jo...@gmail.com>.

On Tue, Feb 23, 2016 at 12:14 AM, Colin P. McCabe <cm...@apache.org> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [crypto][chimera] Next steps

Posted by Jochen Wiedmann <jo...@gmail.com>.

On Tue, Feb 23, 2016 at 12:14 AM, Colin P. McCabe <cm...@apache.org> 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).

Re: [crypto][chimera] Next steps

Posted by Gary Gregory <ga...@gmail.com>.

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

Gary
On Feb 22, 2016 3:14 PM, "Colin P. McCabe" <cm...@apache.org> 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
> <jo...@gmail.com> wrote:
> > On Mon, Feb 22, 2016 at 6:28 PM, Colin P. McCabe <cm...@apache.org>
> 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: [crypto][chimera] Next steps

Posted by Gary Gregory <ga...@gmail.com>.

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

Gary
On Feb 22, 2016 3:14 PM, "Colin P. McCabe" <cm...@apache.org> 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
> <jo...@gmail.com> wrote:
> > On Mon, Feb 22, 2016 at 6:28 PM, Colin P. McCabe <cm...@apache.org>
> 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: [crypto][chimera] Next steps

Posted by "Colin P. McCabe" <cm...@apache.org>.

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
<jo...@gmail.com> wrote:
> On Mon, Feb 22, 2016 at 6:28 PM, Colin P. McCabe <cm...@apache.org> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [crypto][chimera] Next steps

Posted by "Colin P. McCabe" <cm...@apache.org>.

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
<jo...@gmail.com> wrote:
> On Mon, Feb 22, 2016 at 6:28 PM, Colin P. McCabe <cm...@apache.org> 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

Re: [crypto][chimera] Next steps

Posted by Jochen Wiedmann <jo...@gmail.com>.

On Mon, Feb 22, 2016 at 6:28 PM, Colin P. McCabe <cm...@apache.org> 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

Re: [crypto][chimera] Next steps

Posted by Jochen Wiedmann <jo...@gmail.com>.

On Mon, Feb 22, 2016 at 6:28 PM, Colin P. McCabe <cm...@apache.org> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [crypto][chimera] Next steps

Posted by "Colin P. McCabe" <cm...@apache.org>.

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 <br...@apache.org> 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

Posted by Ole Ersoy <ol...@gmail.com>.

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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

RE: [crypto][chimera] Next steps

Posted by "Xu, Cheng A" <ch...@intel.com>.

Hi Gary,
We use JNI to get to Openssl.

Ferd

-----Original Message-----
From: Gary Gregory [mailto:garydgregory@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 <ha...@intel.com>
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:garydgregory@gmail.com]
> Sent: Monday, February 22, 2016 11:36 AM
> To: Commons Developers List <de...@commons.apache.org>
> 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 <ha...@intel.com>
> 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.gangumalla@intel.com]
> > Sent: Sunday, February 21, 2016 3:07 AM
> > To: Commons Developers List <de...@commons.apache.org>
> > 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" <ga...@gmail.com> 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" <br...@apache.org> 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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@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
>



-- 
E-Mail: garydgregory@gmail.com | ggregory@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

Posted by Nick Burch <ni...@apache.org>.

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 <ha...@intel.com>
> 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:garydgregory@gmail.com]
>> Sent: Monday, February 22, 2016 11:36 AM
>> To: Commons Developers List <de...@commons.apache.org>
>> 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 <ha...@intel.com>
>> 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.gangumalla@intel.com]
>>> Sent: Sunday, February 21, 2016 3:07 AM
>>> To: Commons Developers List <de...@commons.apache.org>
>>> 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" <ga...@gmail.com> 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" <br...@apache.org> 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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@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
>>
>
>
>
>

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

Re: [crypto][chimera] Next steps

Posted by Gary Gregory <ga...@gmail.com>.

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

Gary

On Sun, Feb 21, 2016 at 10:51 PM, Chen, Haifeng <ha...@intel.com>
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:garydgregory@gmail.com]
> Sent: Monday, February 22, 2016 11:36 AM
> To: Commons Developers List <de...@commons.apache.org>
> 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 <ha...@intel.com>
> 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.gangumalla@intel.com]
> > Sent: Sunday, February 21, 2016 3:07 AM
> > To: Commons Developers List <de...@commons.apache.org>
> > 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" <ga...@gmail.com> 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" <br...@apache.org> 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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@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
>



-- 
E-Mail: garydgregory@gmail.com | ggregory@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

Posted by "Chen, Haifeng" <ha...@intel.com>.

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:garydgregory@gmail.com] 
Sent: Monday, February 22, 2016 11:36 AM
To: Commons Developers List <de...@commons.apache.org>
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 <ha...@intel.com>
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.gangumalla@intel.com]
> Sent: Sunday, February 21, 2016 3:07 AM
> To: Commons Developers List <de...@commons.apache.org>
> 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" <ga...@gmail.com> 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" <br...@apache.org> 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


--
E-Mail: garydgregory@gmail.com | ggregory@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

Posted by "Chen, Haifeng" <ha...@intel.com>.

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 <de...@commons.apache.org>
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:garydgregory@gmail.com]
Sent: Monday, February 22, 2016 11:36 AM
To: Commons Developers List <de...@commons.apache.org>
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 <ha...@intel.com>
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.gangumalla@intel.com]
> Sent: Sunday, February 21, 2016 3:07 AM
> To: Commons Developers List <de...@commons.apache.org>
> 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" <ga...@gmail.com> 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" <br...@apache.org> 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


--
E-Mail: garydgregory@gmail.com | ggregory@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

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

Re: [crypto][chimera] Next steps

Posted by Gary Gregory <ga...@gmail.com>.

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 <ha...@intel.com>
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.gangumalla@intel.com]
> Sent: Sunday, February 21, 2016 3:07 AM
> To: Commons Developers List <de...@commons.apache.org>
> 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" <ga...@gmail.com> 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" <br...@apache.org> 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@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

Posted by "Chen, Haifeng" <ha...@intel.com>.

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.gangumalla@intel.com] 
Sent: Sunday, February 21, 2016 3:07 AM
To: Commons Developers List <de...@commons.apache.org>
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" <ga...@gmail.com> 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" <br...@apache.org> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


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

Re: [crypto][chimera] Next steps

Posted by "Gangumalla, Uma" <um...@intel.com>.

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" <ga...@gmail.com> 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" <br...@apache.org> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [crypto][chimera] Next steps

Posted by Gary Gregory <ga...@gmail.com>.

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" <br...@apache.org> 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

Posted by "Colin P. McCabe" <cm...@apache.org>.

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 <br...@apache.org> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org