RE: [CRYPTO] Feedback from ApacheCON Europe

[Sun, Dapeng]

Sure. Thank Benedikt for the reminder. Here is my thoughts:

>>1) Why does Commons Crypto implement it's own Crypto API instead of providing 
>>a JCE provider?
>>If it is possible to write an adapter to JCE, I think this would be a  good 
>>improvement for 1.1. 
>>If it is not possible for technical reasons, we should document it on the 
>>website.
At first, we built an adapter for JCE, it called diceros 
(https://github.com/intel-hadoop/diceros), but we found it is not easy to 
deploy the library to a cluster with many nodes (need to modify JDK profile or 
update source code with special code). For these cases, Crypto would be the 
better solution.

>> 2) Is it possible to stub in a custom secret generator? There where 
>> concerns in the audience with regards to the hardware secret generator 
>> build into the Intel chips, because it is not clear what is happening 
>> inside that chips.
Yes, the secret generator is also designed as an interface, we can custom 
secret generator.
About what is happening inside the chips, I think this article would be 
helpful: 
https://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide



-Original Message-
From: Benedikt Ritter [mailto:brit...@apache.org] 
Sent: Wednesday, November 23, 2016 3:36 AM
To: Commons Developers List 
Subject: Re: [CRYPTO] Feedback from ApacheCON Europe

Hello Dapeng,

Sun, Dapeng  schrieb am Mo., 21. Nov. 2016 um
03:12 Uhr:

> Thank Benedikt for the minutes! And thank Xianda for the presentation.
>

Can you share your thoughts regarding the comments 1) & 2) we got from the 
audience? (see below)

Thank you!
Benedikt


>
> -Original Message-
> From: Benedikt Ritter [mailto:brit...@apache.org]
> Sent: Saturday, November 19, 2016 7:49 PM
> To: Commons Developers List 
> Subject: [CRYPTO] Feedback from ApacheCON Europe
>
> Hi,
>
> Xianda Ke held a nice presentation about Commons Crypto yesterday at 
> ApacheCON Europe in Seville. Kudos to Xianda Ke and Dapeng Sun for 
> preparing the presentation and making the long trip to Europe.
>
> Here are the comments we got from the audience:
>
> 1) Why does Commons Crypto implement it's own Crypto API instead of 
> providing a JCE provider?
> If it is possible to write an adapter to JCE, I think this would be a 
> good improvement for 1.1. If it is not possible for technical reasons, 
> we should document it on the website.
>
> 2) Is it possible to stub in a custom secret generator? There where 
> concerns in the audience with regards to the hardware secret generator 
> build into the Intel chips, because it is not clear what is happening 
> inside that chips.
> Can we extend the API in a why so that users can provide their own 
> secret generator? Does this even make sense or will that degrade the 
> performance of Crypto?
>
> Regards,
> Benedikt
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

RE: [CRYPTO] Feedback from ApacheCON Europe

[Sun, Dapeng]

Thank Benedikt for the minutes! And thank Xianda for the presentation.

-Original Message-
From: Benedikt Ritter [mailto:brit...@apache.org] 
Sent: Saturday, November 19, 2016 7:49 PM
To: Commons Developers List 
Subject: [CRYPTO] Feedback from ApacheCON Europe

Hi,

Xianda Ke held a nice presentation about Commons Crypto yesterday at ApacheCON 
Europe in Seville. Kudos to Xianda Ke and Dapeng Sun for preparing the 
presentation and making the long trip to Europe.

Here are the comments we got from the audience:

1) Why does Commons Crypto implement it's own Crypto API instead of providing a 
JCE provider?
If it is possible to write an adapter to JCE, I think this would be a good 
improvement for 1.1. If it is not possible for technical reasons, we should 
document it on the website.

2) Is it possible to stub in a custom secret generator? There where concerns in 
the audience with regards to the hardware secret generator build into the Intel 
chips, because it is not clear what is happening inside that chips.
Can we extend the API in a why so that users can provide their own secret 
generator? Does this even make sense or will that degrade the performance of 
Crypto?

Regards,
Benedikt

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

RE: [crypto] package access on ivars?

[Sun, Dapeng]

I think so. Thank Gary, I will look into it.

Regards,
Dapeng

-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com] 
Sent: Tuesday, November 8, 2016 9:34 AM
To: Commons Developers List 
Subject: Re: [crypto] package access on ivars?

There are a bunch of ivars that are at the package level. A per-class scan is 
warranted IMO.

Gary

On Mon, Nov 7, 2016 at 5:32 PM, Sun, Dapeng  wrote:

> I think it should be access level should be protected, not 
> package-protected.
>
> Is the ivars in CryptoInputStream? Some fields are also needed by its 
> subclass (not only for the classes in the package), such as 
> CtrCryptoInputStream.
>
> Regards,
> Dapeng
>
> -Original Message-
> From: Gary Gregory [mailto:garydgreg...@gmail.com]
> Sent: Tuesday, November 8, 2016 8:15 AM
> To: Commons Developers List 
> Subject: Re: [crypto] package access on ivars?
>
> On Mon, Nov 7, 2016 at 4:11 PM, sebb  wrote:
>
> > On 6 November 2016 at 19:56, Gary Gregory 
> wrote:
> > > Hi all,
> > >
> > > I see ivars left at the package access level. This must be an 
> > > oversight, right?
> > >
> > > We can only fix that in 2.0 and a new package. What a bummer!
> >
> > I'm not sure I understand.
> > Why would making package-protected fields private affect compatibility?
> >
>
> As a user, I can add a class to a [crypto] package and access the ivars.
> Then when change the access level, my code will no longer compile. If 
> we do not define BC like that due to a class living in a package it 
> really has no business being in, then I'm OK with it.
>
> Gary
>
> >
> > > Gary
> > >
> > > --
> > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java 
> > > Persistence with Hibernate, Second Edition 
> > > <https://www.amazon.com/gp/product/1617290459/ref=as_li_
> > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
> > linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a
> > 2b
> > 8>
> > >
> > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=
> > > 1&
> > > a=
> > 1617290459>
> > > JUnit in Action, Second Edition
> > > <https://www.amazon.com/gp/product/1935182021/ref=as_li_
> > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
> > linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de
> > 41
> > 8%22
> > >
> > >
> > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=
> > > 1&
> > > a=
> > 1935182021>
> > > Spring Batch in Action
> > > <https://www.amazon.com/gp/product/1935182951/ref=as_li_
> > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&
> > linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%
> > 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=
> > > 1&
> > > a=
> > 1935182951>
> > > Blog: http://garygregory.wordpress.com
> > > Home: http://garygregory.com/
> > > Tweet! http://twitter.com/GaryGregory
> >
> > 
> > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence 
> with Hibernate, Second Edition <https://www.amazon.com/gp/ 
> product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=
> 9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=
> cadb800f39946ec62ea2b1af9fe6a2b8>
>
> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1617290459>
> JUnit in Action, Second Edition
> <https://www.amazon.com/gp/product/1935182021/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
> linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de41
> 8%22
> >
>
> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1935182021>
> Spring Batch in Action
> <https://www.amazon.com/gp/product/1935182951/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&
> linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%
> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Acti

RE: [crypto] package access on ivars?

[Sun, Dapeng]

I think it should be access level should be protected, not package-protected.

Is the ivars in CryptoInputStream? Some fields are also needed by its subclass 
(not only for the classes in the package), such as CtrCryptoInputStream.

Regards,
Dapeng

-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com] 
Sent: Tuesday, November 8, 2016 8:15 AM
To: Commons Developers List 
Subject: Re: [crypto] package access on ivars?

On Mon, Nov 7, 2016 at 4:11 PM, sebb  wrote:

> On 6 November 2016 at 19:56, Gary Gregory  wrote:
> > Hi all,
> >
> > I see ivars left at the package access level. This must be an 
> > oversight, right?
> >
> > We can only fix that in 2.0 and a new package. What a bummer!
>
> I'm not sure I understand.
> Why would making package-protected fields private affect compatibility?
>

As a user, I can add a class to a [crypto] package and access the ivars.
Then when change the access level, my code will no longer compile. If we do not 
define BC like that due to a class living in a package it really has no 
business being in, then I'm OK with it.

Gary

>
> > Gary
> >
> > --
> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java 
> > Persistence with Hibernate, Second Edition 
> >  tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
> linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b
> 8>
> >
> >  > a=
> 1617290459>
> > JUnit in Action, Second Edition
> >  tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
> linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de41
> 8%22
> >
> >
> >  > a=
> 1935182021>
> > Spring Batch in Action
> >  tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&
> linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%
> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> >  > a=
> 1935182951>
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


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



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

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

RE: [crypto] package access on ivars?

[Sun, Dapeng]

Hi Gary,

>> I see ivars left at the package access level. This must be an oversight, 
>> right?
Thank you for the suggestion, I will fix it.

>> We can only fix that in 2.0 and a new package. What a bummer!
I'm agreed with you, the new package could also contain the recent fixes. Thank 
you :)

Regards,
Dapeng

-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com] 
Sent: Monday, November 7, 2016 3:56 AM
To: Commons Developers List 
Subject: [crypto] package access on ivars?

Hi all,

I see ivars left at the package access level. This must be an oversight, right?

We can only fix that in 2.0 and a new package. What a bummer!

Gary

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



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

RE: [Website] download link could not redirect consistently

[Sun, Dapeng]

Thank Benedikt for your help, and I have updated crypto/download_crypto.cgi to 
proper/commons-crypto/download_crypto.cgi as a workround.

Regards
Dapeng

-Original Message-
From: Benedikt Ritter [mailto:brit...@apache.org] 
Sent: Wednesday, August 17, 2016 3:02 AM
To: Commons Developers List
Cc: sebb AT ASF
Subject: Re: [Website] download link could not redirect consistently

Hi,

the redirects a defined in
https://svn.apache.org/repos/infra/websites/production/commons/content/.htaccess
I can't find a reason why it does not work for crypto.

Sebb do you have an idea? I think you set the redirects up initially.

Regards,
Benedikt

Sun, Dapeng  schrieb am Fr., 5. Aug. 2016 um
11:34 Uhr:

> Hello
>
> The following link cannot redirect. Anyone know the reason about it?
> https://commons.apache.org/crypto/download_crypto.cgi
> It should redirect to
> https://commons.apache.org/proper/commons-crypto/download_crypto.cgi
>
> Sites for other components could redirect. But some download_*cgi 
> redirect *.cgi, others redirect to *html.
>
> For example:
> https://commons.apache.org/codec/download_codec.cgi  -> 
> https://commons.apache.org/proper/commons-codec/download_codec.cgi
> https://commons.apache.org/net/download_net.cgi  ->
> http://commons.apache.org/proper/commons-net/download_net.html
>
>
> Regards
> Dapeng
>
>

RE: commons-crypto git commit: CRYPTO-122: Fix CRYPTO website after 1.0.0

[Sun, Dapeng]

Hi Benedikt,

Thank you for your review and suggestion, I think the commit is mainly fixing 
some typos and error links, I will also pay attention to the formatting.

Welcome back :)

Regards
Dapeng

-Original Message-
From: Benedikt Ritter [mailto:brit...@apache.org] 
Sent: Wednesday, August 17, 2016 2:33 PM
To: dev@commons.apache.org
Subject: Re: commons-crypto git commit: CRYPTO-122: Fix CRYPTO website after 
1.0.0

Hello Dapeng,

it looks like this commit contains a lot of unrelated formatting changes.
Keeping change sets small an focused makes it easier for others to review the 
changes.

Thank you!
Benedikt

 schrieb am Mi., 17. Aug. 2016 um 03:43 Uhr:

> Repository: commons-crypto
> Updated Branches:
>   refs/heads/master d94c71904 -> 3f6e54994
>
>
> CRYPTO-122: Fix CRYPTO website after 1.0.0
>
>
> Project: http://git-wip-us.apache.org/repos/asf/commons-crypto/repo
> Commit:
> http://git-wip-us.apache.org/repos/asf/commons-crypto/commit/3f6e5499
> Tree: 
> http://git-wip-us.apache.org/repos/asf/commons-crypto/tree/3f6e5499
> Diff: 
> http://git-wip-us.apache.org/repos/asf/commons-crypto/diff/3f6e5499
>
> Branch: refs/heads/master
> Commit: 3f6e549948fbb6584a21c2350e410cb834f28502
> Parents: d94c719
> Author: Sun Dapeng 
> Authored: Wed Aug 17 09:37:08 2016 +0800
> Committer: Sun Dapeng 
> Committed: Wed Aug 17 09:37:08 2016 +0800
>
> --
>  README.md  |  4 ++--
>  RELEASE-NOTES.txt  |  4 ++--
>  pom.xml|  4 ++--
>  src/site/resources/download_crypto.cgi |  2 +-
>  src/site/site.xml  |  2 +-
>  src/site/xdoc/index.xml| 10 +-
>  6 files changed, 13 insertions(+), 13 deletions(-)
> --
>
>
>
> http://git-wip-us.apache.org/repos/asf/commons-crypto/blob/3f6e5499/RE
> ADME.md
> --
> diff --git a/README.md b/README.md
> index 15b98ce..d037270 100644
> --- a/README.md
> +++ b/README.md
> @@ -58,9 +58,9 @@ Features
>  
>
>  1. Cipher API for low level cryptographic operations.
> -2. Java stream API (CryptoInputStream/CryptoOutputStream) for high 
> level stream encyrption/decryption.
> +2. Java stream API (CryptoInputStream/CryptoOutputStream) for high 
> +level
> stream encryption/decryption.
>  3. Both optimized with high performance AES encryption/decryption. 
> (1400 MB/s - 1700 MB/s throughput in modern Xeon processors).
> -4. JNI-based implementation to achieve comparable performance to the 
> native C++ version based on OpenSsl.
> +4. JNI-based implementation to achieve comparable performance to the
> native C/C++ version based on OpenSsl.
>  5. Portable across various operating systems (currently only 
> Linux/MacOSX/Windows);
> Apache Commons Crypto loads the library according to your machine 
> environment (it checks system properties, `os.name` and `os.arch`).
>  6. Simple usage. Add the commons-crypto-(version).jar file to your 
> classpath.
>
>
> http://git-wip-us.apache.org/repos/asf/commons-crypto/blob/3f6e5499/RE
> LEASE-NOTES.txt
> --
> diff --git a/RELEASE-NOTES.txt b/RELEASE-NOTES.txt index 
> f98d1c4..083898d 100644
> --- a/RELEASE-NOTES.txt
> +++ b/RELEASE-NOTES.txt
> @@ -13,9 +13,9 @@ Features
>  
>
>  1. Cipher API for low level cryptographic operations.
> -2. Java stream API (CryptoInputStream/CryptoOutputStream) for high 
> level stream encyrption/decryption.
> +2. Java stream API (CryptoInputStream/CryptoOutputStream) for high 
> +level
> stream encryption/decryption.
>  3. Both optimized with high performance AES encryption/decryption. 
> (1400 MB/s - 1700 MB/s throughput in modern Xeon processors).
> -4. JNI-based implementation to achieve comparable performance to the 
> native C++ version based on OpenSsl.
> +4. JNI-based implementation to achieve comparable performance to the
> native C/C++ version based on OpenSsl.
>  5. Portable across various operating systems (currently only 
> Linux/MacOSX/Windows);  Apache Commons Crypto loads the library 
> according to your machine environment (it checks system properties, 
> `os.name` and `os.arch`).
>  6. Simple usage. Add the commons-crypto-(version).jar file to your 
> classpath.
>
> http://git-wip-us.apache.org/repos/asf/commons-crypto/blob/3f6e5499/po
> m.xml
> --
> diff --git a/pom.xml b/pom.xml
> index e3153e9..1d5c6af 100644
> --- a/pom.xm

