Re: [crypto] OpenSslCryptoRandomTest fails on Mac OS High Sierra

2018-03-23 Thread Alex Remily 
I did a bit more troubleshooting.  I confirmed that the rdrand engine
loads natively on Mac High Sierra by running the below test program in
XCode.  I believe the issue is one of the commons-crypto build, not
openssl itself.  Hopefully, someone more familiar with the codebase
will pick this up and troubleshoot.

See 
https://software.intel.com/en-us/articles/how-to-use-the-rdrand-engine-in-openssl-for-random-number-generation.

/*
Copyright July, 2014 Intel Corporation
All Rights Reserved.

The source code, information and material ("Material") contained herein
is owned by Intel Corporation or its suppliers or licensors, and title
to such Material remains with Intel Corporation or its suppliers or
licensors. The Material contains proprietary information of Intel or
its suppliers and licensors. The Material is protected by worldwide
copyright laws and treaty provisions. No part of the Material may be used,
copied, reproduced, modified, published, uploaded, posted, transmitted,
distributed or disclosed in any way without Intel's prior express written
permission. No license under any patent, copyright or other intellectual
property rights in the Material is granted to or conferred upon you,
either expressly, by implication, inducement, estoppel or otherwise. Any
license under such intellectual property rights must be express and
approved by Intel in writing.

Unless otherwise agreed by Intel in writing, you may not remove or alter
this notice or any other notice embedded in Materials by Intel or Intel's
suppliers or licensors in any way.
*/

/*
 * This sample program fills a 64-byte buffer with random data using the
 * rdrand engine in OpenSSL
 */

#define BUFFERSZ 64

#include 
#include 
#include 

int main (int argc, char *argv[])
{
unsigned char buf[BUFFERSZ];
ENGINE *engine;
int i;

/* Set our buffer to all zeroes for demonstration purposes */

memset(buf, 0, BUFFERSZ);

/* Initialize the engine */

ENGINE_load_rdrand();

engine= ENGINE_by_id("rdrand");
if ( engine == NULL ) {
fprintf(stderr, "ENGINE_load_rdrand returned %lu\n", ERR_get_error());
exit(1);
}

if ( ! ENGINE_init(engine) ) {
fprintf(stderr, "ENGINE_init returned %lu\n", ERR_get_error());
exit(1);
}

/* Set the engine as the default engine for random numbers */

if ( ! ENGINE_set_default(engine, ENGINE_METHOD_RAND) ) {
fprintf(stderr, "ENGINE_set_default returned %lu\n", ERR_get_error());
exit(1);
}

/* Now call RAND_bytes to fill our buffer */

RAND_bytes(buf, BUFFERSZ);

/* Print our buffer as rows of 16 hex values */

for (i= 0; i< BUFFERSZ; ++i) {
if ( ! (i % 16) && i ) printf("\n");
printf("%02x ", buf[i]);
}
printf("\n");

ENGINE_finish(engine);
ENGINE_free(engine);
ENGINE_cleanup();
}

On Fri, Mar 23, 2018 at 9:01 AM, Rob Tompkins  wrote:
> Yes, I can reproduce this error on the Mac running under:
>
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 
> 2018-02-24T14:49:05-05:00)
> Maven home: /usr/local/Cellar/maven/3.5.3/libexec
> Java version: 1.8.0_162, vendor: Oracle Corporation
> Java home: 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_162.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.13.3", arch: "x86_64", family: "mac"
>
>> On Mar 23, 2018, at 8:07 AM, Alex Remily  wrote:
>>
>> Sending again, this time with a subject line.
>>
>> I’m building Apache Commons Crypto from source on Mac OS HighSierra
>> (10.13.3) and the CryptoRandom tests fail, apparently because of
>> failure to load the underlying random number generation library.  All
>> other tests pass.  I successfully built and tested on Ubuntu 16.04 in
>> a similar development environment, so the problem seems isolated to my
>> Mac.  Has anyone had a similar experience, or have any ideas why the
>> Mac is exhibiting this behavior?  I’ve tested two versions of openssl,
>> and both versions produced identical failures.
>>
>> Best wishes,
>>
>> Alex
>>
>>
>> [INFO] Scanning for projects...
>> [INFO]
>> [INFO] 
>> 
>> [INFO] Building Apache Commons Crypto 1.1.0-SNAPSHOT
>> [INFO] 
>> 
>> [INFO]
>> [INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-maven-3) @
>> commons-crypto ---
>> [INFO]
>> [INFO] --- build-helper-maven-plugin:3.0.0:parse-version
>> (parse-version) @ commons-crypto ---
>> [INFO]
>> [INFO] --- maven-resources-plugin:2.7:resources (create-version-file)
>> @ commons-crypto ---
>> [INFO] Using 'iso-8859-1' encoding to copy filtered resources.
>> [INFO] Copying 1 resource
>> [INFO]
>> [INFO] --- maven-antrun-plugin:1.8:run (javadoc.resources) @ commons-crypto 
>> ---
>> [INFO] Executing tasks
>>
>> main:
>> [copy] Copying 2 files to
>>

