OpenSSL Communities

Topics for Brno F2F

Paul Yang Tue 14 Apr 2026 3:38AMPublicSeen by 31

In yesterday's BAC monthly meeting, each community was required to have a topic list before the Brno F2F meeting in May. For the committers community, what do you guys like to put on the list?

For me personally, I find involving the Rust language into the project interests me a lot.

So, collected topics:

  1. AI related topics

    1. AI policy finalized - we experience a lot of PRs (and issues) generated by AI, what is the policy? (Frederik Wedel-Heinen) - together with a related topic raised by Dmitry: AI as a part of contribution and review process

    2. the Mythos, how will these kind of models affect the security of open source software, say OpenSSL as an example (Paul Yang)

  2. Product functionality & features

    1. Rust. Providers implemented in Rust? Or we can refactor some core code of OpenSSL by using Rust? Richard was also playing with Zig for provider implementation (Paul Yang)

    2. I'd like to see a discussion around the function of addrev, and especially where it takes its data from. (Richard)

    3. Increasing OpenSSL plugability (Dmitry)

    4. Privacy computing related features (protocol and algorithms), such as FHE, SMPC protocol, ZKP, Distance-preserving Encryption and so forth... (Paul Yang)

  3. Clean code (Norbert & Shane)

    1. What areas of the code would be beneficial to clean up/refactor?

    2. What are the things that make the code unreadable and hard to understand which should go and be replaced? Hard to Read(/Debug) nested Macros vs expanded form e.g. https://github.com/openssl/openssl/pull/30926/changes#diff-7a39d0fcd854bb417feefebe7756553703ff6faf0f8e811055c1030db999ff88R460

  4. Project management, development and review process

    1. Pull request backlog is growing out of control and needs stronger management (Frederik Wedel-Heinen)

    2. Need for an OpenSSL roadmap to align development across core team and contributor boundaries (Frederik Wedel-Heinen)

    3. OpenSSL development process: PR review/approval process (Dmitry)

    4. Dealing with the stream of CVEs (Dmitry)

  5. Committers management

    1. Do we need some committers tech chat/meetings/etc? (Dmitry)

    2. How should the committers list be modified? (Dmitry)

Richard Levitte (individual)Thu 16 Apr 2026 12:26PM

This would make things much more transparent, and verifiable on per commit basis if anyone finds that important.

Simo SorceFri 17 Apr 2026 1:09PM

@Richard Levitte (individual) If you are collecting suggestions for that page then:

1) PKCS#11 Provider is now: https://github.com/openssl-projects/pkcs11-provider so both link and org needs to be updated

2) You may want to consider whether to add Kryoptic: https://github.com/latchset/kryoptic

This one is tricky, but when built with --feature=fips it creates a statically linked module that is both a PKCS#11 softoken and an OpenSSL FIPS provider (it currently embeds the OpenSSL 4.0 provider when built that way).

Richard Levitte (individual)Sun 19 Apr 2026 1:28PM

@ssorce, thanks for the update. Provider-corner being a provider corner, I think I'll stick to that, even though Kryoptic was interesting to look at.

But, for the future, it's preferable to raise an issue directly with that repo, so as not to saturate the thread here, which isn't quite related.

Norbert PócsMon 27 Apr 2026 11:07AM

My suggestion for topic would be clean code.

  1. What areas of the code would be beneficial to clean up/refactor?

  2. What are the things that make the code unreadable and hard to understand which should go and be replaced?

Shane LontisWed 29 Apr 2026 2:41AM

Related to 2)
Hard to Read(/Debug) nested Macros vs expanded form e.g. https://github.com/openssl/openssl/pull/30926/changes#diff-7a39d0fcd854bb417feefebe7756553703ff6faf0f8e811055c1030db999ff88R460


Adding API Helper functions to hide OSSL_PARAM for common parameters (for KDF's MAC's etc) e.g. https://github.com/openssl/openssl/pull/30989

Paul YangSat 2 May 2026 1:40AM

Nested Macros are the biggest problem preventing developers to understand the code...

Eugene SyromiatnikovMon 4 May 2026 7:30AM

Not necessarily nested, but code-generating (and especially function/structure-defining) macros make code significantly more difficult to navigate.

Eugene SyromiatnikovMon 4 May 2026 7:34AM

My particular pet peeve is overabundance of "methods" without use of designated initialisers for method table definitions, which make it nigh impossible to quickly find where all concrete implementations for a specific method are defined (as opposed to Linux, which also relies heavily on this concept, but doesn't have the similar problem due to consistent use of designated initialisers for almost everything).

Paul DaleTue 5 May 2026 7:21AM

ANSI C doesn't support designated initialisers and that's the standard OpenSSL was coding to until quite recently. Now that the project has embraced C99, they are usable. Adding them in is not a small task. Try raising a PR to see how large it is.

IMO: adding them opportunistically is an easier approach and is what should be done.

Simo SorceMon 4 May 2026 1:14PM

I agree 100% with all these remarks about code readability, do I remember correctly that in the past openssl was relying on a C standard so old that designated initializer could not be used? Would be good to have some historic/present perspective on what can be change and want can't going forward.

Load More