RE: [CRYPTO] Is there anyone can help add Crypto 1.0.0 to reporter tool

[Sun, Dapeng]

Hi Mark,

Thank you for your help :) 

Regards
Dapeng

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Wednesday, August 10, 2016 4:41 PM
To: Commons Developers List
Subject: Re: [CRYPTO] Is there anyone can help add Crypto 1.0.0 to reporter tool

On 10/08/2016 08:44, Sun, Dapeng wrote:
> Hello
> 
> Is there anyone can help add Crypto to the reporter?
> 
> https://reporter.apache.org/addrelease.html?commons
> Full version name: CRYPTO-1.0.0
> Date of release: 2016-08-09

Done.

Mark


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


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

[CRYPTO] Is there anyone can help add Crypto 1.0.0 to reporter tool

[Sun, Dapeng]

Hello

Is there anyone can help add Crypto to the reporter?

https://reporter.apache.org/addrelease.html?commons
Full version name: CRYPTO-1.0.0
Date of release: 2016-08-09


Thanks,
Dapeng

[ANNOUNCEMENT] Apache Commons Crypto 1.0.0 Released

[Sun, Dapeng]

The Apache Commons Crypto team is pleased to announce the release of Apache 
Commons Crypto 1.0.0, The release is available for download at



http://commons.apache.org/proper/commons-crypto/download_crypto.cgi



Apache Commons Crypto is a cryptographic library optimized with AES-NI 
(Advanced Encryption Standard New Instructions). It provides Java API for both 
cipher level and Java stream level. Developers can use it to implement high 
performance AES encryption/decryption with the minimum code and effort. Please 
note that Crypto doesn't implement the cryptographic algorithm such as AES 
directly. It wraps to Openssl or JCE which implement the algorithms.



Features



1. Cipher API for low level cryptographic operations.

2. Java stream API (CryptoInputStream/CryptoOutputStream) for high level stream 
encryption/decryption.

3. Both optimized with high performance AES encryption/decryption. (1400 MB/s - 
1700 MB/s throughput in modern Xeon processors).

4. JNI-based implementation to achieve comparable performance to the native 
C/C++ version based on OpenSSL.

5. Portable across various operating systems (currently only 
Linux/MacOSX/Windows);

Apache Commons Crypto loads the library according to your machine environment 
(it checks system properties, `os.name` and `os.arch`).

6. Simple usage. Add the commons-crypto-(version).jar file to your classpath.



Export restrictions

--

This distribution includes cryptographic software. The country in which you 
currently reside may have restrictions on the import, possession, use, and/or 
re-export to another country, of encryption software. BEFORE using any 
encryption software, please check your country's laws, regulations and policies 
concerning the import, possession, or use, and re-export of encryption 
software, to see if this is permitted. See  for more 
information.



The U.S. Government Department of Commerce, Bureau of Industry and Security 
(BIS), has classified this software as Export Commodity Control Number (ECCN) 
5D002.C.1, which includes information security software using or performing 
cryptographic functions with asymmetric algorithms. The form and manner of this 
Apache Software Foundation distribution makes it eligible for export under the 
License Exception ENC Technology Software Unrestricted (TSU) exception (see the 
BIS Export Administration Regulations, Section 740.13) for both object code and 
source code.



The following provides more details on the included cryptographic software:



* Commons Crypto use [Java Cryptography 
Extension](http://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html)
 provided by Java

* Commons Crypto link to and use [OpenSSL](https://www.openssl.org/) ciphers



Initial release

---

The initial release is known to build on Linux, MacOS/X and Windows (using 
MinGW).

It may build on other systems.

Please note that the JNA interface to OpenSSL is a preliminary release.

It is relatively slow, but may be of use on systems which aren't yet supported 
by the JNI code.



See the release-notes at



http://www.apache.org/dist/commons/crypto/RELEASE-NOTES.txt



for a full list of changes.



Please verify signatures using the KEYS file available at the above location 
when downloading the release.



For complete information on Apache Commons Crypto, including instructions on 
how to submit bug reports, patches, or suggestions for improvement, see the 
Apache Commons Crypto website:



http://commons.apache.org/proper/commons-crypto/



Thanks,

Dapeng, on behalf of the Apache Commons team

[Website] download link could not redirect consistently

[Sun, Dapeng]

Hello

The following link cannot redirect. Anyone know the reason about it?
https://commons.apache.org/crypto/download_crypto.cgi
It should redirect to 
https://commons.apache.org/proper/commons-crypto/download_crypto.cgi

Sites for other components could redirect. But some download_*cgi redirect 
*.cgi, others redirect to *html.

For example:
https://commons.apache.org/codec/download_codec.cgi  -> 
https://commons.apache.org/proper/commons-codec/download_codec.cgi
https://commons.apache.org/net/download_net.cgi  -> 
http://commons.apache.org/proper/commons-net/download_net.html


Regards
Dapeng

RE: [VOTE] Release CRYPTO 1.0.0 based on RC1

[Sun, Dapeng]

>> It would be neat if we could get Jenkins to do that for us!

Thank you for your suggestion, I will do some investigation about it.

-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com] 
Sent: Wednesday, August 03, 2016 10:22 AM
To: Commons Developers List 
Subject: Re: [VOTE] Release CRYPTO 1.0.0 based on RC1

On Tue, Aug 2, 2016 at 7:19 PM, Sun, Dapeng  wrote:

> Hi Gary,
>
> >>Where are the instructions to actually build the same jar contained 
> >>in
> the bin-zip with ALL of the native libraries for Windows, Mac, and Linux?
> Thank you for your comments. I will add a wiki for it.
>
> According the previous discussion, I copied the native binary files 
> complied by different platforms, and put them into target folder. Then 
> all the native files would be packaged into one jar.
>

Ah, yes, of course. Thank you for the reminder!.

It would be neat if we could get Jenkins to do that for us!

Gary


>
> -Original Message-
> From: Gary Gregory [mailto:garydgreg...@gmail.com]
> Sent: Tuesday, August 02, 2016 11:31 PM
> To: Commons Developers List 
> Subject: Re: [VOTE] Release CRYPTO 1.0.0 based on RC1
>
> I know the VOTE is closed but I wanted to note that I was able to 
> build with :
>
> Apache Maven 3.3.9
> Maven home: /usr/share/maven
> Java version: 1.8.0_91, vendor: Oracle Corporation Java home:
> /usr/lib/jvm/java-8-openjdk-i386/jre
> Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version:
> "4.4.0-28-generic", arch: "i386", family: "unix"
>
> Linux ggregory-VirtualBox 4.4.0-28-generic #47-Ubuntu SMP Fri Jun 24
> 10:08:35 UTC 2016 i686 i686 i686 GNU/Linux
>
> BUT
>
> the resulting jar only contains the ONE native libraries.
>
> Where are the instructions to actually build the same jar contained in 
> the bin-zip with ALL of the native libraries for Windows, Mac, and Linux?
>
> Gary
>
> On Mon, Jul 25, 2016 at 8:25 PM, Sun, Dapeng  wrote:
>
> > Hi all,
> >
> >
> >
> > Apache Commons CRYPTO was established at May 9, 2016, There are 
> > presently numbers of resolved issues fix in CRYPTO. We also fix the
> legal issue.
> >
> >
> >
> > Apache Commons CRYPTO 1.0.0 is available for review here:
> >
> > https://dist.apache.org/repos/dist/dev/commons/crypto
> >
> > (rev 14538)
> >
> >
> >
> > The tag is here:
> >
> >
> > https://git-wip-us.apache.org/repos/asf?p=commons-crypto.git;a=tag;h
> > =r
> > efs/tags/CRYPTO-1.0.0-RC1
> >
> > (commit 782ca06a1f9a292756fbad9eb9841e685cd34af1)
> >
> >
> >
> > Maven artifacts:
> >
> >
> >
> >
> > https://repository.apache.org/content/repositories/orgapachecommons-
> > 11 91/org/apache/commons/commons-crypto/1.0.0/
> >
> >
> >
> > I've tested with Java 7 & 8 using Maven 3.0.5 on Mac OS 64bits/Linux 
> > 64&32bits/Windows 64&32 bits
> >
> >
> >
> > Details of changes are in the release notes:
> >
> > https://dist.apache.org/repos/dist/dev/commons/crypto/RELEASE-NOTES.
> > tx
> > t
> >
> > http://home.apache.org/~sdp/crypto-1.0.0-rc1/changes-report.html
> >
> >
> >
> > Site:
> >
> >   http://home.apache.org/~sdp/crypto-1.0.0-rc1/
> >
> > (note some links are broken, these will be OK once the site is
> > deployed)
> >
> >
> >
> > Clirr Report:
> >
> > Not generating Clirr report as there is no previous version of the 
> > library to compare against.
> >
> >
> >
> > RAT Report:
> >
> >   http://home.apache.org/~sdp/crypto-1.0.0-rc1/rat-report.html
> >
> >
> >
> > KEYS:
> >
> >   https://www.apache.org/dist/commons/KEYS
> >
> >
> >
> > Please review the release candidate and vote. This vote will close 
> > no sooner than 72 hours from now, i.e. sometime after 13:00 CST 
> > 29-July
> > 2016
> >
> >
> >
> > [ ] +1 Release these artifacts
> >
> > [ ] +0 OK, but...
> >
> > [ ] -0 OK, but really should fix...
> >
> > [ ] -1 I oppose this release because...
> >
> >
> >
> > Thanks & Regards
> >
> > Dapeng
> >
> >
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence 
> with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit 
> in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>



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

RE: [VOTE] Release CRYPTO 1.0.0 based on RC1

[Sun, Dapeng]

Hi Gary,

>>Where are the instructions to actually build the same jar contained in the 
>>bin-zip with ALL of the native libraries for Windows, Mac, and Linux?
Thank you for your comments. I will add a wiki for it. 

According the previous discussion, I copied the native binary files complied by 
different platforms, and put them into target folder. Then all the native files 
would be packaged into one jar.


-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com] 
Sent: Tuesday, August 02, 2016 11:31 PM
To: Commons Developers List 
Subject: Re: [VOTE] Release CRYPTO 1.0.0 based on RC1

I know the VOTE is closed but I wanted to note that I was able to build with :

Apache Maven 3.3.9
Maven home: /usr/share/maven
Java version: 1.8.0_91, vendor: Oracle Corporation Java home: 
/usr/lib/jvm/java-8-openjdk-i386/jre
Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: 
"4.4.0-28-generic", arch: "i386", family: "unix"

Linux ggregory-VirtualBox 4.4.0-28-generic #47-Ubuntu SMP Fri Jun 24
10:08:35 UTC 2016 i686 i686 i686 GNU/Linux

BUT

the resulting jar only contains the ONE native libraries.

Where are the instructions to actually build the same jar contained in the 
bin-zip with ALL of the native libraries for Windows, Mac, and Linux?

Gary

On Mon, Jul 25, 2016 at 8:25 PM, Sun, Dapeng  wrote:

> Hi all,
>
>
>
> Apache Commons CRYPTO was established at May 9, 2016, There are 
> presently numbers of resolved issues fix in CRYPTO. We also fix the legal 
> issue.
>
>
>
> Apache Commons CRYPTO 1.0.0 is available for review here:
>
> https://dist.apache.org/repos/dist/dev/commons/crypto
>
> (rev 14538)
>
>
>
> The tag is here:
>
>
> https://git-wip-us.apache.org/repos/asf?p=commons-crypto.git;a=tag;h=r
> efs/tags/CRYPTO-1.0.0-RC1
>
> (commit 782ca06a1f9a292756fbad9eb9841e685cd34af1)
>
>
>
> Maven artifacts:
>
>
>
>
> https://repository.apache.org/content/repositories/orgapachecommons-11
> 91/org/apache/commons/commons-crypto/1.0.0/
>
>
>
> I've tested with Java 7 & 8 using Maven 3.0.5 on Mac OS 64bits/Linux 
> 64&32bits/Windows 64&32 bits
>
>
>
> Details of changes are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/crypto/RELEASE-NOTES.tx
> t
>
> http://home.apache.org/~sdp/crypto-1.0.0-rc1/changes-report.html
>
>
>
> Site:
>
>   http://home.apache.org/~sdp/crypto-1.0.0-rc1/
>
> (note some links are broken, these will be OK once the site is 
> deployed)
>
>
>
> Clirr Report:
>
> Not generating Clirr report as there is no previous version of the 
> library to compare against.
>
>
>
> RAT Report:
>
>   http://home.apache.org/~sdp/crypto-1.0.0-rc1/rat-report.html
>
>
>
> KEYS:
>
>   https://www.apache.org/dist/commons/KEYS
>
>
>
> Please review the release candidate and vote. This vote will close no 
> sooner than 72 hours from now, i.e. sometime after 13:00 CST 29-July 
> 2016
>
>
>
> [ ] +1 Release these artifacts
>
> [ ] +0 OK, but...
>
> [ ] -0 OK, but really should fix...
>
> [ ] -1 I oppose this release because...
>
>
>
> Thanks & Regards
>
> Dapeng
>
>


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

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

[RESULT] [VOTE] Release CRYPTO 1.0.0 based on RC1

[Sun, Dapeng]

This vote passed[1].(Three binding +1, three non-binding +1, no +0 or -1).

The following people voted on release CRYPTO 1.0.0:

Benedikt Ritter+1 (binding)
Jörg Schaible  +1(binding)
Hendrik Saly   +1
Marcelo Vanzin+1
Jochen Wiedmann  +1(binding)
Ke Xianda +1

Thank all for all your responses and reviewing this RC.


[1]. http://www.apache.org/foundation/voting.html#ReleaseVotes

Regards
Dapeng

-Original Message-
From: Ke, Xianda [mailto:xianda...@intel.com] 
Sent: Tuesday, August 02, 2016 9:41 AM
To: Commons Developers List
Subject: RE: [VOTE] Release CRYPTO 1.0.0 based on RC1

+1 (non-binding)
Verified locally, UT passed.

Regards,
Xianda

-Original Message-
From: Sun, Dapeng [mailto:dapeng@intel.com] 
Sent: Tuesday, July 26, 2016 11:25 AM
To: Commons Developers List
Subject: [VOTE] Release CRYPTO 1.0.0 based on RC1

Hi all,



Apache Commons CRYPTO was established at May 9, 2016, There are presently 
numbers of resolved issues fix in CRYPTO. We also fix the legal issue.



Apache Commons CRYPTO 1.0.0 is available for review here:

https://dist.apache.org/repos/dist/dev/commons/crypto

(rev 14538)



The tag is here:

https://git-wip-us.apache.org/repos/asf?p=commons-crypto.git;a=tag;h=refs/tags/CRYPTO-1.0.0-RC1

(commit 782ca06a1f9a292756fbad9eb9841e685cd34af1)



Maven artifacts:



https://repository.apache.org/content/repositories/orgapachecommons-1191/org/apache/commons/commons-crypto/1.0.0/



I've tested with Java 7 & 8 using Maven 3.0.5 on Mac OS 64bits/Linux 
64&32bits/Windows 64&32 bits



Details of changes are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/crypto/RELEASE-NOTES.txt

http://home.apache.org/~sdp/crypto-1.0.0-rc1/changes-report.html



Site:

  http://home.apache.org/~sdp/crypto-1.0.0-rc1/

(note some links are broken, these will be OK once the site is deployed)



Clirr Report:

Not generating Clirr report as there is no previous version of the library to 
compare against.



RAT Report:

  http://home.apache.org/~sdp/crypto-1.0.0-rc1/rat-report.html



KEYS:

  https://www.apache.org/dist/commons/KEYS



Please review the release candidate and vote. This vote will close no sooner 
than 72 hours from now, i.e. sometime after 13:00 CST 29-July 2016



[ ] +1 Release these artifacts

[ ] +0 OK, but...

