[jira] [Resolved] (CRYPTO-60) opensslCipher support GCM mode
[
https://issues.apache.org/jira/browse/CRYPTO-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dapeng Sun resolved CRYPTO-60.
--
Resolution: Fixed
Thank Xianda for the contribution!
{noformat}
commit aad8c55a43f72d7869d704a44b42557bb634baf2
Author: Xianda Ke
Date: Mon Nov 20 07:57:14 2017 +0800
CRYPTO-60: opensslCipher support GCM mode
Closes #70 from kexianda/gcm3
{noformat}
> opensslCipher support GCM mode
> ---
>
> Key: CRYPTO-60
> URL: https://issues.apache.org/jira/browse/CRYPTO-60
> Project: Commons Crypto
> Issue Type: Sub-task
>Reporter: Xianda Ke
>Assignee: Xianda Ke
> Attachments: gcm_design_doc.pdf
>
>
> The interface would look like JCE. In encryption mode, the authenticated tag
> information is appended at the end of output.
> In decryption mode, the authenticated tag should appended at the end of
> input. If the encrypted data is tampered, it will throw an
> AEADBadTagException.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (CRYPTO-135) CryptoOutputStream is always blocking
[ https://issues.apache.org/jira/browse/CRYPTO-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15877240#comment-15877240 ] Dapeng Sun edited comment on CRYPTO-135 at 2/22/17 1:48 AM: Thank [~vanzin] for filing this issue, I think we should fix it. [~junjie] Do you have any comments? was (Author: dapengsun): Thank [~vanzin] for file this issue, I think we should fix it. [~junjie] Do you have any comments? > CryptoOutputStream is always blocking > - > > Key: CRYPTO-135 > URL: https://issues.apache.org/jira/browse/CRYPTO-135 > Project: Commons Crypto > Issue Type: Bug > Components: Stream >Affects Versions: 1.1.0 >Reporter: Marcelo Vanzin > > CRYPTO-125 described a bug where not all data written to the > CryptoOutputStream would make it to the underlying channel if that channel > was non-blocking. > The fix added in that bug makes CryptoOutputStream blocking by doing a busy > loop. This makes it a poor match (not to say unusable) for applications that > use non-blocking channels, since it will turn non-blocking streams into > blocking streams that waste a lot of CPU. > Instead, CryptoOutputStream should correctly implement non-blocking semantics > in its implementation of WritableByteChannel. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CRYPTO-135) CryptoOutputStream is always blocking
[ https://issues.apache.org/jira/browse/CRYPTO-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15877240#comment-15877240 ] Dapeng Sun commented on CRYPTO-135: --- Thank [~vanzin] for file this issue, I think we should fix it. [~junjie] Do you have any comments? > CryptoOutputStream is always blocking > - > > Key: CRYPTO-135 > URL: https://issues.apache.org/jira/browse/CRYPTO-135 > Project: Commons Crypto > Issue Type: Bug > Components: Stream >Affects Versions: 1.1.0 >Reporter: Marcelo Vanzin > > CRYPTO-125 described a bug where not all data written to the > CryptoOutputStream would make it to the underlying channel if that channel > was non-blocking. > The fix added in that bug makes CryptoOutputStream blocking by doing a busy > loop. This makes it a poor match (not to say unusable) for applications that > use non-blocking channels, since it will turn non-blocking streams into > blocking streams that waste a lot of CPU. > Instead, CryptoOutputStream should correctly implement non-blocking semantics > in its implementation of WritableByteChannel. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CRYPTO-129) Change access of instance variables from package private to private (or protected if appropriate)
[ https://issues.apache.org/jira/browse/CRYPTO-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15865374#comment-15865374 ] Dapeng Sun commented on CRYPTO-129: --- Thank [~vanzin], [~s...@apache.org], I'm agreed we should fix it. > Change access of instance variables from package private to private (or > protected if appropriate) > - > > Key: CRYPTO-129 > URL: https://issues.apache.org/jira/browse/CRYPTO-129 > Project: Commons Crypto > Issue Type: Bug >Affects Versions: 1.0.0 >Reporter: Gary Gregory >Assignee: Jianguo Tian > Fix For: 1.1.0 > > > Change access of instance variables from package private to private (or > protected if appropriate). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (CRYPTO-134) CipherByteBufferExample should not truncate the string
[ https://issues.apache.org/jira/browse/CRYPTO-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun reassigned CRYPTO-134: - Assignee: Sebb > CipherByteBufferExample should not truncate the string > -- > > Key: CRYPTO-134 > URL: https://issues.apache.org/jira/browse/CRYPTO-134 > Project: Commons Crypto > Issue Type: Bug > Components: Document >Affects Versions: 1.0.0 >Reporter: Sebb >Assignee: Sebb > Fix For: 1.1.0 > > > CipherByteBufferExample#asString currently truncates the output to 50 bytes. > This was probably a hangover from some debugging, and should be removed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CRYPTO-129) Change access of instance variables from package private to private (or protected if appropriate)
[ https://issues.apache.org/jira/browse/CRYPTO-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15863127#comment-15863127 ] Dapeng Sun commented on CRYPTO-129: --- Hi [~vanzin], it have been committed to master, do you have any idea? > Change access of instance variables from package private to private (or > protected if appropriate) > - > > Key: CRYPTO-129 > URL: https://issues.apache.org/jira/browse/CRYPTO-129 > Project: Commons Crypto > Issue Type: Bug >Affects Versions: 1.0.0 >Reporter: Gary Gregory >Assignee: Jianguo Tian > Fix For: 1.1.0 > > > Change access of instance variables from package private to private (or > protected if appropriate). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CRYPTO-131) Provide FAQ page
[ https://issues.apache.org/jira/browse/CRYPTO-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15700968#comment-15700968 ] Dapeng Sun commented on CRYPTO-131: --- Thank [~britter] and [~kinow] > Provide FAQ page > > > Key: CRYPTO-131 > URL: https://issues.apache.org/jira/browse/CRYPTO-131 > Project: Commons Crypto > Issue Type: Improvement > Components: Document >Reporter: Benedikt Ritter >Assignee: Benedikt Ritter > Fix For: 1.1.0 > > > It would be good to have an FAQ page answering frequently asked questions -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CRYPTO-127) CryptoInputStream#read should handle non-block case
[ https://issues.apache.org/jira/browse/CRYPTO-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun resolved CRYPTO-127. --- Resolution: Fixed Patch committed, thank Xianda. Repository: commons-crypto Updated Branches: refs/heads/master 3adc20723 -> a760177b6 CRYPTO-127: CryptoInputStream#read should handle non-block case Closes #72 from kexianda/inputstream Project: http://git-wip-us.apache.org/repos/asf/commons-crypto/repo Commit: http://git-wip-us.apache.org/repos/asf/commons-crypto/commit/a760177b Tree: http://git-wip-us.apache.org/repos/asf/commons-crypto/tree/a760177b Diff: http://git-wip-us.apache.org/repos/asf/commons-crypto/diff/a760177b Branch: refs/heads/master Commit: a760177b6d1b95bef512902c0b987ace614ab359 Parents: 3adc207 Author: Xianda Ke Authored: Mon Oct 24 11:22:21 2016 +0800 Committer: Sun Dapeng Committed: Mon Nov 14 16:09:05 2016 +0800 > CryptoInputStream#read should handle non-block case > --- > > Key: CRYPTO-127 > URL: https://issues.apache.org/jira/browse/CRYPTO-127 > Project: Commons Crypto > Issue Type: Bug >Reporter: Xianda Ke >Assignee: Xianda Ke > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CRYPTO-129) Change access of instance variables from package private to private (or protected if appropriate)
[ https://issues.apache.org/jira/browse/CRYPTO-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15653209#comment-15653209 ] Dapeng Sun commented on CRYPTO-129: --- Sure, thank [~JonnyR]. Pls send a pull request at github after you finish the development. https://github.com/apache/commons-crypto/blob/master/CONTRIBUTING.md > Change access of instance variables from package private to private (or > protected if appropriate) > - > > Key: CRYPTO-129 > URL: https://issues.apache.org/jira/browse/CRYPTO-129 > Project: Commons Crypto > Issue Type: Bug >Affects Versions: 1.0.0 >Reporter: Gary Gregory > > Change access of instance variables from package private to private (or > protected if appropriate). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CRYPTO-127) CryptoInputStream#read should handle non-block case
[ https://issues.apache.org/jira/browse/CRYPTO-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15642912#comment-15642912 ] Dapeng Sun commented on CRYPTO-127: --- Thank Xianda, I left some comments on your pr https://github.com/apache/commons-crypto/pull/72 > CryptoInputStream#read should handle non-block case > --- > > Key: CRYPTO-127 > URL: https://issues.apache.org/jira/browse/CRYPTO-127 > Project: Commons Crypto > Issue Type: Bug >Reporter: Xianda Ke >Assignee: Xianda Ke > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CRYPTO-128) Make constructors of CryptoOutputStream and CryptoInputStream are public
[ https://issues.apache.org/jira/browse/CRYPTO-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun updated CRYPTO-128: -- Description: for better integrate with Hadoop HDFS, it is better to Make constructors of CryptoOutputStream and CryptoInputStream are public > Make constructors of CryptoOutputStream and CryptoInputStream are public > > > Key: CRYPTO-128 > URL: https://issues.apache.org/jira/browse/CRYPTO-128 > Project: Commons Crypto > Issue Type: Bug > Components: Stream >Affects Versions: 1.0.0 >Reporter: Dapeng Sun >Assignee: Dapeng Sun > > for better integrate with Hadoop HDFS, it is better to Make constructors of > CryptoOutputStream and CryptoInputStream are public -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CRYPTO-128) Make constructors of CryptoOutputStream and CryptoInputStream are public
[ https://issues.apache.org/jira/browse/CRYPTO-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun updated CRYPTO-128: -- Affects Version/s: 1.0.0 > Make constructors of CryptoOutputStream and CryptoInputStream are public > > > Key: CRYPTO-128 > URL: https://issues.apache.org/jira/browse/CRYPTO-128 > Project: Commons Crypto > Issue Type: Bug > Components: Stream >Affects Versions: 1.0.0 >Reporter: Dapeng Sun >Assignee: Dapeng Sun > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CRYPTO-128) Make constructors of CryptoOutputStream and CryptoInputStream are public
[ https://issues.apache.org/jira/browse/CRYPTO-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun updated CRYPTO-128: -- Component/s: Stream > Make constructors of CryptoOutputStream and CryptoInputStream are public > > > Key: CRYPTO-128 > URL: https://issues.apache.org/jira/browse/CRYPTO-128 > Project: Commons Crypto > Issue Type: Bug > Components: Stream >Affects Versions: 1.0.0 >Reporter: Dapeng Sun >Assignee: Dapeng Sun > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CRYPTO-128) Make constructors of CryptoOutputStream and CryptoInputStream are public
Dapeng Sun created CRYPTO-128: - Summary: Make constructors of CryptoOutputStream and CryptoInputStream are public Key: CRYPTO-128 URL: https://issues.apache.org/jira/browse/CRYPTO-128 Project: Commons Crypto Issue Type: Bug Reporter: Dapeng Sun Assignee: Dapeng Sun -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CRYPTO-125) CryptoOutputStream does not call write in a loop when underlying channel works in non-block mode.
[
https://issues.apache.org/jira/browse/CRYPTO-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dapeng Sun resolved CRYPTO-125.
---
Resolution: Fixed
Thank Junjie for the contribution.
Repository: commons-crypto
Updated Branches:
refs/heads/master 77af2da3d -> 3adc20723
CRYPTO-125: CryptoOutputStream does not call write in a loop when underlying
channel works in non-block mode. (Reviewed by Sun, Dapeng and Ke, Xianda)
Closes #71 from cjjnjust:master
Project: http://git-wip-us.apache.org/repos/asf/commons-crypto/repo
Commit: http://git-wip-us.apache.org/repos/asf/commons-crypto/commit/3adc2072
Tree: http://git-wip-us.apache.org/repos/asf/commons-crypto/tree/3adc2072
Diff: http://git-wip-us.apache.org/repos/asf/commons-crypto/diff/3adc2072
Branch: refs/heads/master
Commit: 3adc20723b823bad58a39f7952300538450d3b7c
Parents: 77af2da
Author: Junjie Chen
Authored: Mon Oct 24 10:11:29 2016 +0800
Committer: Sun Dapeng
Committed: Mon Oct 24 10:12:29 2016 +0800
> CryptoOutputStream does not call write in a loop when underlying channel
> works in non-block mode.
> -
>
> Key: CRYPTO-125
> URL: https://issues.apache.org/jira/browse/CRYPTO-125
> Project: Commons Crypto
> Issue Type: Bug
> Components: Stream
>Affects Versions: 1.0.0
>Reporter: Junjie Chen
>Assignee: Junjie Chen
> Fix For: 1.1.0
>
>
> The encrypt function call output.write without loop which lead to data loss
> when creating the output encryption stream with a SocketChannel and works in
> non-block mode.
> As suggested, it should be call as following way:
> while(buf.hasRemaining()) {
> channel.write(buf);
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CRYPTO-125) CryptoOutputStream does not call write in a loop when underlying channel works in non-block mode.
[
https://issues.apache.org/jira/browse/CRYPTO-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dapeng Sun updated CRYPTO-125:
--
Assignee: Junjie Chen
> CryptoOutputStream does not call write in a loop when underlying channel
> works in non-block mode.
> -
>
> Key: CRYPTO-125
> URL: https://issues.apache.org/jira/browse/CRYPTO-125
> Project: Commons Crypto
> Issue Type: Bug
> Components: Stream
>Affects Versions: 1.0.0
>Reporter: Junjie Chen
>Assignee: Junjie Chen
> Fix For: 1.1.0
>
>
> The encrypt function call output.write without loop which lead to data loss
> when creating the output encryption stream with a SocketChannel and works in
> non-block mode.
> As suggested, it should be call as following way:
> while(buf.hasRemaining()) {
> channel.write(buf);
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CRYPTO-125) CryptoOutputStream does not call write in a loop when underlying channel works in non-block mode.
[
https://issues.apache.org/jira/browse/CRYPTO-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dapeng Sun updated CRYPTO-125:
--
Fix Version/s: 1.1.0
> CryptoOutputStream does not call write in a loop when underlying channel
> works in non-block mode.
> -
>
> Key: CRYPTO-125
> URL: https://issues.apache.org/jira/browse/CRYPTO-125
> Project: Commons Crypto
> Issue Type: Bug
> Components: Stream
>Affects Versions: 1.0.0
>Reporter: Junjie Chen
> Fix For: 1.1.0
>
>
> The encrypt function call output.write without loop which lead to data loss
> when creating the output encryption stream with a SocketChannel and works in
> non-block mode.
> As suggested, it should be call as following way:
> while(buf.hasRemaining()) {
> channel.write(buf);
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CRYPTO-60) opensslCipher support GCM mode
[ https://issues.apache.org/jira/browse/CRYPTO-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15581580#comment-15581580 ] Dapeng Sun commented on CRYPTO-60: -- Thank [~kexianda] for the contribution, I will look into it. > opensslCipher support GCM mode > --- > > Key: CRYPTO-60 > URL: https://issues.apache.org/jira/browse/CRYPTO-60 > Project: Commons Crypto > Issue Type: Sub-task >Reporter: Xianda Ke >Assignee: Xianda Ke > Attachments: gcm_design_doc.pdf > > > The interface would look like JCE. In encryption mode, the authenticated tag > information is appended at the end of output. > In decryption mode, the authenticated tag should appended at the end of > input. If the encrypted data is tampered, it will throw an > AEADBadTagException. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CRYPTO-124) Fix JavaCryptoRandom extend java.util.Random
[ https://issues.apache.org/jira/browse/CRYPTO-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun resolved CRYPTO-124. --- Resolution: Fixed Repository: commons-crypto Updated Branches: refs/heads/master e230e30d5 -> 77af2da3d CRYPTO-124: Fix JavaCryptoRandom extend java.util.Random Project: http://git-wip-us.apache.org/repos/asf/commons-crypto/repo Commit: http://git-wip-us.apache.org/repos/asf/commons-crypto/commit/77af2da3 Tree: http://git-wip-us.apache.org/repos/asf/commons-crypto/tree/77af2da3 Diff: http://git-wip-us.apache.org/repos/asf/commons-crypto/diff/77af2da3 > Fix JavaCryptoRandom extend java.util.Random > > > Key: CRYPTO-124 > URL: https://issues.apache.org/jira/browse/CRYPTO-124 > Project: Commons Crypto > Issue Type: Bug >Reporter: Dapeng Sun >Assignee: Dapeng Sun > > JavaCryptoRandom should extend java.util.Random like other CryptoRandom did. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (CRYPTO-124) Fix JavaCryptoRandom extend java.util.Random
[ https://issues.apache.org/jira/browse/CRYPTO-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CRYPTO-124 started by Dapeng Sun. - > Fix JavaCryptoRandom extend java.util.Random > > > Key: CRYPTO-124 > URL: https://issues.apache.org/jira/browse/CRYPTO-124 > Project: Commons Crypto > Issue Type: Bug >Reporter: Dapeng Sun >Assignee: Dapeng Sun > > JavaCryptoRandom should extend java.util.Random like other CryptoRandom did. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CRYPTO-124) Fix JavaCryptoRandom extend java.util.Random
[ https://issues.apache.org/jira/browse/CRYPTO-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun updated CRYPTO-124: -- Summary: Fix JavaCryptoRandom extend java.util.Random (was: JavaCryptoRandom should extend java.util.Random) > Fix JavaCryptoRandom extend java.util.Random > > > Key: CRYPTO-124 > URL: https://issues.apache.org/jira/browse/CRYPTO-124 > Project: Commons Crypto > Issue Type: Bug >Reporter: Dapeng Sun >Assignee: Dapeng Sun > > JavaCryptoRandom should extend java.util.Random like other CryptoRandom did. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CRYPTO-124) JavaCryptoRandom should extend java.util.Random
Dapeng Sun created CRYPTO-124: - Summary: JavaCryptoRandom should extend java.util.Random Key: CRYPTO-124 URL: https://issues.apache.org/jira/browse/CRYPTO-124 Project: Commons Crypto Issue Type: Bug Reporter: Dapeng Sun Assignee: Dapeng Sun JavaCryptoRandom should extend java.util.Random like other CryptoRandom did. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CRYPTO-123) Clean CRYPTO build script
[ https://issues.apache.org/jira/browse/CRYPTO-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun resolved CRYPTO-123. --- Resolution: Fixed Repository: commons-crypto Updated Branches: refs/heads/master 3f6e54994 -> e230e30d5 CRYPTO-123: Clean CRYPTO build script. Project: http://git-wip-us.apache.org/repos/asf/commons-crypto/repo Commit: http://git-wip-us.apache.org/repos/asf/commons-crypto/commit/e230e30d Tree: http://git-wip-us.apache.org/repos/asf/commons-crypto/tree/e230e30d Diff: http://git-wip-us.apache.org/repos/asf/commons-crypto/diff/e230e30d > Clean CRYPTO build script > - > > Key: CRYPTO-123 > URL: https://issues.apache.org/jira/browse/CRYPTO-123 > Project: Commons Crypto > Issue Type: Bug >Reporter: Dapeng Sun >Assignee: Dapeng Sun > > Currently, some build scripts are out of time, like the part of building on > IBM JDK, the latest IBM JDK have fixed the jni issue, we should clean the > script -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CRYPTO-123) Clean CRYPTO build script
[ https://issues.apache.org/jira/browse/CRYPTO-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun updated CRYPTO-123: -- Description: Currently, some build scripts are out of time, like the part of building on IBM JDK, the latest IBM JDK have fixed the jni issue, we should clean the script (was: Currently, some build scripts are out of time, like the part of building on IBM JDK, we should clean the script) > Clean CRYPTO build script > - > > Key: CRYPTO-123 > URL: https://issues.apache.org/jira/browse/CRYPTO-123 > Project: Commons Crypto > Issue Type: Bug >Reporter: Dapeng Sun >Assignee: Dapeng Sun > > Currently, some build scripts are out of time, like the part of building on > IBM JDK, the latest IBM JDK have fixed the jni issue, we should clean the > script -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (CRYPTO-123) Clean CRYPTO build script
[ https://issues.apache.org/jira/browse/CRYPTO-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CRYPTO-123 started by Dapeng Sun. - > Clean CRYPTO build script > - > > Key: CRYPTO-123 > URL: https://issues.apache.org/jira/browse/CRYPTO-123 > Project: Commons Crypto > Issue Type: Bug >Reporter: Dapeng Sun >Assignee: Dapeng Sun > > Currently, some build scripts are out of time, like the part of building on > IBM JDK, we should clean the script -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CRYPTO-123) Clean CRYPTO build script
[ https://issues.apache.org/jira/browse/CRYPTO-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun updated CRYPTO-123: -- Description: Currently, some build scripts are out of time, like the part of building on IBM JDK, we should clean the script > Clean CRYPTO build script > - > > Key: CRYPTO-123 > URL: https://issues.apache.org/jira/browse/CRYPTO-123 > Project: Commons Crypto > Issue Type: Bug >Reporter: Dapeng Sun >Assignee: Dapeng Sun > > Currently, some build scripts are out of time, like the part of building on > IBM JDK, we should clean the script -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CRYPTO-123) Clean CRYPTO build script
Dapeng Sun created CRYPTO-123: - Summary: Clean CRYPTO build script Key: CRYPTO-123 URL: https://issues.apache.org/jira/browse/CRYPTO-123 Project: Commons Crypto Issue Type: Bug Reporter: Dapeng Sun Assignee: Dapeng Sun -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CRYPTO-122) Fix CRYPTO website after 1.0.0
[ https://issues.apache.org/jira/browse/CRYPTO-122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun resolved CRYPTO-122. --- Resolution: Fixed 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 > Fix CRYPTO website after 1.0.0 > -- > > Key: CRYPTO-122 > URL: https://issues.apache.org/jira/browse/CRYPTO-122 > Project: Commons Crypto > Issue Type: Bug > Components: Document >Affects Versions: 1.0.0 >Reporter: Dapeng Sun >Assignee: Dapeng Sun >Priority: Trivial > > 1.Fix the download link > 2.Fix support OS list > 3.Fix a typo on website page > 4.Fix file permission of web cgi script -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CRYPTO-121) Fix CRYPTO website after 1.0.0
[ https://issues.apache.org/jira/browse/CRYPTO-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun closed CRYPTO-121. - Resolution: Duplicate > Fix CRYPTO website after 1.0.0 > -- > > Key: CRYPTO-121 > URL: https://issues.apache.org/jira/browse/CRYPTO-121 > Project: Commons Crypto > Issue Type: Bug > Components: Document >Affects Versions: 1.0.0 >Reporter: Dapeng Sun >Assignee: Dapeng Sun >Priority: Trivial > > 1.Fix the download link > 2.Fix support OS list > 3.Fix a typo on website page > 4.Fix file permission of web cgi script -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CRYPTO-122) Fix CRYPTO website after 1.0.0
Dapeng Sun created CRYPTO-122: - Summary: Fix CRYPTO website after 1.0.0 Key: CRYPTO-122 URL: https://issues.apache.org/jira/browse/CRYPTO-122 Project: Commons Crypto Issue Type: Bug Components: Document Affects Versions: 1.0.0 Reporter: Dapeng Sun Assignee: Dapeng Sun Priority: Trivial 1.Fix the download link 2.Fix support OS list 3.Fix a typo on website page 4.Fix file permission of web cgi script -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CRYPTO-121) Fix CRYPTO website after 1.0.0
Dapeng Sun created CRYPTO-121: - Summary: Fix CRYPTO website after 1.0.0 Key: CRYPTO-121 URL: https://issues.apache.org/jira/browse/CRYPTO-121 Project: Commons Crypto Issue Type: Bug Components: Document Affects Versions: 1.0.0 Reporter: Dapeng Sun Assignee: Dapeng Sun Priority: Trivial 1.Fix the download link 2.Fix support OS list 3.Fix a typo on website page 4.Fix file permission of web cgi script -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CRYPTO-120) Add instructions for native build at wiki
[ https://issues.apache.org/jira/browse/CRYPTO-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun updated CRYPTO-120: -- Summary: Add instructions for native build at wiki (was: The instructions for native build should be added to wiki) > Add instructions for native build at wiki > - > > Key: CRYPTO-120 > URL: https://issues.apache.org/jira/browse/CRYPTO-120 > Project: Commons Crypto > Issue Type: Bug >Reporter: Dapeng Sun >Assignee: Dapeng Sun > > CRYPTO release built the same jar contained in the bin-zip with ALL of the > native libraries for Windows, Mac, and Linux, will add a wiki for it -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CRYPTO-120) The instructions for native build should be added to wiki
Dapeng Sun created CRYPTO-120: - Summary: The instructions for native build should be added to wiki Key: CRYPTO-120 URL: https://issues.apache.org/jira/browse/CRYPTO-120 Project: Commons Crypto Issue Type: Bug Reporter: Dapeng Sun Assignee: Dapeng Sun CRYPTO release built the same jar contained in the bin-zip with ALL of the native libraries for Windows, Mac, and Linux, will add a wiki for it -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CRYPTO-118) Fix pmd and findbugs issues
[ https://issues.apache.org/jira/browse/CRYPTO-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun resolved CRYPTO-118. --- Resolution: Fixed CRYPTO-118: Fix pmd and findbugs issues Project: http://git-wip-us.apache.org/repos/asf/commons-crypto/repo Commit: http://git-wip-us.apache.org/repos/asf/commons-crypto/commit/5a3bf996 Tree: http://git-wip-us.apache.org/repos/asf/commons-crypto/tree/5a3bf996 Diff: http://git-wip-us.apache.org/repos/asf/commons-crypto/diff/5a3bf996 > Fix pmd and findbugs issues > --- > > Key: CRYPTO-118 > URL: https://issues.apache.org/jira/browse/CRYPTO-118 > Project: Commons Crypto > Issue Type: Bug >Reporter: Dapeng Sun >Assignee: Dapeng Sun > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CRYPTO-119) Fix checkstyle issues
[ https://issues.apache.org/jira/browse/CRYPTO-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun resolved CRYPTO-119. --- Resolution: Fixed CRYPTO-119: Fix checkstyle issues Project: http://git-wip-us.apache.org/repos/asf/commons-crypto/repo Commit: http://git-wip-us.apache.org/repos/asf/commons-crypto/commit/ed1b6097 Tree: http://git-wip-us.apache.org/repos/asf/commons-crypto/tree/ed1b6097 Diff: http://git-wip-us.apache.org/repos/asf/commons-crypto/diff/ed1b6097 > Fix checkstyle issues > - > > Key: CRYPTO-119 > URL: https://issues.apache.org/jira/browse/CRYPTO-119 > Project: Commons Crypto > Issue Type: Bug >Reporter: Dapeng Sun >Assignee: Dapeng Sun > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CRYPTO-119) Fix checkstyle issues
Dapeng Sun created CRYPTO-119: - Summary: Fix checkstyle issues Key: CRYPTO-119 URL: https://issues.apache.org/jira/browse/CRYPTO-119 Project: Commons Crypto Issue Type: Bug Reporter: Dapeng Sun Assignee: Dapeng Sun -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CRYPTO-118) Fix pmd&findbugs issues
Dapeng Sun created CRYPTO-118: - Summary: Fix pmd&findbugs issues Key: CRYPTO-118 URL: https://issues.apache.org/jira/browse/CRYPTO-118 Project: Commons Crypto Issue Type: Bug Reporter: Dapeng Sun Assignee: Dapeng Sun -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CRYPTO-118) Fix pmd and findbugs issues
[ https://issues.apache.org/jira/browse/CRYPTO-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun updated CRYPTO-118: -- Summary: Fix pmd and findbugs issues (was: Fix pmd&findbugs issues) > Fix pmd and findbugs issues > --- > > Key: CRYPTO-118 > URL: https://issues.apache.org/jira/browse/CRYPTO-118 > Project: Commons Crypto > Issue Type: Bug >Reporter: Dapeng Sun >Assignee: Dapeng Sun > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CRYPTO-116) Fix compile error at 64 bits windows
[
https://issues.apache.org/jira/browse/CRYPTO-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15383871#comment-15383871
]
Dapeng Sun commented on CRYPTO-116:
---
Committed to master
CRYPTO-116: Fix compile error at 64 bits windows
Project: http://git-wip-us.apache.org/repos/asf/commons-crypto/repo
Commit: http://git-wip-us.apache.org/repos/asf/commons-crypto/commit/7eac68da
Tree: http://git-wip-us.apache.org/repos/asf/commons-crypto/tree/7eac68da
Diff: http://git-wip-us.apache.org/repos/asf/commons-crypto/diff/7eac68da
> Fix compile error at 64 bits windows
>
>
> Key: CRYPTO-116
> URL: https://issues.apache.org/jira/browse/CRYPTO-116
> Project: Commons Crypto
> Issue Type: Bug
>Reporter: Dapeng Sun
>Assignee: Xianda Ke
>
> For mingw64 on windows 64bits, we got the compile error like these:
> {noformat}
> [exec] "C:/Program Files/Java/jdk1.7.0_67/bin/javah" -force -classpath
> target/classes -o
> target/jni-classes/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.h
> org.apache.commons.crypto.random.OpenSslCryptoRandomNative
> [exec] Picked up _JAVA_OPTIONS:
> [exec] In file included from
> C:/msys64/mingw64/x86_64-w64-mingw32/include/guiddef.h:148:0,
> [exec] from
> C:/msys64/mingw64/x86_64-w64-mingw32/include/winnt.h:628,
> [exec] from
> C:/msys64/mingw64/x86_64-w64-mingw32/include/minwindef.h:163,
> [exec] from
> C:/msys64/mingw64/x86_64-w64-mingw32/include/windef.h:8,
> [exec] from
> C:/msys64/mingw64/x86_64-w64-mingw32/include/Windows.h:69,
> [exec] from
> src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h:132,
> [exec] from
> src/main/native/org/apache/commons/crypto/random/org_apache_commons_crypto_random.h:22,
> [exec] from
> src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c:19:
> [exec] C:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:107:3:
> error: 'inline' in empty declaration
> [exec]__CRT_INLINE int __cdecl strncasecmp (const char *__sz1, const
> char *__sz2, size_t __sizeMaxCompare) { return _strnicmp (__sz1, __sz2,
> __sizeMaxCompare); }
> [exec]^
> [exec] C:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:108:3:
> error: 'inline' in empty declaration
> [exec]__CRT_INLINE int __cdecl strcasecmp (const char *__sz1, const
> char *__sz2) { return _stricmp (__sz1, __sz2); }
> [exec]^
> [exec] gcc -I"C:/Program Files/Java/jdk1.7.0_67/include" -Ilib/inc_win
> -O2 -fno-inline-functions -Ilib/include -I/usr/include
> -I"src/main/native/org/apache/commons/crypto/" -I"C:/Program
> Files/Java/jdk1.7.0_67/include/win32"
> -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/OpenSslCryptoRandomNative.c
> -o
> target/commons-crypto-1.0.0-SNAPSHOT-Windows-x86_64/OpenSslCryptoRandomNative.o
> [exec] In file included from
> C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/5.4.0/include/mm_malloc.h:27:0,
> [exec] from
> C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/5.4.0/include/xmmintrin.h:34,
> [exec] from
> C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/5.4.0/include/x86intrin.h:31,
> [exec] from
> C:/msys64/mingw64/x86_64-w64-mingw32/include/winnt.h:1519,
> [exec] from
> C:/msys64/mingw64/x86_64-w64-mingw32/include/minwindef.h:163,
> [exec] from
> C:/msys64/mingw64/x86_64-w64-mingw32/include/windef.h:8,
> [exec] from
> C:/msys64/mingw64/x86_64-w64-mingw32/include/Windows.h:69,
> [exec] from
> src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h:132,
> [exec] from
> src/main/native/org/apache/commons/crypto/random/org_apache_commons_crypto_random.h:22,
> [exec] from
> src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c:19:
> [exec] C:/msys64/mingw64/x86_64-w64-mingw32/include/stdlib.h:313:3:
> error: 'inline' in empty declaration
> [exec]__CRT_INLINE __MINGW_ATTRIB_NORETURN void __cdecl _Exit(int
> status)
> [exec]^
> [exec] C:/msys64/mingw64/x86_64-w64-mingw32/include/stdlib.h:650:3:
> error: 'inline' in empty declaration
> [exec]__MINGW_EXTENSION __CRT_INLINE long long __cdecl llabs(long
> long _j) { return (_j >= 0 ? _j : -_j); }
> [exec]^
> [exec] C:/msys64/mingw64/x86_64-w64-mingw32/include/stdlib.h:668:3:
> error: 'inline' in empty declaration
> [exec]__MINGW_EXTENSION __CRT_I
[jira] [Resolved] (CRYPTO-116) Fix compile error at 64 bits windows
[
https://issues.apache.org/jira/browse/CRYPTO-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dapeng Sun resolved CRYPTO-116.
---
Resolution: Fixed
> Fix compile error at 64 bits windows
>
>
> Key: CRYPTO-116
> URL: https://issues.apache.org/jira/browse/CRYPTO-116
> Project: Commons Crypto
> Issue Type: Bug
>Reporter: Dapeng Sun
>Assignee: Xianda Ke
>
> For mingw64 on windows 64bits, we got the compile error like these:
> {noformat}
> [exec] "C:/Program Files/Java/jdk1.7.0_67/bin/javah" -force -classpath
> target/classes -o
> target/jni-classes/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.h
> org.apache.commons.crypto.random.OpenSslCryptoRandomNative
> [exec] Picked up _JAVA_OPTIONS:
> [exec] In file included from
> C:/msys64/mingw64/x86_64-w64-mingw32/include/guiddef.h:148:0,
> [exec] from
> C:/msys64/mingw64/x86_64-w64-mingw32/include/winnt.h:628,
> [exec] from
> C:/msys64/mingw64/x86_64-w64-mingw32/include/minwindef.h:163,
> [exec] from
> C:/msys64/mingw64/x86_64-w64-mingw32/include/windef.h:8,
> [exec] from
> C:/msys64/mingw64/x86_64-w64-mingw32/include/Windows.h:69,
> [exec] from
> src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h:132,
> [exec] from
> src/main/native/org/apache/commons/crypto/random/org_apache_commons_crypto_random.h:22,
> [exec] from
> src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c:19:
> [exec] C:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:107:3:
> error: 'inline' in empty declaration
> [exec]__CRT_INLINE int __cdecl strncasecmp (const char *__sz1, const
> char *__sz2, size_t __sizeMaxCompare) { return _strnicmp (__sz1, __sz2,
> __sizeMaxCompare); }
> [exec]^
> [exec] C:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:108:3:
> error: 'inline' in empty declaration
> [exec]__CRT_INLINE int __cdecl strcasecmp (const char *__sz1, const
> char *__sz2) { return _stricmp (__sz1, __sz2); }
> [exec]^
> [exec] gcc -I"C:/Program Files/Java/jdk1.7.0_67/include" -Ilib/inc_win
> -O2 -fno-inline-functions -Ilib/include -I/usr/include
> -I"src/main/native/org/apache/commons/crypto/" -I"C:/Program
> Files/Java/jdk1.7.0_67/include/win32"
> -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/OpenSslCryptoRandomNative.c
> -o
> target/commons-crypto-1.0.0-SNAPSHOT-Windows-x86_64/OpenSslCryptoRandomNative.o
> [exec] In file included from
> C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/5.4.0/include/mm_malloc.h:27:0,
> [exec] from
> C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/5.4.0/include/xmmintrin.h:34,
> [exec] from
> C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/5.4.0/include/x86intrin.h:31,
> [exec] from
> C:/msys64/mingw64/x86_64-w64-mingw32/include/winnt.h:1519,
> [exec] from
> C:/msys64/mingw64/x86_64-w64-mingw32/include/minwindef.h:163,
> [exec] from
> C:/msys64/mingw64/x86_64-w64-mingw32/include/windef.h:8,
> [exec] from
> C:/msys64/mingw64/x86_64-w64-mingw32/include/Windows.h:69,
> [exec] from
> src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h:132,
> [exec] from
> src/main/native/org/apache/commons/crypto/random/org_apache_commons_crypto_random.h:22,
> [exec] from
> src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c:19:
> [exec] C:/msys64/mingw64/x86_64-w64-mingw32/include/stdlib.h:313:3:
> error: 'inline' in empty declaration
> [exec]__CRT_INLINE __MINGW_ATTRIB_NORETURN void __cdecl _Exit(int
> status)
> [exec]^
> [exec] C:/msys64/mingw64/x86_64-w64-mingw32/include/stdlib.h:650:3:
> error: 'inline' in empty declaration
> [exec]__MINGW_EXTENSION __CRT_INLINE long long __cdecl llabs(long
> long _j) { return (_j >= 0 ? _j : -_j); }
> [exec]^
> [exec] C:/msys64/mingw64/x86_64-w64-mingw32/include/stdlib.h:668:3:
> error: 'inline' in empty declaration
> [exec]__MINGW_EXTENSION __CRT_INLINE long long __cdecl atoll (const
> char * _c) { return _atoi64 (_c); }
> [exec]^
> [exec] C:/msys64/mingw64/x86_64-w64-mingw32/include/stdlib.h:669:3:
> error: 'inline' in empty declaration
> [exec]__MINGW_EXTENSION __CRT_INLINE char *__cdecl lltoa (long long
> _n, char * _c, int _i) { return _i64toa (_n, _c, _i); }
> [exec]^
> [exec] C:/msys64/mingw64/x
[jira] [Resolved] (CRYPTO-117) Define WINDOWS when _WIN64 and CYGWIN defined
[
https://issues.apache.org/jira/browse/CRYPTO-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dapeng Sun resolved CRYPTO-117.
---
Resolution: Fixed
> Define WINDOWS when _WIN64 and CYGWIN defined
> --
>
> Key: CRYPTO-117
> URL: https://issues.apache.org/jira/browse/CRYPTO-117
> Project: Commons Crypto
> Issue Type: Bug
>Reporter: Dapeng Sun
>Assignee: Dapeng Sun
>
> define WINDOWS when {{__WIN64}} defined
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CRYPTO-117) Define WINDOWS when _WIN64 and CYGWIN defined
[
https://issues.apache.org/jira/browse/CRYPTO-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15383870#comment-15383870
]
Dapeng Sun commented on CRYPTO-117:
---
Committed to master
CRYPTO-117: Define WINDOWS when _WIN64 and CYGWIN defined
Project: http://git-wip-us.apache.org/repos/asf/commons-crypto/repo
Commit: http://git-wip-us.apache.org/repos/asf/commons-crypto/commit/6488aa6e
Tree: http://git-wip-us.apache.org/repos/asf/commons-crypto/tree/6488aa6e
Diff: http://git-wip-us.apache.org/repos/asf/commons-crypto/diff/6488aa6e
> Define WINDOWS when _WIN64 and CYGWIN defined
> --
>
> Key: CRYPTO-117
> URL: https://issues.apache.org/jira/browse/CRYPTO-117
> Project: Commons Crypto
> Issue Type: Bug
>Reporter: Dapeng Sun
>Assignee: Dapeng Sun
>
> define WINDOWS when {{__WIN64}} defined
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CRYPTO-117) Define WINDOWS when __WIN64 defined
[
https://issues.apache.org/jira/browse/CRYPTO-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dapeng Sun updated CRYPTO-117:
--
Summary: Define WINDOWS when __WIN64 defined (was: Define WINDOWS when
{{__WIN64}} defined )
> Define WINDOWS when __WIN64 defined
>
>
> Key: CRYPTO-117
> URL: https://issues.apache.org/jira/browse/CRYPTO-117
> Project: Commons Crypto
> Issue Type: Bug
>Reporter: Dapeng Sun
>Assignee: Dapeng Sun
>
> define WINDOWS when {{__WIN64}} defined
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CRYPTO-117) Define WINDOWS when _WIN64 and CYGWIN defined
[
https://issues.apache.org/jira/browse/CRYPTO-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dapeng Sun updated CRYPTO-117:
--
Summary: Define WINDOWS when _WIN64 and CYGWIN defined (was: Define
WINDOWS when __WIN64 defined )
> Define WINDOWS when _WIN64 and CYGWIN defined
> --
>
> Key: CRYPTO-117
> URL: https://issues.apache.org/jira/browse/CRYPTO-117
> Project: Commons Crypto
> Issue Type: Bug
>Reporter: Dapeng Sun
>Assignee: Dapeng Sun
>
> define WINDOWS when {{__WIN64}} defined
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CRYPTO-117) Compile support for windows 64bits
[
https://issues.apache.org/jira/browse/CRYPTO-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dapeng Sun updated CRYPTO-117:
--
Description: define WINDOWS when {{__WIN64}} defined (was: Set window
flag when __WIN64 defined)
> Compile support for windows 64bits
> --
>
> Key: CRYPTO-117
> URL: https://issues.apache.org/jira/browse/CRYPTO-117
> Project: Commons Crypto
> Issue Type: Bug
>Reporter: Dapeng Sun
>Assignee: Dapeng Sun
>
> define WINDOWS when {{__WIN64}} defined
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CRYPTO-117) Define WINDOWS when {{__WIN64}} defined
[
https://issues.apache.org/jira/browse/CRYPTO-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dapeng Sun updated CRYPTO-117:
--
Summary: Define WINDOWS when {{__WIN64}} defined (was: Compile support
for windows 64bits)
> Define WINDOWS when {{__WIN64}} defined
>
>
> Key: CRYPTO-117
> URL: https://issues.apache.org/jira/browse/CRYPTO-117
> Project: Commons Crypto
> Issue Type: Bug
>Reporter: Dapeng Sun
>Assignee: Dapeng Sun
>
> define WINDOWS when {{__WIN64}} defined
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CRYPTO-117) Compile support for windows 64bits
Dapeng Sun created CRYPTO-117: - Summary: Compile support for windows 64bits Key: CRYPTO-117 URL: https://issues.apache.org/jira/browse/CRYPTO-117 Project: Commons Crypto Issue Type: Bug Reporter: Dapeng Sun Assignee: Dapeng Sun Set window flag when __WIN64 defined -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CRYPTO-116) Fix compile error at 64 bits windows
[
https://issues.apache.org/jira/browse/CRYPTO-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dapeng Sun updated CRYPTO-116:
--
Summary: Fix compile error at 64 bits windows (was: Fix windows 64bits)
> Fix compile error at 64 bits windows
>
>
> Key: CRYPTO-116
> URL: https://issues.apache.org/jira/browse/CRYPTO-116
> Project: Commons Crypto
> Issue Type: Bug
>Reporter: Dapeng Sun
>Assignee: Xianda Ke
>
> For mingw64 on windows 64bits, we got the compile error like these:
> {noformat}
> [exec] "C:/Program Files/Java/jdk1.7.0_67/bin/javah" -force -classpath
> target/classes -o
> target/jni-classes/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.h
> org.apache.commons.crypto.random.OpenSslCryptoRandomNative
> [exec] Picked up _JAVA_OPTIONS:
> [exec] In file included from
> C:/msys64/mingw64/x86_64-w64-mingw32/include/guiddef.h:148:0,
> [exec] from
> C:/msys64/mingw64/x86_64-w64-mingw32/include/winnt.h:628,
> [exec] from
> C:/msys64/mingw64/x86_64-w64-mingw32/include/minwindef.h:163,
> [exec] from
> C:/msys64/mingw64/x86_64-w64-mingw32/include/windef.h:8,
> [exec] from
> C:/msys64/mingw64/x86_64-w64-mingw32/include/Windows.h:69,
> [exec] from
> src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h:132,
> [exec] from
> src/main/native/org/apache/commons/crypto/random/org_apache_commons_crypto_random.h:22,
> [exec] from
> src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c:19:
> [exec] C:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:107:3:
> error: 'inline' in empty declaration
> [exec]__CRT_INLINE int __cdecl strncasecmp (const char *__sz1, const
> char *__sz2, size_t __sizeMaxCompare) { return _strnicmp (__sz1, __sz2,
> __sizeMaxCompare); }
> [exec]^
> [exec] C:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:108:3:
> error: 'inline' in empty declaration
> [exec]__CRT_INLINE int __cdecl strcasecmp (const char *__sz1, const
> char *__sz2) { return _stricmp (__sz1, __sz2); }
> [exec]^
> [exec] gcc -I"C:/Program Files/Java/jdk1.7.0_67/include" -Ilib/inc_win
> -O2 -fno-inline-functions -Ilib/include -I/usr/include
> -I"src/main/native/org/apache/commons/crypto/" -I"C:/Program
> Files/Java/jdk1.7.0_67/include/win32"
> -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/OpenSslCryptoRandomNative.c
> -o
> target/commons-crypto-1.0.0-SNAPSHOT-Windows-x86_64/OpenSslCryptoRandomNative.o
> [exec] In file included from
> C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/5.4.0/include/mm_malloc.h:27:0,
> [exec] from
> C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/5.4.0/include/xmmintrin.h:34,
> [exec] from
> C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/5.4.0/include/x86intrin.h:31,
> [exec] from
> C:/msys64/mingw64/x86_64-w64-mingw32/include/winnt.h:1519,
> [exec] from
> C:/msys64/mingw64/x86_64-w64-mingw32/include/minwindef.h:163,
> [exec] from
> C:/msys64/mingw64/x86_64-w64-mingw32/include/windef.h:8,
> [exec] from
> C:/msys64/mingw64/x86_64-w64-mingw32/include/Windows.h:69,
> [exec] from
> src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h:132,
> [exec] from
> src/main/native/org/apache/commons/crypto/random/org_apache_commons_crypto_random.h:22,
> [exec] from
> src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c:19:
> [exec] C:/msys64/mingw64/x86_64-w64-mingw32/include/stdlib.h:313:3:
> error: 'inline' in empty declaration
> [exec]__CRT_INLINE __MINGW_ATTRIB_NORETURN void __cdecl _Exit(int
> status)
> [exec]^
> [exec] C:/msys64/mingw64/x86_64-w64-mingw32/include/stdlib.h:650:3:
> error: 'inline' in empty declaration
> [exec]__MINGW_EXTENSION __CRT_INLINE long long __cdecl llabs(long
> long _j) { return (_j >= 0 ? _j : -_j); }
> [exec]^
> [exec] C:/msys64/mingw64/x86_64-w64-mingw32/include/stdlib.h:668:3:
> error: 'inline' in empty declaration
> [exec]__MINGW_EXTENSION __CRT_INLINE long long __cdecl atoll (const
> char * _c) { return _atoi64 (_c); }
> [exec]^
> [exec] C:/msys64/mingw64/x86_64-w64-mingw32/include/stdlib.h:669:3:
> error: 'inline' in empty declaration
> [exec]__MINGW_EXTENSION __CRT_INLINE char *__cdecl lltoa (long long
> _n, char * _c, int _i) { return _i64toa (_n, _c, _i); }
[jira] [Updated] (CRYPTO-116) Fix windows 64bits
[
https://issues.apache.org/jira/browse/CRYPTO-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dapeng Sun updated CRYPTO-116:
--
Description:
For mingw64 on windows 64bits, we got the compile error like these:
{noformat}
[exec] "C:/Program Files/Java/jdk1.7.0_67/bin/javah" -force -classpath
target/classes -o
target/jni-classes/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.h
org.apache.commons.crypto.random.OpenSslCryptoRandomNative
[exec] Picked up _JAVA_OPTIONS:
[exec] In file included from
C:/msys64/mingw64/x86_64-w64-mingw32/include/guiddef.h:148:0,
[exec] from
C:/msys64/mingw64/x86_64-w64-mingw32/include/winnt.h:628,
[exec] from
C:/msys64/mingw64/x86_64-w64-mingw32/include/minwindef.h:163,
[exec] from
C:/msys64/mingw64/x86_64-w64-mingw32/include/windef.h:8,
[exec] from
C:/msys64/mingw64/x86_64-w64-mingw32/include/Windows.h:69,
[exec] from
src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h:132,
[exec] from
src/main/native/org/apache/commons/crypto/random/org_apache_commons_crypto_random.h:22,
[exec] from
src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c:19:
[exec] C:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:107:3: error:
'inline' in empty declaration
[exec]__CRT_INLINE int __cdecl strncasecmp (const char *__sz1, const
char *__sz2, size_t __sizeMaxCompare) { return _strnicmp (__sz1, __sz2,
__sizeMaxCompare); }
[exec]^
[exec] C:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:108:3: error:
'inline' in empty declaration
[exec]__CRT_INLINE int __cdecl strcasecmp (const char *__sz1, const
char *__sz2) { return _stricmp (__sz1, __sz2); }
[exec]^
[exec] gcc -I"C:/Program Files/Java/jdk1.7.0_67/include" -Ilib/inc_win -O2
-fno-inline-functions -Ilib/include -I/usr/include
-I"src/main/native/org/apache/commons/crypto/" -I"C:/Program
Files/Java/jdk1.7.0_67/include/win32"
-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/OpenSslCryptoRandomNative.c -o
target/commons-crypto-1.0.0-SNAPSHOT-Windows-x86_64/OpenSslCryptoRandomNative.o
[exec] In file included from
C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/5.4.0/include/mm_malloc.h:27:0,
[exec] from
C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/5.4.0/include/xmmintrin.h:34,
[exec] from
C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/5.4.0/include/x86intrin.h:31,
[exec] from
C:/msys64/mingw64/x86_64-w64-mingw32/include/winnt.h:1519,
[exec] from
C:/msys64/mingw64/x86_64-w64-mingw32/include/minwindef.h:163,
[exec] from
C:/msys64/mingw64/x86_64-w64-mingw32/include/windef.h:8,
[exec] from
C:/msys64/mingw64/x86_64-w64-mingw32/include/Windows.h:69,
[exec] from
src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h:132,
[exec] from
src/main/native/org/apache/commons/crypto/random/org_apache_commons_crypto_random.h:22,
[exec] from
src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c:19:
[exec] C:/msys64/mingw64/x86_64-w64-mingw32/include/stdlib.h:313:3: error:
'inline' in empty declaration
[exec]__CRT_INLINE __MINGW_ATTRIB_NORETURN void __cdecl _Exit(int
status)
[exec]^
[exec] C:/msys64/mingw64/x86_64-w64-mingw32/include/stdlib.h:650:3: error:
'inline' in empty declaration
[exec]__MINGW_EXTENSION __CRT_INLINE long long __cdecl llabs(long long
_j) { return (_j >= 0 ? _j : -_j); }
[exec]^
[exec] C:/msys64/mingw64/x86_64-w64-mingw32/include/stdlib.h:668:3: error:
'inline' in empty declaration
[exec]__MINGW_EXTENSION __CRT_INLINE long long __cdecl atoll (const
char * _c) { return _atoi64 (_c); }
[exec]^
[exec] C:/msys64/mingw64/x86_64-w64-mingw32/include/stdlib.h:669:3: error:
'inline' in empty declaration
[exec]__MINGW_EXTENSION __CRT_INLINE char *__cdecl lltoa (long long
_n, char * _c, int _i) { return _i64toa (_n, _c, _i); }
[exec]^
[exec] C:/msys64/mingw64/x86_64-w64-mingw32/include/stdlib.h:670:3: error:
'inline' in empty declaration
[exec]__MINGW_EXTENSION __CRT_INLINE char *__cdecl ulltoa (unsigned
long long _n, char * _c, int _i) { return _ui64toa (_n, _c, _i); }
[exec]^
[exec] C:/msys64/mingw64/x86_64-w64-mingw32/include/stdlib.h:671:3: error:
'inline' in empty declaration
[exec]__MINGW_EXTENSION __CRT_INLINE long long __cdecl wtoll (const
wchar_t * _w) { return _wtoi64 (_w); }
[exec]^
[ex
[jira] [Created] (CRYPTO-116) Fix windows 64bits
Dapeng Sun created CRYPTO-116: - Summary: Fix windows 64bits Key: CRYPTO-116 URL: https://issues.apache.org/jira/browse/CRYPTO-116 Project: Commons Crypto Issue Type: Bug Reporter: Dapeng Sun Assignee: Xianda Ke -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CRYPTO-70) Compiling on Windows
[ https://issues.apache.org/jira/browse/CRYPTO-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15383848#comment-15383848 ] Dapeng Sun commented on CRYPTO-70: -- Thank Sebb, 32 bits MinGW runs fine on 64 bit windows, but the binary could only use for 32bits, The issue have been fixed at mingw64 and windows 64bit. > Compiling on Windows > > > Key: CRYPTO-70 > URL: https://issues.apache.org/jira/browse/CRYPTO-70 > Project: Commons Crypto > Issue Type: New Feature > Components: Build >Reporter: Gary Gregory >Assignee: Sebb > Fix For: 1.0.0 > > > The build needs to be updated to compile on Windows. TDB if this should be > for 1.0 or 1.1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CRYPTO-70) Compiling on Windows
[
https://issues.apache.org/jira/browse/CRYPTO-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15381920#comment-15381920
]
Dapeng Sun edited comment on CRYPTO-70 at 7/18/16 8:53 AM:
---
Hi Sebb, thank you for your contribution, I have verify it by Windows with
32bit.
But I got some errors when I build it with {{msys2}} and
{{mingw64-x86_64-mingw32}} at 64bit Windows. Have you built it on 64bits
windows successful?
was (Author: dapengsun):
Hi Sebb, thank you for your contribution, I have verify it by Windows with
32bit.
But I got some errors when I build it with {{msys2}} and
{{mingw64-x86_64-mingw32}} at 64bit Windows. Have you built it on windows
64bits successful?
> Compiling on Windows
>
>
> Key: CRYPTO-70
> URL: https://issues.apache.org/jira/browse/CRYPTO-70
> Project: Commons Crypto
> Issue Type: New Feature
> Components: Build
>Reporter: Gary Gregory
>Assignee: Sebb
> Fix For: 1.0.0
>
>
> The build needs to be updated to compile on Windows. TDB if this should be
> for 1.0 or 1.1.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CRYPTO-70) Compiling on Windows
[
https://issues.apache.org/jira/browse/CRYPTO-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15381920#comment-15381920
]
Dapeng Sun edited comment on CRYPTO-70 at 7/18/16 8:52 AM:
---
Hi Sebb, thank you for your contribution, I have verify it by Windows with
32bit.
But I got some errors when I build it with {{msys2}} and
{{mingw64-x86_64-mingw32}} at 64bit Windows. Have you built it on windows
64bits successful?
was (Author: dapengsun):
Hi Sebb, thank you for your contribution, I have verify it by Windows with
32bit.
But I got some errors when I build it with {{msys2}} and
{{mingw64-w64-mingw32}} at 64bit Windows. Have you built it on windows 64bits
successful?
> Compiling on Windows
>
>
> Key: CRYPTO-70
> URL: https://issues.apache.org/jira/browse/CRYPTO-70
> Project: Commons Crypto
> Issue Type: New Feature
> Components: Build
>Reporter: Gary Gregory
>Assignee: Sebb
> Fix For: 1.0.0
>
>
> The build needs to be updated to compile on Windows. TDB if this should be
> for 1.0 or 1.1.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CRYPTO-70) Compiling on Windows
[
https://issues.apache.org/jira/browse/CRYPTO-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15381920#comment-15381920
]
Dapeng Sun commented on CRYPTO-70:
--
Hi Sebb, thank you for your contribution, I have verify it by Windows with
32bit.
But I got some errors when I build it with {{msys2}} and
{{mingw64-w64-mingw32}} at 64bit Windows. Have you built it on windows 64bits
successful?
> Compiling on Windows
>
>
> Key: CRYPTO-70
> URL: https://issues.apache.org/jira/browse/CRYPTO-70
> Project: Commons Crypto
> Issue Type: New Feature
> Components: Build
>Reporter: Gary Gregory
>Assignee: Sebb
> Fix For: 1.0.0
>
>
> The build needs to be updated to compile on Windows. TDB if this should be
> for 1.0 or 1.1.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CRYPTO-70) Compiling on Windows
[ https://issues.apache.org/jira/browse/CRYPTO-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun updated CRYPTO-70: - Assignee: Sebb > Compiling on Windows > > > Key: CRYPTO-70 > URL: https://issues.apache.org/jira/browse/CRYPTO-70 > Project: Commons Crypto > Issue Type: New Feature > Components: Build >Reporter: Gary Gregory >Assignee: Sebb > Fix For: 1.0.0 > > > The build needs to be updated to compile on Windows. TDB if this should be > for 1.0 or 1.1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CRYPTO-111) Include minimal main class to show that the code is working
[ https://issues.apache.org/jira/browse/CRYPTO-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun updated CRYPTO-111: -- Assignee: Sebb > Include minimal main class to show that the code is working > --- > > Key: CRYPTO-111 > URL: https://issues.apache.org/jira/browse/CRYPTO-111 > Project: Commons Crypto > Issue Type: New Feature >Reporter: Sebb >Assignee: Sebb > Fix For: 1.0.0 > > > It would be useful to include a minimal main class which can be used to check > if the code is able to find and use the OpenSSL library. > This could show the Java and OpenSSL version strings, or a suitable error if > the OpenSSL library cannot be found. > Usage would be: > java -jar commons-crypto-1.0.jar -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CRYPTO-103) NativeCodeLoader.getVersion() is not needed
[ https://issues.apache.org/jira/browse/CRYPTO-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun updated CRYPTO-103: -- Assignee: Dapeng Sun > NativeCodeLoader.getVersion() is not needed > --- > > Key: CRYPTO-103 > URL: https://issues.apache.org/jira/browse/CRYPTO-103 > Project: Commons Crypto > Issue Type: Bug >Reporter: Sebb >Assignee: Dapeng Sun > Fix For: 1.0.0 > > > The NativeCodeLoader.getVersion() method seems badly named, as it has nothing > to do with the native code that has been loaded. > It only relates to the version of the Java code in the jar. > I would expect the method to return the version details from the library > itself. > If there is a need to return the Java code version, it should be done from a > method in another class, e.g. Utils or Crypto. Note: also the extraction > should be done once, e.g. using IODH or using a synchronised/volatile lock. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CRYPTO-104) Native code should provide getVersion() methods
[ https://issues.apache.org/jira/browse/CRYPTO-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun updated CRYPTO-104: -- Assignee: Sebb > Native code should provide getVersion() methods > --- > > Key: CRYPTO-104 > URL: https://issues.apache.org/jira/browse/CRYPTO-104 > Project: Commons Crypto > Issue Type: New Feature >Reporter: Sebb >Assignee: Sebb > Fix For: 1.0.0 > > > It would be useful to have getVersion() methods for the native code. > These should be able to return: > - the VERSION used to create the library (i.e. project.version) > - the NAME used to create the library (i.e. project.name) > - the BUILD_DATE might also be useful > - the OpenSSL version string > - the SSLeay_version details > Although the Java jar and the native code are generally built together, they > are distributed as separate files, so it's useful to be able to identify > their versions independently at run-time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CRYPTO-108) OpenSSL does not handle Native code loading failure
[ https://issues.apache.org/jira/browse/CRYPTO-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun updated CRYPTO-108: -- Assignee: Sebb > OpenSSL does not handle Native code loading failure > --- > > Key: CRYPTO-108 > URL: https://issues.apache.org/jira/browse/CRYPTO-108 > Project: Commons Crypto > Issue Type: Bug >Reporter: Sebb >Assignee: Sebb > Fix For: 1.0.0 > > > OpenSSL fails to check if the Native code was loaded successfully before > creating an instance. > This just defers the inevitable failure; it would be better to throw an error > immediately. > Also the code should provide the details of the load faiure -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CRYPTO-112) OpenSslCipher.loadingFailureReason should be a Throwable
[ https://issues.apache.org/jira/browse/CRYPTO-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun updated CRYPTO-112: -- Assignee: Sebb > OpenSslCipher.loadingFailureReason should be a Throwable > > > Key: CRYPTO-112 > URL: https://issues.apache.org/jira/browse/CRYPTO-112 > Project: Commons Crypto > Issue Type: Improvement >Reporter: Sebb >Assignee: Sebb > Fix For: 1.0.0 > > > OpenSslCipher.loadingFailureReason is currently a String; however that loses > a lot of information. It should be a Throwable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CRYPTO-110) Provide component version and name
[ https://issues.apache.org/jira/browse/CRYPTO-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun updated CRYPTO-110: -- Assignee: Sebb > Provide component version and name > -- > > Key: CRYPTO-110 > URL: https://issues.apache.org/jira/browse/CRYPTO-110 > Project: Commons Crypto > Issue Type: New Feature >Reporter: Sebb >Assignee: Sebb > Fix For: 1.0.0 > > > Further to CRYPTO-104, it would be useful to provide the Java component name > and version. This would allow for run-time checks against the JNI portion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CRYPTO-114) exception.c/exception.h are not used
[ https://issues.apache.org/jira/browse/CRYPTO-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun updated CRYPTO-114: -- Assignee: Sebb > exception.c/exception.h are not used > > > Key: CRYPTO-114 > URL: https://issues.apache.org/jira/browse/CRYPTO-114 > Project: Commons Crypto > Issue Type: Bug >Reporter: Sebb >Assignee: Sebb > Fix For: 1.0.0 > > > Looks like exception.c/.h are not actually used. > They don't appear to be compiled by the Makefile, and I cannot find any > references to the methods in the main native sources. > Also the terror(int) method does not look like it would work on Windows > anyway. > Both MacOSX and Windows build and test OK without the files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CRYPTO-113) Improve error reporting by factories
[ https://issues.apache.org/jira/browse/CRYPTO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun updated CRYPTO-113: -- Assignee: Sebb > Improve error reporting by factories > > > Key: CRYPTO-113 > URL: https://issues.apache.org/jira/browse/CRYPTO-113 > Project: Commons Crypto > Issue Type: Bug >Reporter: Sebb >Assignee: Sebb > Fix For: 1.0.0 > > > The Cipher and Random factories currently return errors as the text of the > exception. > This means a lot of the context is lost, particularly the cause of any > Reflection failures. It would be useful to return the last known exception as > the cause. > This would allow further analysis of actual error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CRYPTO-103) NativeCodeLoader.getVersion() seems badly named
[ https://issues.apache.org/jira/browse/CRYPTO-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15367167#comment-15367167 ] Dapeng Sun commented on CRYPTO-103: --- Related PR : https://github.com/apache/commons-crypto/pull/69 > NativeCodeLoader.getVersion() seems badly named > --- > > Key: CRYPTO-103 > URL: https://issues.apache.org/jira/browse/CRYPTO-103 > Project: Commons Crypto > Issue Type: Bug >Reporter: Sebb > > The NativeCodeLoader.getVersion() method seems badly named, as it has nothing > to do with the native code that has been loaded. > It only relates to the version of the Java code in the jar. > I would expect the method to return the version details from the library > itself. > If there is a need to return the Java code version, it should be done from a > method in another class, e.g. Utils or Crypto. Note: also the extraction > should be done once, e.g. using IODH or using a synchronised/volatile lock. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CRYPTO-103) NativeCodeLoader.getVersion() seems badly named
[
https://issues.apache.org/jira/browse/CRYPTO-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15365869#comment-15365869
]
Dapeng Sun edited comment on CRYPTO-103 at 7/7/16 9:29 AM:
---
Thank Sebb, since the version is only used at loading native. I prefer to
change method name to getCryptoVersion and remove the Crypto#getVersion().
{quote} also the extraction should be done once, e.g. using IODH or using a
synchronised/volatile lock.{quote}
In fact, the method is called at static block and it is limited for outside, I
think we don't need to add a lock.
Do you have any comment?
was (Author: dapengsun):
Thank Sebb, since the version is only used at loading native. I prefer to
change method name to getCryptoVersion and remove the Crypto#getVersion().
{quote} also the extraction should be done once, e.g. using IODH or using a
synchronised/volatile lock.{quote}
In fact, the method is called at static block and is limit usage from outside,
I think we don't need to add a lock.
Do you have any comment?
> NativeCodeLoader.getVersion() seems badly named
> ---
>
> Key: CRYPTO-103
> URL: https://issues.apache.org/jira/browse/CRYPTO-103
> Project: Commons Crypto
> Issue Type: Bug
>Reporter: Sebb
>
> The NativeCodeLoader.getVersion() method seems badly named, as it has nothing
> to do with the native code that has been loaded.
> It only relates to the version of the Java code in the jar.
> I would expect the method to return the version details from the library
> itself.
> If there is a need to return the Java code version, it should be done from a
> method in another class, e.g. Utils or Crypto. Note: also the extraction
> should be done once, e.g. using IODH or using a synchronised/volatile lock.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CRYPTO-103) NativeCodeLoader.getVersion() seems badly named
[
https://issues.apache.org/jira/browse/CRYPTO-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15365869#comment-15365869
]
Dapeng Sun edited comment on CRYPTO-103 at 7/7/16 9:29 AM:
---
Thank Sebb, since the version is only used at loading native. I prefer to
change method name to getCryptoVersion and remove the Crypto#getVersion().
{quote} also the extraction should be done once, e.g. using IODH or using a
synchronised/volatile lock.{quote}
In fact, the method is called at static block and it is limited for outside, I
don't think we need to add a lock.
Do you have any comment?
was (Author: dapengsun):
Thank Sebb, since the version is only used at loading native. I prefer to
change method name to getCryptoVersion and remove the Crypto#getVersion().
{quote} also the extraction should be done once, e.g. using IODH or using a
synchronised/volatile lock.{quote}
In fact, the method is called at static block and it is limited for outside, I
think we don't need to add a lock.
Do you have any comment?
> NativeCodeLoader.getVersion() seems badly named
> ---
>
> Key: CRYPTO-103
> URL: https://issues.apache.org/jira/browse/CRYPTO-103
> Project: Commons Crypto
> Issue Type: Bug
>Reporter: Sebb
>
> The NativeCodeLoader.getVersion() method seems badly named, as it has nothing
> to do with the native code that has been loaded.
> It only relates to the version of the Java code in the jar.
> I would expect the method to return the version details from the library
> itself.
> If there is a need to return the Java code version, it should be done from a
> method in another class, e.g. Utils or Crypto. Note: also the extraction
> should be done once, e.g. using IODH or using a synchronised/volatile lock.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CRYPTO-103) NativeCodeLoader.getVersion() seems badly named
[
https://issues.apache.org/jira/browse/CRYPTO-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15365869#comment-15365869
]
Dapeng Sun commented on CRYPTO-103:
---
Thank Sebb, since the version is only used at loading native. I prefer to
change method name to getCryptoVersion and remove the Crypto#getVersion().
{quote} also the extraction should be done once, e.g. using IODH or using a
synchronised/volatile lock.{quote}
In fact, the method is called at static block and is limit usage from outside,
I think we don't need to add a lock.
Do you have any comment?
> NativeCodeLoader.getVersion() seems badly named
> ---
>
> Key: CRYPTO-103
> URL: https://issues.apache.org/jira/browse/CRYPTO-103
> Project: Commons Crypto
> Issue Type: Bug
>Reporter: Sebb
>
> The NativeCodeLoader.getVersion() method seems badly named, as it has nothing
> to do with the native code that has been loaded.
> It only relates to the version of the Java code in the jar.
> I would expect the method to return the version details from the library
> itself.
> If there is a need to return the Java code version, it should be done from a
> method in another class, e.g. Utils or Crypto. Note: also the extraction
> should be done once, e.g. using IODH or using a synchronised/volatile lock.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CRYPTO-109) Move Openssl JNA to feature branch
[ https://issues.apache.org/jira/browse/CRYPTO-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun resolved CRYPTO-109. --- Resolution: Won't Fix > Move Openssl JNA to feature branch > -- > > Key: CRYPTO-109 > URL: https://issues.apache.org/jira/browse/CRYPTO-109 > Project: Commons Crypto > Issue Type: Bug >Reporter: Dapeng Sun >Assignee: Dapeng Sun > > JNA is an important feature. > Since it have some bugs like causing JVM crash, the target of JNA should be > next release(after 1.0.0). We should move the related code to feature branch > currently. > If JNA feature is strong demanded, we can speed up the progress of merging > JNA feature branch to master and make another release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CRYPTO-109) Move Openssl JNA to feature branch
[
https://issues.apache.org/jira/browse/CRYPTO-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15365800#comment-15365800
]
Dapeng Sun commented on CRYPTO-109:
---
Thank Sebb for your comments.
{quote}
The implementation is not currently included in the factory enums, and is not a
default, so users have to specifically request it.
{quote}
The reason sound good to me.
> Move Openssl JNA to feature branch
> --
>
> Key: CRYPTO-109
> URL: https://issues.apache.org/jira/browse/CRYPTO-109
> Project: Commons Crypto
> Issue Type: Bug
>Reporter: Dapeng Sun
>Assignee: Dapeng Sun
>
> JNA is an important feature.
> Since it have some bugs like causing JVM crash, the target of JNA should be
> next release(after 1.0.0). We should move the related code to feature branch
> currently.
> If JNA feature is strong demanded, we can speed up the progress of merging
> JNA feature branch to master and make another release.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CRYPTO-96) OpenSSL Random implementation silently falls back to Java
[ https://issues.apache.org/jira/browse/CRYPTO-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun resolved CRYPTO-96. -- Resolution: Fixed CRYPTO-96: OpenSSL Random implementation silently falls back to Java Fixes #66 Project: http://git-wip-us.apache.org/repos/asf/commons-crypto/repo Commit: http://git-wip-us.apache.org/repos/asf/commons-crypto/commit/34df7306 Tree: http://git-wip-us.apache.org/repos/asf/commons-crypto/tree/34df7306 Diff: http://git-wip-us.apache.org/repos/asf/commons-crypto/diff/34df7306 > OpenSSL Random implementation silently falls back to Java > - > > Key: CRYPTO-96 > URL: https://issues.apache.org/jira/browse/CRYPTO-96 > Project: Commons Crypto > Issue Type: Bug >Reporter: Sebb >Assignee: Dapeng Sun > > The OpensslRandom class silently falls back to using the Java implementation > if the native code is loaded but the nextRandBytes method fails. > This seems wrong as it can cause unexpected results and mask problems. > The corresponding OpensslCipher class does not fall back to JCE. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CRYPTO-109) Move Openssl JNA to feature branch
[ https://issues.apache.org/jira/browse/CRYPTO-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15364022#comment-15364022 ] Dapeng Sun edited comment on CRYPTO-109 at 7/6/16 9:06 AM: --- Hi [~s...@apache.org], I will start to move the code if you agreed, do you have any comments? was (Author: dapengsun): Hi Sebb, I will start to move the code if you agreed, do you have any comments? [~s...@apache.org] > Move Openssl JNA to feature branch > -- > > Key: CRYPTO-109 > URL: https://issues.apache.org/jira/browse/CRYPTO-109 > Project: Commons Crypto > Issue Type: Bug >Reporter: Dapeng Sun >Assignee: Dapeng Sun > > JNA is an important feature. > Since it have some bugs like causing JVM crash, the target of JNA should be > next release(after 1.0.0). We should move the related code to feature branch > currently. > If JNA feature is strong demanded, we can speed up the progress of merging > JNA feature branch to master and make another release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CRYPTO-109) Move Openssl JNA to feature branch
[ https://issues.apache.org/jira/browse/CRYPTO-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15364022#comment-15364022 ] Dapeng Sun commented on CRYPTO-109: --- Hi Sebb, I will start to move the code if you agreed, do you have any comments? > Move Openssl JNA to feature branch > -- > > Key: CRYPTO-109 > URL: https://issues.apache.org/jira/browse/CRYPTO-109 > Project: Commons Crypto > Issue Type: Bug >Reporter: Dapeng Sun >Assignee: Dapeng Sun > > JNA is an important feature. > Since it have some bugs like causing JVM crash, the target of JNA should be > next release(after 1.0.0). We should move the related code to feature branch > currently. > If JNA feature is strong demanded, we can speed up the progress of merging > JNA feature branch to master and make another release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CRYPTO-109) Move Openssl JNA to feature branch
[ https://issues.apache.org/jira/browse/CRYPTO-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15364022#comment-15364022 ] Dapeng Sun edited comment on CRYPTO-109 at 7/6/16 9:05 AM: --- Hi Sebb, I will start to move the code if you agreed, do you have any comments? [~s...@apache.org] was (Author: dapengsun): Hi Sebb, I will start to move the code if you agreed, do you have any comments? > Move Openssl JNA to feature branch > -- > > Key: CRYPTO-109 > URL: https://issues.apache.org/jira/browse/CRYPTO-109 > Project: Commons Crypto > Issue Type: Bug >Reporter: Dapeng Sun >Assignee: Dapeng Sun > > JNA is an important feature. > Since it have some bugs like causing JVM crash, the target of JNA should be > next release(after 1.0.0). We should move the related code to feature branch > currently. > If JNA feature is strong demanded, we can speed up the progress of merging > JNA feature branch to master and make another release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CRYPTO-109) Move Openssl JNA to feature branch
Dapeng Sun created CRYPTO-109: - Summary: Move Openssl JNA to feature branch Key: CRYPTO-109 URL: https://issues.apache.org/jira/browse/CRYPTO-109 Project: Commons Crypto Issue Type: Bug Reporter: Dapeng Sun JNA is an important feature. Since it have some bugs like causing JVM crash, the target of JNA should be next release(after 1.0.0). We should move the related code to feature branch currently. If JNA feature is strong demanded, we can speed up the progress of merging JNA feature branch to master and make another release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CRYPTO-109) Move Openssl JNA to feature branch
[ https://issues.apache.org/jira/browse/CRYPTO-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun reassigned CRYPTO-109: - Assignee: Dapeng Sun > Move Openssl JNA to feature branch > -- > > Key: CRYPTO-109 > URL: https://issues.apache.org/jira/browse/CRYPTO-109 > Project: Commons Crypto > Issue Type: Bug >Reporter: Dapeng Sun >Assignee: Dapeng Sun > > JNA is an important feature. > Since it have some bugs like causing JVM crash, the target of JNA should be > next release(after 1.0.0). We should move the related code to feature branch > currently. > If JNA feature is strong demanded, we can speed up the progress of merging > JNA feature branch to master and make another release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CRYPTO-92) Handling default properties; allow SystemProperties to be ignored
[ https://issues.apache.org/jira/browse/CRYPTO-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun updated CRYPTO-92: - Assignee: Dapeng Sun (was: Sebb) > Handling default properties; allow SystemProperties to be ignored > - > > Key: CRYPTO-92 > URL: https://issues.apache.org/jira/browse/CRYPTO-92 > Project: Commons Crypto > Issue Type: Improvement >Reporter: Sebb >Assignee: Dapeng Sun > Fix For: 1.0.0 > > > The code currently checks both local Properties and SystemProperties in > several places. > This is unnecessary, as the Properties class already supports the notion of > property defaults, as these can be passed in to the constructor. > I think it would be better to drop the specific check of the SystemProperties. > This would be more flexible, as the user could decide whether or not to allow > the use of SystemProperties or some other set of defaults. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CRYPTO-90) Utils loads system properties during class loading
[ https://issues.apache.org/jira/browse/CRYPTO-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun updated CRYPTO-90: - Assignee: Dapeng Sun (was: Sebb) > Utils loads system properties during class loading > -- > > Key: CRYPTO-90 > URL: https://issues.apache.org/jira/browse/CRYPTO-90 > Project: Commons Crypto > Issue Type: Bug >Reporter: Sebb >Assignee: Dapeng Sun > Fix For: 1.0.0 > > > The Utils class reads properties from a properties file if it exists, and > adds them to the set of System properties. > There are several problems with this: > - there's no way of knowing exactly when the properties will be processed, > because it depends when the Utils class is first used > - generally it's a bad idea to update System properties. > - updates to System properties require additional privileges, so the > behaviour of the code will depend on the environment in which it is run. > - the code catches Throwable, which is not allowed. > If there is a use case for supporting a properties file, it should be > processed at a predictable stage in the code, should be done before > command-line parameters are processed, and should not require updating System > properties. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CRYPTO-95) Code should never catch Throwable
[ https://issues.apache.org/jira/browse/CRYPTO-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun updated CRYPTO-95: - Assignee: Sebb > Code should never catch Throwable > - > > Key: CRYPTO-95 > URL: https://issues.apache.org/jira/browse/CRYPTO-95 > Project: Commons Crypto > Issue Type: Bug >Reporter: Sebb >Assignee: Sebb > Fix For: 1.0.0 > > > As a general rule, code should never catch Throwable or Error, only Exception. > Sometimes it is necessary to catch more than just Exception, but if so, the > code must be careful to rethrow certain errors, e.g. > ThreadDeath > VirtualMachineError > There may be some others > If the throwable is not logged, then it's vital to ensure that only the > appropriate ones are swallowed. > But it is better to be explicit and only catch errors which are safe to > handle. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CRYPTO-92) Handling default properties; allow SystemProperties to be ignored
[ https://issues.apache.org/jira/browse/CRYPTO-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun updated CRYPTO-92: - Assignee: Sebb > Handling default properties; allow SystemProperties to be ignored > - > > Key: CRYPTO-92 > URL: https://issues.apache.org/jira/browse/CRYPTO-92 > Project: Commons Crypto > Issue Type: Improvement >Reporter: Sebb >Assignee: Sebb > Fix For: 1.0.0 > > > The code currently checks both local Properties and SystemProperties in > several places. > This is unnecessary, as the Properties class already supports the notion of > property defaults, as these can be passed in to the constructor. > I think it would be better to drop the specific check of the SystemProperties. > This would be more flexible, as the user could decide whether or not to allow > the use of SystemProperties or some other set of defaults. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CRYPTO-90) Utils loads system properties during class loading
[ https://issues.apache.org/jira/browse/CRYPTO-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun updated CRYPTO-90: - Assignee: Sebb > Utils loads system properties during class loading > -- > > Key: CRYPTO-90 > URL: https://issues.apache.org/jira/browse/CRYPTO-90 > Project: Commons Crypto > Issue Type: Bug >Reporter: Sebb >Assignee: Sebb > Fix For: 1.0.0 > > > The Utils class reads properties from a properties file if it exists, and > adds them to the set of System properties. > There are several problems with this: > - there's no way of knowing exactly when the properties will be processed, > because it depends when the Utils class is first used > - generally it's a bad idea to update System properties. > - updates to System properties require additional privileges, so the > behaviour of the code will depend on the environment in which it is run. > - the code catches Throwable, which is not allowed. > If there is a use case for supporting a properties file, it should be > processed at a predictable stage in the code, should be done before > command-line parameters are processed, and should not require updating System > properties. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CRYPTO-100) Makefile does not need to include VERSION file
[ https://issues.apache.org/jira/browse/CRYPTO-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun updated CRYPTO-100: -- Assignee: Sebb > Makefile does not need to include VERSION file > -- > > Key: CRYPTO-100 > URL: https://issues.apache.org/jira/browse/CRYPTO-100 > Project: Commons Crypto > Issue Type: Improvement >Reporter: Sebb >Assignee: Sebb > Fix For: 1.0.0 > > > The VERSION file is purely used to copy project.version into the VERSION > variable used in the makefile. > This is unnecessary, as the value can easily be passed in as an environment > variable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CRYPTO-101) Makefile does not use correct PATH separator for Windows
[ https://issues.apache.org/jira/browse/CRYPTO-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun updated CRYPTO-101: -- Assignee: Sebb > Makefile does not use correct PATH separator for Windows > > > Key: CRYPTO-101 > URL: https://issues.apache.org/jira/browse/CRYPTO-101 > Project: Commons Crypto > Issue Type: Bug >Reporter: Sebb >Assignee: Sebb > Fix For: 1.0.0 > > > Makefile.common defines the variable 'sep' but does not use it. > Makefile uses the separator ':' for paths; this is not valid on Windows. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CRYPTO-105) Eliminate Configuration class
[ https://issues.apache.org/jira/browse/CRYPTO-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun updated CRYPTO-105: -- Assignee: Sebb > Eliminate Configuration class > - > > Key: CRYPTO-105 > URL: https://issues.apache.org/jira/browse/CRYPTO-105 > Project: Commons Crypto > Issue Type: Improvement >Reporter: Sebb >Assignee: Sebb > Fix For: 1.0.0 > > > As per discussion on the mailing list the Configuration class does not serve > a particularly useful purpose. > Several of the entries are internal use only, and the KEY entries belong more > naturally in the classes that use the properties, e.g. the relevant factory > classes. > This also allows many of the KEY names to be shortened as they are now > qualified by the class name where they are defined -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CRYPTO-102) Makefile.common defines JAVA/JAVAH/JAVAC incorrectly for Windows
[ https://issues.apache.org/jira/browse/CRYPTO-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun updated CRYPTO-102: -- Assignee: Sebb > Makefile.common defines JAVA/JAVAH/JAVAC incorrectly for Windows > > > Key: CRYPTO-102 > URL: https://issues.apache.org/jira/browse/CRYPTO-102 > Project: Commons Crypto > Issue Type: Bug >Reporter: Sebb >Assignee: Sebb > Fix For: 1.0.0 > > > Makefile.common defines the following: > JAVA := "$$JAVA_HOME/bin/java" > JAVAC := "$$JAVA_HOME/bin/javac" > JAVAH := "$$JAVA_HOME/bin/javah" > This results in the the following being used at run-time: > "$JAVA_HOME/bin/java" > etc > This is OK for shells that support $NAME as a variable reference; Windows for > one does not. > The variables should be resolved at definition time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CRYPTO-106) CryptoRandomFactory only handles ClassCast and ClassNotFound
[ https://issues.apache.org/jira/browse/CRYPTO-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun updated CRYPTO-106: -- Assignee: Sebb > CryptoRandomFactory only handles ClassCast and ClassNotFound > > > Key: CRYPTO-106 > URL: https://issues.apache.org/jira/browse/CRYPTO-106 > Project: Commons Crypto > Issue Type: Bug >Reporter: Sebb >Assignee: Sebb > Fix For: 1.0.0 > > > The RandomFactory getCryptoRandom method only handles ClassCast and > ClassNotFound. > It ought to handle all other exceptions as per the corresponding > CipherFactory. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CRYPTO-99) Makefile clean removes too much
[
https://issues.apache.org/jira/browse/CRYPTO-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dapeng Sun updated CRYPTO-99:
-
Assignee: Sebb
> Makefile clean removes too much
> ---
>
> Key: CRYPTO-99
> URL: https://issues.apache.org/jira/browse/CRYPTO-99
> Project: Commons Crypto
> Issue Type: Bug
>Reporter: Sebb
>Assignee: Sebb
>
> The clean target currently consist of:
> {code}
> clean:
> rm -rf $(TARGET)
> rm -rf $(COMMONS_CRYPTO_OUT)
> {code}
> This removes some input files that it needs and anyway COMMONS_CRYPTO_OUT is
> under TARGET
> It should only drop the files it actually creates.
> For example:
> {code}
> clean:
> rm -rf $(TARGET)/jni-classes
> rm -rf $(COMMONS_CRYPTO_OUT)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CRYPTO-97) Code uses System.err/System.out
[
https://issues.apache.org/jira/browse/CRYPTO-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dapeng Sun reassigned CRYPTO-97:
Assignee: Dapeng Sun
> Code uses System.err/System.out
> ---
>
> Key: CRYPTO-97
> URL: https://issues.apache.org/jira/browse/CRYPTO-97
> Project: Commons Crypto
> Issue Type: Bug
>Reporter: Sebb
>Assignee: Dapeng Sun
> Fix For: 1.0.0
>
>
> There are several instances where the code writes to System.err or System.out
> This is not generally useful in library code.
> A better way needs to be found to report the information, if it is actually
> needed.
> Locations are:
> org/apache/commons/crypto/NativeCodeLoader.java
> 197:e.printStackTrace(System.err);
> 229:System.err.println(e);
> org/apache/commons/crypto/utils/Utils.java
> 76:System.err.println("Could not load '"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CRYPTO-107) NativeCodeLoader fails to handle UnsatisfiedLinkError
[ https://issues.apache.org/jira/browse/CRYPTO-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun updated CRYPTO-107: -- Assignee: Sebb > NativeCodeLoader fails to handle UnsatisfiedLinkError > - > > Key: CRYPTO-107 > URL: https://issues.apache.org/jira/browse/CRYPTO-107 > Project: Commons Crypto > Issue Type: Bug >Reporter: Sebb >Assignee: Sebb > Fix For: 1.0.0 > > > UnsatisfiedLinkError can be returned by System.loadLibrary and System.load. > The code needs to catch this. > It would also be useful to save the exception and provide a means to access > it when loading fails. > It's also rather difficult to unit test the code as the class can only be > loaded once per run. Moving the bulk of the static block code into a > package-protected method would help here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CRYPTO-98) Makefile does not use MVN or TAR variables
[ https://issues.apache.org/jira/browse/CRYPTO-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun reassigned CRYPTO-98: Assignee: Dapeng Sun > Makefile does not use MVN or TAR variables > -- > > Key: CRYPTO-98 > URL: https://issues.apache.org/jira/browse/CRYPTO-98 > Project: Commons Crypto > Issue Type: Bug >Reporter: Sebb >Assignee: Dapeng Sun > Fix For: 1.0.0 > > > The Makefile defines variables for MVN and TAR but does not appear to use > them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CRYPTO-98) Makefile does not use MVN or TAR variables
[ https://issues.apache.org/jira/browse/CRYPTO-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361087#comment-15361087 ] Dapeng Sun commented on CRYPTO-98: -- Thank Sebb for catching it, PR is https://github.com/apache/commons-crypto/pull/68 > Makefile does not use MVN or TAR variables > -- > > Key: CRYPTO-98 > URL: https://issues.apache.org/jira/browse/CRYPTO-98 > Project: Commons Crypto > Issue Type: Bug >Reporter: Sebb > > The Makefile defines variables for MVN and TAR but does not appear to use > them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CRYPTO-97) Code uses System.err/System.out
[
https://issues.apache.org/jira/browse/CRYPTO-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361079#comment-15361079
]
Dapeng Sun commented on CRYPTO-97:
--
PR is https://github.com/apache/commons-crypto/pull/67
> Code uses System.err/System.out
> ---
>
> Key: CRYPTO-97
> URL: https://issues.apache.org/jira/browse/CRYPTO-97
> Project: Commons Crypto
> Issue Type: Bug
>Reporter: Sebb
>
> There are several instances where the code writes to System.err or System.out
> This is not generally useful in library code.
> A better way needs to be found to report the information, if it is actually
> needed.
> Locations are:
> org/apache/commons/crypto/NativeCodeLoader.java
> 197:e.printStackTrace(System.err);
> 229:System.err.println(e);
> org/apache/commons/crypto/utils/Utils.java
> 76:System.err.println("Could not load '"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CRYPTO-97) Code uses System.err/System.out
[
https://issues.apache.org/jira/browse/CRYPTO-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361078#comment-15361078
]
Dapeng Sun commented on CRYPTO-97:
--
Hi Sebb, I think we can remove these information
> Code uses System.err/System.out
> ---
>
> Key: CRYPTO-97
> URL: https://issues.apache.org/jira/browse/CRYPTO-97
> Project: Commons Crypto
> Issue Type: Bug
>Reporter: Sebb
>
> There are several instances where the code writes to System.err or System.out
> This is not generally useful in library code.
> A better way needs to be found to report the information, if it is actually
> needed.
> Locations are:
> org/apache/commons/crypto/NativeCodeLoader.java
> 197:e.printStackTrace(System.err);
> 229:System.err.println(e);
> org/apache/commons/crypto/utils/Utils.java
> 76:System.err.println("Could not load '"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CRYPTO-96) OpenSSL Random implementation silently falls back to Java
[ https://issues.apache.org/jira/browse/CRYPTO-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361064#comment-15361064 ] Dapeng Sun commented on CRYPTO-96: -- Thank Sebb， PR created https://github.com/apache/commons-crypto/pull/66 > OpenSSL Random implementation silently falls back to Java > - > > Key: CRYPTO-96 > URL: https://issues.apache.org/jira/browse/CRYPTO-96 > Project: Commons Crypto > Issue Type: Bug >Reporter: Sebb >Assignee: Dapeng Sun > > The OpensslRandom class silently falls back to using the Java implementation > if the native code is loaded but the nextRandBytes method fails. > This seems wrong as it can cause unexpected results and mask problems. > The corresponding OpensslCipher class does not fall back to JCE. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CRYPTO-96) OpenSSL Random implementation silently falls back to Java
[ https://issues.apache.org/jira/browse/CRYPTO-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun reassigned CRYPTO-96: Assignee: Dapeng Sun > OpenSSL Random implementation silently falls back to Java > - > > Key: CRYPTO-96 > URL: https://issues.apache.org/jira/browse/CRYPTO-96 > Project: Commons Crypto > Issue Type: Bug >Reporter: Sebb >Assignee: Dapeng Sun > > The OpensslRandom class silently falls back to using the Java implementation > if the native code is loaded but the nextRandBytes method fails. > This seems wrong as it can cause unexpected results and mask problems. > The corresponding OpensslCipher class does not fall back to JCE. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (CRYPTO-63) Add JNA binding
[
https://issues.apache.org/jira/browse/CRYPTO-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dapeng Sun updated CRYPTO-63:
-
Comment: was deleted
(was: The Unit Tests fixed at
{noformat}
CRYPTO-63: Add JNA binding (issue fix)
Project: http://git-wip-us.apache.org/repos/asf/commons-crypto/repo
Commit: http://git-wip-us.apache.org/repos/asf/commons-crypto/commit/5b4c302d
Tree: http://git-wip-us.apache.org/repos/asf/commons-crypto/tree/5b4c302d
Diff: http://git-wip-us.apache.org/repos/asf/commons-crypto/diff/5b4c302d
{noformat})
> Add JNA binding
> ---
>
> Key: CRYPTO-63
> URL: https://issues.apache.org/jira/browse/CRYPTO-63
> Project: Commons Crypto
> Issue Type: Improvement
>Reporter: Hendrik Saly
>Assignee: Hendrik Saly
>
> Needs benchmarking before merge.
> PR https://github.com/apache/commons-crypto/pull/47
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CRYPTO-63) Add JNA binding
[
https://issues.apache.org/jira/browse/CRYPTO-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15356606#comment-15356606
]
Dapeng Sun commented on CRYPTO-63:
--
The Unit Tests fixed at
{noformat}
CRYPTO-63: Add JNA binding (issue fix)
Project: http://git-wip-us.apache.org/repos/asf/commons-crypto/repo
Commit: http://git-wip-us.apache.org/repos/asf/commons-crypto/commit/5b4c302d
Tree: http://git-wip-us.apache.org/repos/asf/commons-crypto/tree/5b4c302d
Diff: http://git-wip-us.apache.org/repos/asf/commons-crypto/diff/5b4c302d
{noformat}
> Add JNA binding
> ---
>
> Key: CRYPTO-63
> URL: https://issues.apache.org/jira/browse/CRYPTO-63
> Project: Commons Crypto
> Issue Type: Improvement
>Reporter: Hendrik Saly
>Assignee: Hendrik Saly
>
> Needs benchmarking before merge.
> PR https://github.com/apache/commons-crypto/pull/47
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CRYPTO-63) Add JNA binding
[
https://issues.apache.org/jira/browse/CRYPTO-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15356542#comment-15356542
]
Dapeng Sun edited comment on CRYPTO-63 at 6/30/16 5:28 AM:
---
Thank Sebb for your comments,
{quote}
Note that JNA covers far more OSes than the JNI code, so it may be the only way
to make OpenSSL available on many platforms.
Unless there are serious problems with it, I think it would be better to
include the code, but include a warning in the documentation / release notes
that it may not be as reliable or performant as the JNI code. Users won't get
the JNA version unless they ask for it. For some platforms it may be the best
choice.
{quote}
I'm agree that JNA is an important feature, but I think move to next release
should be also reasonable. If JNA feature is strong demanded, we can speed up
the progress of the JNA release.
was (Author: dapengsun):
Thank Sebb,
{quote}
Note that JNA covers far more OSes than the JNI code, so it may be the only way
to make OpenSSL available on many platforms.
Unless there are serious problems with it, I think it would be better to
include the code, but include a warning in the documentation / release notes
that it may not be as reliable or performant as the JNI code. Users won't get
the JNA version unless they ask for it. For some platforms it may be the best
choice.
{quote}
I'm agree that JNA is an important feature, but I think move to next release
should be also reasonable. If JNA feature is strong demanded, we can speed up
the progress of the JNA release.
> Add JNA binding
> ---
>
> Key: CRYPTO-63
> URL: https://issues.apache.org/jira/browse/CRYPTO-63
> Project: Commons Crypto
> Issue Type: Improvement
>Reporter: Hendrik Saly
>Assignee: Hendrik Saly
>
> Needs benchmarking before merge.
> PR https://github.com/apache/commons-crypto/pull/47
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CRYPTO-63) Add JNA binding
[
https://issues.apache.org/jira/browse/CRYPTO-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15356542#comment-15356542
]
Dapeng Sun edited comment on CRYPTO-63 at 6/30/16 5:28 AM:
---
Thank Sebb for your comments,
{quote}
Note that JNA covers far more OSes than the JNI code, so it may be the only way
to make OpenSSL available on many platforms.
Unless there are serious problems with it, I think it would be better to
include the code, but include a warning in the documentation / release notes
that it may not be as reliable or performant as the JNI code. Users won't get
the JNA version unless they ask for it. For some platforms it may be the best
choice.
{quote}
I'm agree that JNA is an important feature, but I think moving JNA to next
release should be also reasonable. If JNA feature is strong demanded, we can
speed up the progress of the JNA release.
was (Author: dapengsun):
Thank Sebb for your comments,
{quote}
Note that JNA covers far more OSes than the JNI code, so it may be the only way
to make OpenSSL available on many platforms.
Unless there are serious problems with it, I think it would be better to
include the code, but include a warning in the documentation / release notes
that it may not be as reliable or performant as the JNI code. Users won't get
the JNA version unless they ask for it. For some platforms it may be the best
choice.
{quote}
I'm agree that JNA is an important feature, but I think move to next release
should be also reasonable. If JNA feature is strong demanded, we can speed up
the progress of the JNA release.
> Add JNA binding
> ---
>
> Key: CRYPTO-63
> URL: https://issues.apache.org/jira/browse/CRYPTO-63
> Project: Commons Crypto
> Issue Type: Improvement
>Reporter: Hendrik Saly
>Assignee: Hendrik Saly
>
> Needs benchmarking before merge.
> PR https://github.com/apache/commons-crypto/pull/47
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CRYPTO-63) Add JNA binding
[
https://issues.apache.org/jira/browse/CRYPTO-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15356542#comment-15356542
]
Dapeng Sun commented on CRYPTO-63:
--
Thank Sebb,
{quote}
Note that JNA covers far more OSes than the JNI code, so it may be the only way
to make OpenSSL available on many platforms.
Unless there are serious problems with it, I think it would be better to
include the code, but include a warning in the documentation / release notes
that it may not be as reliable or performant as the JNI code. Users won't get
the JNA version unless they ask for it. For some platforms it may be the best
choice.
{quote}
I'm agree that JNA is an important feature, but I think move to next release
should be also reasonable. If JNA feature is strong demanded, we can speed up
the progress of the JNA release.
> Add JNA binding
> ---
>
> Key: CRYPTO-63
> URL: https://issues.apache.org/jira/browse/CRYPTO-63
> Project: Commons Crypto
> Issue Type: Improvement
>Reporter: Hendrik Saly
>Assignee: Hendrik Saly
>
> Needs benchmarking before merge.
> PR https://github.com/apache/commons-crypto/pull/47
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CRYPTO-92) Handling default properties; allow SystemProperties to be ignored
[ https://issues.apache.org/jira/browse/CRYPTO-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15354990#comment-15354990 ] Dapeng Sun commented on CRYPTO-92: -- Thank Sebb, pr https://github.com/apache/commons-crypto/pull/64 is created for this issue. > Handling default properties; allow SystemProperties to be ignored > - > > Key: CRYPTO-92 > URL: https://issues.apache.org/jira/browse/CRYPTO-92 > Project: Commons Crypto > Issue Type: Improvement >Reporter: Sebb > > The code currently checks both local Properties and SystemProperties in > several places. > This is unnecessary, as the Properties class already supports the notion of > property defaults, as these can be passed in to the constructor. > I think it would be better to drop the specific check of the SystemProperties. > This would be more flexible, as the user could decide whether or not to allow > the use of SystemProperties or some other set of defaults. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
