ache/commons/crypto/OpenSslInfoNative.c#L74
> > >
> > > It might also help to remove the global flag to avoid re-exports?
> >
> > Not sure that would make a difference here.
> >
> > > Whats the lib filename constant in above line in your case?
> > >
> >
d
> > --
> > http://bernd.eckenfels.net
> > ____________
> > Von: Alex Remily
> > Gesendet: Friday, July 1, 2022 4:26:33 AM
> > An: Commons Developers List
> > Betreff: Re: [CRYPTO] Problem with JNA on macOS and Windows
> >
> &g
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
>
> Von: Alex Remily
> Gesendet: Friday, July 1, 2022 4:26:33 AM
> An: Commons Developers List
> Betreff: Re: [CRYPTO] Problem with JNA on macOS and Windows
>
>
>
> Yup. Still loads Li
lib filename constant in above line in your case?
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: Alex Remily
Gesendet: Friday, July 1, 2022 4:26:33 AM
An: Commons Developers List
Betreff: Re: [CRYPTO] Problem with JNA on macOS and Windows
Yup. Still loads
I tinkered with the same issues today and have come to the
same conclusion. We may want to consider optionally prepending a path to
the COMMONS_CRYPTO_OPENSSL_LIBRARY to specify a specific libcrypto.
On Thu, Jun 30, 2022 at 5:35 PM sebb wrote:
> On Thu, 30 Jun 2022 at 16:21, Alex Remily wrote:
Yup. Still loads LibreSSL.
Alex@Alexs-MacBook-Pro commons-crypto % java
-Djava.library.path=/usr/local/opt/openssl/lib -cp target/classes
org.apache.commons.crypto.Crypto
Apache Commons Crypto 1.1.1-SNAPSHOT
Native code loaded OK: 1.1.1-SNAPSHOT
Native name: Apache Commons Crypto
Native bui
Le jeu. 30 juin 2022 à 23:35, sebb a écrit :
>
> On Thu, 30 Jun 2022 at 16:21, Alex Remily wrote:
> >
> > > loading the dll, whereas Java apparently does not.>
> >
> > I experience the same behavior. What's more interesting is that when I run
> > the main function from Eclipse as a Run Configur
On Thu, 30 Jun 2022 at 16:21, Alex Remily wrote:
>
> loading the dll, whereas Java apparently does not.>
>
> I experience the same behavior. What's more interesting is that when I run
> the main function from Eclipse as a Run Configuration with the
> LD_LIBRARY_PATH set as an Environment variab
I experience the same behavior. What's more interesting is that when I run
the main function from Eclipse as a Run Configuration with the
LD_LIBRARY_PATH set as an Environment variable appended to the native
environment, it runs as expected. As of yet I haven't found a way to get
the java CLI
I've started copying bits of the C code to create a standalone tool to
load the dll and report some info.
No idea why yet, but it behaves differently from basically the same
code when run via JNI.
For example, the standalone code takes note of LD_LIBRARY_PATH when
loading the dll, whereas Java ap
On Thu, Jun 30, 2022 at 8:02 AM sebb wrote:
>
> That looks fine, however I don't see the same, and nor does GH.
>
> What version of macOS are you using?
uname says: Darwin xxx 21.5.0 Darwin Kernel Version 21.5.0: Tue Apr 26
21:08:22 PDT 2022; root:xnu-8020.121.3~4/RELEASE_X86_64 x86_64
UI says 1
I also get the "Error looking up function 'ENGINE_load_rdrand'" when I run
the Jna test class from the command line. Interesting. dlopen finds the
LibreSSL when run from the CLI.
On Thu, Jun 30, 2022 at 8:02 AM sebb wrote:
> That looks fine, however I don't see the same, and nor does GH.
>
> W
That looks fine, however I don't see the same, and nor does GH.
What version of macOS are you using?
On Thu, 30 Jun 2022 at 12:52, Gary Gregory wrote:
>
> With the 1.1.0 tagm I get:
>
> garydgregory@xxx ~/git/commons-crypto ➦ 3b2561b java -cp
> target/classes org.apache.commons.crypto.Cry
With the 1.1.0 tagm I get:
garydgregory@xxx ~/git/commons-crypto ➦ 3b2561b java -cp
target/classes org.apache.commons.crypto.Crypto
Apache Commons Crypto 1.1.0
Native code loaded OK: 1.1.0
Native name: Apache Commons Crypto
Native built: Jun 30 2022
OpenSSL library loaded OK, version: 0x101
On Thu, 30 Jun 2022 at 02:03, Alex Remily wrote:
>
> Which Mac OS version did you use? Since I upgraded to BigSur (OS 11) my
> Commons Crypto builds fail. I think Apple moved a bunch of the developer
> libraries, but I haven't taken the time to troubleshoot.
Note that GH Action macos-latest use
Yes, 1.1.0 builds OK on macOS, but the sample classes fail.
As previously noted, please try:
java -cp target/classes org.apache.commons.crypto.Crypto
and
mvn -q exec:java -D"exec.mainClass=org.apache.commons.crypto.jna.OpenSslJna"
See the GH run I linked yesterday:
https://github.com/apache/commo
The only OpenSSL fork I know of in macOS is BoringSSL which is also used by
Chrome. This fork maintains some level of compatibility though.
—
Matt Sicker
> On Jun 29, 2022, at 20:03, Alex Remily wrote:
>
> Which Mac OS version did you use? Since I upgraded to BigSur (OS 11) my
> Commons Cryp
Which Mac OS version did you use? Since I upgraded to BigSur (OS 11) my
Commons Crypto builds fail. I think Apple moved a bunch of the developer
libraries, but I haven't taken the time to troubleshoot.
On Wed, Jun 29, 2022 at 8:55 PM Gary Gregory wrote:
> Arg, idiotic line wrapping removed: ht
Arg, idiotic line wrapping removed: https://pastebin.com/raw/nPczrrd8
Gary
On Wed, Jun 29, 2022 at 8:49 PM Gary Gregory wrote:
>
> FWIW, I just checked out the rel/commons-crypto-1.1.0 on macOS and ran
> 'mvn clean verify' and everything built just fine.
>
> The Maven ant-run output was:
>
> [IN
FWIW, I just checked out the rel/commons-crypto-1.1.0 on macOS and ran
'mvn clean verify' and everything built just fine.
The Maven ant-run output was:
[INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto ---
[INFO] Executing tasks
make:
[exec] "/usr/local/Cellar/openjdk@8/1.8.0+3
I agree with Alex.
Forget LibreSSL. Commons Crypto is for OpenSSL, nice, simple, and
tight. Last time I checked I had an antique version of LibreSSL on my
mac years ago, I just installed OpenSSL and never looked back.
Gary
On Wed, Jun 29, 2022 at 8:11 PM Alex Remily wrote:
>
> issues with JNA
I wouldn't characterize the issues running against LibreSSL as
"undetected". I also don't see this as an issue with Mac or Windows, but
with LibreSSL. Install any supported OpenSSL library on any supported
architecture (to include Mac and Windows) and all commons crypto
functionality is availab
://bernd.eckenfels.net
Von: sebb
Gesendet: Thursday, June 30, 2022 12:14:06 AM
An: Commons Developers List
Betreff: Re: [CRYPTO] Problem with JNA on macOS and Windows
On Wed, 29 Jun 2022 at 18:06, Gary Gregory wrote:
>
> We cannot remove support for Windo
On Wed, 29 Jun 2022 at 18:06, Gary Gregory wrote:
>
> We cannot remove support for Windows and macOS, that's silly.
AFAICT that means we must support the different set of function names
in LibreSSL.
Note that we only currently use a small proportion of them.
> I have not followed all the branche
We cannot remove support for Windows and macOS, that's silly.
I have not followed all the branches and commits, so I'm not sure what the
current problems are, but I know I was able to release all OSs last go
around. I don't see why we need to rip out anything as fundamental.
Gary
On Wed, Jun 29,
On Wed, 29 Jun 2022 at 16:11, Alex Remily wrote:
>
> I agree with Gary that we just don't support LibreSSL. To my knowledge
> we've never advertised LibreSSL support, so I don't see it as an issue.
In that case AFAICT we will have to drop *all* support for macOS and
Windows, as they both seem to
I agree with Gary that we just don't support LibreSSL. To my knowledge
we've never advertised LibreSSL support, so I don't see it as an issue.
On Wed, Jun 29, 2022 at 10:21 AM sebb wrote:
> On Wed, 29 Jun 2022 at 14:17, Gary Gregory wrote:
> >
> > The simple solution is to keep doing what we d
On Wed, 29 Jun 2022 at 14:17, Gary Gregory wrote:
>
> The simple solution is to keep doing what we do now: only support OpenSSL
> and not whatever Apple does with LibreSSL which may or may not be up to
> date.
I think this also affects Windows.
I don't have Windows box at present, but I have se
The simple solution is to keep doing what we do now: only support OpenSSL
and not whatever Apple does with LibreSSL which may or may not be up to
date.
Gary
On Wed, Jun 29, 2022, 06:59 sebb wrote:
> It looks like macOS 10.5+ and Windows (latest) use LibreSSL by default
> rather than OpenSSL.
>
It looks like macOS 10.5+ and Windows (latest) use LibreSSL by default
rather than OpenSSL.
The LibreSSL API does not have the same functions as either 1.0.2 or
1.1.1, so needs its own JNA class. In particular it looks like
ENGINE_load_rdrand is not present, nor is OpenSSL_version_num; 1.0.2
has t
30 matches
Mail list logo