[ ] -0 OK, but really should fix...

[ ] -1 I oppose this release because...



Thanks & Regards

Dapeng


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


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

RE: [VOTE] Release CRYPTO 1.0.0 based on RC1

[Sun, Dapeng]

Thank Jörg for the testing.

>>I am building crypto with my compiler zoo on Gentoo Linux with OpenSSL 1.02h 
>>installed.
I don't have environment with Gentoo Linux, I just tested the library with 
OpenJDK on pure Ubuntu OS: OpenJDK 7 on Ubuntu 14.04 and OpenJDK 8 on Ubuntu 
16.04, All of them are passed:

Here are the steps for the pure Ubuntu OS
1. Install essential tools
apt-get update
apt-get install openjdk-7-jdk (on 14.04)/ apt-get install openjdk-8-jdk (on 
16.04)
apt-get install make gcc g++ git

2.Install Openssl development tools
apt-get install libssl-dev

3.Set maven and JAVA_HOME

4.git clone the source code and run "mvn clean test"

Here are the version for the two environment
For Ubuntu 16.04
Java version is
openjdk version "1.8.0_91"
OpenJDK Runtime Environment (build 1.8.0_91-8u91-b14-3ubuntu1~16.04.1-b14)
OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode)

Openssl version is
OpenSSL 1.0.2g-fips  1 Mar 2016

For Ubuntu 14.04
Java version is 
java version "1.7.0_101"
OpenJDK Runtime Environment (IcedTea 2.6.6) (7u101-2.6.6-0ubuntu0.14.04.1) 
OpenJDK 64-Bit Server VM (build 24.95-b01, mixed mode)

Openssl version is
OpenSSL 1.0.1f 6 Jan 2014

Is your Openssl got from OS repo, if you compiled it yourself, do you add 
"shared" to you config args before make?

>> However, the build first fails and then hangs in a unit test when building 
>> with IBM JDK 7

About building CRYPTO on IBM JDK, I wonder if we should support it, because 
even for different minor versions of IBM JDK 7, the JNI header files may be 
changed, the change would be cause some weird failures at native. But the 
binary would be right, I have test the RC1 on latest IBM JDK 7 from their 
official website, all the tests are okay.

About the build fails, I did't encounter it before, if it is the same 
environment with openjdk, I think we can fix the Openssl shade issue first, if 
we encounter it again, we can run the pure unit tests, I uploaded them to my 
personal repo: https://github.com/sundapeng/TCRYPTO.git, could you help verify 
it in your environment?( The cached files in maven should be cleaned before 
test, for example: rm ~/.m2/repository/org/apache/commons/commons-crypto/ -rf). 

About the test hang, if the hanging UT is the test for JavaSecureRandom, it 
should be an issue about SecureRandom in JDK. 
https://bugs.openjdk.java.net/browse/JDK-6577564


Here is the IBM JDK in my environment:
java version "1.7.0"
Java(TM) SE Runtime Environment (build pxa6470_27sr3fp40-20160422_01(SR3 FP40))
IBM J9 VM (build 2.7, JRE 1.7.0 Linux amd64-64 Compressed References 
20160406_298393 (JIT enabled, AOT enabled)
J9VM - R27_Java727_SR3_20160406_0942_B298393
JIT  - tr.r13.java_20160328_114186
GC   - R27_Java727_SR3_20160406_0942_B298393_CMPRSS
J9CL - 20160406_298393)
JCL - 20160421_01 based on Oracle jdk7u101-b14


Regards
Dapeng

-Original Message-
From: Jörg Schaible [mailto:joerg.schai...@gmx.de] 
Sent: Friday, July 29, 2016 5:04 AM
To: dev@commons.apache.org
Subject: Re: [VOTE] Release CRYPTO 1.0.0 based on RC1

Hi,

I am building crypto with my compiler zoo on Gentoo Linux with OpenSSL 1.02h 
installed. Even compiling with Java 9 works, tests fail only because of a 
missing jce.

Running the tests I get always those two warnings:

 %< == Running 
org.apache.commons.crypto.NativeCodeLoaderTest
** WARN: Native (JNI) code was not loaded: java.lang.UnsatisfiedLinkError: 
/tmp/commons-crypto-9c688d6a-fc55-4a35-9d78-79cedd4ad842-libcommons-
crypto.so: /tmp/commons-crypto-9c688d6a-fc55-4a35-9d78-79cedd4ad842-
libcommons-crypto.so: failed to map segment from shared object Tests run: 5, 
Failures: 0, Errors: 0, Skipped: 3, Time elapsed: 0.008 sec - in 
org.apache.commons.crypto.NativeCodeLoaderTest
Running org.apache.commons.crypto.jna.OpenSslNativeJnaTest
** WARN: JNA could not be enabled: 
/tmp/jna--1154654109/jna4836274946397519400.tmp: 
/tmp/jna--1154654109/jna4836274946397519400.tmp: failed to map segment from 
shared object Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 
sec - in org.apache.commons.crypto.jna.OpenSslNativeJnaTest
 %< ==

The build of the shared library produces additional warnings for OpenJDK 7 (and 
OpenJDK 8 produces same warning):
 %< == [INFO] --- 
maven-antrun-plugin:1.8:run (make) @ commons-crypto --- [INFO] Executing tasks

make:
 [exec] "/home/joehni/.gentoo/java-config-2/current-user-vm/bin/javah" - 
force -classpath target/classes -o target/jni- 
classes/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.h
org.apache.commons.crypto.random.OpenSslCryptoRandomNative
 [exec] gcc -Ilib/inc_linux -I/home/joehni/.gentoo/java- 
config-2/current-user-vm/include -Ilib/inc_mac -O2 -fPIC -fvisibility=hidden
-m64 -Ilib/include -I/usr/include -
I"src/main/native/org/apache/commons/crypto/" -I"/home/joehni/.gentoo/java- 
config-2/current-user-vm/include/l

RE: [VOTE] Release CRYPTO 1.0.0 based on RC1

[Sun, Dapeng]

Thank Benedikt for the detailed report.

>>JceCipherTest.checkJceUnlimitedStrength:44 Testing requires support for an 
>>AES key length of 256, but the detected maximum key length is 128.  This may 
>>indicate that the test environment is missing the JCE Unlimited Strength 
>>Jurisdiction Policy Files.
Yes, the failure is caused by missing JCE Unlimited Strength Jurisdiction 
Policy Files. Installed JCE Unlimited Strength Jurisdiction Policy Files 
according BUILDING.txt would fix it.

>> Release notes look good. Minor nit: they don't mention the minimum required 
>> Java version.
Thank you for pointing it out. I will pay attention on next time.

Thanks,
Dapeng

-Original Message-
From: Benedikt Ritter [mailto:brit...@apache.org] 
Sent: Thursday, July 28, 2016 2:14 AM
To: Commons Developers List
Subject: Re: [VOTE] Release CRYPTO 1.0.0 based on RC1

Hello Dapeng,

first of all: Great work moving Crypto to Apache Commons and creating your 
first release candidate for the Apache Commons Project. I'm very happy to see 
this happening and I hope you and the other former Chimera developers are still 
happy with moving the code to Commons.

Here is my review of this RC:

- Release notes look good. Minor nit: they don't mention the minimum required 
Java version.
- BUILDING.txt is very descriptive, good work
- Website looks good
- signs and hashes are good

I've tried the build with:

Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T17:41:47+01:00)
Maven home: /usr/local/Cellar/maven/3.3.9/libexec
Java version: 1.7.0_79, vendor: Oracle Corporation Java home:
/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/jre
Default locale: de_DE, platform encoding: UTF-8 OS name: "mac os x", version: 
"10.11.6", arch: "x86_64", family: "mac"

I get an error:

JceCipherTest.checkJceUnlimitedStrength:44 Testing requires support for an AES 
key length of 256, but the detected maximum key length is 128.  This may 
indicate that the test environment is missing the JCE Unlimited Strength 
Jurisdiction Policy Files.

I have installed the necessary files, but it doesn't work. I suspect that 
there's something wrong with my JDK installation.

I've tried building with:

Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=128m; 
support was removed in 8.0 Apache Maven 3.3.9 
(bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T17:41:47+01:00)
Maven home: /usr/local/Cellar/maven/3.3.9/libexec
Java version: 1.8.0_91, vendor: Oracle Corporation Java home:
/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre
Default locale: de_DE, platform encoding: UTF-8 OS name: "mac os x", version: 
"10.11.6", arch: "x86_64", family: "mac"

And it works perfectly fine.

Since the build failure is probably related to my environment:

+1

Regards,
Benedikt

Sun, Dapeng  schrieb am Di., 26. Juli 2016 um
05:25 Uhr:

> Hi all,
>
>
>
> Apache Commons CRYPTO was established at May 9, 2016, There are 
> presently numbers of resolved issues fix in CRYPTO. We also fix the legal 
> issue.
>
>
>
> Apache Commons CRYPTO 1.0.0 is available for review here:
>
> https://dist.apache.org/repos/dist/dev/commons/crypto
>
> (rev 14538)
>
>
>
> The tag is here:
>
>
> https://git-wip-us.apache.org/repos/asf?p=commons-crypto.git;a=tag;h=r
> efs/tags/CRYPTO-1.0.0-RC1
>
> (commit 782ca06a1f9a292756fbad9eb9841e685cd34af1)
>
>
>
> Maven artifacts:
>
>
>
>
> https://repository.apache.org/content/repositories/orgapachecommons-11
> 91/org/apache/commons/commons-crypto/1.0.0/
>
>
>
> I've tested with Java 7 & 8 using Maven 3.0.5 on Mac OS 64bits/Linux 
> 64&32bits/Windows 64&32 bits
>
>
>
> Details of changes are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/crypto/RELEASE-NOTES.tx
> t
>
> http://home.apache.org/~sdp/crypto-1.0.0-rc1/changes-report.html
>
>
>
> Site:
>
>   http://home.apache.org/~sdp/crypto-1.0.0-rc1/
>
> (note some links are broken, these will be OK once the site is 
> deployed)
>
>
>
> Clirr Report:
>
> Not generating Clirr report as there is no previous version of the 
> library to compare against.
>
>
>
> RAT Report:
>
>   http://home.apache.org/~sdp/crypto-1.0.0-rc1/rat-report.html
>
>
>
> KEYS:
>
>   https://www.apache.org/dist/commons/KEYS
>
>
>
> Please review the release candidate and vote. This vote will close no 
> sooner than 72 hours from now, i.e. sometime after 13:00 CST 29-July 
> 2016
>
>
>
> [ ] +1 Release these artifacts
>
> [ ] +0 OK, but...
>
> [ ] -0 OK, but really should fix...
>
> [ ] -1 I oppose this release because...
>
>
>
> Thanks & Regards
>
> Dapeng
>
>

[VOTE] Release CRYPTO 1.0.0 based on RC1

[Sun, Dapeng]

Hi all,



Apache Commons CRYPTO was established at May 9, 2016, There are presently 
numbers of resolved issues fix in CRYPTO. We also fix the legal issue.



Apache Commons CRYPTO 1.0.0 is available for review here:

https://dist.apache.org/repos/dist/dev/commons/crypto

(rev 14538)



The tag is here:

https://git-wip-us.apache.org/repos/asf?p=commons-crypto.git;a=tag;h=refs/tags/CRYPTO-1.0.0-RC1

(commit 782ca06a1f9a292756fbad9eb9841e685cd34af1)



Maven artifacts:



https://repository.apache.org/content/repositories/orgapachecommons-1191/org/apache/commons/commons-crypto/1.0.0/



I've tested with Java 7 & 8 using Maven 3.0.5 on Mac OS 64bits/Linux 
64&32bits/Windows 64&32 bits



Details of changes are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/crypto/RELEASE-NOTES.txt

http://home.apache.org/~sdp/crypto-1.0.0-rc1/changes-report.html



Site:

  http://home.apache.org/~sdp/crypto-1.0.0-rc1/

(note some links are broken, these will be OK once the site is deployed)



Clirr Report:

Not generating Clirr report as there is no previous version of the library to 
compare against.



RAT Report:

  http://home.apache.org/~sdp/crypto-1.0.0-rc1/rat-report.html



KEYS:

  https://www.apache.org/dist/commons/KEYS



Please review the release candidate and vote. This vote will close no sooner 
than 72 hours from now, i.e. sometime after 13:00 CST 29-July 2016



[ ] +1 Release these artifacts

[ ] +0 OK, but...

[ ] -0 OK, but really should fix...

[ ] -1 I oppose this release because...



Thanks & Regards

Dapeng

RE: [CRYPTO]1.0.0 Release Plan

[Sun, Dapeng]

Hi all,

I want to kick off the process of the first release on July 25th (next Monday) 
, please let me know if you have any concerns.

And here is the latest binary.(contains Linux/Mac/Windows)
https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-crypto/1.0.0-SNAPSHOT/commons-crypto-1.0.0-20160722.085755-6.jar

Thanks & Regards
Dapeng

-Original Message-
From: Sun, Dapeng [mailto:dapeng@intel.com] 
Sent: Tuesday, July 19, 2016 6:48 PM
To: Commons Developers List
Subject: RE: [CRYPTO]1.0.0 Release Plan

Thank Dennis for your suggestion, but it seems maven and apache site don't 
provide the feature. And the native files are all small size, putting them into 
one jar would be okay.

Regards
Dapeng

-Original Message-
From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org]
Sent: Thursday, July 14, 2016 11:18 PM
To: 'Commons Developers List'
Subject: RE: [CRYPTO]1.0.0 Release Plan

I don't know if the deployment method for the binaries (.jar, etc.) of these 
releases provides useful download statistics for the Commons project.

If it does, differentiating by the native platforms for which there are native 
shared-libraries that need to also be on the runtime path (e.g., to work with 
JNI) is important.  You will have some evidence for what your users intend to 
run the related classes on.

That might be important to know if you are considering a triage with respect to 
native support.

 - Dennis

> -Original Message-
> From: sebb [mailto:seb...@gmail.com]
> Sent: Tuesday, July 12, 2016 09:09
> To: Commons Developers List 
> Subject: Re: [CRYPTO]1.0.0 Release Plan
> 
> On 12 July 2016 at 14:54, sebb  wrote:
> > On 12 July 2016 at 14:20, Sun, Dapeng  wrote:
> >> Separating artifacts for each native library, I think it should be
> same as copying the native binary files. We also need to collect the 
> artifacts for unpacking and bundling.
> >
> > Yes.
> >
> >> About using the 'all' artifact, users may be confused about
> downloading the artifacts for all the different platforms, especially 
> for the platforms they don't need.
> >
> > I think we could have a separate project that creates a jar 
> > containing the Java classes plus all released native builds.
> >
> > AIUI the code can automatically extract the native code from the 
> > jar, so it should be easy to use.
> >
> > If we also release the Java classes and native builds as separate 
> > jars, then users would have the choice:
> >
> > - download the jar containing the Java classes plus all released
> native builds
> > - download the Java classes jar plus any native builds they need
> >
> > Or maybe when releasing a native build, we could package it with the 
> > Java classes.
> 
> It looks like that already happens - the MacOSX installed jar includes 
> the jnilib file.
> 
[  ]


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

