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 modules? Not support both?>
> >
> >
Given Marcelo's response, I think it makes sense to retain support for
1.1.x, add support for 3.0.x using dynamic version discovery, and drop
support for anything older than 1.1. This would align us with the openssl
LTS versions. Looks like 3.1.x isn't FIPS validated.
On Fri, Aug 25, 2023 at 9:48 PM Alex Remily wrote:
>
> the current module into different maven modules? Not support both?>
>
> Agreed. Just to provide 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
Oh, wow, I think I heard my name.
First, big disclaimer that I haven't really worked with any of this stuff
for years, so take what I say with a big pinch of salt. I have no idea of
what's the current state of things in OpenSSL-land.
As far as I can remember, the desire to do runtime discovery
Agreed. Just to provide 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, but he insisted
That would be great. I think this is worth the effort. A big item to
consider is if and how 1.1 vs 3.0 should be handled. Breakup the current
module into different maven modules? Not support both?
Gary
On Wed, Aug 23, 2023, 8:37 PM Alex Remily wrote:
> how to implement message digests and
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 neither the
I'm still trying to come up to speed on your PR/fork. A lot to learn!
Ack about licensing. The idea wouldn't be to copy the code, but to learn
how to implement message digests and HMAC on top of OpenSSL 3.0.8.
On Tue, Aug 1, 2023, 5:03 AM Gary Gregory wrote:
> In the short, the best way to
In the short, the best way to help is to provide PRs.
In more detail, we should probably come up with some kind of a plan so that
everyone uses their time wisely.
I'll review my branch this week or next and see where that stands, but feel
free to look at it, use it, PR it, as I might not actually
A split seems reasonable. We were amazed at how few changes you had to make
to support OpenSSL 3.x. The EVPs are very different. But it sounds like
there's more to do.
The problem with commons-codec is that it doesn't use OpenSSL or any other
FIPS-certified cryptographic module. For example,
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 because
We are trying to replace bc-fips (https://www.bouncycastle.org/fips-java/)
with a JSP that is based on a cryptographic module that is 1) a native
library and 2) is certified for FIPS 140-2 (
https://csrc.nist.gov/pubs/fips/140-2/upd2/final).
A native library is faster, plus it doesn't entangle
12 matches
Mail list logo
