March, 2026 minutes

Attendees: Matt Caswell, Tomas Mraz, Shubham Kumar, Richard Levitte, Jon Ericson, Clemens Lang, Randall Becker, Dr. Yi Ouyang

• Moving the TAC election (Jon)

  • There wasn’t a Foundation TAC election yet, there’s some election fatigue and some spots are unfilled

• Future of the advisory committees (Jon)

  • Perhaps have a longer period of time (2 years?) and staggered (Clemens)

  • Would it make sense to merge the committees? (Matt)

  • There’s overlap between the two committees’ discussions (Tomas)

  • One of the ideas was to have two committees to attract different types of people who might not be involved (Matt)

  • What does the Foundation need more? Technical or business feedback? (Randall)

  • We probably need more input on the business side of things. Strategy, release roadmap, etc. (Matt)

  • In order to maintain the separation, we need to be stricter about cutting off discussion that belongs (in theory) in the other committee. The conversations are interconnected. (Tomas)

  • We aren’t talking about the Corporation committees. (Tomas)

  • The timeframe seems to be the problem more than the number of committees. (Randall)

  • Merging the BAC and TAC would be another solution. (Matt)

  • Since most seats seem to have just one candidate in the elections, combining the committees, at least temporarily, would reduce the number of seats to fill. (Clemens)

  • If we merge, we could lose the diversity that is the point of having two committees, especially when it comes to non-technical backgrounds. (Yi)

  • We need to look at boundaries. More formal referral mechanism to move discussions to the right place. (Randall)

  • Emphasize that we don’t want to lose non-technical people(Richard)

• Updated 4.0 release date: April 14 (Matt)

  • Milestones has an overview of what still needs to be done and what the proposed release dates are.

• Alpha release of 4.0 is out now! Please take a look and encourage your communities to try it out. (Matt)

  • The next LTS will be in April next year, probably 4.2 (Matt)

  • How does one find out what the next LTS release is? (Randall)

    • https://openssl-library.org/roadmap/index.html has a list at the bottom.

• Potential for predictable major release schedule. What's your view? (Matt)

  • Discussion in the engineering team about having a more predictable schedule since major releases allow us to clean stuff up and correct mistakes.

  • On the other hand, it’s painful to downstream users to fix their code when there is a breaking change.

  • The major release isn’t about you (the maintainers), it's about the downstream users. It’s a communication mechanism. It’s not so much about the timing of the features, but have we had enough communication from the community to know if a major release is needed. (Randall)

  • Major version releases is the place where we can remove interfaces, so it is important to the development team. (Tomas)

  • Time-based major release does help with planning for distributions. But don’t make the cycle too short. Distributions would like to support just one version of OpenSSL. When a new major release comes out, all the people who use OpenSSL have to decide to update or maybe just stick with one of the forks that haven’t changed their interface. (Clemens)

  • The counter-argument is that if we have a shorter major release timetable, the number of changes in each release will have a smaller impact. (Matt)

  • On the other hand, death by a thousand cuts. (Richard)

  • No matter what, we aren’t going to break things willy-nilly. (Tomas)

  • The thing that matters is whether the .so name changes. If a new feature comes out, the distributions have hard decisions when the major version boundary is crossed. Backporting features across soname changes is a bad idea and breaks symbol versioning, so it can’t be done by distros. In other words: new OpenSSL features will take a new distro release to show up (but no such limitation exists for new functionality added in minor releases) (Clemens)

  • It takes a long time to test all the things before taking a major release. If we refresh too often it’s hard for people to decide whether to move up or not. (Yi)

  • Enterprises also are concerned with what releases are supported. People might not want to update to a major release unless there is an LTS. (Randall)

  • Maybe the third release in the major release line is the LTS so that the LTS schedule is tied to the major release schedule. (Clemens)

• In the last meeting, Matt asked for suggestions for NCSU Practicum, can we encourage students to work on finding a practical solution on how to test the new code against lots of no-* build combinations, which is not feasible right at the moment (ref: https://openssl-communities.org/d/hT3LIM4H/comment/1153). A CI pipeline check is possible (after some changes) however, contributors can't run those tests locally. So maybe a tool around this may be feasible. (Shubham)

  • It takes a long time to run through the no-* options. (Matt)

  • Limit the number of possible combinations. (Tomas)

  • Ideally test the options that have an impact. We might be able to reuse some of the tools that researchers have used with the Linux kernel. Clemens will reach out to some people. (Clemens)

  • For other projects we’ve  to moved to more run-time options instead of compile-time, to simplify builds and allow each customer to decide on their preferred options. (Randall)

• Claude has recently released code review agent (https://claude.com/blog/code-review) to check PRs and in the last meeting, I recall there is some collaboration/partnership where AISLE Security will be checking the Openssl PRs for the security vulnerabilities. Right now, openssl has around 400 PRs open and with AI advancement, there are more AI based code in recent PRs. Maybe Openssl can use this claude agent for PR code review and detect AI slop and can help maintainers reduce the PR count to some extent. Right now, this is on beta testing so I am not sure how much this can help, but can have a discussion on this. (Shubham)

  • If we don’t actively scan the code, someone else will. (Yi)

  • Since the end of last year, we’ve seen a flood of issues through the security email. Recently we addressed 12 AI-generated security reports. (Matt)

  • We can’t compete with the issues coming in from outside, but we can use the tools ourselves. (Tomas)

• Last month, Aditya and I were working on a benchmark between jostle and bouncy castle and results are quite in favor of jostle. Putting it here to bring light on it - https://ngkore.github.io/jostle-bc-crypto-benchmarking/. (Shubham)

  • These are great results! Two thoughts: (a) error bars are sometimes a lot larger for Jostle, any idea why? (b) Will you write a blog post to publicize this? (Clemens)

  • The errors are from the noise in the system, I have to run this on my system for around 6-7 hours and there are some things running as well, so that maybe the cause of such noise. The ideal condition to have better results will take around 1-2 days to run the benchmark, but that was not feasible at that time. (shubham)

  • https://medium.com/@chmodshubham/openssl-jostle-vs-bouncy-castle-cryptography-benchmarking-6c8bc5def05c 

• This is of my personal interest, some of you might have heard of CBOMkit by LF PQCA and recently, there is work going on to extend the support to other languages and libraries. It has support for java and python and recently there was a merge regarding support for golang and lib support for standard crypto lib and golang.org/x/crypto lib. I am working on the support for c/c++ language and working on supporting openssl as the first lib. I am pretty much done with it (for the language support) and partially added support for openssl 3.6 (https://github.com/chmodshubham/pqca-sonar-cryptography/tree/cpp-support). Just putting it here for discussion in today's meeting. (Shubham)

  • This is great, soon a lot more orgs will start making an inventory of their use of cryptography to transition to PQC, and the easier it is for them and the more tooling we have, the better. (Clemens)

  • We’re also working on something to have better runtime tracing results that we intend to contribute upstream, you’ll hear from us on that eventually (Clemens)

• Publicity work in response to the PyCA blog post (Clemens)

  • I have been working on something, but it got lost in the shuffle lately. Thanks for the nudge. But we could use a variety of responses. (Jon)

Action items

• Strawman proposal for the future of the committees (Jon)

• Public response to the criticisms of OpenSSL (Jon)