B CB  [  
X  ܚX KK[XZ[
 ] ][  X  ܚX P  [[ۜ˘\X K ܙ B  ܈Y][ۘ[  [X[  K[XZ[
 ] Z[  [[ۜ˘\X K ܙ B

RE: [CRYPTO]1.0.0 Release Plan

[Sun, Dapeng]

Thank Dennis for your suggestion, but it seems maven and apache site don't 
provide the feature. And the native files are all small size, putting them into 
one jar would be okay.

Regards
Dapeng

-Original Message-
From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] 
Sent: Thursday, July 14, 2016 11:18 PM
To: 'Commons Developers List'
Subject: RE: [CRYPTO]1.0.0 Release Plan

I don't know if the deployment method for the binaries (.jar, etc.) of these 
releases provides useful download statistics for the Commons project.

If it does, differentiating by the native platforms for which there are native 
shared-libraries that need to also be on the runtime path (e.g., to work with 
JNI) is important.  You will have some evidence for what your users intend to 
run the related classes on.

That might be important to know if you are considering a triage with respect to 
native support.

 - Dennis

> -Original Message-
> From: sebb [mailto:seb...@gmail.com]
> Sent: Tuesday, July 12, 2016 09:09
> To: Commons Developers List 
> Subject: Re: [CRYPTO]1.0.0 Release Plan
> 
> On 12 July 2016 at 14:54, sebb  wrote:
> > On 12 July 2016 at 14:20, Sun, Dapeng  wrote:
> >> Separating artifacts for each native library, I think it should be
> same as copying the native binary files. We also need to collect the 
> artifacts for unpacking and bundling.
> >
> > Yes.
> >
> >> About using the 'all' artifact, users may be confused about
> downloading the artifacts for all the different platforms, especially 
> for the platforms they don't need.
> >
> > I think we could have a separate project that creates a jar 
> > containing the Java classes plus all released native builds.
> >
> > AIUI the code can automatically extract the native code from the 
> > jar, so it should be easy to use.
> >
> > If we also release the Java classes and native builds as separate 
> > jars, then users would have the choice:
> >
> > - download the jar containing the Java classes plus all released
> native builds
> > - download the Java classes jar plus any native builds they need
> >
> > Or maybe when releasing a native build, we could package it with the 
> > Java classes.
> 
> It looks like that already happens - the MacOSX installed jar includes 
> the jnilib file.
> 
[  ]


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

RE: [CRYPTO]1.0.0 Release Plan

[Sun, Dapeng]

Copy the native files from other platforms to target is worked. I also uploaded 
a SNAPSHOT version contains native of Linux and Mac. If there is no concerns, I 
will try to add windows and kick off the first release.

https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-crypto/1.0.0-SNAPSHOT/commons-crypto-1.0.0-20160713.032556-2.jar


Regards
Dapeng

-Original Message-
From: sebb [mailto:seb...@gmail.com] 
Sent: Wednesday, July 13, 2016 12:09 AM
To: Commons Developers List
Subject: Re: [CRYPTO]1.0.0 Release Plan

On 12 July 2016 at 14:54, sebb  wrote:
> On 12 July 2016 at 14:20, Sun, Dapeng  wrote:
>> Separating artifacts for each native library, I think it should be same as 
>> copying the native binary files. We also need to collect the artifacts for 
>> unpacking and bundling.
>
> Yes.
>
>> About using the 'all' artifact, users may be confused about downloading the 
>> artifacts for all the different platforms, especially for the platforms they 
>> don't need.
>
> I think we could have a separate project that creates a jar containing 
> the Java classes plus all released native builds.
>
> AIUI the code can automatically extract the native code from the jar, 
> so it should be easy to use.
>
> If we also release the Java classes and native builds as separate 
> jars, then users would have the choice:
>
> - download the jar containing the Java classes plus all released 
> native builds
> - download the Java classes jar plus any native builds they need
>
> Or maybe when releasing a native build, we could package it with the 
> Java classes.

It looks like that already happens - the MacOSX installed jar includes the 
jnilib file.

> That would give users a different choice:
> - download the specific build for their system; this would work as is
> - download the combined build for all released native targets
>
>> -Original Message-
>> From: Marcelo Vanzin [mailto:van...@cloudera.com]
>> Sent: Tuesday, July 12, 2016 2:09 AM
>> To: Commons Developers List 
>> Subject: Re: [CRYPTO]1.0.0 Release Plan
>>
>> On Mon, Jul 11, 2016 at 2:34 AM, sebb  wrote:
>>> However bundling multiple native binaries is going to make it tricky to 
>>> release.
>>> How will it be done? The native parts will have to be built 
>>> separately and then combined somehow.
>>
>> The way I'd do it is to have separate artifacts for each native library, and 
>> then a final job that merges all those into a final "commons-crypto-all" 
>> artifact containing all the native libraries.
>> That would mean a single artifact ultimately deployed as part of a 
>> commons-crypto release, but I don't know how easy it is to pull that off as 
>> far as build infrastructure goes.
>>
>> Another option is to actually deploy each native artifact separately, and 
>> have the "all" artifact be just a dummy artifact that depends on all the 
>> others; so no jar merging or anything. That might be easier.
>> Maybe.
>>
>> --
>> Marcelo
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>

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

RE: [CRYPTO]1.0.0 Release Plan

[Sun, Dapeng]

Separating artifacts for each native library, I think it should be same as 
copying the native binary files. We also need to collect the artifacts for 
unpacking and bundling.

About using the 'all' artifact, users may be confused about downloading the 
artifacts for all the different platforms, especially for the platforms they 
don't need.

-Original Message-
From: Marcelo Vanzin [mailto:van...@cloudera.com] 
Sent: Tuesday, July 12, 2016 2:09 AM
To: Commons Developers List 
Subject: Re: [CRYPTO]1.0.0 Release Plan

On Mon, Jul 11, 2016 at 2:34 AM, sebb  wrote:
> However bundling multiple native binaries is going to make it tricky to 
> release.
> How will it be done? The native parts will have to be built separately 
> and then combined somehow.

The way I'd do it is to have separate artifacts for each native library, and 
then a final job that merges all those into a final "commons-crypto-all" 
artifact containing all the native libraries.
That would mean a single artifact ultimately deployed as part of a 
commons-crypto release, but I don't know how easy it is to pull that off as far 
as build infrastructure goes.

Another option is to actually deploy each native artifact separately, and have 
the "all" artifact be just a dummy artifact that depends on all the others; so 
no jar merging or anything. That might be easier.
Maybe.

--
Marcelo

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

RE: [CRYPTO]1.0.0 Release Plan

[Sun, Dapeng]

I think we can copy the native binary files complied by different platforms, 
and put them into target folder. Then all the native files would be packaged 
into one jar.

Okay, I will build a SNAPSHOT contains Linux and Mac.

Regards
Dapeng


-Original Message-
From: sebb [mailto:seb...@gmail.com] 
Sent: Monday, July 11, 2016 5:35 PM
To: Commons Developers List 
Subject: Re: [CRYPTO]1.0.0 Release Plan

On 11 July 2016 at 09:02, Sun, Dapeng  wrote:
> About the native binaries, I think we should put them in the same jar 
> finally. CRYPTO is library, user shouldn't need to specify Platform in 
> theory. I just checked the jars of JNA and SNAPPY at maven, the jar contains 
> native for all the platform their support. For the first release of CRYPTO, I 
> think we'd better to add Linux_x86, Linux_x86_64 and MAC_x86_64 at least.

Also Windows, now that it is working OK.

However bundling multiple native binaries is going to make it tricky to release.
How will it be done? The native parts will have to be built separately and then 
combined somehow.

Maybe try creating a snapshot release with just  Linux and Mac and see how that 
pans out.


> About eclipse, I think it is different from CRYPTO, each eclipse's binary 
> file is platform specify and the binary file is not in small size...
>
> Regards
> Dapeng
>
> -Original Message-
> From: sebb [mailto:seb...@gmail.com]
> Sent: Saturday, July 09, 2016 2:19 AM
> To: Commons Developers List
> Subject: Re: [CRYPTO]1.0.0 Release Plan
>
> On 8 July 2016 at 18:56, Gary Gregory  wrote:
>> On Fri, Jul 8, 2016 at 10:46 AM, Bhowmik, Bindul 
>> 
>> wrote:
>>
>>> On Fri, Jul 8, 2016 at 11:37 AM, sebb  wrote:
>>> > On 8 July 2016 at 18:31, Gary Gregory  wrote:
>>> >> On Fri, Jul 8, 2016 at 10:07 AM, Marcelo Vanzin 
>>> >> 
>>> wrote:
>>> >>
>>> >>> Answering based on old knowledge of this code, but I don't 
>>> >>> believe it has changed...
>>> >>>
>>> >>> On Fri, Jul 8, 2016 at 9:36 AM, Gary Gregory 
>>> >>> 
>>> >>> wrote:
>>> >>> > The delivered jar file contains a native .so file, and this 
>>> >>> > .so file
>>> is
>>> >>> > _extracted_ and _installed_ on the user's machine at runtime?
>>> >>> > See NativeCodeLoader.extractLibraryFile().
>>> >>>
>>> >>> It's not really installed, but copied to a temp location. There 
>>> >>> might be flags to configure a permanent location (which would 
>>> >>> bypass this code that finds the library inside the jar), but I 
>>> >>> don't remember if that was added to crypto.
>>> >>>
>>> >>> This feature is borrowed from Snappy's java bindings, and is 
>>> >>> pretty helpful on distributed applications where a "launcher" 
>>> >>> app starts processes on a whole bunch of different machines (and 
>>> >>> needs these libraries).
>>> >>>
>>> >>> > Does this mean that the jar will contain all possible native 
>>> >>> > formats
>>> >>> (.so,
>>> >>> > .dll, what about 32 vs. 64 bit, or are we only dealing with 64
>>> >>> > bit?)
>>> and
>>> >>> > extract the right one at runtime for the current platform?
>>> >>> > Seems
>>> wasteful
>>> >>> > in space but portable and clever.
>>>
>>> One option could be to go the Eclipse way, the way they handle SWT 
>>> distributions which have native components[1]. Thinking more about 
>>> it, that might even be a better option given that the different 
>>> binary components may need to be built on different OSes.
>>>
>>> And from a consumption standpoint, if the user is using Maven, they 
>>> could use profiles to select the correct dependency. I have done 
>>> something like this for SWT on a project:
>>>
>>> 
>>> org.eclipse.swt
>>> ${swt.artifact}
>>> ${eclipse.swt.version}
>>> compile
>>> 
>>>
>>> 
>>> win64_x8664
>>> 
>>> 
>>> windows
>>> x86_64
>>> 
>>> 
>>> 
>>> swt-win32-win32-x86_64
>>> 
>>> 
>>> 
>>> linux64_x8664
>>> 
>>> 

RE: [CRYPTO]1.0.0 Release Plan

[Sun, Dapeng]

About the native binaries, I think we should put them in the same jar finally. 
CRYPTO is library, user shouldn't need to specify Platform in theory. I just 
checked the jars of JNA and SNAPPY at maven, the jar contains native for all 
the platform their support. For the first release of CRYPTO, I think we'd 
better to add Linux_x86, Linux_x86_64 and MAC_x86_64 at least.

About eclipse, I think it is different from CRYPTO, each eclipse's binary file 
is platform specify and the binary file is not in small size...

Regards
Dapeng

-Original Message-
From: sebb [mailto:seb...@gmail.com] 
Sent: Saturday, July 09, 2016 2:19 AM
To: Commons Developers List
Subject: Re: [CRYPTO]1.0.0 Release Plan

On 8 July 2016 at 18:56, Gary Gregory  wrote:
> On Fri, Jul 8, 2016 at 10:46 AM, Bhowmik, Bindul 
> 
> wrote:
>
>> On Fri, Jul 8, 2016 at 11:37 AM, sebb  wrote:
>> > On 8 July 2016 at 18:31, Gary Gregory  wrote:
>> >> On Fri, Jul 8, 2016 at 10:07 AM, Marcelo Vanzin 
>> >> 
>> wrote:
>> >>
>> >>> Answering based on old knowledge of this code, but I don't 
>> >>> believe it has changed...
>> >>>
>> >>> On Fri, Jul 8, 2016 at 9:36 AM, Gary Gregory 
>> >>> 
>> >>> wrote:
>> >>> > The delivered jar file contains a native .so file, and this .so 
>> >>> > file
>> is
>> >>> > _extracted_ and _installed_ on the user's machine at runtime? 
>> >>> > See NativeCodeLoader.extractLibraryFile().
>> >>>
>> >>> It's not really installed, but copied to a temp location. There 
>> >>> might be flags to configure a permanent location (which would 
>> >>> bypass this code that finds the library inside the jar), but I 
>> >>> don't remember if that was added to crypto.
>> >>>
>> >>> This feature is borrowed from Snappy's java bindings, and is 
>> >>> pretty helpful on distributed applications where a "launcher" app 
>> >>> starts processes on a whole bunch of different machines (and 
>> >>> needs these libraries).
>> >>>
>> >>> > Does this mean that the jar will contain all possible native 
>> >>> > formats
>> >>> (.so,
>> >>> > .dll, what about 32 vs. 64 bit, or are we only dealing with 64 
>> >>> > bit?)
>> and
>> >>> > extract the right one at runtime for the current platform? 
>> >>> > Seems
>> wasteful
>> >>> > in space but portable and clever.
>>
>> One option could be to go the Eclipse way, the way they handle SWT 
>> distributions which have native components[1]. Thinking more about 
>> it, that might even be a better option given that the different 
>> binary components may need to be built on different OSes.
>>
>> And from a consumption standpoint, if the user is using Maven, they 
>> could use profiles to select the correct dependency. I have done 
>> something like this for SWT on a project:
>>
>> 
>> org.eclipse.swt
>> ${swt.artifact}
>> ${eclipse.swt.version}
>> compile
>> 
>>
>> 
>> win64_x8664
>> 
>> 
>> windows
>> x86_64
>> 
>> 
>> 
>> swt-win32-win32-x86_64
>> 
>> 
>> 
>> linux64_x8664
>> 
>> 
>> unix
>> x86_64
>> 
>> 
>> 
>> swt-gtk-linux-x86_64
>> 
>> 
>>
>>
> Yeah, that seems like a more normal way to go.
>
> We've been making changes for 1.0 for a little while now (not _that_ 
> long) but this would be a big change because the Maven coordinate business.
>
> Let's see what the rest if the community thinks.
>
> I am concerned as I've already stated as to what the current scheme 
> means went Windows DLL support is done. It does not seem OK to include 
> >1 native library in the jar.

Another possibility for the first release is to avoid the problem entirely, by 
only releasing source.

AIUI many Linux distros rebuild from source anyway.

We would need to ensure that the build instructions are clear, and that the 
code produced a sensible error message if the JNI code is not found.
This could include a URL to the latest build instructions/FAQ (like Maven does).

But longer term it might be better to release the JNI binaries separately from 
the Java binaries.
This would allow new OSes to be added without having to re-release everything.

> Gary
>
>
>> - Bindul
>>
>> [1]
>> http://download.eclipse.org/eclipse/downloads/drops4/R-4.6-2016060611
>> 00/#SWT
>>
>> >>>
>> >>> That's the goal if multiple OSes are to be supported; I'm not 
>> >>> sure how easy it would be to achieve with the current build 
>> >>> system available (haven't really looked into it), but I have 
>> >>> ideas of how to hack something like that in maven (using a few 
>> >>> separate jobs per OS + a final job to collect everything).
>> >>>
>> >>> I've heard comments here about using JNA, so maybe this whole 
>> >>> discussion will eventually become moot?
>> >>>
>> >>
>> >> The JNA code is in place, it's just much slower than the JNI path.
>> >
>> > Have you managed to get it going on Windows?
>> >
>> > So far I have failed.
>> > It's tricky getting JNA to find the crypto DLL, and then it hangs 
>> > 

RE: [CRYPTO]1.0.0 Release Plan

[Sun, Dapeng]

Hi all,

Please let me know if there is any blocks need to be resolved before the 
release.

Regards
Dapeng

-Original Message-
From: sebb [mailto:seb...@gmail.com] 
Sent: Tuesday, June 28, 2016 6:48 PM
To: Commons Developers List
Subject: Re: [CRYPTO]1.0.0 Release Plan

On 28 June 2016 at 07:03, Sun, Dapeng  wrote:
> Thank Sebb for your great work!
>
> About the Properties instance, I have some personal opinions.
>
> I think properties provide a flexible configuration mechanism. Config values 
> could be added and read/written without too much limitation, we also provides 
> default values for each properties, user don't need set value for every 
> properties. They could also give null, if they want to use the default 
> settings.

Agreed they are flexible.

>>> also the way that classes are instantiated is very awkward, as properties 
>>> are not as easy to use as plain variables - String/boolean etc and 
>>> properties don't offer any type validation.
>
> Properties don't offer any type validation, but we can validate the type and 
> value before we using them. For example, stream buffer size, when 
> CryptoStream is creating, it will read the value and convert it to int.
>
>>> Since properties are used in the constructors, it's not enough for 3rd 
>>> parties to just implement the CryptoRandom interface - they also have to 
>>> provide a constructor which takes a Properties instance.
>
> For 3rd parties implementations, they may need to read some configuration 
> when initializing, properties will provide this ability at this time. 
> Otherwise, they need to handle the work such as reading config file, read 
> config value ant etc. For the 3rd parties implementations which don't need 
> the properties, they can leave it null or ignore.
>
> If you have a better configuration mechanism, could you tell me more detail?

On further reflection, I think it's not going to make the API any easier for 
the general case where implementation-specific values are needed.

However, we could perhaps add a convenience method for the case where only the 
classname(s) are needed.
 e.g. add  new methods as below:

CryptoRandom getCryptoRandom(String classids) and CryptoCipher 
getInstance(String transformation, String classids)

These would each create a Property instance and call the existing getInstance 
method

This would not save a lot of code, but it would be simpler for the OpenSSL 
implementations at least.

> Regards
> Dapeng
>
> -Original Message-
> From: sebb [mailto:seb...@gmail.com]
> Sent: Sunday, June 26, 2016 7:53 AM
> To: Commons Developers List
> Subject: Re: [CRYPTO]1.0.0 Release Plan
>
> On 24 June 2016 at 11:17, sebb  wrote:
>> On 24 June 2016 at 10:08, Sun, Dapeng  wrote:
>>> Hi all,
>>>
>>> Thank all for helping review CRYPTO from different angles.
>>>
>>> According the number of jira remaining issues, I prefer to start the thread 
>>> for rolling a RC at June 29th(Next Wednesday). Please feel free to let me 
>>> know if you have any concern about it.
>>
>> Yes, I do have some concerns.
>>
>> I think the public API needs to be better documented.
>> There are still a lot of public classes that AFAICT don't really 
>> belong in the API.
>> For example
>> JceCipher
>> OpensslCipher
>> JavaCryptoRandom
>> OpensslCryptoRandom
>> OsCryptoRandom
>> These need to be made private/package protected or moved into an 
>> internal package, or at the very least clearly documented as internal.
>
> I have made them package private.
>
>> Also the way that classes are instantiated is very awkward, as 
>> properties are not as easy to use as plain variables - String/boolean 
>> etc - and properties don't offer any type validation.
>> Since properties are used in the constructors, it's not enough for 
>> 3rd parties to just implement the CryptoRandom interface - they also 
>> have to provide a constructor which takes a Properties instance.
>
> This is still an issue.
>
>> Indeed I wonder why there is a CryptoRandom interface - would it not 
>> be better for JavaCryptoRandom to extend java.util.Random? The other 
>> implementations of CryptoRandom do.
>> Or maybe none of them should extend j.u.Random?
>
> Likewise, this ought to be resolved.
>
>>> Regards
>>> Dapeng
>>>
>>> -Original Message-
>>> From: Sun, Dapeng [mailto:dapeng@intel.com]
>>> Sent: Monday, June 06, 2016 5:14 PM
>>> To: Commons Developers List
>>> Subject: [CRYPTO]1.0.0 Release Plan
>>>
>>> Hello,
>>&g

RE: [crypto] Camel case for names

[Sun, Dapeng]

+1 for keeping them consistent.

I prefer "OpenSslCipher"

Regards
Dapeng

-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com] 
Sent: Thursday, June 30, 2016 9:35 AM
To: Commons Developers List
Subject: Re: [crypto] Camel case for names

On Wed, Jun 29, 2016 at 5:33 PM, sebb  wrote:

> The product is called OpenSSL, so perhaps it should be OpenSSLcipher
>

Even worse from my POV due to the lower case "c" in cipher. At work, we do 
camel case even for acronyms to avoid W3CXMLSAXThingy and get W3cXmlSaxThingy 
for example.

I vote for OpenSslCipher (or OpenSLLCipher).

Right now we have inconsistencies. We have JceCipher but then we have OSInfo 
(vs. OsInfo) and OsCryptoRandom. Then there is CTRCryptoInputStream which could 
be CtrCryptoInputStream. Also IOUtils.

I'd think some consistency would be nice.

Gary

>
> On 30 June 2016 at 01:17, Gary Gregory  wrote:
> > It seems to me that OpensslCipher should be called OpenSslCipher
> >
> > Gary
> >
> > --
> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java 
> > Persistence with Hibernate, Second Edition 
> >  JUnit in Action, Second Edition 
> > 
> > Spring Batch in Action 
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


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

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

RE: [CRYPTO]1.0.0 Release Plan

[Sun, Dapeng]

Thank Sebb for your great work!

About the Properties instance, I have some personal opinions.

I think properties provide a flexible configuration mechanism. Config values 
could be added and read/written without too much limitation, we also provides 
default values for each properties, user don't need set value for every 
properties. They could also give null, if they want to use the default settings.

>> also the way that classes are instantiated is very awkward, as properties 
>> are not as easy to use as plain variables - String/boolean etc and 
>> properties don't offer any type validation.

Properties don't offer any type validation, but we can validate the type and 
value before we using them. For example, stream buffer size, when CryptoStream 
is creating, it will read the value and convert it to int.

>> Since properties are used in the constructors, it's not enough for 3rd 
>> parties to just implement the CryptoRandom interface - they also have to 
>> provide a constructor which takes a Properties instance.

For 3rd parties implementations, they may need to read some configuration when 
initializing, properties will provide this ability at this time. Otherwise, 
they need to handle the work such as reading config file, read config value ant 
etc. For the 3rd parties implementations which don't need the properties, they 
can leave it null or ignore.

If you have a better configuration mechanism, could you tell me more detail?

Regards
Dapeng

-Original Message-
From: sebb [mailto:seb...@gmail.com] 
Sent: Sunday, June 26, 2016 7:53 AM
To: Commons Developers List
Subject: Re: [CRYPTO]1.0.0 Release Plan

On 24 June 2016 at 11:17, sebb  wrote:
> On 24 June 2016 at 10:08, Sun, Dapeng  wrote:
>> Hi all,
>>
>> Thank all for helping review CRYPTO from different angles.
>>
>> According the number of jira remaining issues, I prefer to start the thread 
>> for rolling a RC at June 29th(Next Wednesday). Please feel free to let me 
>> know if you have any concern about it.
>
> Yes, I do have some concerns.
>
> I think the public API needs to be better documented.
> There are still a lot of public classes that AFAICT don't really 
> belong in the API.
> For example
> JceCipher
> OpensslCipher
> JavaCryptoRandom
> OpensslCryptoRandom
> OsCryptoRandom
> These need to be made private/package protected or moved into an 
> internal package, or at the very least clearly documented as internal.

I have made them package private.

> Also the way that classes are instantiated is very awkward, as 
> properties are not as easy to use as plain variables - String/boolean 
> etc - and properties don't offer any type validation.
> Since properties are used in the constructors, it's not enough for 3rd 
> parties to just implement the CryptoRandom interface - they also have 
> to provide a constructor which takes a Properties instance.

This is still an issue.

> Indeed I wonder why there is a CryptoRandom interface - would it not 
> be better for JavaCryptoRandom to extend java.util.Random? The other 
> implementations of CryptoRandom do.
> Or maybe none of them should extend j.u.Random?

Likewise, this ought to be resolved.

>> Regards
>> Dapeng
>>
>> -Original Message-
>> From: Sun, Dapeng [mailto:dapeng@intel.com]
>> Sent: Monday, June 06, 2016 5:14 PM
>> To: Commons Developers List
>> Subject: [CRYPTO]1.0.0 Release Plan
>>
>> Hello,
>>
>> Apache Commons CRYPTO was established at May 9, 2016[1], There are presently 
>> numbers of resolved issues fix in CRYPTO[2]. Recently, we also fixed the 
>> legal issue[3].
>>
>> With the first release, we can begin to promote CRYPTO to other Apache 
>> components, like Apache Hadoop, Apache Spark, so that they can benefit the 
>> higher performance improvement from Apache Commons Crypto.
>>
>> We plan the following three opening features to next release(I think it 
>> should be 1.1.0): GCM support[4], JNACipher implementation[5] and benchmark 
>> tool[6]. Please let me know if there is anything need to be done before the 
>> release.
>>
>>
>> Regards
>> Dapeng
>>
>>
>> [1] 
>> http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3CC
>> AB917RJkcNYL4KeRJTo%3D5F7P3A4iyME0TA40GNmuU4RLs5N4KQ%40mail.gmail.com
>> %3E [2] 
>> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&p
>> id=12310464&sorter/field=issuekey&sorter/order=DESC&status=5&status=6
>> [3] 
>> http://mail-archives.apache.org/mod_mbox/commons-dev/201606.mbox/%3CC
>> ACZkXP

RE: [CRYPTO]1.0.0 Release Plan

[Sun, Dapeng]

Hi all,

Thank all for helping review CRYPTO from different angles.

According the number of jira remaining issues, I prefer to start the thread for 
rolling a RC at June 29th(Next Wednesday). Please feel free to let me know if 
you have any concern about it.

Regards
Dapeng

-Original Message-
From: Sun, Dapeng [mailto:dapeng@intel.com] 
Sent: Monday, June 06, 2016 5:14 PM
To: Commons Developers List
Subject: [CRYPTO]1.0.0 Release Plan

Hello,

Apache Commons CRYPTO was established at May 9, 2016[1], There are presently 
numbers of resolved issues fix in CRYPTO[2]. Recently, we also fixed the legal 
issue[3].

With the first release, we can begin to promote CRYPTO to other Apache 
components, like Apache Hadoop, Apache Spark, so that they can benefit the 
higher performance improvement from Apache Commons Crypto.

We plan the following three opening features to next release(I think it should 
be 1.1.0): GCM support[4], JNACipher implementation[5] and benchmark tool[6]. 
Please let me know if there is anything need to be done before the release.


Regards
Dapeng


[1] 
http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3CCAB917RJkcNYL4KeRJTo%3D5F7P3A4iyME0TA40GNmuU4RLs5N4KQ%40mail.gmail.com%3E
[2] 
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310464&sorter/field=issuekey&sorter/order=DESC&status=5&status=6
[3] 
http://mail-archives.apache.org/mod_mbox/commons-dev/201606.mbox/%3CCACZkXPyrYvY8NMyQLnT6qMDpNxWiDUudoEw%2BDe%2BYBDHoBBhCzQ%40mail.gmail.com%3E
[4] https://github.com/apache/commons-crypto/pull/44
[5] https://github.com/apache/commons-crypto/pull/47
[6] https://github.com/apache/commons-crypto/pull/1


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

RE: [crypto] Logging dependency

[Sun, Dapeng]

>>Do I understand correctly that Crypto should fall back to JCE if native code 
>>could not be loaded?

Yes, if "ENABLE_FALLBACK_ON_NATIVE_FAILED" is true(by default), it would fall 
back to JCE

Regards
Dapeng

-Original Message-
From: Benedikt Ritter [mailto:brit...@apache.org] 
Sent: Saturday, June 18, 2016 12:43 AM
To: Commons Developers List
Subject: Re: [crypto] Logging dependency

Hello Dapeng,

Sun, Dapeng  schrieb am Mi., 15. Juni 2016 um
11:22 Uhr:

> Thank all for your input!
>
> I will try to remove the log dependence.
>
> About the logging of native library failure, users of CRYPTO could get 
> the information about whether native is enabled or native failure 
> reason from
> org.apache.commons.crypto.utils.NativeCodeLoader#isNativeCodeLoaded() 
> or org.apache.commons.crypto.cipher.Openssl#loadingFailureReason(), 
> they could log these information in their system if they need.
>
> At the same time, I think we can add an option for "native only"
> (Currently, when loading native failed, we log native failure error 
> and use JCE implementation as fallback directly), the property in 
> configuration may like "ENABLE_FALLBACK_ON_NATIVE_FAILED", if user 
> disable the option, it could throw an exception when loading native failed.
>
> Is there anyone have other opinions?
>

Do I understand correctly that Crypto should fall back to JCE if native code 
could not be loaded?

Benedikt


>
>
> Regards
> Dapeng
>
> -Original Message-
> From: Torsten Curdt [mailto:tcu...@vafer.org]
> Sent: Saturday, June 11, 2016 6:44 PM
> To: Commons Developers List
> Subject: Re: [crypto] Logging dependency
>
> On Sat, Jun 11, 2016 at 7:34 AM, Ralph Goers 
> 
> wrote:
>
> >
> > > On Jun 10, 2016, at 2:56 PM, Torsten Curdt  wrote:
> > >
> > >> Matt, there is a big difference between printing the stack trace 
> > >> and walking it to find the info. printing it on every debug call 
> > >> would be insane.
> > >>
> > >
> > > Why would anyone want to do that?
> > >
> > >
> > https://docs.oracle.com/javase/7/docs/api/java/lang/StackTraceElement.
> > html
> > >
> > >
> > > And how do you think the logging frameworks get that kind of
> > information? :)
> >
> > I think you missed Sebb’s suggestion of having the debug method call 
> > printStackTrace().
> >
>
> Not really - that's was my "Why would anyone want to do that?" in 
> reference to.
> I was just trying to say that context information is not lost as you 
> suggested.
>

RE: [CRYPTO] JIRA fix comments should please link to the Git change

[Sun, Dapeng]

+1, thank Sebb for adding these comments.

Regards
Dapeng

-Original Message-
From: sebb [mailto:seb...@gmail.com] 
Sent: Thursday, June 16, 2016 9:40 PM
To: CommonsDev
Subject: [CRYPTO] JIRA fix comments should please link to the Git change

When fixing a JIRA issue, it's very helpful if the details of the commit are 
added as part of the comment.

I've done this for some recent commits.

Thanks.

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


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

RE: [crypto] On Java 6, really?

[Sun, Dapeng]

Thank all for the comments. I will file a jira to update CRYPTO to JDK 1.7.

Regards
Dapeng

-Original Message-
From: sebb [mailto:seb...@gmail.com] 
Sent: Wednesday, June 15, 2016 9:35 PM
To: Commons Developers List
Subject: Re: [crypto] On Java 6, really?

On 15 June 2016 at 13:48, James Carman  wrote:
> If it's compiled at a higher target version, it's not a drop-in 
> replacement. They must upgrade their JRE.

Only if their JRE is currently lower than the target version.

So whether it will affect many users depends on the JRE upgrade bump.

i.e.  at present a minimum target of Java 8 is likely to affect many more 
installations than a min target of Java 7.
And an update to Java 6 is not likely to affect as many.

> One might argue that's actually
> *less* backward compatible. We've had this debate before. I don't 
> really care which way we go, but let's make sure we stay true to the 
> philosophy (if we want to maintain that philosophy).

Since Java is upwards compatible, generally hosts can be upgraded if necessary.

This is very different from changing Maven coords or package names, which have 
a much more profound effect.

> On Tue, Jun 14, 2016 at 10:57 AM Gary Gregory 
> wrote:
>
>> On Jun 14, 2016 7:51 AM, "James Carman" 
>> wrote:
>> >
>> > The trick is if we want to require a major version upgrade to bump 
>> > JDK levels. That's why you'd want to bump it now if possible.
>>
>> We've not required major version bumps for Java bumps in the past.
>>
>> Gary
>>
>> >
>> > On Tue, Jun 14, 2016 at 10:41 AM Matt Sicker  wrote:
>> >
>> > > I'd prefer to get to 1.7 as soon as possible, but if the API is 
>> > > ready
>> for a
>> > > 1.0 release already, we could wait for 1.1 or 1.2 before going 
>> > > full
>> 1.7.
>> > >
>> > > On 14 June 2016 at 06:16, Stian Soiland-Reyes 
>> wrote:
>> > >
>> > > > +1 to JDK7 on crypto
>> > > > On 14 Jun 2016 10:25 a.m., "Sun, Dapeng" 
>> wrote:
>> > > >
>> > > > > > Then next release(after 1.0.0) must be a major release you mean?
>> > > > > > If there are no potential users looking for JDK 1.6, 
>> > > > > > dropping now
>> > > > should
>> > > > > be good idea IMO.
>> > > > >
>> > > > > Thank Uma, I just checked there is no much changes on 
>> > > > > upgrading JDK
>> to
>> > > > > 1.7, I think we can upgrade before this release.
>> > > > >
>> > > > > Is there anyone have other opinions?
>> > > > >
>> > > > > Regards
>> > > > > Dapeng
>> > > > >
>> > > > > -Original Message-
>> > > > > From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com]
>> > > > > Sent: Tuesday, June 14, 2016 4:21 PM
>> > > > > To: Commons Developers List
>> > > > > Subject: Re: [crypto] On Java 6, really?
>> > > > >
>> > > > > Then next release(after 1.0.0) must be a major release you mean?
>> > > > > If there are no potential users looking for JDK 1.6, dropping 
>> > > > > now
>> > > should
>> > > > > be good idea IMO.
>> > > > >
>> > > > > I also remembered that we wanted to mark 1.0.0 release as 
>> > > > > Alpha
>> right?
>> > > > > (just a question)
>> > > > >
>> > > > > Regards,
>> > > > > Uma
>> > > > >
>> > > > > On 6/14/16, 12:27 AM, "Sun, Dapeng"  wrote:
>> > > > >
>> > > > > >Thank Gary, Benedikt, Marcelo, sebb, James, Jochen, ecki, 
>> > > > > >Ralph
>> and
>> > > > > >Matt for all your input.
>> > > > > >
>> > > > > >How about make a conservative decision: regarding the first 
>> > > > > >release(1.0.0), we keep the JDK version as 1.6, and we 
>> > > > > >wouldn't
>> > > support
>> > > > > >JDK 1.6 for the releases after 1.0.0.
>> > > > > >
>> > > > > >Regards
>> > > > > >Dapeng
>> > > > > >
>> > > > > >-Original Message-
>> > > > > >From

RE: [crypto] Logging dependency

[Sun, Dapeng]

Thank all for your input!

I will try to remove the log dependence.

About the logging of native library failure, users of CRYPTO could get the 
information about whether native is enabled or native failure reason from 
org.apache.commons.crypto.utils.NativeCodeLoader#isNativeCodeLoaded() or 
org.apache.commons.crypto.cipher.Openssl#loadingFailureReason(), they could log 
these information in their system if they need.

At the same time, I think we can add an option for "native only" (Currently, 
when loading native failed, we log native failure error and use JCE 
implementation as fallback directly), the property in configuration may like 
"ENABLE_FALLBACK_ON_NATIVE_FAILED", if user disable the option, it could throw 
an exception when loading native failed. 

Is there anyone have other opinions?


Regards
Dapeng

-Original Message-
From: Torsten Curdt [mailto:tcu...@vafer.org] 
Sent: Saturday, June 11, 2016 6:44 PM
To: Commons Developers List
Subject: Re: [crypto] Logging dependency

On Sat, Jun 11, 2016 at 7:34 AM, Ralph Goers 
wrote:

>
> > On Jun 10, 2016, at 2:56 PM, Torsten Curdt  wrote:
> >
> >> Matt, there is a big difference between printing the stack trace 
> >> and walking it to find the info. printing it on every debug call 
> >> would be insane.
> >>
> >
> > Why would anyone want to do that?
> >
> >
> https://docs.oracle.com/javase/7/docs/api/java/lang/StackTraceElement.
> html
> >
> >
> > And how do you think the logging frameworks get that kind of
> information? :)
>
> I think you missed Sebb’s suggestion of having the debug method call 
> printStackTrace().
>

Not really - that's was my "Why would anyone want to do that?" in reference to.
I was just trying to say that context information is not lost as you suggested.

RE: [crypto] On Java 6, really?

[Sun, Dapeng]

> Then next release(after 1.0.0) must be a major release you mean?
> If there are no potential users looking for JDK 1.6, dropping now should be 
> good idea IMO.

Thank Uma, I just checked there is no much changes on upgrading JDK to 1.7, I 
think we can upgrade before this release. 

Is there anyone have other opinions?

Regards
Dapeng

-Original Message-
From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com] 
Sent: Tuesday, June 14, 2016 4:21 PM
To: Commons Developers List
Subject: Re: [crypto] On Java 6, really?

Then next release(after 1.0.0) must be a major release you mean?
If there are no potential users looking for JDK 1.6, dropping now should be 
good idea IMO.

I also remembered that we wanted to mark 1.0.0 release as Alpha right?
(just a question)

Regards,
Uma

On 6/14/16, 12:27 AM, "Sun, Dapeng"  wrote:

>Thank Gary, Benedikt, Marcelo, sebb, James, Jochen, ecki, Ralph and 
>Matt for all your input.
>
>How about make a conservative decision: regarding the first 
>release(1.0.0), we keep the JDK version as 1.6, and we wouldn't support 
>JDK 1.6 for the releases after 1.0.0.
>
>Regards
>Dapeng
>
>-Original Message-
>From: Matt Sicker [mailto:boa...@gmail.com]
>Sent: Wednesday, June 08, 2016 6:18 AM
>To: Commons Developers List
>Subject: Re: [crypto] On Java 6, really?
>
>I'd imagine that close to 100% of users who are on Java 6 are not 
>upgrading anything else, either, nor would they be adding in new 
>dependencies. Every Java 6 project I've come across lately has been in 
>legacy maintenance mode (just like Java 6 itself).
>
>On 7 June 2016 at 16:47, Gary Gregory  wrote:
>
>> Let's not forget that customers are paying Oracle to get Java 6 updates.
>>
>> Gary
>> On Jun 7, 2016 1:24 PM, "Ralph Goers" 
>>wrote:
>>
>> > I really don¹t think the premier & extended support dates should 
>> > really mean much, except as an indicator of how many users of that 
>> > version might still exist.  Basically, no new features are going to 
>> > be added to Java
>> so I
>> > don¹t think we should be targeting new features there either. If 
>> > there
>> is a
>> > bug that needs to be fixed it should be possible to do it on a 
>> > branch of the the release for that version of Java.  The web site 
>> > should clearly indicate which versions of the component support the 
>> > appropriate Java versions.
>> >
>> > Ralph
>> >
>> > > On Jun 7, 2016, at 12:26 PM, sebb  wrote:
>> > >
>> > > I have just checked Oracle support for Java 6.
>> > >
>> > > The Support Life for Java 6 has been extended to Dec 2018 [1] I 
>> > > think this means that there are critical systems that cannot yet 
>> > > be updated to Java 7+.
>> > >
>> > > This does not mean that we should ensure that all Commons code 
>> > > still works on Java 6.
>> > > But it should be taken into account when evaluating the pros and 
>> > > cons of requiring a later version.
>> > >
>> > > [1]
>> > > http://www.oracle.com/technetwork/java/eol-135779.html#extended6
>> > >
>> > > On 7 June 2016 at 20:02, Jochen Wiedmann 
>> > > 
>> > wrote:
>> > >>> Gary Gregory  wrote on Tue., 7. Juni
>> > >>> 2016
>> > >>>
>> > >>>> Are we really starting a new component on a dead platform like 
>> > >>>> Java
>> 6?
>> > >>
>> > >>
>> > >> You are, of course, right, that the component is more than 
>> > >> welcome to use another version. OTOH, given our latest
>> > >> experiences: Is this really someting, that we should care for?
>> > >> IMO, let the component have, whatever they want.
>> > >>
>> > >> Jochen
>> > >>
>> > >> 
>> > >> -
>> > >>  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > >> For additional commands, e-mail: dev-h...@commons.apache.org
>> > >>
>> > >
>> > > -
>> > > -
>> > > --- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > > For additional commands, e-mail: dev-h...@commons.apache.org
>> > >
>> > >
>> >
>> >
>> >
>> > ---
>> > -
>> > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > For additional commands, e-mail: dev-h...@commons.apache.org
>> >
>> >
>>
>
>
>
>--
>Matt Sicker 


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


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

RE: [crypto] On Java 6, really?

[Sun, Dapeng]

Thank Gary, Benedikt, Marcelo, sebb, James, Jochen, ecki, Ralph and Matt for 
all your input.

How about make a conservative decision: regarding the first release(1.0.0), we 
keep the JDK version as 1.6, and we wouldn't support JDK 1.6 for the releases 
after 1.0.0. 

Regards
Dapeng

-Original Message-
From: Matt Sicker [mailto:boa...@gmail.com] 
Sent: Wednesday, June 08, 2016 6:18 AM
To: Commons Developers List
Subject: Re: [crypto] On Java 6, really?

I'd imagine that close to 100% of users who are on Java 6 are not upgrading 
anything else, either, nor would they be adding in new dependencies. Every Java 
6 project I've come across lately has been in legacy maintenance mode (just 
like Java 6 itself).

On 7 June 2016 at 16:47, Gary Gregory  wrote:

> Let's not forget that customers are paying Oracle to get Java 6 updates.
>
> Gary
> On Jun 7, 2016 1:24 PM, "Ralph Goers"  wrote:
>
> > I really don’t think the premier & extended support dates should 
> > really mean much, except as an indicator of how many users of that 
> > version might still exist.  Basically, no new features are going to 
> > be added to Java
> so I
> > don’t think we should be targeting new features there either. If 
> > there
> is a
> > bug that needs to be fixed it should be possible to do it on a 
> > branch of the the release for that version of Java.  The web site 
> > should clearly indicate which versions of the component support the 
> > appropriate Java versions.
> >
> > Ralph
> >
> > > On Jun 7, 2016, at 12:26 PM, sebb  wrote:
> > >
> > > I have just checked Oracle support for Java 6.
> > >
> > > The Support Life for Java 6 has been extended to Dec 2018 [1] I 
> > > think this means that there are critical systems that cannot yet 
> > > be updated to Java 7+.
> > >
> > > This does not mean that we should ensure that all Commons code 
> > > still works on Java 6.
> > > But it should be taken into account when evaluating the pros and 
> > > cons of requiring a later version.
> > >
> > > [1] 
> > > http://www.oracle.com/technetwork/java/eol-135779.html#extended6
> > >
> > > On 7 June 2016 at 20:02, Jochen Wiedmann 
> > > 
> > wrote:
> > >>> Gary Gregory  wrote on Tue., 7. Juni 
> > >>> 2016
> > >>>
> >  Are we really starting a new component on a dead platform like 
> >  Java
> 6?
> > >>
> > >>
> > >> You are, of course, right, that the component is more than 
> > >> welcome to use another version. OTOH, given our latest 
> > >> experiences: Is this really someting, that we should care for? 
> > >> IMO, let the component have, whatever they want.
> > >>
> > >> Jochen
> > >>
> > >> -
> > >>  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > >> For additional commands, e-mail: dev-h...@commons.apache.org
> > >>
> > >
> > > --
> > > --- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
> >
> >
> > 
> > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>



--
Matt Sicker 

RE: [crypto] Instructions MUST mention running the tests

[Sun, Dapeng]

Thank Bernd, it seems "mvn verify" can't cover creating binary distribution, I 
think we can add it to Jenkins.

Regards
Dapeng

-Original Message-
From: e...@zusammenkunft.net [mailto:e...@zusammenkunft.net] 
Sent: Tuesday, June 07, 2016 10:40 AM
To: Commons Developers List
Subject: Re: [crypto] Instructions MUST mention running the tests

Hello,

I also make a habit out of using "mvn verify" instead of "mvn package" (for the 
same reason, do never document circumventing potential tests).

Gruss
Bernd

--
http://bernd.eckenfels.net

-Original Message-
From: Gary Gregory 
To: Commons Developers List 
Sent: Di., 07 Juni 2016 4:37
Subject: [crypto] Instructions MUST mention running the tests

Hi All:

When I see instructions in BUILDING.txt like:

Create binary distribution:

  $ mvn package -DskipTests

I am worried!

Why would you NOT want to run unit tests? Skipping tests from Maven is a hack 
when you know what you are doing. Like when I just ran the tests, all passed, 
and I changed something that is not Java source.

IMO, we need better build instructions.

I've added steps for RAT and Clirr, a must for any Maven component here.

Thank you,
Gary
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with 
Hibernate, Second Edition  JUnit in Action, 
Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

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


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

RE: [crypto] Instructions MUST mention running the tests

[Sun, Dapeng]

Thank Gary for pointing it out, The reason sounds good to me, and running tests 
didn't cost too much time, I think we can remove " -DskipTests "

Regards
Dapeng

-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com] 
Sent: Tuesday, June 07, 2016 10:37 AM
To: Commons Developers List
Subject: [crypto] Instructions MUST mention running the tests

Hi All:

When I see instructions in BUILDING.txt like:

Create binary distribution:

  $ mvn package -DskipTests

I am worried!

Why would you NOT want to run unit tests? Skipping tests from Maven is a hack 
when you know what you are doing. Like when I just ran the tests, all passed, 
and I changed something that is not Java source.

IMO, we need better build instructions.

I've added steps for RAT and Clirr, a must for any Maven component here.

Thank you,
Gary
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with 
Hibernate, Second Edition  JUnit in Action, 
Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

RE: [CRYPTO]1.0.0 Release Plan

[Sun, Dapeng]

> So we can assume the current master (commit
> a289ecd26257ac4ffaf1bbb686cf06b3a9ececdc) is buildable, right?

Yes, a289ecd26257ac4ffaf1bbb686cf06b3a9ececdc is buildable.

> https://github.com/apache/commons-crypto/blob/master/BUILDING.txt
> describes build requirements - in particular you need to have openssl library 
> headers.

Good suggestion, I will add the requirements to BUILDING.txt

Regards
Dapeng

-Original Message-
From: Stian Soiland-Reyes [mailto:st...@apache.org] 
Sent: Monday, June 06, 2016 11:53 PM
To: Commons Developers List
Subject: Re: [CRYPTO]1.0.0 Release Plan

Makes sense for the first release.. like a pre-release candidate candidate, 
tested from git.

So we can assume the current master (commit
a289ecd26257ac4ffaf1bbb686cf06b3a9ececdc) is buildable, right?

https://github.com/apache/commons-crypto/blob/master/BUILDING.txt

describes build requirements - in particular you need to have openssl library 
headers.

On 6 June 2016 at 15:53, Gary Gregory  wrote:
> Why don't you give us a couple of days before rolling an RC, I for 
> one, would like to review the project a little more carefully. This 
> would avoid wasting time on failed RCs and give an opportunity for 
> others committers and PMC members to make any changes they think 
> should be be done. Could be things like reviewing PMD, CPD, and 
> Checkstyle reports, and so on. Mayve announce something like, "I plan 
> on rolling an RC and Friday" or something like that.
>
> Gary
> On Jun 6, 2016 2:49 AM, "Benedikt Ritter"  wrote:
>
>> Hello Dapeng
>>
>> Sun, Dapeng  schrieb am Mo., 6. Juni 2016 um
>> 11:13 Uhr:
>>
>> > Hello,
>> >
>> > Apache Commons CRYPTO was established at May 9, 2016[1], There are 
>> > presently numbers of resolved issues fix in CRYPTO[2]. Recently, we 
>> > also fixed the legal issue[3].
>> >
>> > With the first release, we can begin to promote CRYPTO to other 
>> > Apache components, like Apache Hadoop, Apache Spark, so that they 
>> > can benefit
>> the
>> > higher performance improvement from Apache Commons Crypto.
>> >
>> > We plan the following three opening features to next release(I 
>> > think it should be 1.1.0): GCM support[4], JNACipher 
>> > implementation[5] and
>> benchmark
>> > tool[6]. Please let me know if there is anything need to be done 
>> > before
>> the
>> > release.
>> >
>> >
>> Sounds good to me. Let me know if you need help preparing the RC.
>>
>> Benedikt
>>
>>
>> >
>> > Regards
>> > Dapeng
>> >
>> >
>> > [1]
>> >
>> http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3CC
>> AB917RJkcNYL4KeRJTo%3D5F7P3A4iyME0TA40GNmuU4RLs5N4KQ%40mail.gmail.com
>> %3E
>> > [2]
>> >
>> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&p
>> id=12310464&sorter/field=issuekey&sorter/order=DESC&status=5&status=6
>> > [3]
>> >
>> http://mail-archives.apache.org/mod_mbox/commons-dev/201606.mbox/%3CC
>> ACZkXPyrYvY8NMyQLnT6qMDpNxWiDUudoEw%2BDe%2BYBDHoBBhCzQ%40mail.gmail.c
>> om%3E
>> > [4] https://github.com/apache/commons-crypto/pull/44
>> > [5] https://github.com/apache/commons-crypto/pull/47
>> > [6] https://github.com/apache/commons-crypto/pull/1
>> >
>> >
>>



--
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons
http://orcid.org/-0001-9842-9718

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


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

RE: [CRYPTO]1.0.0 Release Plan

[Sun, Dapeng]

Thank Gary for reviewing the project.

> Mayve announce something like, "I plan on rolling an RC and Friday" or 
> something like that
It's a good suggestion. I think the date can be June 13th (the Next Monday). I 
will send another email with the date.

Regards
Dapeng

-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com] 
Sent: Monday, June 06, 2016 10:53 PM
To: Commons Developers List
Subject: Re: [CRYPTO]1.0.0 Release Plan

Why don't you give us a couple of days before rolling an RC, I for one, would 
like to review the project a little more carefully. This would avoid wasting 
time on failed RCs and give an opportunity for others committers and PMC 
members to make any changes they think should be be done. Could be things like 
reviewing PMD, CPD, and Checkstyle reports, and so on. Mayve announce something 
like, "I plan on rolling an RC and Friday" or something like that.

Gary
On Jun 6, 2016 2:49 AM, "Benedikt Ritter"  wrote:

> Hello Dapeng
>
> Sun, Dapeng  schrieb am Mo., 6. Juni 2016 um
> 11:13 Uhr:
>
> > Hello,
> >
> > Apache Commons CRYPTO was established at May 9, 2016[1], There are 
> > presently numbers of resolved issues fix in CRYPTO[2]. Recently, we 
> > also fixed the legal issue[3].
> >
> > With the first release, we can begin to promote CRYPTO to other 
> > Apache components, like Apache Hadoop, Apache Spark, so that they 
> > can benefit
> the
> > higher performance improvement from Apache Commons Crypto.
> >
> > We plan the following three opening features to next release(I think 
> > it should be 1.1.0): GCM support[4], JNACipher implementation[5] and
> benchmark
> > tool[6]. Please let me know if there is anything need to be done 
> > before
> the
> > release.
> >
> >
> Sounds good to me. Let me know if you need help preparing the RC.
>
> Benedikt
>
>
> >
> > Regards
> > Dapeng
> >
> >
> > [1]
> >
> http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3CCA
> B917RJkcNYL4KeRJTo%3D5F7P3A4iyME0TA40GNmuU4RLs5N4KQ%40mail.gmail.com%3
> E
> > [2]
> >
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pi
> d=12310464&sorter/field=issuekey&sorter/order=DESC&status=5&status=6
> > [3]
> >
> http://mail-archives.apache.org/mod_mbox/commons-dev/201606.mbox/%3CCA
> CZkXPyrYvY8NMyQLnT6qMDpNxWiDUudoEw%2BDe%2BYBDHoBBhCzQ%40mail.gmail.com
> %3E
> > [4] https://github.com/apache/commons-crypto/pull/44
> > [5] https://github.com/apache/commons-crypto/pull/47
> > [6] https://github.com/apache/commons-crypto/pull/1
> >
> >
>

RE: [CRYPTO]1.0.0 Release Plan

[Sun, Dapeng]

Thank Benedikt.

Regards
Dapeng

-Original Message-
From: Benedikt Ritter [mailto:brit...@apache.org] 
Sent: Monday, June 06, 2016 5:50 PM
To: Commons Developers List
Subject: Re: [CRYPTO]1.0.0 Release Plan

Hello Dapeng

Sun, Dapeng  schrieb am Mo., 6. Juni 2016 um
11:13 Uhr:

> Hello,
>
> Apache Commons CRYPTO was established at May 9, 2016[1], There are 
> presently numbers of resolved issues fix in CRYPTO[2]. Recently, we 
> also fixed the legal issue[3].
>
> With the first release, we can begin to promote CRYPTO to other Apache 
> components, like Apache Hadoop, Apache Spark, so that they can benefit 
> the higher performance improvement from Apache Commons Crypto.
>
> We plan the following three opening features to next release(I think 
> it should be 1.1.0): GCM support[4], JNACipher implementation[5] and 
> benchmark tool[6]. Please let me know if there is anything need to be 
> done before the release.
>
>
Sounds good to me. Let me know if you need help preparing the RC.

Benedikt


>
> Regards
> Dapeng
>
>
> [1]
> http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3CCA
> B917RJkcNYL4KeRJTo%3D5F7P3A4iyME0TA40GNmuU4RLs5N4KQ%40mail.gmail.com%3
> E
> [2]
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pi
> d=12310464&sorter/field=issuekey&sorter/order=DESC&status=5&status=6
> [3]
> http://mail-archives.apache.org/mod_mbox/commons-dev/201606.mbox/%3CCA
> CZkXPyrYvY8NMyQLnT6qMDpNxWiDUudoEw%2BDe%2BYBDHoBBhCzQ%40mail.gmail.com
> %3E [4] https://github.com/apache/commons-crypto/pull/44
> [5] https://github.com/apache/commons-crypto/pull/47
> [6] https://github.com/apache/commons-crypto/pull/1
>
>

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

[CRYPTO]1.0.0 Release Plan

[Sun, Dapeng]

Hello,

Apache Commons CRYPTO was established at May 9, 2016[1], There are presently 
numbers of resolved issues fix in CRYPTO[2]. Recently, we also fixed the legal 
issue[3].

With the first release, we can begin to promote CRYPTO to other Apache 
components, like Apache Hadoop, Apache Spark, so that they can benefit the 
higher performance improvement from Apache Commons Crypto.

We plan the following three opening features to next release(I think it should 
be 1.1.0): GCM support[4], JNACipher implementation[5] and benchmark tool[6]. 
Please let me know if there is anything need to be done before the release.


Regards
Dapeng


[1] 
http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3CCAB917RJkcNYL4KeRJTo%3D5F7P3A4iyME0TA40GNmuU4RLs5N4KQ%40mail.gmail.com%3E
[2] 
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310464&sorter/field=issuekey&sorter/order=DESC&status=5&status=6
[3] 
http://mail-archives.apache.org/mod_mbox/commons-dev/201606.mbox/%3CCACZkXPyrYvY8NMyQLnT6qMDpNxWiDUudoEw%2BDe%2BYBDHoBBhCzQ%40mail.gmail.com%3E
[4] https://github.com/apache/commons-crypto/pull/44
[5] https://github.com/apache/commons-crypto/pull/47
[6] https://github.com/apache/commons-crypto/pull/1

RE: US Export classification & ECCN registration for encryption in commons?

[Sun, Dapeng]

Thank Stian for your review!

>We also need a second  for the (future) source/binary distributions 
>with ControlledSource href=https://www.apache.org/dist/commons/crypto/ - you 
>would need to duplicate the OpenSSL and JavaSE  for that. 
>See other examples in the XML file.
Thank you for pointing it out, we should add it.

> is it 1.0.0 we're targeting for the first Commons Crypto release?
Yes, 1.0.0 would be the first release. 

I have updated the staging website. 
http://www.staging.apache.org/licenses/exports/index.html 


Regards
Dapeng

-Original Message-
From: Stian Soiland-Reyes [mailto:st...@apache.org] 
Sent: Tuesday, May 31, 2016 6:45 PM
To: Commons Developers List
Subject: Re: US Export classification & ECCN registration for encryption in 
commons?

Thanks! Looks good.

We also need a second  for the (future) source/binary distributions 
with ControlledSource href=https://www.apache.org/dist/commons/crypto/ - you 
would need to duplicate the OpenSSL and JavaSE  for that. See 
other examples in the XML file.

In the second Version you can say 1.0.0 and later - is it 1.0.0 
we're targeting for the first Commons Crypto release?

On 31 May 2016 at 11:03, Sun, Dapeng  wrote:
> Thank Stian and Haifeng, I have updated the file at my cms workspace. 
> If the change is okay for you, I will try to commit it to 
> http://www.staging.apache.org/licenses/exports/
>
> Index: trunk/content/licenses/exports/index.page/eccnmatrix.xml
> ===
> --- trunk/content/licenses/exports/index.page/eccnmatrix.xml(revision 
> 1655892)
> +++ trunk/content/licenses/exports/index.page/eccnmatrix.xml(working copy)
> @@ -212,6 +212,25 @@
>  
>
>
> +Apache Commons Crypto
> +
> +  development
> +  5D002
> +   href="https://git-wip-us.apache.org/repos/asf/commons-crypto.git";>
> +ASF
> +designed for use with encryption library
> +  
> +  http://www.openssl.org/source/";>
> +The OpenSSL Project
> +general-purpose cryptography library included with OpenSSL
> +  
> +   href="http://www.oracle.com/technetwork/java/javase/downloads/index.html";>
> +Oracle
> +general-purpose cryptography library (JCE) included with 
> Java
> +  
> +
> +  
> +  
>  Apache Commons OpenPGP
>  
>development
>
>
> Regards
> Dapeng
>
> -Original Message-
> From: Stian Soiland-Reyes [mailto:st...@apache.org]
> Sent: Monday, May 30, 2016 5:20 PM
> To: Commons Developers List
> Subject: RE: US Export classification & ECCN registration for encryption in 
> commons?
>
> I think we are good to continue as a "normal" 5D002 self-classification.
>
> Great if you will have a go, let me know if you would like me to help or 
> review!
>
> See http://www.apache.org/dev/crypto.html#sources for svn details, 
> linking to 
> https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/lic
> enses/exports/index.page/eccnmatrix.xml
>
> I found just being a committer was enough to update the svn, after 
> which it should be live on 
> http://www.staging.apache.org/licenses/exports/
>
> If that works fine, then any ASF member can publish it using 
> https://cms.apache.org/ for the main website (it can be a bit slow)
>
> Normally it is the PMC Chair that sends the registration email after that.
> On 30 May 2016 8:09 a.m., "Chen, Haifeng"  wrote:
>
> Hi Stian,
> If we decide to go ECCN 5D002 self-classify category, do you have an idea 
> that what I can proceed next?
>
> I saw you updated eccnmatrix.xml file for Taverna. Would you please help 
> share where is the place of the file and who has the privilege to make an 
> similar update for Commons Crypto?
>
> Thanks for your help.
>
> Haifeng
>
>
> -Original Message-
> From: Chen, Haifeng [mailto:haifeng.c...@intel.com]
> Sent: Thursday, May 26, 2016 9:42 AM
> To: Commons Developers List 
> Subject: RE: US Export classification & ECCN registration for encryption in 
> commons?
>
> https://issues.apache.org/jira/browse/LEGAL-256 is created and commented to 
> track this.
>
> If we think this analysis makes sense, we will choose to go ECCN 5D002 
> self-classify category. Will wait for a few days for feedbacks.
>
> Regards,
> Haifeng
>
> -Original Message-
> From: Chen, Haifeng [mailto:haifeng.c...@intel.com]
> Sent: Tuesday, May 24, 2016 3:57 PM
> To: Commons Developers List 
> Subject: RE: US Export classification & ECCN registration for encryption in 
> commons?
>
> Thanks Stian and Benedikt!
>
>

RE: US Export classification & ECCN registration for encryption in commons?

[Sun, Dapeng]

Thank Stian and Haifeng, I have updated the file at my cms workspace. If the 
change is okay for you, I will try to commit it to 
http://www.staging.apache.org/licenses/exports/

Index: trunk/content/licenses/exports/index.page/eccnmatrix.xml
===
--- trunk/content/licenses/exports/index.page/eccnmatrix.xml(revision 
1655892)
+++ trunk/content/licenses/exports/index.page/eccnmatrix.xml(working copy)
@@ -212,6 +212,25 @@
 
   
   
+Apache Commons Crypto
+
+  development
+  5D002
+  https://git-wip-us.apache.org/repos/asf/commons-crypto.git";>
+ASF
+designed for use with encryption library
+  
+  http://www.openssl.org/source/";>
+The OpenSSL Project
+general-purpose cryptography library included with OpenSSL
+  
+  http://www.oracle.com/technetwork/java/javase/downloads/index.html";>
+Oracle
+general-purpose cryptography library (JCE) included with 
Java
+  
+
+  
+  
 Apache Commons OpenPGP
 
   development


Regards
Dapeng

-Original Message-
From: Stian Soiland-Reyes [mailto:st...@apache.org] 
Sent: Monday, May 30, 2016 5:20 PM
To: Commons Developers List
Subject: RE: US Export classification & ECCN registration for encryption in 
commons?

I think we are good to continue as a "normal" 5D002 self-classification.

Great if you will have a go, let me know if you would like me to help or review!

See http://www.apache.org/dev/crypto.html#sources for svn details, linking to 
https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/licenses/exports/index.page/eccnmatrix.xml

I found just being a committer was enough to update the svn, after which it 
should be live on http://www.staging.apache.org/licenses/exports/

If that works fine, then any ASF member can publish it using 
https://cms.apache.org/ for the main website (it can be a bit slow)

Normally it is the PMC Chair that sends the registration email after that.
On 30 May 2016 8:09 a.m., "Chen, Haifeng"  wrote:

Hi Stian,
If we decide to go ECCN 5D002 self-classify category, do you have an idea that 
what I can proceed next?

I saw you updated eccnmatrix.xml file for Taverna. Would you please help share 
where is the place of the file and who has the privilege to make an similar 
update for Commons Crypto?

Thanks for your help.

Haifeng


-Original Message-
From: Chen, Haifeng [mailto:haifeng.c...@intel.com]
Sent: Thursday, May 26, 2016 9:42 AM
To: Commons Developers List 
Subject: RE: US Export classification & ECCN registration for encryption in 
commons?

https://issues.apache.org/jira/browse/LEGAL-256 is created and commented to 
track this.

If we think this analysis makes sense, we will choose to go ECCN 5D002 
self-classify category. Will wait for a few days for feedbacks.

Regards,
Haifeng

-Original Message-
From: Chen, Haifeng [mailto:haifeng.c...@intel.com]
Sent: Tuesday, May 24, 2016 3:57 PM
To: Commons Developers List 
Subject: RE: US Export classification & ECCN registration for encryption in 
commons?

Thanks Stian and Benedikt!

> Let's create a Jira issue to track the categorisation process.
Do you mean to create a JIRA in LEGAL similar to LEGAL-250 to track this?


Regards,
Haifeng

-Original Message-
From: Benedikt Ritter [mailto:brit...@apache.org]
Sent: Monday, May 23, 2016 3:36 PM
To: Commons Developers List 
Subject: Re: US Export classification & ECCN registration for encryption in 
commons?

Stian Soiland-Reyes  schrieb am Mo., 23. Mai 2016 um
09:34 Uhr:

> On 23 May 2016 3:42 a.m., "Chen, Haifeng"  wrote:
> >
> > So how about we go to the process of ECCN 5D002 self-classify 
> > category
> and registration like Taverna did?
>
> Agree on your evaluation, so ECCN 5D002 is good. This makes things a 
> lot easier! :)
>
> Let's create a Jira issue to track the categorisation process.
>

+1! good work everybody.

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

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

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

RE: [CRYPTO] How to build CRYPTO on Mac OS 10.11?

[Sun, Dapeng]

>I've found a fix, see [1]. Now I can publish the site. After the site has been 
>published, I'll send an ANNOUNCE about the establishment of the Apache Commons 
>Crypto Component.

I really appreciate your help, I will look into CRYPTO-57.

Regards
Dapeng

-Original Message-
From: Benedikt Ritter [mailto:brit...@apache.org] 
Sent: Tuesday, May 10, 2016 3:34 AM
To: Commons Developers List
Subject: Re: [CRYPTO] How to build CRYPTO on Mac OS 10.11?

Hello again :-)

