Meeting Minutes: Board and TAC Monthly (2026-05-11)

Meeting Minutes: Board and TAC Monthly (2026-05-11)

Below are the minutes from the recent TAC and Board of Directors meeting. Everyone is encouraged to review the minutes and actively participate in the discussion. This is an opportunity to talk directly with TAC members by replying in the thread below. Your input helps ensure the OpenSSL community remains transparent, collaborative, and responsive to your needs.

Attendees

@Dmitry Belyavsky, @Aditya Koranga, @Anton Arapov, @Tim Hudson, @Lenka Luklová, @Simo Sorce, @Kevin Micciche, @Nikolas Gauder

High-level topics covered

•       Meeting planning and agenda shape for the upcoming face-to-face

•       Handling TAC advice and formal requests — FIPS_mode() “fifth mode macro” follow-up

•       Security response, Mythos reports, and Friday follow-up session

•       AI and vulnerability disclosure — embargo process vs. immediate public release

•       C-BOMs / crypto visibility and OpenSSL’s crypto audit instrumentation

•       Rust ecosystem and OpenSSL positioning

•       AI usage, local models, and cost constraints

•       Broader AI reliability and future concerns

Detailed points and discussion

1) Meeting planning and agenda shape

• Anton explained that the upcoming in-person session will be technically oriented and include representatives from OpenSSL projects as well as external participants from Bouncy Castle and work related to Rust and PQC/SSL topics.

• The intended structure is to concentrate the most difficult discussions on Monday and Tuesday, then shift toward advisory-committee topics on Wednesday, with Thursday and Friday left open depending on how discussions evolve.

• Dmitry requested enough agenda detail to know which topics would appear on which day so he could decide whether to invite colleagues to developer-specific talks.

• Tim agreed to provide a high-level agenda broken into morning and afternoon slots for Monday and Tuesday, which Dmitry confirmed would be sufficient.

• Anton noted that although exact timing may still be fluid, rough topic buckets and day-part assignments should be enough to support invitations and planning.

2) Handling TAC advice and formal requests

• Dmitry raised a follow-up from a previous TAC discussion about the “macro” poll, noting that community input and advisory committee support appeared to confirm a community need.

• Tim explained the process: Dmitry should write up the issue at the appropriate level of detail, include references, and send it to the board as TAC advice; Anton and Tim would then prepare the formal response within a week.

• Anton suggested that publishing the advice in the Communities/TAC community space would be the best way to make both the recommendation and the response visible.

• The group agreed that Dmitry should post a formal request in the relevant discussion topic, after which the board can respond through the established process.

3) Security response, Mythos reports, and Friday follow-up

• The group discussed a planned security-response-team conversation later in the week, with Anton suggesting a Friday session adjusted for Europe/Brisbane timing.

• Kevin asked whether OpenSSL Project should consider more formal engagement with Trusted Computing Group (TCG) work around TPM integration and OpenSSL 3, noting the tpm2-openssl integration and related provisioning workflows.

• Tim said he was not aware of any official, coordinated contact from TCG on that topic, though OpenSSL Project does receive occasional TPM-related input.

• Kevin indicated he would explore whether a future outreach connection could be established and follow up through the business-advisory channel.

• Tim described internal work around “Mythos” security reports and noted the idea of sharing the nature of those reports with the broader advisory groups so they can understand the kinds of issues being reviewed.

4) AI and vulnerability disclosure

• Kevin introduced a community discussion sparked by Linus’ public comments that vulnerabilities found via AI should be disclosed immediately, without the usual embargo process.

• Simo strongly opposed immediate public release, arguing that the dangerous part is exploitation, not discovery, and that public disclosure before patches are ready increases the number of people who can weaponize the issue.

• Tim acknowledged Simo’s concerns but argued that AI changes the economics of discovery and exploitation because the same tool can help many actors simultaneously and can rapidly turn a vulnerability into an exploit.

• The group generally converged on the idea that OpenSSL Project should continue to use its existing security advisory and embargo process, while being explicit that AI-discovered issues are handled through the same triage and disclosure framework.

• Kevin emphasized that the goal remains fixing vulnerabilities before release and that the discussion is about disclosure timing and process, not abandoning responsible handling.

• The discussion also touched on how AI can accelerate proof-of-concept generation and exploit scripting once a bug is known, which increases the importance of controlled disclosure.

5) C-BOMs / crypto visibility

• Kevin asked whether OpenSSL had been approached about C-BOMs (software bill of materials for cryptographic usage).

• Simo argued that general C-BOM style lists are of limited utility because they are difficult to keep accurate, often become stale quickly, and do not tell you what matters operationally.

• Simo proposed a more useful alternative: OpenSSL’s ongoing “crypto audit” work, which uses trace points and instrumentation in the crypto library so that applications can be observed from the kernel or tracing layer without needing each application to implement its own reporting APIs.

• He shared the public project reference for crypto-auditing and explained that the design is meant to make auditing broadly applicable across applications, containers, and network paths, with minimal performance impact when not in use.

• Kevin noted that some external library efforts are trying to expose easier APIs for visibility, but Simo argued that library-level instrumentation is more directly useful than application-specific reporting hooks.

6) Rust ecosystem and OpenSSL positioning

• Simo raised a concern about the Rust ecosystem, observing that unlike Go, Rust does not have a single dominant cryptographic implementation or a highly centralized cryptography library path.

• He noted that many Rust projects are adopting AWS-LC and that OpenSSL is losing ground in parts of that ecosystem, despite OpenSSL’s importance and the work being done on Rust-based providers.

• Tim said that one of the goals of the OpenSSL Project is to ensure users can get to a provider written in pure Rust.

• Kevin said Rust adoption is real but often runs into migration friction, especially for teams already committed to C or Go, though there is growing interest and movement.

7) AI usage, local models, and cost constraints

• Nikolas reported that his area is using more AI than a few months ago, but they run out of tokens frequently and funding is limited.

• Tim said OpenSSL is also experimenting with local models and Nvidia-based setups to evaluate whether AI workstations make sense for development tasks such as code review and exploit analysis.

• Simo said local LLMs are already usable for many targeted tasks and will become more compelling as memory and GPU pricing falls.

• Tim estimated that for under $5,000 per developer, teams could potentially have an AI code reviewer that outperforms the average human reviewer for certain classes of tasks.

• The group agreed that AI usefulness depends heavily on task type: it can be strong for refactoring and pattern application, but much weaker for architecture and broader system design.

8) Broader AI reliability and future concerns

• The conversation ended with concerns about feedback loops in AI-generated training data, with Kevin and Simo noting that as more AI-generated material enters the public web, models may increasingly train on their own errors.

• Tim emphasized that the current pace of change means analyses become stale in a matter of months and that organizations need to sift through hype to identify what is real and operationally useful.

• The group agreed that AI capabilities are moving quickly enough that policy and evaluation need regular reassessment, rather than assumptions based on older snapshots of the technology.