• The OpenSSL project has some performance issues. These need to be addressed by setting performance standards and testing before making changes. The team has agreed to prioritize this process.
• Technical debt is another problem that needs to be dealt with. The proposed solutions are:
  • Setting performance targets.
  • Improving inefficient data structures.
• The team also discussed ways to improve engagement with the community, including:
  • Updating the current outdated communication channels.
  • Revamping the website.
  • Creating a separate space for user queries and software issues.
  • Starting to use GitHub Discussions for better communication.
• Supporting different OpenSSL versions poses challenges. The team also discussed how to manage Long Term Support (LTS) releases.
• When talking about the QUIC protocol, several points were emphasized:
  • Its development is crucial.
  • Features need to be prioritized.
  • It’s important to gather feedback early.
  • There was agreement to turn on QUIC by default in the next release.
• Nicola Tuveri pointed out that the BIGNUM issue needs to be addressed. He suggested setting aside dedicated resources to work on it.
• Code reviews are essential for maintaining the quality of the project. Documentation should be easy to understand and useful for users. The team stressed its importance.
• The error API has some problems. These were discussed along with potential solutions.

On performance Issues (slides) (Paul Dale)

We discussed performance issues within the project, emphasising the significance of conducting performance tests and establishing baselines prior to implementing any improvements. Various optimizations were suggested during the discussion. Additionally, we addressed licensing and compatibility concerns. The conversation concluded with a consensus to prioritise performance testing and integrate it as a regular practice within the development process.

• Investigate the profiling of mallocs

Technical Debt: Inefficient Data Structures (slides) (Paul Dale)

The discussion, initially focused on identifying specific places and structures in the code, eventually shifted towards the broader performance landscape again. We recognized the importance of developing a concrete plan and design for the performance infrastructure.

• Performance improvements/fixes should be in the roadmap.
• Define performance indicators such as transactions per second (tps), memory usage, and others.
• Develop a design for the performance suite.

Community Engagement (slides) (Matthias St. Pierre)

We discussed the need to improve communication and engagement within the diverse OpenSSL community, consisting of ordinary users, developers, security researchers, companies, etc. The current communication channels, such as the website and mailing lists, were identified as outdated, overwhelming, and lacking clear guidance for newcomers. To address this, suggestions were made to redesign the website for better user-friendliness and information, separate user questions from software issues, and explore platforms like GitHub Discussions for improved organisation and engagement.

• Improvements to be made include redesigning the website, enhancing communication channels, and expanding the list of committers.

Personal 15 minute time slot: Shane Lontis

We discussed the challenges associated with utilising various versions of OpenSSL and the resulting implications for support. Specifically, we examined the drawbacks of certain versions, such as 3.1 not being an LTS branch and 3.0 lacking optimal performance. The conversation also addressed the support burden and the necessity for extended support in certain modules. Additionally, we explored the challenges encountered by customers seeking FIPS validation and the subsequent impact on their certification process. To address these concerns, we explored different approaches for managing LTS releases and providing extended support for specific modules.

• Establish the prerequisites for nominating a release as an LTS version.
• Review the schedule for LTS releases.

Expanding the Committers List (Dmitry Belyavsky)

We discussed the involvement of committers in code reviews and the overall engagement within our community, emphasising the importance of code reviews as a critical component in upholding project quality. We reached a consensus that code review should be regarded as an essential responsibility of committers and a valuable contribution to the community. The discussion also touched upon the topic of incentives and accountability (“carrot/stick” approach) to motivate and ensure active participation.

• Explore the possibility of transitioning certain committers into advisory roles and determine where advisors fit within our structure.
• Simplify the onboarding process for new committers by providing comprehensive documentation, guides, and resources.
• Investigate methods to attract and onboard more trusted committers to strengthen our community.
• Explore various motivation options to incentivize and retain committers.
• Establish code review as a mandatory requirement for maintaining the committer role, considering automation and effective communication.

QUIC Forward Planning (slides) (Hugo Landau)

The group engaged in discussions regarding the development and prioritisation of features concerning the QUIC protocol. The conversation revolved around the significance of server support, protocol performance tuning, and the importance of early engagement to gather feedback. A debate emerged regarding the prioritisation between performance tuning and server support. The question of enabling the QUIC protocol by default in the upcoming release was raised, with a general consensus in favour of doing so. Furthermore, the importance of quality assurance and testing was emphasised, and the existing tests and interoperability efforts were acknowledged.

• Break down the work and assess what is realistically achievable

Security Hardening Prioritisation (slides) (Nicola Tuveri)

Nicola presented the necessity of addressing BIGNUM and suggested assigning someone who is knowledgeable and meticulous to work on it. He provided an overview of the historical context and the current state of BIGNUM. We deliberated on the importance of allocating dedicated time to tackle this task. Although the task may seem routine, it requires the expertise and attentiveness of an individual well-versed in the subject matter.

• Develop a comprehensive plan for addressing the BIGNUM task.
• Gain a thorough understanding of the complexity and prioritise it accordingly.

Personal 15 minute time slot: Hugo Landau (slides)

Hugo discussed the need for an improved OpenSSL Command Line Interface (CLI) that is user-friendly and doesn’t necessitate external research.

Personal 15 minute time slot: Todd Short (slides)

Shared amusing stories from his past career, highlighting his journey into cryptography and experiences working on OpenSSL.

Personal 15 minute time slot: Tom Cosgrove (slides)

Tom introduced himself and the Security Libraries team at Arm, provided an overview of their work.

Personal 15 minute time slot: Matthias St. Pierre (slides)

Shared entertaining stories from the past, along with discussions about the upcoming 25th anniversary celebration of OpenSSL.

Personal 15 minute time slot: Nicola Tuveri (slides)

Introduced himself, providing an overview of his work in academia and his involvement in the QUBIP initiative.

Documentation Approach (Richard Levitte)

We engaged in a discussion regarding the current state of documentation, delving into past conversations and addressing requirements. Specific items that we aimed to retain or create, such as manpages, tutorials, HOWTOs, and demos, were identified. We strived to adopt a user-centric perspective and also examined documentation practices employed by other projects. Throughout the discussion, Richard led conversations emphasising the significance of user-centric documents and underscoring our recognition of the pivotal role that clear, accessible, and comprehensive documentation plays in enhancing user experience and promoting project adoption.

• Identify a tool for rendering .md (Markdown) documents into a web format.
• Structured content and indexing.
• Ability to write text in the repository and have it published as-is.
• Continued support for manpages.
• Inclusion of images in the tutorial document.
• Compatibility with our build system.
• Code documentation should reside in the same repository as the code.
• Capability to generate demos from the same source as the tutorial.

Technical Debt: ERR API (slides) (Hugo Landau)

We discussed the shortcomings of the error (ERR) API and its issues regarding diagnostic versus normative error handling. Hugo presented potential solutions, including defining some strict rules for ERR usage and employing “explicit passing” to explicitly note the relationships between new and earlier errors and remove old errors from the stack. We deliberated on the advantages and disadvantages of these approaches and brainstormed alternative methods to address the problem. Matt proposed an idea to achieve this without causing any disruptions or issues.

• Flesh out a proposal and design document.

Return to Face-to-face Summary page.