Benedikt Ritter  schrieb am Mo., 9. Mai 2016 um
21:24 Uhr:

> Hello Dapeng,
>
> Sun, Dapeng  schrieb am Mi., 4. Mai 2016 um
> 05:33 Uhr:
>
>> Hi Benedikt,
>>
>> Hope this information will be helpful
>>
>> 1. Upgrade openssl to 1.0.1c above using brew(http://brew.sh/)[1]:
>> Check your openssl version, by default it's not 1.0.1 $openssl 
>> version OpenSSL 0.9.8r 8 Feb 2011
>>
>> $ brew search openssl
>> $ brew install homebrew/versions/openssl101 $ brew link openssl 
>> --force
>>
>> Open a new terminal window, test your openssl version, it should be 
>> 1.0.1 now $ openssl version OpenSSL 1.0.1s 1 Mar 2016 If not, please 
>> check if Homebrew /usr/local/bin if at the front of $PATH
>>
>> 2. Download and install JCE Unlimited Strength Jurisdiction Policy 
>> Files[2]
>>
>> Download the Java Cryptography Extension (JCE) Unlimited Strength 
>> Jurisdiction Policy Files from Oracle.
>> For JDK 1.6:
>> http://www.oracle.com/technetwork/java/javase/downloads/jce-6-downloa
>> d-429243.html
>> For JDK 1.7:
>> http://www.oracle.com/technetwork/java/javase/downloads/jce-7-downloa
>> d-432124.html
>> For JDK 1.8:
>> http://www.oracle.com/technetwork/java/javase/downloads/jce8-download
>> -2133166.html
>>
>> Uncompress and extract the downloaded file. The download includes a 
>> Readme.txt and two .jar files with the same names as the existing 
>> policy files.
>>
>> Replace local_policy.jar and US_export_policy.jar at 
>> /lib/security/
>>
>> 3. Set system environment JAVA_HOME[3] $ echo $JAVA_HOME In Mac OSX 
>> 10.5 or later, Apple recommends to set the $JAVA_HOME variable to 
>> /usr/libexec/java_home, just export $JAVA_HOME in file ~/. 
>> bash_profile or ~/.profile.
>>
>> I have tried it on local machine, please feel free to let me know if 
>> you still have any problem.
>>
>
> I've followed your guide, but I'm still getting:
>
> compiling OSInfo.java
> gcc -arch x86_64 -Ilib/inc_mac
> -I/Library/Java/JavaVirtualMachines/jdk1.8.0_65.jdk/Contents/Home/incl
> ude
> -O2 -fPIC -mmacosx-version-min=10.5 -fvisibility=hidden -Ilib/include 
> -I/usr/include -I"src/main/native/org/apache/commons/crypto/"
> -I"/Library/Java/JavaVirtualMachines/jdk1.8.0_65.jdk/Contents/Home/include/darwin"
> -I"target/jni-classes/org/apache/commons/crypto/cipher"
> -I"target/jni-classes/org/apache/commons/crypto/random" -c 
> src/main/native/org/apache/commons/crypto/random/OpensslCryptoRandomNa
> tive.c -o 
> target/commons-crypto-1.0.0-SNAPSHOT-Mac-x86_64/OpensslCryptoRandom.o
> In file included from
> src/main/native/org/apache/commons/crypto/random/OpensslCryptoRandomNative.c:19:
> In file included from
> src/main/native/org/apache/commons/crypto/random/org_apache_commons_crypto_random.h:22:
> src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h:200:10:
> fatal error: 'openssl/aes.h' file not found #include 
>
> So it looks like my openssl installation is not picked up by the build.
> I'm not sure what to do now. Maybe we can have a skype call, try to 
> identify the problems on my machine together and document them on the 
> website. I'll be on vacation the next week, so I won't have time to 
> work on crypto until May, 19th.
>

I've found a fix, see [1]. Now I can publish the site. After the site has been 
published, I'll send an ANNOUNCE about the establishment of the Apache Commons 
Crypto Component.

Benedikt

[1] https://issues.apache.org/jira/browse/CRYPTO-57


>
> Regards,
> Benedikt
>
>
>>
>> Regards
>> Dapeng
>>
>> [1]
>> http://stackoverflow.com/questions/15185661/update-openssl-on-os-x-wi
>> th-homebrew
>> [2]
>> https://www.attachmate.com/documentation/rweb/rweb-installguide/data/
>> b1gdutii.htm
>> [3]
>> http://www.mkyong.com/java/how-to-set-java_home-environment-variable-
>> on-mac-os-x/
>>
>> -Original Message-
>> From: Benedikt Ritter [mailto:brit...@apache.org]
>> Sent: Wednesday, May 04, 2016 12:39 AM
>> To: Commons Devel

RE: [CRYPTO] Discuss to proceed the alpha release for Commons Crypto

[Sun, Dapeng]

I'm agreed. I think we can prepare the first release.

Regards
Dapeng

-Original Message-
From: Chen, Haifeng [mailto:haifeng.c...@intel.com] 
Sent: Thursday, May 05, 2016 11:21 AM
To: Commons Developers List
Subject: RE: [CRYPTO] Discuss to proceed the alpha release for Commons Crypto

Sorry for the typo in the second paragraph.

Hi,
After weeks of collaborated work from the community, the renaming, building, 
API refactoring and documentation are almost done.
Much thanks to the Commons community for all your support.

The community folks proposed to go with an alpha release if we want sooner. So 
I suggest we can proceed the alpha release now.
Please feel free to share your opinion.

If there is no objection, we will proceed to prepare the release artifacts and 
send out the release VOTE to the community when ready.

Regards,
Haifeng


From: Chen, Haifeng
Sent: Thursday, May 5, 2016 11:18 AM
To: Commons Developers List 
Subject: [CRYPTO] Discuss to proceed the alpha release for Commons Crypto

Hi,
After weeks of collaborated work from the community, the renaming, building, 
API refactoring and documentation are almost done.
Much thanks to the Commons community for all your support.

The community folks to prepare an alpha release if we want sooner. So I suggest 
we can proceed the alpha release now.
Please feel free to share your opinion.

If there is no objection, we will proceed to prepare the release artifacts and 
send out the release VOTE to the community when ready.

Regards,
Haifeng

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

RE: [CRYPTO] How to build CRYPTO on Mac OS 10.11?

[Sun, Dapeng]

Hi Benedikt,

Hope this information will be helpful

1. Upgrade openssl to 1.0.1c above using brew(http://brew.sh/)[1]:
Check your openssl version, by default it's not 1.0.1
$openssl version
OpenSSL 0.9.8r 8 Feb 2011

$ brew search openssl
$ brew install homebrew/versions/openssl101
$ brew link openssl --force

Open a new terminal window, test your openssl version, it should be 1.0.1 now
$ openssl version
OpenSSL 1.0.1s 1 Mar 2016
If not, please check if Homebrew /usr/local/bin if at the front of $PATH

2. Download and install JCE Unlimited Strength Jurisdiction Policy Files[2]

Download the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction 
Policy Files from Oracle.
For JDK 1.6: 
http://www.oracle.com/technetwork/java/javase/downloads/jce-6-download-429243.html
 
For JDK 1.7: 
http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html
 
For JDK 1.8: 
http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html
 

Uncompress and extract the downloaded file. The download includes a Readme.txt 
and two .jar files with the same names as the existing policy files.

Replace local_policy.jar and US_export_policy.jar at /lib/security/

3. Set system environment JAVA_HOME[3]
$ echo $JAVA_HOME
In Mac OSX 10.5 or later, Apple recommends to set the $JAVA_HOME variable to 
/usr/libexec/java_home, just export $JAVA_HOME in file ~/. bash_profile or 
~/.profile.

I have tried it on local machine, please feel free to let me know if you still 
have any problem.

Regards
Dapeng

[1] 
http://stackoverflow.com/questions/15185661/update-openssl-on-os-x-with-homebrew
 
[2] 
https://www.attachmate.com/documentation/rweb/rweb-installguide/data/b1gdutii.htm
 
[3] 
http://www.mkyong.com/java/how-to-set-java_home-environment-variable-on-mac-os-x/
 

-Original Message-
From: Benedikt Ritter [mailto:brit...@apache.org] 
Sent: Wednesday, May 04, 2016 12:39 AM
To: Commons Developers List
Subject: Re: [CRYPTO] How to build CRYPTO on Mac OS 10.11?

Chen, Haifeng  schrieb am Di., 3. Mai 2016 um
03:49 Uhr:

> Sorry to not response in the past days due to Holiday here.
> We will start to check that. I agree that JNA is a good thing to try 
> as long as the performance impact is in an acceptable level.
>

It would be good enough for me to have some documentation on how to setup the 
development environment. If none of the crypto developers uses Mac OS, I'll 
need to figure out and document myself. Maybe somebody can help me via hang out 
to understand better what the requirements are.

Regards,
Benedikt


>
>
> -Original Message-
> From: sebb [mailto:seb...@gmail.com]
> Sent: Monday, May 2, 2016 6:51 PM
> To: Commons Developers List 
> Subject: Re: [CRYPTO] How to build CRYPTO on Mac OS 10.11?
>
> On 2 May 2016 at 11:45, Benedikt Ritter  wrote:
> > sebb  schrieb am So., 1. Mai 2016 um 21:19 Uhr:
> >
> >> On 1 May 2016 at 19:17, Benedikt Ritter  wrote:
> >> > Hi,
> >> >
> >> > today I started working on the site build. I ran into problems 
> >> > with the native build and with different JDK versions. Can anybody help?
> >> > I've documented my problems in CRYPTO-45 [1].
> >>
> >> I think you have discovered why there were concerns about using JNI...
> >>
> >
> > :-)
> >
> > I think it just has to be documented. The problem seems to be 
> > specific to Mac OS 10.11.
>
> But it's not possible to document these problems without having access 
> to the relevant OS.
>
> And even if one does, this is a non-trivial exercise as you have just 
> shown.
>
> >
> >>
> >> > Regards,
> >> > Benedikt
> >> >
> >> > [1] https://issues.apache.org/jira/browse/CRYPTO-45
> >>
> >> ---
> >> -- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

RE: [jira] [Updated] (CRYPTO-31) Make fields final wherever possible

[Sun, Dapeng]

Hi Gary,

Thank you for pointing it out. I will remove the tag of 'affects version'.

Regards
Dapeng

-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com] 
Sent: Thursday, April 28, 2016 1:03 PM
To: Commons Developers List
Subject: Re: [jira] [Updated] (CRYPTO-31) Make fields final wherever possible

