s://dlcdn.apache.org/maven/maven-3/3.9.9/binaries/apache-maven-
> # Ensure we are in the correct directory (this will be overlaid by the
> virtual mount)
> WORKDIR /home/crypto
>
> -CMD ['/bin/bash']
> +CMD ["/bin/bash"]
>
-
This is on my to-do list... maybe within a month or so.
Gary
On Mon, Feb 17, 2025 at 10:46 AM Callum Rogers
wrote:
>
> Hi,
>
> The most recent version of commons-crypto (1.2.0, released January
> 2023<https://github.com/apache/commons-crypto/releases/tag/rel%2Fco
Hi,
The most recent version of commons-crypto (1.2.0, released January
2023<https://github.com/apache/commons-crypto/releases/tag/rel%2Fcommons-crypto-1.2.0>)
supports up to OpenSSL 1.1.x. I see in the unreleased changelog that OpenSSL
3.x is supported on the main
branch<https://g
On Tue, 23 Jul 2024 at 15:16, sebb wrote:
>
> It looks like macos-latest does not include the openssl header files
> (or at least they are not in the expected place).
Eventually found them under /opt/homebrew/include
Although the GH macos-13 and macos-14 hosts have the same version of
openssl ins
It looks like macos-latest does not include the openssl header files
(or at least they are not in the expected place).
Hope to find time later to fix this, but if anyone knows the solution,
please pipe up!
Sebb
-
To unsubscribe,
gt;
> > Hi,
> >
> > Hope this email finds you in good health.
> > We are looking for opensl3.0.x supported commons crypto library and I think
> > you already have the changes in master code
> > https://github.com/apache/commons-crypto,
> > Is it possible
opensl3.0.x supported commons crypto library and I think
> you already have the changes in master code
> https://github.com/apache/commons-crypto,
> Is it possible to know when you are planning to release those changes?
>
> Thank you in advance! for your help.
>
> --
> Thanks & Regards,
> Sreeram
>
Hi,
Hope this email finds you in good health.
We are looking for opensl3.0.x supported commons crypto library and I think
you already have the changes in master code
https://github.com/apache/commons-crypto,
Is it possible to know when you are planning to release those changes?
Thank you in
s a link pointing to libcrypto.1.1.dylib or
> > similar in the same directory)
> >
> > I have not yet found this lone library, so I am beginning to wonder if
> > it is in the dylib cache?
>
> On further investigation, it appears that the default crypto library
> is a d
lone library, so I am beginning to wonder if
> it is in the dylib cache?
On further investigation, it appears that the default crypto library
is a dummy that does not have an in-built version.
It does not matter if the file name includes a version or not. That
was a red herring.
> If so, th
gt;
> Just pulled master and successfully ran tests against OpenSSL 3.1.3 on Mac
> OS 11 BigSur. Nice work sebb!
>
> Apache Commons Crypto 1.2.1-SNAPSHOT
>
> Native code loaded OK: 1.2.1-SNAPSHOT
>
> Native name: Apache Commons Crypto
>
> Native built: Nov 17 2023
>
Just pulled master and successfully ran tests against OpenSSL 3.1.3 on Mac
OS 11 BigSur. Nice work sebb!
Apache Commons Crypto 1.2.1-SNAPSHOT
Native code loaded OK: 1.2.1-SNAPSHOT
Native name: Apache Commons Crypto
Native built: Nov 17 2023
OpenSSL library loaded OK, version: 0x30100030
There are now separate cross-host image build and test jobs
docker_images.yml - creates the Docker images and stores them in the
ghcr.io package repo
maven_crosstest.yml - fetches the images and uses them to build/test
the code on different architectures
Some commits may cause both jobs to run at
On Tue, 14 Nov 2023 at 13:17, Alex Remily wrote:
>
> That's fantastic. I read that there were big API changes with the move to
> OpenSSL 3, but maybe those changes were not in the functionality that
> commons crypto exposes. Have you merged into master yet? I look forward
&g
That's fantastic. I read that there were big API changes with the move to
OpenSSL 3, but maybe those changes were not in the functionality that
commons crypto exposes. Have you merged into master yet? I look forward
to playing around with it.
Alex
On Wed, Nov 8, 2023 at 7:12 PM sebb
gt; said, it's been at least a year and I haven't gotten around to it,
> > > and I'm
> > > > > > not firmly committed to the idea of maintaining backwards
> > > compatibility. I
> > > > > > think that if we're going to br
o it,
> > and I'm
> > > > > not firmly committed to the idea of maintaining backwards
> > compatibility. I
> > > > > think that if we're going to break backwards compatibility with
> older
> > > > > versions, the upgrade to 3.
; > > not firmly committed to the idea of maintaining backwards
> compatibility. I
> > > > think that if we're going to break backwards compatibility with older
> > > > versions, the upgrade to 3.X would probably be a good time to do
> it. From
> > &g
to 3.X would probably be a good time to do it. From
> > > what little I've read on the subject, the move from 1.1.1 to 3.X is a
> > > significant change. In short, I would be in favor of dropping legacy
> > > OpenSSL support in the next commons crypto re
Crypto now builds and tests OK on
macOS-latest - OpenSSL 3.1.4 24 Oct 2023
and
Ubuntu-latest - OpenSSL 3.0.2 15 Mar 2022
Tested with Java 8 and 21
I only had to allow for two changed names:
EVP_CIPHER_CTX_block_size => EVP_CIPHER_CTX_get_block_size
EVP_CIPHER_flags => EVP_CIPHER_get_flags
Managed to find the library using GH after all.
It seems that Windows installs all the libraries in the same SYSTEM
directory, using a version suffix for non-default ones.
e.g. the default is libcrypto.dll, whereas an additional one might be
libcrypto-1_1-x84.dll.
[I'm working on updates to the c
Does anyone have a working debug config for the commons-crypto project? I
had one for Eclipse a few years ago but I blew it away and now recreating
it is getting to be a time sink. I'm looking to be able to step from the
Java code to the native code. I use Eclipse, but I'm also comfor
On Thu, 2 Nov 2023 at 10:35, sebb wrote:
> On macOS, CC and CXX have the same definition, so it's not surprising
> there was no difference in your testing.
Face palm. Sorry
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache
On Thu, 2 Nov 2023 at 10:12, Peter Hull wrote:
>
> On Wed, 1 Nov 2023 at 23:54, Alex Remily wrote:
> > I believe it is for cross compilation, owing to the comments in the
> > makefile:
> > # for cross-compilation on Ubuntu, install the g++-mingw-w64-x86-64 package
> I think you could also argue t
On Wed, 1 Nov 2023 at 23:54, Alex Remily wrote:
> I believe it is for cross compilation, owing to the comments in the
> makefile:
> # for cross-compilation on Ubuntu, install the g++-mingw-w64-x86-64 package
I think you could also argue that the other way around - ie. those are
the packages you ne
I don't currently have ready access to a Windows host, and have so far
failed to find the correct setting of jn[ai].library.path required to
cause OpenSSL to be loaded rather than the default which seems to be
LibreSSL.
So if anyone with Windows and OpenSSL 1.1.x can help that would be great!
The
I think there may need to be some more GH tests to check all the
> combinations.
>
> > Gary
> >
> > On Wed, Nov 1, 2023, 8:45 AM sebb wrote:
> >
> > > Crypto currently only uses .c files, and the Makefile uses CC
> > > throughout, except for creating the
e that out.
Alex
On Wed, Nov 1, 2023 at 11:36 AM sebb wrote:
> The Crypto makefile includes a lot of different OS and architecture
> combinations.
>
> Not all of these are included in the binary jar.
>
> I don't think we need to generate native binaries for all the
> com
The Crypto makefile includes a lot of different OS and architecture
combinations.
Not all of these are included in the binary jar.
I don't think we need to generate native binaries for all the
combinations, but I do think we need to document which ones are
included, and note that any others
elease from multiple machines to get macOS, Linux, and
> Windows binaries correctly compiled, linked, and packaged up. I hope
> nothing was broken in all the recent commits.
I think there may need to be some more GH tests to check all the combinations.
> Gary
>
> On Wed, Nov 1, 2023
thing was broken in all the recent commits.
Gary
On Wed, Nov 1, 2023, 8:45 AM sebb wrote:
> Crypto currently only uses .c files, and the Makefile uses CC
> throughout, except for creating the object output. [This has been the
> case since the initial release.]
>
> Using CXX (C+
Crypto currently only uses .c files, and the Makefile uses CC
throughout, except for creating the object output. [This has been the
case since the initial release.]
Using CXX (C++) for the link does not make sense to me - surely CC can
create the object equally well?
It would simplify builds
It looks like the macOS and Windows tests do not actually use the
OpenSSL crypto library.
Instead, they use the LibreSSL library which is bundled with the system.
What do we want to do about this?
Sebb
-
To unsubscribe, e-mail
The current crypto release states the details of the tested
configurations on the home page:
https://commons.apache.org/proper/commons-crypto/
The current release is 1.2.0, which is not shown.
It ought really to be added.
What was the list for 1.2.0, and where can one find the test results
from
.X is a
> > significant change. In short, I would be in favor of dropping legacy
> > OpenSSL support in the next commons crypto release.
> >
> > Alex
> >
> > On Sun, Oct 29, 2023 at 9:15 AM sebb wrote:
> >
> > > There is quite a lot of Crypto code tha
e're going to break backwards compatibility with older
> versions, the upgrade to 3.X would probably be a good time to do it. From
> what little I've read on the subject, the move from 1.1.1 to 3.X is a
> significant change. In short, I would be in favor of dropping legacy
dropping legacy
OpenSSL support in the next commons crypto release.
Alex
On Sun, Oct 29, 2023 at 9:15 AM sebb wrote:
> There is quite a lot of Crypto code that depends on the check:
>
> if (dlsym_OpenSSL_version_num() < VERSION_1_1_X)
> where
> VERSION_1_1_X = 0x1010;
>
There is quite a lot of Crypto code that depends on the check:
if (dlsym_OpenSSL_version_num() < VERSION_1_1_X)
where
VERSION_1_1_X = 0x1010;
Dropping such support would simplify the code.
Is there any need to continue to support such old versions?
S
How to reproduce these test failures?
On Sat, Sep 9, 2023 at 12:33 PM sebb wrote:
> Some of the test runs fail when testing with the class:
>
> org.apache.commons.crypto.jna.OpenSslJna
>
> It looks like all the OSes complete the test OK if the default JNA
> library is used.
>
> However for some
Some of the test runs fail when testing with the class:
org.apache.commons.crypto.jna.OpenSslJna
It looks like all the OSes complete the test OK if the default JNA
library is used.
However for some reason its version does not always agree with the
default openSSL version.
This library can be ov
Gary,
Can you have a look at this?
https://github.com/apache/commons-crypto/pull/242
Alex
On Sun, Aug 27, 2023 at 8:38 AM Gary Gregory wrote:
> On Fri, Aug 25, 2023 at 9:48 PM Alex Remily wrote:
> >
> > Breakup
> > the current module into different maven modu
some history, when I was working on the 1.1.x
> > upgrade I was guided by commons committer Marcelo Vanzin. Marcelo
> required
> > a design that supported runtime discovery of the underlying openssl
> API. I
> > don't recall all of the rationale for the requirement, bu
ed
> a design that supported runtime discovery of the underlying openssl API. I
> don't recall all of the rationale for the requirement, but he insisted that
> any commons-crypto upgrade must support legacy and current versions of
> openssl transparently to the calling program. The e
e I was guided by commons committer Marcelo Vanzin. Marcelo required
> a design that supported runtime discovery of the underlying openssl API. I
> don't recall all of the rationale for the requirement, but he insisted that
> any commons-crypto upgrade must support legacy and cu
isted that
any commons-crypto upgrade must support legacy and current versions of
openssl transparently to the calling program. The end result is what we
have now. I don't recall where in the code commons-crypto makes the
underlying version checks, at library initialization time or when
and HMAC on top of OpenSSL 3.0.8.>
>
> Implementing the OpenSSL 3 API and exposing OpenSSL HMAC functionality in
> commons-crypto are things I've wanted to engage on for a while now. I was
> involved in the commons-crypto OpenSSL 1.1.x upgrade so I have some
> familiarity with t
Implementing the OpenSSL 3 API and exposing OpenSSL HMAC functionality in
commons-crypto are things I've wanted to engage on for a while now. I was
involved in the commons-crypto OpenSSL 1.1.x upgrade so I have some
familiarity with the code base, albeit dated. The reason that neithe
https://issues.apache.org/jira/browse/CRYPTO-136 asks that the
https://wiki.openssl.org/index.php/FIPS_mode_set() and FIPS_selftest()
functions be exposed in commons-crypto. (There is also
https://wiki.openssl.org/index.php/FIPS_mode(), which we'd want to
include.)
When exposed in OpenSSL,
Have a look at
https://github.com/apache/commons-crypto/blob/master/src/docker/README.md
On Thu, 10 Aug 2023 at 01:33, Daniel Thertell wrote:
>
> Okay thanks Alex, I haven't looked at the Docker file! I just called make
> in the root of the project.
> I will be digging into
Okay thanks Alex, I haven't looked at the Docker file! I just called make
in the root of the project.
I will be digging into it more tomorrow!
Dan Thertell
On Wed, Aug 9, 2023, 8:21 p.m. Alex Remily wrote:
> I've been meaning to add openssl3 support to common crypto for a while
I've been meaning to add openssl3 support to common crypto for a while
now. Maybe this will give me the push that I need. I'm on my phone now
without access to the branch, but I recall a docker file that provided a
lot of build information on the main branch. You may consider having
_X right now.
> > >
> > > Thanks,
> > > Dan Thertell
> > >
> > > On Wed, Aug 9, 2023 at 2:10 PM Gary Gregory
> > > wrote:
> > >
> > >> I should have kept notes!
> > >>
> > >> Gary
> > >>
> > &
ght now.
> >
> > Thanks,
> > Dan Thertell
> >
> > On Wed, Aug 9, 2023 at 2:10 PM Gary Gregory
> > wrote:
> >
> >> I should have kept notes!
> >>
> >> Gary
> >>
> >> On Wed, Aug 9, 2023, 1:49 PM Daniel Thertell
>
d, Aug 9, 2023 at 2:10 PM Gary Gregory
> wrote:
>
>> I should have kept notes!
>>
>> Gary
>>
>> On Wed, Aug 9, 2023, 1:49 PM Daniel Thertell wrote:
>>
>> > Hey All,
>> >
>> > I am looking to compile Commons Crypto from sourc
, 2023, 1:49 PM Daniel Thertell wrote:
>
> > Hey All,
> >
> > I am looking to compile Commons Crypto from source and I am wondering if
> > there is any documentation for this process? I am trying to build Gary
> > Gregory's OpenSSL3 branch but I am encountering
I should have kept notes!
Gary
On Wed, Aug 9, 2023, 1:49 PM Daniel Thertell wrote:
> Hey All,
>
> I am looking to compile Commons Crypto from source and I am wondering if
> there is any documentation for this process? I am trying to build Gary
> Gregory's OpenSSL3 branch b
Hey All,
I am looking to compile Commons Crypto from source and I am wondering if
there is any documentation for this process? I am trying to build Gary
Gregory's OpenSSL3 branch but I am encountering the following error, I know
this isn't the main branch but I am hoping someone wil
Hey All,
I am looking to compile Commons Crypto from source and I am wondering if
there is any documentation for this process? I am trying to build Gary
Gregory's OpenSSL3 branch but I am encountering the following error. I know
this isn't the main branch but I am hoping someone wil
he drawback is that the bc-fips org is funded
> > through donations and consulting, and is always very far behind Java
> > releases (it's still on Java 11, for example).
> >
> > What we need is a full-featured JSP that is based on a FIPS-certified
> > cryptog
till on Java 11, for example).
>
> What we need is a full-featured JSP that is based on a FIPS-certified
> cryptographic module that is implemented using native code and JNI.
>
> We can get FIPS-certified digests and HMAC from openssl4j. What we need
> from commons-crypto are the ci
cryptographic module that is implemented using native code and JNI.
We can get FIPS-certified digests and HMAC from openssl4j. What we need
from commons-crypto are the ciphers, and they need to be on OpenSSL 3.0.8.
If there's anything we can do to help make that happen, please let us know.
O
Hi Jim,
My branch has not been merged because it does not fully work. It's
challenging to update the code such that one can use either OpenSSL 1.1.1
or 3.0.0 or both. We might need the component split into more than one
Maven module.
The name commons-crypto might have been poorly chosen be
o add FIPS support), and the certification expires soon.
OpenSSL 1.1.1 is the version commons-crypto is currently based on.
OpenSSL 3.0.8 is FIPS-certified on a variety of platforms, supports FIPS
mode natively, and its successor (3.1.x) will be certified for FIPS 140-3.
We're very inte
The Apache Commons Crypto team is pleased to announce the release of
Apache Commons Crypto 1.2.0.
Apache Commons Crypto is a cryptographic library optimized with AES-NI
(Advanced Encryption Standard New Instructions). It provides Java API
for both the cipher level and Java stream level
wrote:
> >
> > We have fixed a few bugs and made some enhancements since Apache
> > Commons Crypto 1.1.0 was released, so I would like to release Apache
> > Commons Crypto 1.2.0.
> >
> > Apache Commons Crypto 1.2.0 RC1 is available for review here:
> >
My +1
Gary
On Sat, Jan 14, 2023 at 5:39 PM Gary Gregory wrote:
>
> We have fixed a few bugs and made some enhancements since Apache
> Commons Crypto 1.1.0 was released, so I would like to release Apache
> Commons Crypto 1.2.0.
>
> Apache Commons Crypto 1.2.0 RC1 is availab
oCo, japicmp, Checkstyle, SpotBugs, CPD, and PMD all
look reasonable
--
We have fixed a few bugs and made some enhancements since Apache
Commons Crypto 1.1.0 was released, so I would like to release Apache
Commons Crypto 1.2.0.
Apache Commons Crypto 1.2.0 RC1
gt; > Gary
> >
> > On Sat, Jan 14, 2023, 17:39 Gary Gregory wrote:
> >
> >> We have fixed a few bugs and made some enhancements since Apache
> >> Commons Crypto 1.1.0 was released, so I would like to release Apache
> >> Commons Crypto 1.2.0.
>
We need more reviews and votes please.
Gary
On Tue, Jan 17, 2023, 10:12 Gary Gregory wrote:
> Ping to PMC members.
>
> Gary
>
> On Sat, Jan 14, 2023, 17:39 Gary Gregory wrote:
>
>> We have fixed a few bugs and made some enhancements since Apache
>> Commons C
Ping to PMC members.
Gary
On Sat, Jan 14, 2023, 17:39 Gary Gregory wrote:
> We have fixed a few bugs and made some enhancements since Apache
> Commons Crypto 1.1.0 was released, so I would like to release Apache
> Commons Crypto 1.2.0.
>
> Apache Commons Crypto 1.2.0 RC1 i
; - mvn apache-rat:check OK!
>>>> - mvn clirr:check OK!
>>>> - mvn install -DskipTests -P japicmp japicmp:cmp OK!
>>>> - mvn -V clean package Failed to run with Java 17. Tried with Java 11,
>>>> same
>>>> failure. Tried Java 8 Oracle, same fail
gt; - mvn clirr:check OK!
> >> - mvn install -DskipTests -P japicmp japicmp:cmp OK!
> >> - mvn -V clean package Failed to run with Java 17. Tried with Java 11,
> >> same
> >> failure. Tried Java 8 Oracle, same failure:
> >>
> >> https://paste.apache.org
> - mvn clirr:check OK!
>> - mvn install -DskipTests -P japicmp japicmp:cmp OK!
>> - mvn -V clean package Failed to run with Java 17. Tried with Java 11,
>> same
>> failure. Tried Java 8 Oracle, same failure:
>>
>> https://paste.apache.org/12mdq
>>
>> C
ure:
>
> https://paste.apache.org/12mdq
>
> Cheers
>
> Bruno
>
>
> On Sat, 14 Jan 2023 at 23:41, Gary Gregory wrote:
>
> > We have fixed a few bugs and made some enhancements since Apache
> > Commons Crypto 1.1.0 was released, so I would like to release Apache
same
failure. Tried Java 8 Oracle, same failure:
https://paste.apache.org/12mdq
Cheers
Bruno
On Sat, 14 Jan 2023 at 23:41, Gary Gregory wrote:
> We have fixed a few bugs and made some enhancements since Apache
> Commons Crypto 1.1.0 was released, so I would like to release Apache
>
We have fixed a few bugs and made some enhancements since Apache
Commons Crypto 1.1.0 was released, so I would like to release Apache
Commons Crypto 1.2.0.
Apache Commons Crypto 1.2.0 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/crypto/1.2.0-RC1
(svn
On Mon, 4 Jul 2022 at 23:53, sebb wrote:
>
> On Mon, 4 Jul 2022 at 17:20, sebb wrote:
> >
> > The JNA code should now be able to support all combinations of methods.
> >
> > Also JNA supports the property jna.library.path when loading the crypto
> > library.
On Mon, 4 Jul 2022 at 17:20, sebb wrote:
>
> The JNA code should now be able to support all combinations of methods.
>
> Also JNA supports the property jna.library.path when loading the crypto
> library.
> This allows one to override the default which may not be the same as
>
The JNA code should now be able to support all combinations of methods.
Also JNA supports the property jna.library.path when loading the crypto library.
This allows one to override the default which may not be the same as
the default OpenSSL version. e.g. the GH action builds default to
OpenSSL
"Right now, we are (in my opinion) basically unable to create a new
release."
Uh? I did the previous release so "we" means what exactly?
Gary
On Sun, Jul 3, 2022, 15:49 Jochen Wiedmann
wrote:
> On Wed, Jun 29, 2022 at 7:08 PM Gary Gregory
> wrote:
> >
> > An important aspect to consider is co
There is no reason to drop macOS.
Gary
On Sun, Jul 3, 2022, 15:49 Jochen Wiedmann
wrote:
> On Wed, Jun 29, 2022 at 7:08 PM Gary Gregory
> wrote:
> >
> > An important aspect to consider is compatibility, we do not want to break
> > anything within a major version.
>
> True, but nothing prevents
at 3:56 PM Sebb (Jira) wrote:
>
>
> [
> https://issues.apache.org/jira/browse/CRYPTO-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
>
> Sebb resolved CRYPTO-158.
> -
> Resolution: Invalid
On Wed, Jun 29, 2022 at 7:08 PM Gary Gregory wrote:
>
> An important aspect to consider is compatibility, we do not want to break
> anything within a major version.
True, but nothing prevents us from incrementing the major version
number at this point.
That would also enable us, to address more
On Fri, 1 Jul 2022 at 16:33, Alex Remily wrote:
>
> be shown in the Crypto main output.>
Now committed; seems to work on all 3 main OSes.
> I like the approach. I wrote most of the version code that you're
> touching, and your refactoring is more elegant.
Thanks, but I&#x
> worked since it loaded the commons-crypto JNI lib.
> >
> > The dlopen In that shim searches various places, including PATH.
>
> According to dlopen(3) it does not search PATH, instead it uses
> LD_LIBRARY_PATH, and some DYLD_* paths.
>
> > If you can’t put the Open
On Fri, 1 Jul 2022 at 04:16, Bernd Eckenfels wrote:
>
> The Java.library.path controls the Java side loadLibrary() but that worked
> since it loaded the commons-crypto JNI lib.
>
> The dlopen In that shim searches various places, including PATH.
According to dlopen(3) it does
The Java.library.path controls the Java side loadLibrary() but that worked
since it loaded the commons-crypto JNI lib.
The dlopen In that shim searches various places, including PATH. If you can’t
put the OpenSSL variant first, then it might instead help to define the path
with a absolute name
ATH=/usr/lib
> export LD_LIBRARY_PATH=/usr/lib
> env | grep LIBRAR
>
> I get:
>
> LD_LIBRART_PATH=/usr/lib
>
> Similarly with DYLD_*
>
> I think we may need to allow the user to provide the full path name to
> the crypto library.
>
> > On Thu, Jun 30, 2
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
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
LIBRAR
I get:
LD_LIBRART_PATH=/usr/lib
Similarly with DYLD_*
I think we may need to allow the user to provide the full path name to
the crypto library.
> On Thu, Jun 30, 2022 at 9:39 AM sebb wrote:
>
> > I've started copying bits of the C code to create a standalone tool to
>
rote:
> >
> > > 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
;
> 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?
> >
> > On Thu, 30 Jun 2022 at 12:52, Gary Gregory wrote:
> > >
> > > Wit
4 x86_64
UI says 12.4
Gary
>
> 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.Crypto
> > A
ee 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
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
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
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 Ac
com/apache/commons-crypto/actions/runs/2586011129
I just noticed also that 'openssl version' shows 1.1.1p but the Crypto
class shows
OpenSSL library info: LibreSSL 2.2.9 (on current code; the 1.11.0 code crashes)
Something strange is going on; it looks like dlopen is finding a
different ve
> 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: https://pastebin.com/raw/nPczrrd8
1 - 100 of 904 matches
Mail list logo
