OpenSSL Communities

Topics for Brno F2F

Paul YangPaul 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)

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 Sorce

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)

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ócs

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 Lontis

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 Yang

Paul YangSat 2 May 2026 1:40AM

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

Eugene Syromiatnikov

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 Syromiatnikov

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 Dale

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 Sorce

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.

Richard Levitte (individual)

Richard Levitte (individual)Wed 20 May 2026 8:52AM

@ssorce The base C language syntax level was set to C89/C90 until recently, when it was elevated to C99.

We've veered from that base level in places, especially surrounding std functions and some included headers, with heavy guards around such sections.

Dmitry Belyavsky

Dmitry BelyavskyMon 4 May 2026 3:06PM

My personal 2c

1. OpenSSL development process: PR review/approval process
2. AI as a part of contribution and review process
3. Increasing OpenSSL plugability

Dmitry Belyavsky

Dmitry BelyavskyMon 4 May 2026 5:21PM

  1. Dealing with the stream of CVEs

Richard Levitte (individual)

Richard Levitte (individual)Mon 4 May 2026 8:25PM

  1. AI as a part of contribution and review process

Incidently, I've started playing with https://pi.dev on a personal project...
Not on OpenSSL code yet, but I gotta say, it's tempting to start experimenting.

Dmitry Belyavsky

Dmitry BelyavskyTue 5 May 2026 7:09AM

@Richard Levitte (individual)you can evaluate my PRs on symmetric keys in PKCS#12 with heavy Claude cooperation

Richard Levitte (individual)

Richard Levitte (individual)Tue 5 May 2026 8:56AM

@beldmit, I suppose I can do the same with any agent and a sufficiently good model. There are some relatively good prompts available for this sort of thing.

Dmitry Belyavsky

Dmitry BelyavskyTue 5 May 2026 9:02AM

@Richard Levitte (individual) Sure

Dmitry Belyavsky

Dmitry BelyavskyWed 6 May 2026 7:38PM

2 more topics

Do we need some committers tech chat/meetings/etc?
How should the committers list be modified?

Paul Yang

Paul YangWed 13 May 2026 1:34AM

Do we need to publish these topics to the general discussion? IIRC, this committers community is not accessible for non-committers

Dmitry Belyavsky

Dmitry BelyavskyWed 13 May 2026 8:32AM

@Paul Yang I think it's still visible

Paul Yang

Paul YangWed 13 May 2026 10:11AM

@Dmitry Belyavsky , OK, then I will add a link in your thread in general discussion