I do not think tickets should be marked as affects 1.0.0 since that version is 
not released.

Gary
On Apr 27, 2016 8:33 PM, "Dapeng Sun (JIRA)"  wrote:

>
>  [
> https://issues.apache.org/jira/browse/CRYPTO-31?page=com.atlassian.jir
> a.plugin.system.issuetabpanels:all-tabpanel
> ]
>
> Dapeng Sun updated CRYPTO-31:
> -
> Affects Version/s: 1.0.0
>
> > Make fields final wherever possible
> > ---
> >
> > Key: CRYPTO-31
> > URL: https://issues.apache.org/jira/browse/CRYPTO-31
> > Project: Commons Crypto
> >  Issue Type: Improvement
> >  Components: Stream
> >Affects Versions: 1.0.0
> >Reporter: Sebb
> >Assignee: Ferdinand Xu
> >Priority: Minor
> > Fix For: 1.0.0
> >
> >
> > Final fields are automatically thread safe if the object itself is 
> > not
> modified.
> > Whereas non-final fields are not necessarily thread-safe even if 
> > they
> are not mutated - this is because of the Java memory model.
> > There are several non-final fields that are not mutated once created.
> They should be made final to improve thread-safety. This is 
> particularly important for static fields since they are more likely to 
> be used by multiple threads.
> > Note: such changes will not affect the public API if the fields are
> private or package-protected.
> > The fields include:
> > JavaSecureRandom.instance
> > OpensslSecureRandom.fallback
> > OpensslSecureRandom.nativeEnabled
> > ChannelInput.channel
> > StreamInput.buf - since no point creating an instance if it is not 
> > going
> to be used for reading, might as well create the buffer up front
> > StreamOutput.bufferSize
> > StreamOutput.buf - as for StreamInput StreamOutput.out - should also 
> > be private static NativeCodeLoader.nativeCodeLoaded static 
> > OSInfo.archMapping static ReflectionUtils.classLoader
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>

