Re: [commons-crypto] OpenSSL 3.x, FIPS, digests, and HMAC
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 be able to take the time this week. WRT openssl4j, you CANNOT bring in anything licensed under the LGPL. IANAL, but our documentation seems clear to me, please see https://www.apache.org/legal/resolved.html#category-x Hope this helps and we can make it work! Gary On Mon, Jul 31, 2023, 8:02 PM Jim Showalter wrote: > 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, HmacUtils uses Mac, which > is supplied by the JRE, which isn't FIPS-certified. > > In order to qualify for FedRAMP High, which is table stakes for a lot of > corporate and government contracts, FIPS has to be used. It's mandated by > statute. No wiggle room. > > The promise of bc-fips is that it is FIPS-certified, is a JSP, and > implements the full JCE. The 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 > 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. > > On Mon, Jul 31, 2023 at 2:58 PM Gary Gregory > wrote: > > > 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 it's > current > > remit is an OpelSSL wrapper. That said there is 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-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 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 the Java classpath > > > with restrictions on Java versions or load order the way bc-fips does. > > > > > > The two available native libraries we're aware of are BoringSSL and > > > OpenSSL. > > > > > > For various reasons, we want to use OpenSSL. > > > > > > OpenSSL 1.1.1 was only FIPS-certified on RedHat (and they had to modify > > it > > > to 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 interested in > > > https://github.com/garydgregory/commons-crypto/tree/openssl3, which > adds > > > support for OpenSSL 3.0.8 to commons-crypto, per > > > https://issues.apache.org/jira/browse/CRYPTO-164. > > > > > > But that PR was never merged, hasn't been touched since December 20, > > 2022, > > > and is currently 92 commits behind the main branch. > > > > > > What would it take to update that PR with all of the commits since > then, > > > and get it merged? > > > > > > Once that's done, we'd be happy to submit a PR to add FIPS mode, per > > > https://issues.apache.org/jira/browse/CRYPTO-136. > > > > > > Also, commons-crypto doesn't support message digests or HMAC. We're in > > the > > > process of adding HMAC and FIPS mode to > > > https://github.com/sfuhrm/openssl4j, > > > which has message digests, and targets OpenSSL 3.0.8. > > > > > > It seems like the message digests and HMAC from openssl4j could be > merged > > > into commons-crypto, to bring it closer to being a full JCE > > implementation. > > > Is there any interest in seeing that happen? > > > > > >
Re: [commons-crypto] OpenSSL 3.x, FIPS, digests, and HMAC
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 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 be able to take > the time this week. > > WRT openssl4j, you CANNOT bring in anything licensed under the LGPL. IANAL, > but our documentation seems clear to me, please see > https://www.apache.org/legal/resolved.html#category-x > > Hope this helps and we can make it work! > Gary > > > On Mon, Jul 31, 2023, 8:02 PM Jim Showalter > wrote: > > > 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, HmacUtils uses Mac, > which > > is supplied by the JRE, which isn't FIPS-certified. > > > > In order to qualify for FedRAMP High, which is table stakes for a lot of > > corporate and government contracts, FIPS has to be used. It's mandated by > > statute. No wiggle room. > > > > The promise of bc-fips is that it is FIPS-certified, is a JSP, and > > implements the full JCE. The 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 > > 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. > > > > On Mon, Jul 31, 2023 at 2:58 PM Gary Gregory > > wrote: > > > > > 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 it's > > current > > > remit is an OpelSSL wrapper. That said there is 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-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 < > jamesleeshowal...@gmail.com > > > > > > wrote: > > > > > > > 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 the Java > classpath > > > > with restrictions on Java versions or load order the way bc-fips > does. > > > > > > > > The two available native libraries we're aware of are BoringSSL and > > > > OpenSSL. > > > > > > > > For various reasons, we want to use OpenSSL. > > > > > > > > OpenSSL 1.1.1 was only FIPS-certified on RedHat (and they had to > modify > > > it > > > > to 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 interested in > > > > https://github.com/garydgregory/commons-crypto/tree/openssl3, which > > adds > > > > support for OpenSSL 3.0.8 to commons-crypto, per > > > > https://issues.apache.org/jira/browse/CRYPTO-164. > > > > > > > > But that PR was never merged, hasn't been touched since December 20, > > > 2022, > > > > and is currently 92 commits behind the main branch. > > > > > > > > What would it take to update that PR with all of the commits since > > then, > > > > and get it merged? > > > > > > > > Once that's done, we'd be happy to submit a PR to add FIPS mode, per > > > > https://issues.apache.org/jira/browse/CRYPTO-136. > > > > > > > > Also, commons-crypto doesn't support message digests or HMAC. We're > in > > > the > > > > process of addi
[VOTE] Release Apache Commons DbUtils 1.8.0 based on RC1
We have fixed a few bugs and added some enhancements since Apache Commons DbUtils 1.7 was released, so I would like to release Apache Commons DbUtils 1.8.0. Apache Commons DbUtils 1.8.0 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/dbutils/1.8.0-RC1 (svn revision 63303) The Git tag commons-dbutils-1.8.0-RC1 commit for this RC is 675cfcd2f68b03254746c24d76a83a23dcddc6a2 which you can browse here: https://gitbox.apache.org/repos/asf?p=commons-dbutils.git;a=commit;h=675cfcd2f68b03254746c24d76a83a23dcddc6a2 You may checkout this tag using: git clone https://gitbox.apache.org/repos/asf/commons-dbutils.git --branch commons-dbutils-1.8.0-RC1 commons-dbutils-1.8.0-RC1 Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1648/commons-dbutils/commons-dbutils/1.8.0/ These are the artifacts and their hashes: #Release SHA-512s #Tue Aug 01 20:32:34 EDT 2023 commons-dbutils-1.8.0-src.tar.gz=be1af717639a605d9510e2ac7435c0f06ba37ce8700e93f38e3f71a83ea2758c71821545d7271adc5ae7d9506c1f557386ee9b67a4979f9ab3fe7cb27a08e179 commons-dbutils_commons-dbutils-1.8.0.spdx.json=295f2decdbf6e68696b5c44939029deec01ae8619dae4093b617f4171968cf8b281bd723815331e124a807fb1c5e74b5c22cf6c146281857874f1be38ef12cde commons-dbutils-1.8.0-sources.jar=6ab3192fb57bbdabfeb5f9992e3922cf7e6ef221d3ec5a7d66bd079406f6235058bfb6f115fa3e1ad7c8e02cd65fbb00adebf65c9c8914ba2758b30c24d97e32 commons-dbutils-1.8.0-bom.json=6f939509e9cf901fab00c5e45e38ca8dcfe81c35069c97a270e0ba89f0d557feddd5f98b1320ed346e401e7be5a560325c021b6d8ba55ea2b0ea0a8652d037cb commons-dbutils-1.8.0-test-sources.jar=dac78668a91c6d3eed45f591a8a2c83f3cfc4871bd3a478aa0ed117ad6b315f9e14c43e38aafcf8b6e4f2e4e8076802dc2481d3bc1950f2cb928e74685cee960 commons-dbutils-1.8.0-src.zip=0af2de984787938c1277cf34a5e54cf50dd1674e962cc7280c47f6129ceeda86f8e18e422056dbf859f774cc65135e786552bb4847869e1f6e4c6f3bb089e9c7 commons-dbutils-1.8.0-bom.xml=5d7be2ff22c55ce73022230a4f2242b9d43c9fe6dcf1cda552d19c4bcb255222adb78774bdfc57f0159da947ea65509fd63ad568c79f5fed51e4bb3a2ae8142b commons-dbutils-1.8.0-bin.zip=76ebf30c465218022210f4e6ffc61756360a949156b5b3100ff9024ae6d782c328624b3bf1149280b0df4c466d3b4687efa92e6f9c483fc800bac47eddb0fbf5 commons-dbutils-1.8.0-javadoc.jar=453cdd7517bc1f1ab0fb48e57d2795e8d1ded586246640a77b2b71d10c227ee7fae9c952f7cb82746be3df3e6544e097219873c732ba7b70271961666c2512bd commons-dbutils-1.8.0-bin.tar.gz=1f3832fd5e7a997d93174b8c08f630522b7ef59b878e48ea1aa1f80924290dec6ce56db9ae003c010eec4384e8aea33d8c4b84e4d232bf7ba13ae42b3618e25f commons-dbutils-1.8.0-tests.jar=96291ca4e46c5c426c45d65c4a219aeadb2f9fe1b4e18dd293d1a0529b171403a064a59f675707f2cf773a6a813abf8d1b58f3e46f9652a28eec4193d2421c97 I have tested this with mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy Using: Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f) Maven home: /usr/local/Cellar/maven/3.9.3/libexec Java version: 11.0.20, vendor: Homebrew, runtime: /usr/local/Cellar/openjdk@11/11.0.20/libexec/openjdk.jdk/Contents/Home Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "13.5", arch: "x86_64", family: "mac" Darwin gdg-mac-mini.local 22.6.0 Darwin Kernel Version 22.6.0: Wed Jul 5 22:21:56 PDT 2023; root:xnu-8796.141.3~6/RELEASE_X86_64 x86_64 Java 11 is used to produce a JPMS module but the target byte code and API is enforced as Java 8. Details of changes since 1.7 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/dbutils/1.8.0-RC1/RELEASE-NOTES.txt https://dist.apache.org/repos/dist/dev/commons/dbutils/1.8.0-RC1/site/changes-report.html Site: https://dist.apache.org/repos/dist/dev/commons/dbutils/1.8.0-RC1/site/index.html (note some *relative* links are broken and the 1.8.0 directories are not yet created - these will be OK once the site is deployed.) JApiCmp Report (compared to 1.7): https://dist.apache.org/repos/dist/dev/commons/dbutils/1.8.0-RC1/site/japicmp.html RAT Report: https://dist.apache.org/repos/dist/dev/commons/dbutils/1.8.0-RC1/site/rat-report.html KEYS: https://downloads.apache.org/commons/KEYS Please review the release candidate and vote. This vote will close no sooner than 72 hours from now. [ ] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... Thank you, Gary Gregory, Release Manager (using key 86fdc7e2a11262cb) For following is intended as a helper and refresher for reviewers. Validating a release candidate == These guidelines are NOT complete. Requirements: Git, Java, Maven. You can validate a release from a release candidate (RC) tag as follows. 1a) Clone and checkout the RC tag git clone https://gitbox.apache.org/repos/asf/commons-dbutils.git --branch commons-dbutils-1.8.0-RC1 commons-dbutils-1.8.0-RC1 cd commons-dbutils-1.8.0-RC1 1b) Download and unpack the sourc