Re: [DBCP] troubleshooting pool activity (tomcat version)

2018-03-23 Thread Bernd Eckenfels 
I think it is best you direct your tomcat pool related questions and comments 
about their documentation to the tomcat mailing lists. (On the other hand the 
tomcat documentation on their own pool including a description why they don't 
use dbcp 1.x looks rather comprehensive to me: 
https://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html#Introduction)

Gruss
Bernd
--
http://bernd.eckenfels.net

From: Shawn Heisey 
Sent: Saturday, March 24, 2018 2:09:59 AM
To: user@commons.apache.org
Subject: Re: [DBCP] troubleshooting pool activity (tomcat version)

On 3/23/2018 5:19 PM, Phil Steitz wrote:
> That's the documentation for the alternative pool.  Use this instead:
> https://tomcat.apache.org/tomcat-7.0-doc/jndi-datasource-examples-howto.html#Database_Connection_Pool_(DBCP)_Configurations

This does not really explain how to configure Tomcat.  It says "go see
the DBCP documentation for parameters you can use."  I do see some
Resource configurationsfurther down on the page ... and they do not have
a "factory" attribute at all.  Is that the difference?

The only resource I have is Tomcat documentation, and whatever nuggets
were *left out* of the Tomcat documentation that I might learn here.  If
this were source code, I could get it all working.  Especially using
DBCP2.  But there's no code for me to modify -- I only have Resource
configurations in tomcat's context.xml file.

Since there doesn't appear to be any documentation for setting it up the
way you think I should be setting it up ... can you guide me to writing
a new configuration?

The config I'm planning has evolved a little bit since the last time I
shared it.  Here's an example of its current state:



If you think I should be doing something different, please tell me
exactly what you think I should change, and tell me *why* you think each
of those changes is a good idea.  And then maybe I can discuss
documentation deficiencies with the Tomcat community.


> Yes, that is a borrow.
> There is another, um, "feature" that I forgot to mention in ye olde
> DBCP 1.x.  As documented here
> https://commons.apache.org/proper/commons-dbcp/api-1.4/org/apache/commons/dbcp/BasicDataSource.html#getRemoveAbandoned()
> removal will only happen with your config if there are 57+
> connections out.

That seems like a REALLY bad way to handle it!  Hopefully that's changed
in the newest 1.x and 2.x versions!

Does this affect Tomcat too?  How about the
"org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory" that we currently
have configured?  I was planning to use abandonWhenPercentageFull="50",
which is specific to Tomcat.  The property description looks like it
will fix that issue.  I think I'll just leave it out, which the
documentation says will make connections ALWAYS eligible for removal
once they've reached the abandoned timeout.

Thanks,
Shawn


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

Re: [DBCP] troubleshooting pool activity (tomcat version)

2018-03-23 Thread Shawn Heisey 
On 3/23/2018 5:19 PM, Phil Steitz wrote:
> That's the documentation for the alternative pool.  Use this instead:
> https://tomcat.apache.org/tomcat-7.0-doc/jndi-datasource-examples-howto.html#Database_Connection_Pool_(DBCP)_Configurations

This does not really explain how to configure Tomcat.  It says "go see
the DBCP documentation for parameters you can use."  I do see some
Resource configurationsfurther down on the page ... and they do not have
a "factory" attribute at all.  Is that the difference?

The only resource I have is Tomcat documentation, and whatever nuggets
were *left out* of the Tomcat documentation that I might learn here.  If
this were source code, I could get it all working.  Especially using
DBCP2.  But there's no code for me to modify -- I only have Resource
configurations in tomcat's context.xml file.

Since there doesn't appear to be any documentation for setting it up the
way you think I should be setting it up ... can you guide me to writing
a new configuration?

The config I'm planning has evolved a little bit since the last time I
shared it.  Here's an example of its current state:

    

If you think I should be doing something different, please tell me
exactly what you think I should change, and tell me *why* you think each
of those changes is a good idea.  And then maybe I can discuss
documentation deficiencies with the Tomcat community.


> Yes, that is a borrow.
> There is another, um, "feature" that I forgot to mention in ye olde
> DBCP 1.x.  As documented here
> https://commons.apache.org/proper/commons-dbcp/api-1.4/org/apache/commons/dbcp/BasicDataSource.html#getRemoveAbandoned()
> removal will only happen with your config if there are 57+
> connections out.

That seems like a REALLY bad way to handle it!  Hopefully that's changed
in the newest 1.x and 2.x versions!

Does this affect Tomcat too?  How about the
"org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory" that we currently
have configured?  I was planning to use abandonWhenPercentageFull="50",
which is specific to Tomcat.  The property description looks like it
will fix that issue.  I think I'll just leave it out, which the
documentation says will make connections ALWAYS eligible for removal
once they've reached the abandoned timeout.

Thanks,
Shawn


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

Re: [DBCP] troubleshooting pool activity (tomcat version)

2018-03-23 Thread Phil Steitz 
On 3/22/18 6:14 PM, Shawn Heisey wrote:
> First thing to do is thank you again for taking the time to help me. 
> Apache has great communities.
>
> On 3/22/2018 5:38 PM, Phil Steitz wrote:
>> You must be looking at documentation describing how to use the
>> alternative pool mentioned above (tomcat-jdbc).  The config you
>> posted is correct for DBCP.
> I'm looking at Tomcat documentation.
>
> https://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html

That's the documentation for the alternative pool.  Use this instead:
https://tomcat.apache.org/tomcat-7.0-doc/jndi-datasource-examples-howto.html#Database_Connection_Pool_(DBCP)_Configurations

>
> The tomcat is the one included with Liferay 6.2.  It is 7.0.42.

>From here
http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_42/build.properties.default

You can see the bundled DBCP / Pool are 1.4/1.5.7 which are the
latest compatible versions.
>
>> Don't look at DBCP 2 code for troubleshooting the code you are
>> running.  Either look at the repackaged sources inside the tomcat
>> source, or find the version in the tomcat build files and go to the
>> old DBCP / pool sources referenced there.
> I have figured that out.  Felt pretty dumb when I realized I wasn't
> looking at code from the correct Tomcat version.
>
>> Of course, you *should* upgrade both TC and the DBCP it ships so you
>> *can* look at that (much better) code.  See below for one reason why.
> I hear what you're saying, and don't disagree ... but this is not the
> kind of environment where I can just do an upgrade, even though
> upgrading might make it all better.
>
> We didn't download Tomcat -- we downloaded Liferay, which came with a
> specific version of Tomcat already included.  Upgrading any significant
> component (liferay, tomcat, and others) runs the risk that when we
> restart the service, our web application won't work any more.  For any
> upgrade, we have to spend a lot of resources trying the upgrade in a
> staging environment, so we can be sure that everything still works. 
> Because that's very time-consuming, we tend to not do a lot of
> upgrading, at least of significant components, and our versions get
> REALLY old.
>
> This is also why I'm hesitant to move away from Tomcat's DBCP
> implementation to Commons DBCP (particularly version 2), even though
> that's exactly what I want to do.  Switching to a different library
> might work seamlessly ... or it might completely break the application. 
> Our customers get REALLY irritated when the websites we've built for
> them don't work!

Using DBCP2 with TC 7 won't work.  You need TC 8+ for that.
>
>> One thing that could be going on is that in the old 1.x DBCP, 
>> abandoned connection removal only happens when borrows are
>> attempted.  So if you check out a lot of connections, abandon them
>> and don't ask for more, they won't get closed as abandoned until you
>> borrow a new one.  In DBCP 2, the removeAbandoned property is split
>> into two different properties:  removeAbandonedOnBorrow (the old
>> behavior) and removeAbandonedOnMaintenance.  The second one makes
>> abandoned connection removal run on pool maintenance (so will not
>> have to wait until a borrow is attempted).
> I don't know if anyone needs me to actually back up and describe what's
> happening that led me down this rabbit hole, but that's what I'm going
> to do:
>
> The master MySQL server in our environment has a max connection limit
> configured at 600 connections.
>
> Every now and then, we start getting website failures, because all the
> connections are in use and the connection pools can't make any more
> connections.  Looking at the connections on the MySQL side, the vast
> majority are idle (the command is "Sleep" on the server processlist),
> and have been idle for several hours.
>
> There are five main webservers and a handful of ancillary systems that
> also connect to the database.  When the problem happens, the connection
> count from each webserver has gotten up near 100, and sometimes over
> 100.  The surplus of connections are definitely the ones configured in
> Tomcat.  Liferay has its own DB config for its own data (using c3p0 for
> pooling), and although I often see a higher number of connections to
> that database than I would excpect, I've never seen the idle time on
> those connections above one minute, so I'm not concerned about that
> pool, beyond some minor tweaks.
>
> The frequency of the connection-related failures has been increasing, so
> in response, I have set up monitoring that will send us an alarm when
> the server reaches 550 connections.  This has allowed us to kill idle
> connections and prevent customer-visible problems a couple of times
> already, but we still have a fundamental issue to correct.
>
> I do not yet have any information that indicates whether Tomcat's DBCP
> thinks those connections are idle or active.  I have reason to suspect
> that they are active, and have not been returned to the pool (closed). 
>

Re: [Daemon] StdOut and StdErr use extra newline

2018-03-23 Thread Gil Baruch 
Maybe I was misunderstood, each line ends with two newlines not just the
end of the file...

So there's a gap of one empty line between every two lines...

Thanks
GBa.

On Thu, Mar 22, 2018, 23:32 Gil Baruch  wrote:

> I'm using the daemon to wrap my Jetty based service. I've redirected
> stdout and stderr to the Daemon via the relevant configuration params.
>
> However, both files end up with 2 newline characters (/r/n/r/n) which
> results in a very unreadable log... especially when dealing with
> stacktraces...
>
> Any idea what could cause that?
>
> BTW, when using Jetty without the wrapper, Jetty's stdout and err do not
> suffer from this behavior.
>
> thanks,
> GBa.
>

Re: [crypto] OpenSslCryptoRandomTest fails on Mac OS High Sierra

2018-03-23 Thread Rob Tompkins 
Yes, I can reproduce this error on the Mac running under:

Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 
2018-02-24T14:49:05-05:00)
Maven home: /usr/local/Cellar/maven/3.5.3/libexec
Java version: 1.8.0_162, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_162.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.13.3", arch: "x86_64", family: "mac"

