Complexity of compile-time disableables makes it hard to contribute code to OpenSSL

So, what is your opinion? I believe many users would complain if we removed build-time configure options for many optional features but maybe it is at least time to make ec and ecx mandatory? It would simplify a lot of tests.

Would it make sense to create a list of compile-time flags that could be considered for removal, and then hold a vote to prioritize which ones to remove?

I would like to first see a general discussion on the concept of removing some of the disablables (i.e., making them mandatory).

If build-time configuration is not available, I am concerned that it would make openssl more difficult to use in environments where unused features are not allowed (safety-critical for example) or in embedded where binary size matters.

In the meantime I noticed that there are in fact build-time options to disable PQC, so that part of my initial statement was not correct.

That being said, I believe there are very few good reasons for build-time configuration over run-time configuration. From the top of my head, only two come to mind:

1. Potential legal reasons to avoid shipping specific code (this used to be the case for elliptic curves).

2. Binary size

3. Trust in runtime configurability; if you remove something at compile time, you can be sure that no application or user can re-enable it. The same isn't the case at runtime, since applications can essentially re-configure all settings of the OpenSSL library at runtime, regardless of what the system administrator's configuration said.

Compare those to the downsides of having compile-time configuration:

• ABI changes; a copy of OpenSSL 3.5 built with no-ec isn't binary-compatible with a copy that was built with elliptic curves. This causes headaches for binaries that want to be cross-distro compatible.

• user friendliness; if a distro makes a compile time choice, changing that choice is a major ordeal for common users. A runtime configuration option is much simpler to adjust if required

• Contribution becomes harder; I will compile and test a "standard" set on my local machine, but testing more than maybe 3-4 compile-time options locally is a hassle, so we're very much relying on CI to keep those working

• Combinatorial explosion; testing all combinations of these compile time options is infeasible, so it's entirely possible that those we don't test in CI actually just don't compile, or fail immediately at runtime

For the first two reasons for having these switches, I have additional thoughts:

For (1): Depending on your lawyer's interpretation, removing the code from the binary may not have been enough, in which case a patch downstream also needed to remove the source code — at which point whether a compile-time option exists doesn't really matter. I also believe these times are behind us, for ECC at least.

For (2): How much difference does this actually make, and how many platforms where it would make a difference can actually still run OpenSSL?

unused features are not allowed (safety-critical for example)

I believe this is largely unachievable today already. There are no compile-time options for various TLS extensions that your peers may or may not send, so that's an unused feature that you cannot remove, too.

@Clemens Lang The ABI compatibility issue is true only for the low level functions that are either deprecated or discouraged, not for the recommended EVP API nor for things reached through libssl.

Despite this statement, I am not opposed at all to a discussion about revising current build time options.

@Nicola Tuveri I wouldn't have called the ENGINE APIs low-level functions, but you're right that they're deprecated.

That being said, a quick look at `util/libcrypto.num` suggests there are other symbols that are dependent on compile-time options that don't seem to be deprecated. For example

• OSSL_CMP_log_open/close, depends on cmp

• OSSL_DECODER_from_fp, depends on stdio

• DHparams_it, depends on DH and isn't deprecated

• DSA_SIG_new/free, d2i/i2d_DSA_SIG, DSA_SIG_get0/set0, depend on DSA and aren't deprecated

• various EC_GROUP_* functions, depend on EC, aren't deprecated (and IIRC quite a few of those are actually used in code out there)

• OSSL_HTTP_REQ_CTX*, depend on HTTP

• TS_CONF_*, depends on TS

• various BIO_s_* functions depend on sock

• the entire CMS_* API depends on CMS

• the QUIC APIs depend on QUIC

and many more examples.

@Clemens Lang I do not think we will ever get no ABI changes based on build time options unless we remove all these build time options. Besides I do not see it as a too big problem as basically distros (where the ABI compatibility matters) should be using the default build options. And yeah, I know that for historical reasons that is not true, but they could get there fairly easily, I think.

Solution for things like CMS, TS or CMP could be to split them out to separate libraries which simply won't be built if they are disabled.

@Tomas Mraz I agree that this is largely not a problem in practice — it would be a problem when toggling some of the very commonly used functions, though. A distribution that starts building with no-stdio or no-rsa would quickly see problems. That makes me wonder how useful these options are and whether they should exist at all. But I'm also not a user that would use those options, and I was hoping these users would speak up in the discussion.

What's the actual problem that makes the presence of options hard to contribute code? My code also has lots of options, the tests build with everything enabled for maximum coverage and then it ships with a smaller set of options enabled. Every single odd combination isn't tested and there's possibly some config that no-one has used since 2007 that'll have a problem, but it shouldn't make contributing code harder. In particular the vast majority of users never touch the options, they just build the default config.