OpenSSL Communities
Fri 26 Sep 2025 9:41AM

Face-to-Face Meeting: BAC + TAC

AA Anton Arapov Public Seen by 16

Dates: 2–3 October

We will bring both the Business Advisory Committee (BAC) and the Technical Advisory Committee (TAC) together for two full days. The goal is to align governance and next-year focus areas, and to prepare for the upcoming panel session and the conference.

What We Ask from You

✅ Top 5 priorities/issues for the next 12 months

  • From your perspective (business/community for BAC, technical for TAC).

  • One line per item + a short “why now”.

Please come prepared to share these at the face-to-face meeting.

Planned topics

  • Governance input: boundaries for decision-making (what belongs with TAC, with the BAC, and Board); consensus signals.

  • TAC focus: actionable technical priorities to move TAC to an “operational” state.

  • BAC focus: specific business-impact areas.

  • Examples, slides, and data points (from customers, community feedback).

  • On-site flow:

    • short simulation and simple timing signal before the panel;

    • time-boxed discussions, including uncomfortable issues;

Next Steps

  • Bring your Top 5 priorities to the face-to-face meeting.

  • Everything else will be handled on-site.

AA

Anton Arapov Fri 26 Sep 2025 9:42AM

And don’t wait until we’re in the room, if you already have priorities or thoughts in mind, drop them here. Even a quick note helps get the conversation rolling.

SL

Shane Lontis Wed 1 Oct 2025 2:51AM

  • Performance interop analysis against other toolkits e.g.
    https://www.memorysafety.org/blog/rustls-performance-outperforms/
    https://www.phoronix.com/news/Rustls-Faster-Than-OpenSSL
    These claims probably need to be investigated. This causes reputational damage for the toolkit.

  • Documentation improvements
    - Moving to something like doxygen is hard with large existing podfiles.
    - docs.openssl.org/master has menus that are just large lists of alphabetically ordered names. Is there some way to reorganize this data into sub categories that have menus?
    - Should there be a technical writer resource in OpenSSL.
    - Should the 'needs docs' label auto generate issues?
    - Should there be a 'release notes' label?

  • Technical Debt
    - EC curve dispatch tables?

    - AEAD API?

  • Dedicated resources for assembler?
    - Reviews of assembler code is currently adhoc and substandard.

  • TAC problems
    - Code base is shared, but most decisions from TAC are confusing as to the ownership, BAC is also making TAC decisions.
    - Items that were addressed by OTC that are not being addressed now.
    - There was verbal communication every week, and questions could be asked.
    - There was a clear process of putting Items 'on hold' that were addressed each week.

    - The OTC group involved committers with a wide range of specialized knowledge
    across all of OpenSSL. This has been diluted by dividing the resources into 2 entities.

    - Most of the time it was clear what issues OTC needed to resolve, and when to assign items to the OMC.

NT

Nicola Tuveri Thu 2 Oct 2025 5:47AM

  • Composite PQC Signatures (close to WGLC)

  • Removal of deprecated APIs

  • Survey of ENGINE-related APIs that were not deprecated but are good candidates to be removed, I.e. APIs that had an ENGINE argument.

  • Documentation routinely goes stale: as an example, the disconnect between docs on default groups and its implementation. Can we do something to improved this systematically? Would in-place docs a la doxygen help?

  • Documentation around Providers is written in “reference manual” format. This is good when you already know the answer for what you are looking, and just need refresher and confirmation, but has limits for external authors approaching Provider authoring for the first time. Moreover, it is understandably written in “normative style” but often does not explain when “optional” parameters can/should/may be omitted and what are the consequences (and interactions with other bits of OpenSSL) in specifying them or not specifying them. The problem with this is that to discover the answers external developers have to spend ungodly amount of times in the debugger and the TRACE logs, copy what “that other provider that seems to work” does and often propagate misconceptions or suboptimal choices. Looking at the built in providers is often a last resort (and prone to fail) option, because of the amount of Perl and cpp magic for code generation. I would like to propose the exploration of technical means to improve documentation (not replacing the reference style, but augmenting it with guide-like resources and more and more doctest examples, I.e. compiled to avoid them going stale)