• Discussions were held about introducing a new time-based release policy for OpenSSL. This policy aims to improve the predictability of release schedules and content. Part of this discussion also touched on how to effectively plan and assess feature readiness before each release.
• To enhance project management, the use of feature branches for more complex features was suggested. This idea was paired with the proposal to establish clearly defined criteria for the review and approval of code.
• As part of improving decision-making within the project, dialogues were carried out on how to best select features for inclusion. The proposal to establish a review body, focused on making these decisions and prioritizing features, was also put forward.
• Inspired by Apache’s practices, improvements to the existing security policy were considered and discussed.
• As part of addressing the project’s technical debt, suggestions were made to discuss infallible locking and mandatory atomics. The goal was to streamline locking mechanisms and reduce code complexity.
• Tomas Mraz and Dmitry Belyavsky held personal sessions where they discussed different approaches. Tomas delved into the approach of using decoupled low-level crypto libraries, while Belyavsky considered the potential for incorporating more pluggable elements within OpenSSL.
• Richard Levitte highlighted several areas of technical debt that need addressing. These included issues with composite algorithm names, the functionality of Password-Based Encryption (PBE), and AlgorithmIdentifier parameters. He also proposed potential solutions to these identified issues.

Time Based Releases Policy (slides) (Anton Arapov)

The objective was to make our releases predictable, considering both timing and content. It was emphasised that planning should be an ongoing process and involve the community. The concept of release definition, which involves the final selection of features for each release, was introduced. Nicola raised the question of when external contributions should be selected during the development phases, sparking a spirited discussion. Additionally, there was a debate concerning the planning process and determining the criteria for categorising a feature as small. The question arose as to whether features need to be fully ready before planning or just prior to merging. This conversation naturally transitioned into the next session…

• Additional work is required to finalise the policy.

Feature Branches Policy (slides) (Tomas Mraz)

The discussion was lively and intense, overlapping with the previous session. Multiple viewpoints were presented.The proposal of utilising feature branches for complex features that cannot be developed in a single pull request was put forward. These implementation measures, alongside the defined criteria for code review and approval processes, aimed to enhance predictability, accountability, and project management within OpenSSL.

• Everyone will have an opportunity to propose a solution for the policy. Input will be gathered and presented, enabling us to select the best option.

Code Review Criteria/Approval Process (Tim Hudson)

We have existing policies; however, there is occasional deviation from them. (Specifically, there was agreement on not strictly adhering to the newer DESIGN PROCESS policy verbatim.) It is essential to establish an API guideline to facilitate progress with new contributions. Additionally, we must ensure that our CODE STYLE guidelines align with the practices we have been enforcing. Improving the accessibility of documentation on review expectations is crucial for the project, committers, and external contributors alike. This will contribute to a more efficient and collaborative development process.

• Create a reviewer checklist and ensure it remains up-to-date with policy changes. Keep reviewers (and contributors) informed about the checklist.
• Develop a contributor checklist/guide and regularly update it in line with policy changes.
• Provide comprehensive information to contributors. (CONTRIBUTING.md requires updating.)

Feature Selection Process (slides) (Matt Caswell)

The discussion revolved around feature selection and establishing a review body to engage all of our communities. Key points addressed included determining who makes decisions regarding accepted features and establishing criteria for prioritising features.

• We still have a journey ahead before we can formalise this process.
• It is essential to include it on the roadmap.

Personal 15 minute time slot: Matt Caswell (slides)

The current performance of the master branch is slightly better than that of version 1.1.1 for our own handshakes per second test at higher thread levels. However, it notably performs worse at 1 and 10 threads. Further investigation is warranted to examine this performance issue, but it is unlikely to be related to lock-related problems.

Personal 15 minute time slot: Richard Levitte

Richard shared stories about his past work and experiences, detailing his involvement in the open-source world, which ultimately led him to contribute to OpenSSL.

Security Policy Improvements (slides) Mark J Cox

