Figured you were busy, just wanted to keep this process alive. Let me
know if you need artifacts to be built, I can help there and can stash
them in S3 or somewhere.
-Geoff
On Fri, May 15, 2020 at 1:25 PM Gary Gregory wrote:
>
> Work work work
> I'll see if I can take a look this weekend...
>
Work work work
I'll see if I can take a look this weekend...
Gary
On Fri, May 15, 2020 at 10:19 AM Geoffrey Blake
wrote:
> bump
>
> On Mon, May 11, 2020 at 10:21 AM Geoffrey Blake
> wrote:
> >
> > All outstanding PR's have been merged to the repository, the code
> > coverage from coveralls
bump
On Mon, May 11, 2020 at 10:21 AM Geoffrey Blake
wrote:
>
> All outstanding PR's have been merged to the repository, the code
> coverage from coveralls looks good to me at over 80% coverage.
>
> There are some areas that lack coverage, such as static main functions
> in some classes,
All outstanding PR's have been merged to the repository, the code
coverage from coveralls looks good to me at over 80% coverage.
There are some areas that lack coverage, such as static main functions
in some classes, exception paths that guard against failures coming
from the crypto library,
I see now, you are correct Alex. My confusion is stemming partly from
my lack of familiarity with Java (I touch Java code once every few
years), and not having the API in my head. You can get to
OpenSslJnaCipher in that way. It really should be included in
CryptoCipherFactory.CipherProvider as
So I did a little homework and JNA appears to be a first class citizen
in Commons Crypto. One instantiates a JNA-backed CryptoCipher just as
one does JNI or JCE. The OpenSslJna class is exposed for that
purpose. I hacked together the below from some JNA test classes to
demonstrate and it runs
JNA is the middle ground between JNI and JCE in terms of performance
is my understanding without needing any .c files to create linkage.
The problem appears to be that there is no conditional loading and
stubbing of functions like can be done easily in the JNI code and is
why macOS throws that
> I think Geoff just answered this question for us.
Yup he was quicker with his reply than me! Thanks :-)
--
Adam Retter
skype: adam.retter
tweet: adamretter
http://www.adamretter.org.uk
-
To unsubscribe, e-mail:
My apologies. It is only the JNA. I wasn't paying attention and got
crossed with some errors I dealt with while troubleshooting another
issue.
** WARN: JNA could not be enabled: Error looking up function
'ENGINE_load_rdrand': dlsym(0x7f859c4b6db0, ENGINE_load_rdrand):
symbol not found.
I've
Adam,
I think Geoff just answered this question for us. I'll go back and
check the Travis logs to see which tests were actually skipped. If
they were just the JNA tests then it's probably not much of a problem.
On Mon, Apr 27, 2020 at 9:44 AM Adam Retter
wrote:
>
> Thanks Alex,
>
> I don't
I assumed it was JNI. I'll have to go back and check.
On Mon, Apr 27, 2020 at 9:41 AM Geoffrey Blake
wrote:
>
> Hi Alex,
>
> Just a sanity check, are you sure it was the JNI failing to load or
> was it the JNA? At least on my Mojave MacOS install, libreSSL is
> found and links fine with JNI.
Thanks Alex,
I don't have a great deal of time available to look into this. If
someone could assure me that this compiles, and all the tests run
correctly on their MacOS with LibreSSL first, then I could then figure
out the difference on Travis. I suspect it is a more general Mac issue
than just
Hi Alex,
Just a sanity check, are you sure it was the JNI failing to load or
was it the JNA? At least on my Mojave MacOS install, libreSSL is
found and links fine with JNI. JNA is the library that fails to load
on macOS, but that is apparently ok as the JNA implementation is not
used by
Adam,
Fair points. I don't know if commons-crypto "officially" supports
LibreSSL, but now that I think about it, it may be a moot point. As
long as LibreSSL complies with the OpenSSL 1.0 or 1.1 API, it *should*
run. It did compile and build against LibreSSL on the Mac, and the
tests didn't
Hi Alex,
> Just submitted a PR to increase the coverage in the streams package.
> While prepping the PR I noticed the Travis Mac build is testing
> against LibreSSL
I recently improved the Travis builds for a few platforms, however
libressl on Mac OS has been the case since before I was
Just submitted a PR to increase the coverage in the streams package.
While prepping the PR I noticed the Travis Mac build is testing
against LibreSSL, which doesn't successfully load the native libraries
to support JNI:
[WARNING] Tests run: 139, Failures: 0, Errors: 0, Skipped: 42
Note the 42
I hope to have a PR in this weekend sometime with an increase in code
coverage for streams. I haven't touched anything else yet, so any other
package is fair game.
On Fri, Apr 24, 2020 at 12:16 PM Geoffrey Blake
wrote:
> I figure everyone is a bit busy, but wanted to ask where we are all in
>
On Fri, Apr 24, 2020 at 12:16 PM Geoffrey Blake
wrote:
> I figure everyone is a bit busy, but wanted to ask where we are all in
> getting close to a new release of commons-crypto that contains the new
> binaries, Alex, Gary? Any other unit test areas that need attention
> Alex that you may need
I figure everyone is a bit busy, but wanted to ask where we are all in
getting close to a new release of commons-crypto that contains the new
binaries, Alex, Gary? Any other unit test areas that need attention
Alex that you may need help with?
-Geoff
On Wed, Apr 22, 2020 at 11:33 AM Adam Retter
If you want to build on CentOS for releases that is fine - I can add
Docker Build Environments as a Travis job that use older CentOS.
On Wed, 22 Apr 2020 at 18:02, Geoffrey Blake wrote:
>
> I think it depends on whether using Ubuntu 14.04/16.04 as the base
> distro for releases is ok. It seems
I think it depends on whether using Ubuntu 14.04/16.04 as the base
distro for releases is ok. It seems most projects like to build on
some variant of RHEL/CentOS as they typically use stable (read older)
compilers and libc.
Does Travis allow building all the binaries then having a final
process
No that https://github.com/apache/commons-crypto/pull/96 has been
merged, we have support for Arm64, ppc64le and x64 in Travis.
I wondered if it was useful for the "Release Process" if we had Travis
build and store release artifacts? I believe we can have Travis do
this only when Git tags are
Still plugging away on streams. I bumped one class 15 to 20 points and I'm
on to the next class. My initial impression is that there's good coverage
on the happy paths, but anything non-standard is less well covered. The
biggest challenge so far has been to figure out what input to use to get
I've gotten through the JNA code and Random code for increasing unit
testing. I've got some changes I'm readying to bump up coverage by a
few percentage points, mainly along the lines of passing in invalid
output and making sure nothing falls over.
@Alex, any luck with the stream portion of the
Adding OpenSSL 1.1.x for x64, arm64, and ppc64le, turned out to be
trivial so I just pushed it now in an additional commit to the same
PR.
On Sun, 19 Apr 2020 at 15:19, Alex Remily wrote:
>
> Makes sense to me, but I defer to Gary. Thanks again for making the
> effort.
>
> On Sun, Apr 19, 2020
Makes sense to me, but I defer to Gary. Thanks again for making the
effort.
On Sun, Apr 19, 2020 at 5:33 AM Adam Retter
wrote:
> Presumably that should come as a separate PR which builds on this one?
>
> On Sun, 19 Apr 2020, 11:26 Adam Retter,
> wrote:
>
> > Shouldn't be too bad. Depends on
Presumably that should come as a separate PR which builds on this one?
On Sun, 19 Apr 2020, 11:26 Adam Retter, wrote:
> Shouldn't be too bad. Depends on what packages are prebuilt and available
> - I can take a look later
>
> On Sun, 19 Apr 2020, 04:43 Alex Remily, wrote:
>
>> Thanks Adam.
Shouldn't be too bad. Depends on what packages are prebuilt and available -
I can take a look later
On Sun, 19 Apr 2020, 04:43 Alex Remily, wrote:
> Thanks Adam. Very much appreciated. How much effort would it be to do the
> same for OpenSSL 1.1.x?
>
> On Sat, Apr 18, 2020 at 11:41 AM Adam
Thanks Adam. Very much appreciated. How much effort would it be to do the
same for OpenSSL 1.1.x?
On Sat, Apr 18, 2020 at 11:41 AM Adam Retter
wrote:
> As promised, I added support for further environments to Travis -
> https://github.com/apache/commons-crypto/pull/96
>
> On Mon, 13 Apr 2020
As promised, I added support for further environments to Travis -
https://github.com/apache/commons-crypto/pull/96
On Mon, 13 Apr 2020 at 16:35, Alex Remily wrote:
>
> I don't know whether it would help the build manager with the release
> process, but I think it would be a good idea to update
You can probably use maven-dependency-plugin and maven-assembly-plugin
to form a coherent whole:
https://maven.apache.org/plugins/maven-dependency-plugin/unpack-mojo.html
https://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html
On Fri, 17
> Note that this build uses profiles and each binary is named for its target
> platform.
Except the release artifact on Maven central contains all the shared
libs in one jar in org/apache/commons/crypto/native/OS/ARCH. The
makefile takes the artifact from
targer/commons-crypto--- and places it
On Thu, Apr 16, 2020 at 5:57 PM Geoffrey Blake
wrote:
> I got distracted and wanted to know why you might be thinking of doing
> the cross-compiling path, $mvn release:prepare will always clean the
> target/ directory and rebuild. We don't want that to cobble together
> artifacts from
I got distracted and wanted to know why you might be thinking of doing
the cross-compiling path, $mvn release:prepare will always clean the
target/ directory and rebuild. We don't want that to cobble together
artifacts from different build sources, which ultimately would
probably want to happen
> It looks that me doing a release is going to be a lot more tricky than I
> initially thought due to getting cross-compiling to work instead of hacking
> together a build from other builds on different environments. This means
> that you have more time to increase the coverage ;-)
What is the
On Wed, Apr 15, 2020 at 5:46 PM Geoffrey Blake
wrote:
> So, I built commons-crypto against SSL 1.0.2n on Ubuntu 18.04LTS and
> all the tests pass. The code coverage bumps to 72%, I'm guessing if I
> did Mac we'd see the 73% coverage seen from Travis CI.
>
> @Gary, what should a reasonable
On Wed, Apr 15, 2020 at 7:01 PM Alex Remily wrote:
> I've seen the expected exception error, but rarely and I've never been able
> to reproduce it. I'm surprised it's come up on Travis because it's only
> come up a few times for me in the hundreds of builds I've done. Maybe we
> log it as a
I've seen the expected exception error, but rarely and I've never been able
to reproduce it. I'm surprised it's come up on Travis because it's only
come up a few times for me in the hundreds of builds I've done. Maybe we
log it as a bug just to document it, but like I said, I don't know how to
So, I built commons-crypto against SSL 1.0.2n on Ubuntu 18.04LTS and
all the tests pass. The code coverage bumps to 72%, I'm guessing if I
did Mac we'd see the 73% coverage seen from Travis CI.
@Gary, what should a reasonable coverage target be? 73% is not great,
but not sure how much higher
On Tue, Apr 14, 2020 at 4:45 PM Geoffrey Blake
wrote:
> Hi Gary,
>
> I'm looking through the Jacoco report and see that some of the low
> coverage is coming from the following:
> 1. Not being able to cover the native classes, listing them as 0%
> 2. OpenSSL 1.1.x and 1.0.x, depending on the
Hi Gary,
I'm looking through the Jacoco report and see that some of the low
coverage is coming from the following:
1. Not being able to cover the native classes, listing them as 0%
2. OpenSSL 1.1.x and 1.0.x, depending on the build env, only 1 will be covered
3. Some conditional statements are
> If the only concern is the file signatures, I'm almost sure that the
> maven build will pick up native libraries you drop in some directory
> and include them in the jar, regardless of whether they're for the
> current architecture. Then you'd get the jar with all native libraries
> and the
I don't know whether it would help the build manager with the release
process, but I think it would be a good idea to update the build matrix
regardless. I made an attempt a while ago to add coverage for more
environments, but ultimately I wasn't successful. I don't recall if the
limitations
Travis now offer Arm64 and Mac. I could setup a job to build binaries on
Travis and keep a copy either on every commit or when a tag is created.
Would that be helpful?
On Mon, 13 Apr 2020, 03:13 Gary Gregory, wrote:
> On Sun, Apr 12, 2020 at 8:57 PM Alex Remily wrote:
>
> > I can do the 64 bit
On Sun, Apr 12, 2020 at 6:13 PM Gary Gregory wrote:
> > I can do the 64 bit builds on Mac, Linux and Windows, so I'm happy to
> > provide whichever of those is required. It seems that Geoff can do the
> > arm64 build. Do we even bother supporting 32 bit architectures at this
> > point?
>
>
On Sun, Apr 12, 2020 at 8:57 PM Alex Remily wrote:
> I can do the 64 bit builds on Mac, Linux and Windows, so I'm happy to
> provide whichever of those is required. It seems that Geoff can do the
> arm64 build. Do we even bother supporting 32 bit architectures at this
> point?
>
I can do the 64 bit builds on Mac, Linux and Windows, so I'm happy to
provide whichever of those is required. It seems that Geoff can do the
arm64 build. Do we even bother supporting 32 bit architectures at this
point?
On Sun, Apr 12, 2020 at 7:36 PM Marcelo Vanzin wrote:
> Hi Gary,
>
> On
Hi Gary,
On Sun, Apr 12, 2020 at 8:53 AM Gary Gregory wrote:
> > The 1.0 release on maven central only included linux32 and linux64 native
> > libs, even though the Makefile supports many more targets
> >
>
> Please see the snapshot builds which now include more:
>
I can look into the code coverage this week. The arm64 build needs to be
included, I can provide that from rhel8 if needed. I believe the target is
in the pom file.
On Sun, Apr 12, 2020 at 11:14 AM Alex Remily wrote:
> I'll see if I can look at the code coverage this week. Today is busy with
I'll see if I can look at the code coverage this week. Today is busy with
family stuff. I can contribute an OS X build (High Sierra) if you're
looking for one.
Alex
On Sun, Apr 12, 2020 at 11:53 AM Gary Gregory
wrote:
> On Sun, Apr 12, 2020 at 10:49 AM Geoffrey Blake <
>
On Sun, Apr 12, 2020 at 10:49 AM Geoffrey Blake
wrote:
> Gary, Alex,
>
> Let me know what else needs doing.
Hi All:
See my previous email WRT code coverage using JaCoCo.
> I can certainly help with building
> artifacts, just need guidance on minimum distro and Java to use.
>
Thank you for
Gary, Alex,
Let me know what else needs doing. I can certainly help with building
artifacts, just need guidance on minimum distro and Java to use.
The 1.0 release on maven central only included linux32 and linux64 native
libs, even though the Makefile supports many more targets
-Geoff
On Sun,
On Sat, Apr 11, 2020 at 1:55 PM Alex Remily wrote:
> This looks to be done. I added a comment to the ticket with a link to the
> commit.
>
>
> https://github.com/apache/commons-crypto/commit/3466943e4552474ab681d7852dbfa62c74d8e1ce
Thanks Alex, I resolved the parent ticket and added it to
This looks to be done. I added a comment to the ticket with a link to the
commit.
https://github.com/apache/commons-crypto/commit/3466943e4552474ab681d7852dbfa62c74d8e1ce
Alex
On Sat, Apr 11, 2020 at 11:54 AM Gary Gregory
wrote:
> On Sat, Apr 11, 2020 at 8:43 AM Gary Gregory
> wrote:
>
> >
On Sat, Apr 11, 2020 at 8:43 AM Gary Gregory wrote:
> On Fri, Apr 10, 2020 at 8:38 PM Marcelo Vanzin wrote:
>
>> (-CCs)
>>
>> Hi Gary, thanks for volunteering to help. If needed I can try helping with
>> the release process (e.g. uploading artifacts), but I don't really have
>> the
>> ability
Gary,
I confirmed that all JIRAs listed on
https://issues.apache.org/jira/projects/CRYPTO/versions/12335578 are in git
master.
Alex
On Sat, Apr 11, 2020 at 8:44 AM Gary Gregory wrote:
> On Fri, Apr 10, 2020 at 8:38 PM Marcelo Vanzin wrote:
>
> > (-CCs)
> >
> > Hi Gary, thanks for
On Fri, Apr 10, 2020 at 8:38 PM Marcelo Vanzin wrote:
> (-CCs)
>
> Hi Gary, thanks for volunteering to help. If needed I can try helping with
> the release process (e.g. uploading artifacts), but I don't really have the
> ability to build anything but the linux64 native lib (maybe the linux32
Disregard. I figured it out.
On Fri, Apr 10, 2020 at 9:17 PM Alex Remily wrote:
> Gary,
>
> I don't have access to the page at the link. Can you add me?
> Sorry, you can't view this page
> This page is only available to Jira Software users. If you think you
> should be a Jira Software user,
Gary,
I don't have access to the page at the link. Can you add me?
Sorry, you can't view this page
This page is only available to Jira Software users. If you think you should
be a Jira Software user, you should ask your administrator to give you
application access to Jira Software.
On Fri, Apr
(-CCs)
Hi Gary, thanks for volunteering to help. If needed I can try helping with
the release process (e.g. uploading artifacts), but I don't really have the
ability to build anything but the linux64 native lib (maybe the linux32 one
if I can find the right packages or docker image).
I looked at
On Fri, Apr 10, 2020 at 8:02 PM Gary Gregory wrote:
> I'll see what I can do over the weekend.
>
> Gary
>
Alex,
Here is how you can help now:
Please review the tickets for 1.1.0 here:
https://issues.apache.org/jira/projects/CRYPTO/versions/12335578
These are all marked as resolved. Can you
I'll see what I can do over the weekend.
Gary
On Thu, Apr 9, 2020 at 8:45 PM Alex Remily wrote:
> Commons Crypto Team,
>
> It's been four years since the last release of commons crypto. There have
> been many updates to the repository since then, notably the integration of
> OpenSSL 1.1.1,
Commons Crypto Team,
It's been four years since the last release of commons crypto. There have
been many updates to the repository since then, notably the integration of
OpenSSL 1.1.1, and native arm64 support. Geoff Blake (copied) and I have
been advocating for a new release, and we need
63 matches
Mail list logo
