te its dependencies
> (except for critical security updates). A new major version of a library is
> out of scope anyway and especially in this case since it requires source
> updates.
>
> Gary
>
> On Mon, Aug 14, 2023, 4:30 PM Jim Showalter
> wrote:
>
> > Libraries should b
Libraries should be kept on the oldest safe (LTS) version forever, IMHO, to
avoid stranding legacy services.
On Mon, Aug 14, 2023, 9:15 AM James Reeves wrote:
> I'd very much prefer 11, unless 17 is necessary. I have a library that
> currently depends on FileUpload 1.5, and only requires Java
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, we'll
room for more features,
> > > which may mean splitting things up into more than one Maven module.
> > >
> > > Commons Code provides more convenience wrappers for JRE message digests
> > > including HMAC:
> > > https://commons.apache.org/proper/commons
ge digests
> including HMAC:
> https://commons.apache.org/proper/commons-codec/apidocs/index.html
>
> Are you looking to wrap or implement HMAC and message digests differently?
>
> Gary
>
>
> On Mon, Jul 31, 2023, 5:04 PM Jim Showalter
> wrote:
>
> > We are trying to
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