The session focused on the possibility of enhancing our policy and, if feasible, exploring the ways to achieve it. We deliberated on relaxing strict definitions and drew inspiration from similar policies implemented by Apache.

• A proposal was made to use more generic wording.

Technical Debt: Infallible Locking (slides) (Hugo Landau)

This discussion, focused on technical debt related to infallible locking in OpenSSL. Traditionally, OpenSSL has used the CRYPTO_RWLOCK primitive, which can return failure during read_lock and write_lock operations. This complicates code that utilises CRYPTO_RWLOCK, especially in scenarios where there is no clear solution for handling lock acquisition failure. In contrast, the addition of thread pool support introduced the ossl_crypto_mutex primitive, which is infallible. This inconsistency prompted the proposal to make the existing RW lock API infallible for consistency. Two options were presented: Option A suggests that CRYPTO_RWLOCK_(read|write)_lock no longer returns 0, and Option B proposes creating a new internal infallible RW lock API (ossl_crypto_rwlock) while refactoring existing code to utilise it. The existing API would still be available for compatibility, but internal usage would transition to the new API. The discussion acknowledged the possibility of adopting Option A in the future, where CRYPTO_RWLOCK calls could simply forward to the new internal API.

• The group agreed with the thrust of the presentation.
• A plan should be fleshed out.

Technical Debt: Mandatory Atomics (slides) (Hugo Landau)

The current atomics API requires a lock object as a fallback when platform support is lacking, resulting in potential failures and code complexity. However, it was highlighted that every multiprocessor system supported by OpenSSL utilises atomics for higher-level synchronisation primitives. This led to the proposal of making atomics mandatory, as there is no justification for the burden of lock fallback. The absence of a widely-adopted standard API for atomics necessitates maintaining platform abstraction layers for different compiler and OS atomic APIs. The extent of work required is minimal, primarily involving support for specific platforms and compilers. It was noted that LLVM’s compiler-rt project emulates atomic operations for unsupported data types, demonstrating the feasibility of an atomics API without a lock argument. The session concluded with the recognition that the obstacles to mandatory atomics are compiler/platform-related rather than hardware-related, with the burden being the maintenance of code for different atomic APIs. Making atomics mandatory would simplify code and allow them to be made infallible, aligning with the objective of addressing technical debt.

• An important conclusion from this was that we probably can’t get completely away from falling back to locks on some platforms, but we can hide these details away and not explicitly create locks everywhere. Also with infallible locking this makes the atomics also infallible.
• Note that reference counting (which is based on atomics) has been streamlined as part of opnssl/openssl#21341. Specifically, it doesn’t allocate a lock if the target platform doesn’t need one.

Personal 15 minute time slot: Tomas Mraz (slides)

Tomas delivered an inspiring talk titled “I Have a Dream,” where he shared his ideas on the decoupled low-level crypto algorithm implementation libraries approach.

Personal 15 minute time slot: Dmitry Belyavsky (slides)

Dmitry shared his memories and discussed future work, focusing on the potential for more pluggable elements within OpenSSL, such as X.509 extensions and TLS extensions.

Missing Provider Support (report) (Richard Levitte)

Richard discussed several areas of technical debt in OpenSSL. The topics covered composite algorithm names, PBE functionality, and AlgorithmIdentifier parameters. He highlighted the inconsistencies and challenges associated with these areas and proposed potential solutions for each problem. For composite algorithm names, he suggested interim and future solutions to support them with the existing API. Regarding PBE, he proposed refactoring and providing composite PBE implementations. Finally, for AlgorithmIdentifier parameters, Richard outlined ideas for passing them in symmetric ciphers and discussed potential solutions for PKCS#7 and CMS operations. He also addressed ways to help move forward by deprecating certain functions and discouraging the use of NIDs to find algorithms. Overall, the presentation aimed to identify and address legacy code dependencies to improve the codebase of OpenSSL.

• Some of the covered topics would be beneficial to discuss during the planned Providers Meeting.

Return to Face-to-face Summary page.