> On Mar 23, 2018, at 8:07 AM, Alex Remily  wrote:
> 
> Sending again, this time with a subject line.
> 
> I’m building Apache Commons Crypto from source on Mac OS HighSierra
> (10.13.3) and the CryptoRandom tests fail, apparently because of
> failure to load the underlying random number generation library.  All
> other tests pass.  I successfully built and tested on Ubuntu 16.04 in
> a similar development environment, so the problem seems isolated to my
> Mac.  Has anyone had a similar experience, or have any ideas why the
> Mac is exhibiting this behavior?  I’ve tested two versions of openssl,
> and both versions produced identical failures.
> 
> Best wishes,
> 
> Alex
> 
> 
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 
> [INFO] Building Apache Commons Crypto 1.1.0-SNAPSHOT
> [INFO] 
> 
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-maven-3) @
> commons-crypto ---
> [INFO]
> [INFO] --- build-helper-maven-plugin:3.0.0:parse-version
> (parse-version) @ commons-crypto ---
> [INFO]
> [INFO] --- maven-resources-plugin:2.7:resources (create-version-file)
> @ commons-crypto ---
> [INFO] Using 'iso-8859-1' encoding to copy filtered resources.
> [INFO] Copying 1 resource
> [INFO]
> [INFO] --- maven-antrun-plugin:1.8:run (javadoc.resources) @ commons-crypto 
> ---
> [INFO] Executing tasks
> 
> main:
> [copy] Copying 2 files to
> /Users/Alex/Documents/git_repos/commons-crypto/target/apidocs/META-INF
> [INFO] Executed tasks
> [INFO]
> [INFO] --- maven-remote-resources-plugin:1.5:process
> (process-resource-bundles) @ commons-crypto ---
> [INFO]
> [INFO] --- buildnumber-maven-plugin:1.4:create (default) @ commons-crypto ---
> [INFO] Executing: /bin/sh -c cd
> '/Users/Alex/Documents/git_repos/commons-crypto' && 'git' 'rev-parse'
> '--verify' 'HEAD'
> [INFO] Working directory: /Users/Alex/Documents/git_repos/commons-crypto
> [INFO] Storing buildNumber: d69ef9556f44c076034add15feef1c5513248404
> at timestamp: 2018-03-22 17:12:10-0400
> [INFO] Storing buildScmBranch: master
> [INFO]
> [INFO] --- maven-resources-plugin:2.7:resources (default-resources) @
> commons-crypto ---
> [INFO] Using 'iso-8859-1' encoding to copy filtered resources.
> [INFO] Copying 1 resource
> [INFO]
> [INFO] --- maven-compiler-plugin:3.7.0:compile (default-compile) @
> commons-crypto ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 38 source files to
> /Users/Alex/Documents/git_repos/commons-crypto/target/classes
> [INFO]
> [INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto ---
> [INFO] Executing tasks
> 
> make:
> [exec] 
> "/Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/bin/javah"
> -force -classpath target/classes -o
> target/jni-classes/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.h
> org.apache.commons.crypto.random.OpenSslCryptoRandomNative
> [exec] gcc -arch x86_64 -Ilib/inc_mac
> -I/Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/include
> -O2 -fPIC -mmacosx-version-min=10.5 -fvisibility=hidden
> -I/usr/local/include -I/usr/local/Cellar/openssl/1.0.2n/include
> -Ilib/include -I/usr/include
> -I"src/main/native/org/apache/commons/crypto/"
> -I"/Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/include/darwin"
> -I"target/jni-classes/org/apache/commons/crypto/cipher"
> -I"target/jni-classes/org/apache/commons/crypto/random" -c
> src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c
> -o target/commons-crypto-1.1.0-SNAPSHOT-Mac-x86_64/OpenSslCryptoRandomNative.o
> [exec] 
> "/Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/bin/javah"
> -force -classpath target/classes -o
> target/jni-classes/org/apache/commons/crypto/cipher/OpenSslNative.h
> org.apache.commons.crypto.cipher.OpenSslNative
> [exec] gcc -arch x86_64 -Ilib/inc_mac
> -I/Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/include
> -O2 -fPIC -mmacosx-version-min=10.5 -fvisibility=hidden
> -I/usr/local/include -I/usr/local/Cellar/openssl/1.0.2n/include
> -Ilib/include -I/usr/include
> -I"src/main/native/org/apache/commons/crypto/"
> -I"/Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/include/darwin"
> -I"target/jni-classes/org/apache/commons/crypto/cipher"
> -I"target/jni-classes/org/apache/commons/crypto/random" -c
>

Re: [crypto] OpenSslCryptoRandomTest fails on Mac OS High Sierra

2018-03-23 Thread Rob Tompkins 
Hello Alex,

I haven’t spent much time working with [crypto], but I recall seeing something 
like this when building from a Mac. In fact, my error is upstream to yours:
--
[INFO] Executing tasks

make:
 [exec] 
"/Library/Java/JavaVirtualMachines/jdk1.8.0_162.jdk/Contents/Home/bin/javah" 
-force -classpath target/classes -o 
target/jni-classes/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.h 
org.apache.commons.crypto.random.OpenSslCryptoRandomNative
 [exec] gcc -arch x86_64 -Ilib/inc_mac 
-I/Library/Java/JavaVirtualMachines/jdk1.8.0_162.jdk/Contents/Home/include -O2 
-fPIC -mmacosx-version-min=10.5 -fvisibility=hidden -I/usr/local/include 
-Ilib/include -I/usr/include -I"src/main/native/org/apache/commons/crypto/" 
-I"/Library/Java/JavaVirtualMachines/jdk1.8.0_162.jdk/Contents/Home/include/darwin"
 -I"target/jni-classes/org/apache/commons/crypto/cipher" 
-I"target/jni-classes/org/apache/commons/crypto/random" -c 
src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c -o 
target/commons-crypto-1.1.0-SNAPSHOT-Mac-x86_64/OpenSslCryptoRandomNative.o
 [exec] In file included from 
src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c:19:
 [exec] In file included from 
src/main/native/org/apache/commons/crypto/random/org_apache_commons_crypto_random.h:22:
 [exec] 
src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h:195:10: 
fatal error: 'openssl/aes.h' file not found
 [exec] #include 
 [exec]  ^~~
 [exec] 1 error generated.
 [exec] make: *** 
[target/commons-crypto-1.1.0-SNAPSHOT-Mac-x86_64/OpenSslCryptoRandomNative.o] 
Error 1
--
before execution of the tests even begin. Did you see something similar when 
you were first building the project?

Either way, I agree that the documentation on building the project does not 
seem to result in success.

Cheers,
-Rob


> On Mar 23, 2018, at 8:07 AM, Alex Remily  wrote:
> 
> Sending again, this time with a subject line.
> 
> I’m building Apache Commons Crypto from source on Mac OS HighSierra
> (10.13.3) and the CryptoRandom tests fail, apparently because of
> failure to load the underlying random number generation library.  All
> other tests pass.  I successfully built and tested on Ubuntu 16.04 in
> a similar development environment, so the problem seems isolated to my
> Mac.  Has anyone had a similar experience, or have any ideas why the
> Mac is exhibiting this behavior?  I’ve tested two versions of openssl,
> and both versions produced identical failures.
> 
> Best wishes,
> 
> Alex
> 
> 
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 
> [INFO] Building Apache Commons Crypto 1.1.0-SNAPSHOT
> [INFO] 
> 
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-maven-3) @
> commons-crypto ---
> [INFO]
> [INFO] --- build-helper-maven-plugin:3.0.0:parse-version
> (parse-version) @ commons-crypto ---
> [INFO]
> [INFO] --- maven-resources-plugin:2.7:resources (create-version-file)
> @ commons-crypto ---
> [INFO] Using 'iso-8859-1' encoding to copy filtered resources.
> [INFO] Copying 1 resource
> [INFO]
> [INFO] --- maven-antrun-plugin:1.8:run (javadoc.resources) @ commons-crypto 
> ---
> [INFO] Executing tasks
> 
> main:
> [copy] Copying 2 files to
> /Users/Alex/Documents/git_repos/commons-crypto/target/apidocs/META-INF
> [INFO] Executed tasks
> [INFO]
> [INFO] --- maven-remote-resources-plugin:1.5:process
> (process-resource-bundles) @ commons-crypto ---
> [INFO]
> [INFO] --- buildnumber-maven-plugin:1.4:create (default) @ commons-crypto ---
> [INFO] Executing: /bin/sh -c cd
> '/Users/Alex/Documents/git_repos/commons-crypto' && 'git' 'rev-parse'
> '--verify' 'HEAD'
> [INFO] Working directory: /Users/Alex/Documents/git_repos/commons-crypto
> [INFO] Storing buildNumber: d69ef9556f44c076034add15feef1c5513248404
> at timestamp: 2018-03-22 17:12:10-0400
> [INFO] Storing buildScmBranch: master
> [INFO]
> [INFO] --- maven-resources-plugin:2.7:resources (default-resources) @
> commons-crypto ---
> [INFO] Using 'iso-8859-1' encoding to copy filtered resources.
> [INFO] Copying 1 resource
> [INFO]
> [INFO] --- maven-compiler-plugin:3.7.0:compile (default-compile) @
> commons-crypto ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 38 source files to
> /Users/Alex/Documents/git_repos/commons-crypto/target/classes
> [INFO]
> [INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto ---
> [INFO] Executing tasks
> 
> make:
> [exec] 
> "/Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/bin/javah"
> -force -classpath target/classes -o
> target/jni-classes/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.h
>

[crypto] OpenSslCryptoRandomTest fails on Mac OS High Sierra

2018-03-23 Thread Alex Remily 
Sending again, this time with a subject line.

I’m building Apache Commons Crypto from source on Mac OS HighSierra
(10.13.3) and the CryptoRandom tests fail, apparently because of
failure to load the underlying random number generation library.  All
other tests pass.  I successfully built and tested on Ubuntu 16.04 in
a similar development environment, so the problem seems isolated to my
Mac.  Has anyone had a similar experience, or have any ideas why the
Mac is exhibiting this behavior?  I’ve tested two versions of openssl,
and both versions produced identical failures.

Best wishes,

Alex


[INFO] Scanning for projects...
[INFO]
[INFO] 
[INFO] Building Apache Commons Crypto 1.1.0-SNAPSHOT
[INFO] 
[INFO]
[INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-maven-3) @
commons-crypto ---
[INFO]
[INFO] --- build-helper-maven-plugin:3.0.0:parse-version
(parse-version) @ commons-crypto ---
[INFO]
[INFO] --- maven-resources-plugin:2.7:resources (create-version-file)
@ commons-crypto ---
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO]
[INFO] --- maven-antrun-plugin:1.8:run (javadoc.resources) @ commons-crypto ---
[INFO] Executing tasks

