OpenSSL Communities
Tue 21 Oct 2025 3:41PM

Your Thoughts Wanted — OpenSSL Source Code Reformat

AK Aditya Koranga Public Seen by 84

Hello Individuals,

So, recently a hot topic of discussion in the OpenSSL community has been the upcoming source code reformatting.
It’s been actively discussed in TAC meetings, and even at the OpenSSL Conference, where Bob Beck gave a dedicated talk on the subject (slides attached for reference).

The OpenSSL team plans to reformat the entire codebase using clang-format, following the WebKit coding style.

Since this change touches every contributor in some way — and because your feedback as individual developers, researchers, consultants and contributors is just as valuable as that of any other group — it would be a shame not to know what the individuals’ community thinks about it.

So, let me make it easy for you by asking a few direct and simple questions

1. Initial Reaction
- What’s your first impression of the OpenSSL reformatting plan?
- Does it sound like a good step forward, or do you have any concerns?

2. Impact on Your Workflow
- Do you maintain any personal forks, patches, or experimental branches that could be affected?
- If yes, how much extra effort do you expect to adjust them?

3. Formatting & Accessibility
- Do you think moving to an automated format like clang-format (WebKit style) makes the codebase easier to read and contribute to?
- Or would you prefer keeping the existing OpenSSL style?

4. Tooling & Transition Help
- What kind of support or tools would make this change smoother for you?

  1. Any other feedbacks?

We also started a similar discussion thread in the Small Business community yesterday, and as expected, we’re already seeing great engagement and thoughtful responses — [link for reference].
It would be fantastic if you could take a few minutes to answer even a few of the questions here.

Regards,

Aditya Koranga

RL

Richard Levitte Mon 27 Oct 2025 9:47PM

After much consideration, I cannot see myself supporting a reformat that purely uses clang-format's definition of the webkit code style, for these reasons:

  1. clang-format's webkit definition uses the common C++ form for pointer declarations (* near the type rather than near the variable), which isn't what the webkit code style guidelines say for non-C++ code (see https://webkit.org/code-style-guidelines/#pointers-non-cpp)
    The fix is easy: PointerAlignment: right

  2. Webkit flushes all trailing comments against what comes before them. For example:

    --- a/include/openssl/core.h
+++ b/include/openssl/core.h
@@ -83,11 +83,11 @@ struct ossl_algorithm_st {
  * An array of these is always terminated by key == NULL
  */
 struct ossl_param_st {
-    const char *key;             /* the name of the parameter */
-    unsigned int data_type;      /* declare what kind of content is in buffer */
-    void *data;                  /* value being passed in or out */
-    size_t data_size;            /* data size */
-    size_t return_size;          /* returned content size */
+    const char *key; /* the name of the parameter */
+    unsigned int data_type; /* declare what kind of content is in buffer */
+    void *data; /* value being passed in or out */
+    size_t data_size; /* data size */
+    size_t return_size; /* returned content size */
 };

 /* Currently supported OSSL_PARAM data types */

    simplest clang-format fix:

    AlignTrailingComments:
    Kind: Leave

  3. Webkit doesn't allow preprocessor directive indentation. With our tangle of directives (nested #if variants, along with #elif and #endif), that makes for series of directives that are really hard to follow.

    clang-format fix: IndentPPDirectives: AfterHash (although my experiments with this shows that some further tweaking may be necessary to make it work fully, probably a penalty of some sort)

    We might also want to consider if we want to preserve the current one-space indentation for preprocessor directives (clang-format: PPIndentWidth: 1) or if we want to make it fallback to IdentWidth (PPIndentWidth: -1, which is what the webkit config defaults to anyway).

Apart from these three points, the webkit config looks fine in my view. I hope I'm not asking for hugely dramatic tweaks.

PD

Paul Dale Mon 27 Oct 2025 10:22PM

Once the decision to not use Webkit completely as is is made, I think it makes sense to try to tweak the style to be as close as possible to our current guidelines. This will minimise the impact of the reformat which would be a good thing.