Update from the OpenSSL F2F — Brno, May 2026

What the Brno F2F means for distributions — from both your reps, who were in the room

Hi all — Jaroslav and Dmitry here. We were both at the OpenSSL F2F in Brno this May, wearing this community's two hats: Jaroslav on the business side, Dmitry on the technical side. This is the joint update, and the short version is: several changes land directly in packaging workflows (two will touch your tooling), official Windows binaries are coming, and — the part we'd underline — upstream is asking distributions for design input before building, not after.

The full write-up runs in two committee spaces, worth visiting separately: the BAC thread carries the business and governance discussion, the TAC thread the technical one with the standards drafts behind it. Both readable by anyone. Here is the distribution cut — ordered by how soon it touches you.

Preparations for the F2F

At a very productive meeting in Brussels this January (right before FOSDEM), we collected a long list of community needs; however, on a follow up call in preparation for the F2F, we haven’t seen much interest (other than from the Red Hat cluster). Even thought that according to Anton’s data, the Distribution community is active and is getting mature, we would like to be in a more closer loop with you. For that, we believe you deserve answers in one place to the needs from FOSDEM and this blogpost should give you some.

Community scope - the “Distributions” name of our community may be misleading and can create a false assumption that it only covers Linux distributions. However, nothing can be further from the reality. The Distribution community is open to any distributors of OpenSSL in any form - both source and binary and we will be happy to get more feedback from you in the future!

Anticipate impacts. More often major releases bring opportunities to streamline API changes, though it comes with a cost. 4.0 brought opacity to ASN.1 strings and added missing const modifiers to X.509 API, and this work is to be continued in upcoming releases. Such changes require coordinated efforts as they affect a lot of dependent components. Participation from packagers is expected, and a list of the related changes will be shared.

Editing CHANGES.md and the NEWS file is often painful and causes waste of time to rebase PRs. Some adjustments in this process are expected, so stay tuned.

Packaging and configuration. For many distributions it’s necessary to ensure coexistence of OpenSSL 3 (for backward compatibility) and 4. Obvious collisions caused by package managers’ limitations, potential changes in configuration files, provider folder, and conflicting development packages have been demonstrated as a pain point for Fedora. We suspect that other distributions will have to deal with such problems, and reducing the life cycle of major versions will raise such questions again and again.

There was a request to separate nation-wide algorithms (SM family now, FrodoKEM) to dedicated providers, but the overall consensus is an algorithm-filtering configuration property rather than per-nation providers; SM algorithms stay in the default provider as a legacy exception. 

Working with downstream patches. Almost all distributions carry a burden of downstream patches that are normally pretty well tested and used in production.  A downstream-patch label is being introduced — upstream wants to see the patches distributions carry in production, to track usage and pull them upstream. If you maintain a patch stack, this is your invitation to surface it.

A good example of such patches was a FIPS_mode() API that was reinstated after the meeting as a result of the community poll. It demonstrates a procedure to follow in case of controversy between stakeholders which communities are.

Platform and testing. Tier 3 community-supported architectures will be dropped from the tree in the next major release — the exact list is being confirmed and will be announced with notice, so hold off on planning until it lands. A firm rule to improve quality now applies: a change is carried only where the collective can test it; CPU-specific optimisations must run on real hardware first; and regression testing against the Python and Ruby client ecosystems is being added — fewer surprises reaching your users.

Releases and nearest plans. Releases are now signed on hardware security modules under a published key ceremony and signing policy; the signing certificate, fingerprint, and verification steps are on the official downloads page — worth wiring into your import checks. Official Windows binaries are coming (MSI and executable, FIPS module shipped but off by default) — relevant to anyone who also ships or points users at Windows builds. DTLS 1.3 is in final stages; migration to the SSL API is supported, older DTLS remains configurable.

The period between major releases is going to be shorter, it allows to get rid of deprecated API and allows fine-tuning of the API (e.g. adjusting obvious deficiencies in long-term existing API, c

Trust stores — where your input is wanted most. We are entering drastic changes in the X.509 landscape. The design draws on TLS Trust Anchor Identifiers and Merkle Tree Certificates, and the deployment architecture is genuinely open. Distributions will have to rely on dynamically updating trust stores instead of a mostly static CA bundle as it is now. We need efforts to work on standardising trust stores across Unix/Linux distributions — in cooperation with OS vendors — plus a system-level trust-anchor service and a shared cache usable by the OpenSSL Library, the JRE, and others. Distributions are central to whether this works; early opinions will shape it, late ones will adapt to it.

Also worth knowing. The PKCS#11 provider is actively maintained under the openssl-projects umbrella. It replaces the deprecated and removed in 4.0 engine implementation. The project is interested in having a Windows maintainer, if anyone here wants to own something visible. An open-source compliance one-pager is being prepared for the enterprise questionnaires that land on all of us.

Upcoming OpenSSL conference. The upcoming OpenSSL Conference, scheduled for Oct 13, 2026 to Oct 15, 2026 in Prague, Czechia, represents a critical opportunity for a face-to-face community meeting. The conference follows the success of the 2025 one, where the distribution community first met and established a cadence for follow-up coordination. We are optimistic about securing a dedicated time slot for this community session and encourage all members to save these dates and submit their applications.

The Call for Papers (CfP) is currently open, with the final submission deadline set for Jul 15, 2026. 

Two personal notes.

Jaroslav: what stayed with me from the business sessions was the shift in posture — distributions weren't discussed as a delivery channel but as the partner upstream needs for trust stores, packaging, and the 3-to-4 transition to land well. The downstream-patch label says it plainly: show us what you carry, we want it upstream.

Dmitry: from the technical side, the testing rule is the quiet headline — without proper testing we can’t properly deal with the package and have to deal with surprises turning to become disasters. The system-wide trust store is a must for the circumstances of new standards and X.509 landscape changes. Updated release cadence also raises a lot of questions for all distributions.

So — over to you: Which of these lands hardest in your packaging workflow? What should the trust-store design get right from day one? What patches are you carrying that upstream should see? Business-side follow-ups Jaroslav will carry into the BAC; technical ones Dmitry will take to the TAC — and roadmap items go straight into the new 6–24 month roadmap, which is being assembled in the open and explicitly wants distribution input.

— Jaroslav & Dmitry