OpenSSL Communities
Tue 3 Jun 2025 6:34AM

May 2025 meeting minutes

JE Jon Ericson Public Seen by 10

BAC Meeting May, 2025

In attendance:

  • Dmitry Belyavskiy

  • Paul Dale

  • Nicola Tuveri

  • Matt Caswell

  • Tomas Mraz

  • Richard Levitte

  • Jon Ericson (taking minutes)

Meeting started at 0700 UTC on May 29, 2025

Agenda

  • Features poll (Matt)

    • The Foundation has put out funding requests based on the following features:

      • BIGNUM

      • ECH

      • DTLS 1.3

      • Backlog

    • We’ve made good progress, but nothing solid to report yet

    • Next Generation EU (NGEU) has a mandate to fund projects for European-based entities (Nicola)

      • Horizon Europe grant  (Nicola)

        • Requires a consortium between, say, industry, a university and an end user

        • Next deadline is in November

        • PQC might fit

        • Nicola is looking to form a consortium

        • Funding topics change every year

    • Nicola to send info to Amy Parker so that she can look into these opportunities

    • Foundation does not have a European entity (just US-based) at the moment

    • The Foundation would like to bring in some engineers to do the work, but that requires more sources of funding

  • Forks diversion: consequence for applications and OpenSSL (Dmitry)

    • Many forks since 3.0 and applications are following forks rather than OpenSSL

      • Examples include LibreSSL, BoringSSL, AWS crypto & tls libraries.
        All of these are targeting the 1.1.1 API and are popular among applications, especially for cloud deployments.

    • Some prefer to stay on the 1.1.1 API

    • HAProxy looking for a different fork because of performance concerns

      • Matt suggested fixing the locking performance by optionally allowing lockless operation after the providers are loaded.

    • OpenSSL could pursue an agreement with Google and Amazon on a new API

    • Maybe not a great idea, but could un-deprecate some 1.1.1 API calls

      • Legacy EVP calls, low-level crypto calls

      • Forks have stripped out engines already

      • The code still exists. It just produces warnings at the moment.

    • When we introduce PQC algorithms, will the forks follow OpenSSL?

    • Ricard suggested writing an engine that loads providers (not easy to do)

      • But the forks don’t use engine at all, so this might not buy anything

    • Compatibility shim outside of libcrypto for low-level code

      • Give a path forward for people who are stuck with 1.1.1

      • Is there a subset that covers for many projects

      • Open up questions about the QUIC API that has been requested in the past

    • There doesn’t seem to be a simple solution

    • We have different applications with different requirements

      • We might not be able to cover all requirements

      • New applications care about new API added to BoringSSL

      • They chose a different path

    • 3.5 is LTS and has better performance than 3.0

    • Maybe an option to skip EVP interface

      • But we do need to support this as a public interface in that case.

    • Do we have an interest in retaining some of these users?

      • I think we are getting too much into the technicalities, as BAC we should (and just did) raise awareness about part of our communities getting stuck in 1.1.1/1.02 API-compat nightmares and switching to forks. Does the Foundation care about retaining or recovering such users? (Nicola)

    • Boring still has the 1.0.2 APIs.  Public structures etc.  It's got some 1.1 changes. (Paul)

    • RAND_METHOD is still quite widely used.  It hasn't been deprecated in 3.5. (Paul)

  • OpenSSL Open hours (Dmitry)

    • Foundation directors will consider

  • Consider moving repository out of GitHub (Paul)

    • Disaster recovery plan

    • Issues can be migrated easily

    • PRs are harder because we would need all the forks

      • Most are inactive

      • Active PRs can recreate in the new location

    • Should we be proactive about being ready for [insert disaster here]?

  • Communities platform best practices (Nicola)

    • Postponed

  • Future meetings

    • Timezones mean we need to rotate the time

    • More lead time between the poll and the meeting

    • We need the meetings to get the interactions

    • Maybe a monthly meeting

    • Make a poll with combinations with different days and times

    • Lock times on UTC

    • Try to target the same week of each month (like last week of the month)

    • Get something on the calendar for next month and a plan for the future

    • End poll next week so we have plenty of time

  • AOB

    • Future meeting (Nicola)

      • Memory-safe language rewrite (Rust, Zig, etc)

      • Formally verified crypto implementations

    • Publish minutes (Matt)

      • Community

      • Blog post linking to minutes

      • Jon will do this

Meeting adjourned at 0815 UTC.