RE: [DISCUSS][CHIMERA] Name for the new component

[Sun, Dapeng]

+1 for Apache Commons Crypto


Regards
Dapeng

-Original Message-
From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com] 
Sent: Tuesday, March 29, 2016 9:30 AM
To: Commons Developers List
Subject: Re: [DISCUSS][CHIMERA] Name for the new component

Just collected all the proposed names here for tracking purpose at single
place:

Apache Commons Crypto
Apache Commons Crypto Libs
Apache Commons Crypto Extensions
Apache Commons AES
Apache Commons AES Libs
Apache Commons AES Extensions
Apache Commons Crypto Wrapper
Apache Commons Crypto Helper
Apache Commons EasyCrypt
Apache Commons FastCrypt
Apache Commons OpenSSL
Apache Commons OpenSSL Wrapper (contracted to Apache Commons OSW)



My preference order:
 1) Apache Commons Crypto
 2) Apache Commons FastCrypto
 3) Apache Commons OSW

Regards,
Uma


On 3/25/16, 7:04 AM, "Benedikt Ritter"  wrote:

>Hi,
>
>after we've accepted the Chimera project [1] as new Apache Commons 
>project, it's time to decide on a name. I've used Apache Commons Crypto 
>in the past, but some have argued that it isn't to the point.
>I'd like to find a name the same way we did it for the potential Math TLP.
>Just add your idea to this thread and we'll tally them up after the 
>easter weekend. The name with the most nominations wins :-) Please 
>remember that Apache Commons component names should be short and 
>descriptive.
>
>Here are my proposals:
>
>Apache Commons Crypto
>Apache Commons Crypto Libs
>Apache Commons Crypto Extensions
>Apache Commons AES
>Apache Commons AES Libs
>Apache Commons AES Extensions
>
>Best regards and happy easter!
>Benedikt
>
>[1] https://github.com/intel-hadoop/chimera


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


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