[security] finding known issues for commons projects
Hello commons-dev! I found the very lovely https://commons.apache.org/security.html page and I very much appreciate the links out to individual project's security pages. However, it looks like a little under half (9/21) have security pages linked. Does this mean that the other 12 projects have never had a security vulnerability reported? Reported but rejected? Reported and triaged in other ways - e.g. patched but not assigned a CVE? Any insight into the practices of the community is appreciated! Thanks, Mike - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons JCS 3.2 based on rc1
ping. On Sat, Aug 26, 2023 at 11:08 AM Gary Gregory wrote: > Is this vote this open? If not please, cancel it. > > There is nothing at > > https://repository.apache.org/content/repositories/orgapachecommons-orgapachecommons-1650/org/apache/commons/commons-jcs3/3.2/ > > Gary > > On Tue, Aug 22, 2023 at 9:15 AM Thomas Vandahl wrote: > > > > We have fixed quite a few bugs and added some significant enhancements > since Apache Commons JCS 3.1 was released, so I would like to release > Apache Commons JCS 3.2. > > > > Apache Commons JCS 3.2 rc1 is available for review here: > > https://dist.apache.org/repos/dist/dev/commons/jcs/3.2-rc1 (svn > revision 63581) > > > > The Git tag commons-jcs-3.2-rc1 commit for this RC is > eb9c5b36b48f2b6f45fba7986d46c7006cfb5c4c which you can browse here: > > > https://gitbox.apache.org/repos/asf?p=commons-jcs.git;a=commit;h=eb9c5b36b48f2b6f45fba7986d46c7006cfb5c4c > > You may checkout this tag using: > > git clone https://gitbox.apache.org/repos/asf/commons-jcs.git > --branch commons-jcs3-3.2-rc1 commons-jcs3-3.2-rc1 > > > > Maven artifacts are here: > > > https://repository.apache.org/content/repositories/orgapachecommons-orgapachecommons-1650/org/apache/commons/commons-jcs3/3.2/ > > > > These are the artifacts and their hashes: > > > > > 6fb8c140c49229339ccea583c462e20b5f2abfd13b3615f466e5b7e44abfbfa7f662ce25b54edcf433c2b7010e4b32c2cde09f2da7754d7f697e871b76f61c91 > commons-jcs3-dist-3.2-bin.tar.gz > > > 6d2c47f3e41a6fca3fa94dd423d8e9c4bc76929778d5d44ee094a2d8465f1449feffee24ee1248e80baaec8e2c08051ff3fdcae76610591b451e796904f5dd46 > commons-jcs3-dist-3.2-bin.zip > > > 16c8bb7abe9268a39b80ce03a57adf1ac596191e4aee80756443d1861b850ffe5b67f6fbd9d46f1189d4247b7b928192cb7fb28f45e8bc768317972276acac9a > commons-jcs3-dist-3.2-src.tar.gz > > > 1f78fdc0be26f0b8b350ef2623191a28e13131b6a98abc51927aada192b7b381d1d7264a2083f23a72bf0906a0e4164e0c2a5aee11c3448408399cc87f0b912e > commons-jcs3-dist-3.2-src.zip > > > > I have tested this with ***'mvn clean install site site:stage'*** using: > > > > Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537) > > Java version: 1.8.0_311, vendor: Oracle Corporation, runtime: > /Library/Java/JavaVirtualMachines/jdk1.8.0_311.jdk/Contents/Home/jre > > Default locale: de_DE, platform encoding: UTF-8 > > OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac" > > > > Details of changes since 3.1 are in the release notes: > > > https://dist.apache.org/repos/dist/dev/commons/jcs/3.2-rc1/RELEASE-NOTES.txt > > > https://dist.apache.org/repos/dist/dev/commons/jcs/3.2-rc1/site/changes-report.html > > > > Site: > > > https://dist.apache.org/repos/dist/dev/commons/jcs/3.2-rc1/site/index.html > > (note some *relative* links are broken and the 3.2 directories are > not yet created - these will be OK once the site is deployed.) > > > > JApiCmp Report (compared to 3.1): > > > https://dist.apache.org/repos/dist/dev/commons/jcs/3.2-rc1/site/commons-jcs3-core/japicmp.html > > > > *** > > Note that the above report notes several errors. > > These are considered OK for the reasons stated below. > > These exceptions are also noted in the Changes and Release Notes. > > > > Errors reported: > > - methods added to interface: OK because that does not affect binary > compatibility. > > - annotation @Deprecated added to classes > > *** > > > > RAT Report: > > > https://dist.apache.org/repos/dist/dev/commons/jcs/3.2-rc1/site/rat-report.html > > > > KEYS: > > https://www.apache.org/dist/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, > > > > Thomas Vandahl (tv), > > Release Manager (using key 88817402) > > > > 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. > > > > 1) Clone and checkout the RC tag > > > > git clone https://gitbox.apache.org/repos/asf/commons-jcs.git --branch > commons-jcs3-3.2-rc1 commons-jcs3-3.2-rc1 > > cd commons-jcs3-3.2-rc1 > > > > 2) Check Apache licenses > > > > This step is not required if the site includes a RAT report page which > you then must check. > > > > mvn apache-rat:check > > > > 3) Check binary compatibility > > > > Newer components use JApiCmp with the japicmp Maven Profile: > > > > This step is not required if the site includes a JApiCmp report page > which you then must check. > > > > mvn install -DskipTests -P japicmp japicmp:cmp > > > > 4) Build the package > > > > mvn -V clean package > > > > You can record the Maven and Java version produced by -V in your VOTE > reply. > >
Re: [commons-crypto] OpenSSL 3.x, FIPS, digests, and HMAC
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. https://www.openssl.org/source/ Thoughts? 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?> > > > > 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 > > 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 a > > specific function is called, but the end result is that users need only > > download the latest commons-crypto release regardless of their underlying > > openssl API--as long as they are running supported openssl versions. > > > > In my view there are a few open questions regarding the current approach > as > > compared to an API-specific one. One, what is the performance penalty > > associated with the dynamic version checks? Two, how much complexity > does > > it introduce into the codebase? Finally, what was the use case that > drove > > the runtime checking requirement? Marcelo could answer the last > question. > > I don't know if he is still involved in the community (I haven't seen him > > around for awhile. IIRC, he was primarily a Spark committer). > > > > Another consideration is the FIPS certification. I work in a heavily > > regulated industry and FIPS is a real constraint. I haven't personally > > encountered a requirement to deploy a FIPS compliant openssl in our > > application code, but it's probably just a matter of time. In terms of > > expanding our user base, it may make sense to provide that capability. > It > > doesn't seem to be generally available from an existing provider. > > > > Regarding message digests/HMAC, I question whether the performance gain > > from native code would significantly outperform some of the modern JCA > > providers. As Matt Sicker pointed out, there are other implementations > > supported by major vendors, like AWS, that may be as fast as a JNI > wrapper > > on OpenSSL, or at least close enough not to bother with the added > > complexity of the native stuff. The only way I know to answer that > > question is to write the code and run a load test comparison. > > > > > https://aws.amazon.com/blogs/opensource/introducing-amazon-corretto-crypto-provider-accp/ > > > > In what forum should we discuss these issues? > > This developer's mailing list is where all decisions MUST be recorded, > so it makes sense that discussions occur here. We can also use Jira > tickets for specific tasks. Different discussions can use these > different forums as we best see fit. I would not recommend using Slack > as that data does or will eventually disappear. I do use Slack as a > convenience at times for reminding people/channels to vote or pay > attention to something happening in Jira or on a mailing list. > > > Are we limited to this > > distro or do we have other options? > > I'm not sure what this means. > > > How do we form teams? > I'm not sure what that means in the context of Apache. Apache has no > notion of teams that I am aware of. We have Projects like Apache > Commons, and Commons has Components like Commons Crypto. > We are all on this mailing list, we can work on whatever we want, and > we can use Jira to track tasks. If someone wants to work on a task, > they can announce it here or in a Jira ticket, to avoid clashes or > just be informative. > > > What is our > > governance model? > The same as any Apache project with the usual leeway allowed to each PMC. > > > How do we make decisions? > The same as any Apache project with the usual leeway allowed to each PMC. > See https://httpd.apache.org/dev/guidelines.html > A project can come up with it's own processes, for example see > https://www.apache.org/foundation/voting.html > > Gary > > > > > FYI: There's already issues on the backlog for OpenSSL 3 and HMAC: > > https://issues.apache.org/jira/browse/CRYPTO-165 > > https://issues.apache.org/jira/browse/CRYPTO-164 > > > > Alex > > > > > > On Wed, Aug 23, 2023 at 10:21 PM Gary Gregory > > wrote: > > > > > 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 > >
[VOTE] Release Apache Commons DBCP 2.10.0 based on RC1
We have fixed a few bugs and added some enhancements since Apache Commons DBCP 2.9.0 was released, so I would like to release Apache Commons DBCP 2.10.0. Apache Commons DBCP 2.10.0 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/dbcp/2.10.0-RC1 (svn revision 63672) The Git tag commons-dbcp-2.10.0-RC1 commit for this RC is f612e2f0830f459fc5d2a2fa6004e7c8d2ebf03f which you can browse here: https://gitbox.apache.org/repos/asf?p=commons-dbcp.git;a=commit;h=f612e2f0830f459fc5d2a2fa6004e7c8d2ebf03f You may checkout this tag using: git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git --branch commons-dbcp-2.10.0-RC1 commons-dbcp-2.10.0-RC1 Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1652/org/apache/commons/commons-dbcp2/2.10.0/ These are the artifacts and their hashes: #Release SHA-512s #Mon Aug 28 09:24:09 EDT 2023 commons-dbcp2-2.10.0-javadoc.jar=fe6bc24f091f69142a59a414a6a5a9ad10f998cbab4723a108ad84cd5eef392cc838fd172e25d0432aa18fba316f10d8a28eb50e0a60403798529cf760327e56 commons-dbcp2-2.10.0-test-sources.jar=4a4dffef71d9ff4ad877966ddc6797587f48a87fecbac8d7fda684d26f4c72c3998400df74fabe4cd2143a442c774e6722216e7e0bb00adfd2a3593e0812b3fc commons-dbcp2-2.10.0-src.tar.gz=73cc7227b576bb574221509eb6000ebff320a58de4b0efa7360630d0888c7b14eb35b7887310781723417731fedc767c4d011d55eee7bd12810a9cd50296e287 commons-dbcp2-2.10.0-bom.xml=657ca0014b744ca030c40b4f779752da768c6f4e5075d6505f1c943b0406122a8256582eb08e425302fad58ec411f24353ddd28206e063fbf4ada323985efca2 commons-dbcp2-2.10.0-bin.tar.gz=e16e9e51eacad44314da770b1f150afab99d887a9c03e37114706aa55ba1b790c5ad0b5de4cc444b777036696c258d102b56b9158907b8e5e21b30edc54cf381 commons-dbcp2-2.10.0-sources.jar=01f2e5713e3f1c291fc8393639d0ace7e9d7a9ee4784a124a2452fc4fc4ad11ee27f570c0538f484f4038aca893da4e44f9d17bca83b4e7945bb419b31233bb8 commons-dbcp2-2.10.0-bin.zip=65376d2049bcf0418fc1af456d83c6dd1af738913bb7678f6847a51c84c3aa3630216cef81ce7346f34728a2e54c99c611df3be9dc0994c537d755997c92a177 commons-dbcp2-2.10.0-tests.jar=e13b9aab48f31e65277afa2c149c9b6f754c2f47b1eca13ab0eb246ce7ef4cb6a267bba4b2a1a2051dd05620f3783cde64a31513b821dfe6276f01f2235b099c Apache\ Commons\ DBCP-2.10.0.spdx.rdf.xml=a8ecf26b2961de5d653a86fe5282772b1bbef41e6c928df3830e34898a10c9afbe444e82fc0950278c8d6889caf909e3d80221994a75eac95c7c44ab6e84decc commons-dbcp2-2.10.0-bom.json=9a908537ecebaae63c471a1826bb9d304e36db4a81e8a7d8b9dc4400779a5a0a0282405a593f39018cc79489eac93d323382932209745915f7a0c864cde4883a commons-dbcp2-2.10.0-src.zip=631eea5d36f00d2c648b023057bea55edea174418283769310321f4851a49ccafbb101a6a4f835a396b6c3b1d34b6e284f26038dafc3686be3a9dd3690cf41c7 I have tested this with: mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy Using: pache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9) Maven home: /usr/local/Cellar/maven/3.9.4/libexec Java version: 11.0.20.1, vendor: Homebrew, runtime: /usr/local/Cellar/openjdk@11/11.0.20.1/libexec/openjdk.jdk/Contents/Home Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "13.5.1", arch: "x86_64", family: "mac" Darwin 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 Details of changes since 2.9.0 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/dbcp/2.10.0-RC1/RELEASE-NOTES.txt https://dist.apache.org/repos/dist/dev/commons/dbcp/2.10.0-RC1/site/changes-report.html Site: https://dist.apache.org/repos/dist/dev/commons/dbcp/2.10.0-RC1/site/index.html (note some *relative* links are broken and the 2.10.0 directories are not yet created - these will be OK once the site is deployed.) JApiCmp Report (compared to 2.9.0): https://dist.apache.org/repos/dist/dev/commons/dbcp/2.10.0-RC1/site/japicmp.html RAT Report: https://dist.apache.org/repos/dist/dev/commons/dbcp/2.10.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-dbcp.git --branch commons-dbcp-2.10.0-RC1 commons-dbcp-2.10.0-RC1 cd commons-dbcp-2.10.0-RC1 1b) Download and unpack the source archive from: https://dist.apache.org/repos/dist/dev/commons/dbcp/2.10.0-RC1/source 2) Check Apache licenses This step is not required if the site