main:
 [copy] Copying 2 files to
/Users/Alex/Documents/git_repos/commons-crypto/target/apidocs/META-INF
[INFO] Executed tasks
[INFO]
[INFO] --- maven-remote-resources-plugin:1.5:process
(process-resource-bundles) @ commons-crypto ---
[INFO]
[INFO] --- buildnumber-maven-plugin:1.4:create (default) @ commons-crypto ---
[INFO] Executing: /bin/sh -c cd
'/Users/Alex/Documents/git_repos/commons-crypto' && 'git' 'rev-parse'
'--verify' 'HEAD'
[INFO] Working directory: /Users/Alex/Documents/git_repos/commons-crypto
[INFO] Storing buildNumber: d69ef9556f44c076034add15feef1c5513248404
at timestamp: 2018-03-22 17:12:10-0400
[INFO] Storing buildScmBranch: master
[INFO]
[INFO] --- maven-resources-plugin:2.7:resources (default-resources) @
commons-crypto ---
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO]
[INFO] --- maven-compiler-plugin:3.7.0:compile (default-compile) @
commons-crypto ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 38 source files to
/Users/Alex/Documents/git_repos/commons-crypto/target/classes
[INFO]
[INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto ---
[INFO] Executing tasks

make:
 [exec] 
"/Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/bin/javah"
-force -classpath target/classes -o
target/jni-classes/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.h
org.apache.commons.crypto.random.OpenSslCryptoRandomNative
 [exec] gcc -arch x86_64 -Ilib/inc_mac
-I/Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/include
-O2 -fPIC -mmacosx-version-min=10.5 -fvisibility=hidden
-I/usr/local/include -I/usr/local/Cellar/openssl/1.0.2n/include
-Ilib/include -I/usr/include
-I"src/main/native/org/apache/commons/crypto/"
-I"/Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/include/darwin"
-I"target/jni-classes/org/apache/commons/crypto/cipher"
-I"target/jni-classes/org/apache/commons/crypto/random" -c
src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c
-o target/commons-crypto-1.1.0-SNAPSHOT-Mac-x86_64/OpenSslCryptoRandomNative.o
 [exec] 
"/Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/bin/javah"
-force -classpath target/classes -o
target/jni-classes/org/apache/commons/crypto/cipher/OpenSslNative.h
org.apache.commons.crypto.cipher.OpenSslNative
 [exec] gcc -arch x86_64 -Ilib/inc_mac
-I/Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/include
-O2 -fPIC -mmacosx-version-min=10.5 -fvisibility=hidden
-I/usr/local/include -I/usr/local/Cellar/openssl/1.0.2n/include
-Ilib/include -I/usr/include
-I"src/main/native/org/apache/commons/crypto/"
-I"/Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/include/darwin"
-I"target/jni-classes/org/apache/commons/crypto/cipher"
-I"target/jni-classes/org/apache/commons/crypto/random" -c
src/main/native/org/apache/commons/crypto/cipher/OpenSslNative.c -o
target/commons-crypto-1.1.0-SNAPSHOT-Mac-x86_64/OpenSslNative.o
 [exec] 
"/Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/bin/javah"
-force -classpath target/classes -o
target/jni-classes/org/apache/commons/crypto/OpenSslInfoNative.h
org.apache.commons.crypto.OpenSslInfoNative
 [exec] gcc -arch x86_64 -Ilib/inc_mac
-I/Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/include
-O2 -fPIC -mmacosx-version-min=10.5 -fvisibility=hidden
-I/usr/local/include -I/usr/local/Cellar/openssl/1.0.2n/include
-Ilib/include -I/usr/include
-I"src/main/native/org/apache/commons/crypto/"
-I"/Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/include/darwin"