Yeah, kinda weird

I hope it wasn't an AI-generated score, because AI looooooves rating everything a 9.something.

Yeah. CVEs for 1.85 haven't really been scored yet.

As far as I can tell, CVEs for 1.86 aren't even published yet.

No hits for 1.86 in osv.dev or the GitHub Advisory Database.

Speaking of AI, here's some slop from Claude

My feelings are that the initial CVE score is high, but the impact really isn't. We have a large backlog of FIPS fixups that we need to tackle. I think it's best to not block 9.0 on this so that we can take some time to do a proper FIPS update.

The one place that really should have this update is a 8.x release. So, how about: • We ship 9.0 with the current set of BC libs. • We sort out BC-FIPS 1.x and 1.86 and ship it in a 8.x patch release after 9.0 • We sort out BC-FIPS 2.1 and ship it in a 9.x release after the 8.x patch

Does 1.86 have any other fixes over 1.85?

Sounds like 1.86 is safe at least?

1.86 has 13 additional CVE fixes: github.com/bcgit/bc-java/blob/…/releasenotes.md#… None are actually published with severity scores anywhere that I can find.

We might as well bump that for RC4, no?

Might be doable. I think all the tests around 1.86 are green. Will require cutting some point releases of the supporting libs.

I don't think we need to. All the supporting libs have them as a dep just for testing purposes.

It'd just be bumping on openvox-server and openvoxdb

Unless anyone objects, I'm going to merge in 1.86 for RC4 so at least 99% of users won't get things popped on their scanners

for the record, i'm never opposed to doing dependency updates. i'm only opposed to last-minute breaking changes. 🙂

Yeah, I'm generally with you 🙂

Pulling 1.86 in seems like a plan to me. We can sort the supporting libs out as part of the 8.x patch.

I'll double check the dep libs use them only for testing

jruby-openssl bump github.com/OpenVoxProject/openvox-server/pull/676

Last call for any other changes to agent, server, or db for RC4

jruby-openssl

0.19.3 also came out.

And now we also know which PBX to not buy.

“buy”? 😄

Core maintainers of a project can enroll by opening a pull request on the OSS Scanner's GitHub repository along with a YAML configuration file that provides the following information - Link to the git repository that should be cloned Email address of the primary contact A repository-relative path to the Dockerfile that sets up the environment, pre-installs all dependencies and builds the project so to help an offline agent conduct its security audit

oh nice

sounds like a good idea to me

seems reasonable as long as they don't publish reports publicly. (they do reserve the right to "alter the reporting format")