Experimental Modules

[reneme]

As Botan 3.x will introduce quite a bit of new functionality, I think a concept of "experimental modules" in the build system would be helpful. I'm mainly thinking of the PQC algorithms that are still moving targets. Maybe also for TLS 1.3 until the dust has settled on the API.

An experimental module would...

• be disabled in ./configure.py by default
• need to be enabled via --enable-modules= explicitly
• not establish a fixed API contract for future versions
• be promoted to an ordinary module in minor releases or
• removed without a lengthy deprecation period

I'm hoping that this allows for quicker iterations of freshly added features, by giving us some leeway in terms of API changes. A bit more controversial maybe: Experimental modules could act as a sort-of feature-flag. I.e. allowing us to merge smaller iterations of upcoming features without breaking the stable functionality.

Edit: An implementation was proposed in #3910.

[randombit]

I'd be in favor. Especially with regards to PQC standardization, we are very unlikely to get it "right" in 3.0. Parameters will change, ASN.1 key encodings will change, etc. My only additional suggestion here would be adding options

--enable-experimental / --disable-experimental (latter is the default) options to mass enable (or not) experimental code.

[mouse07410]

How would enabling or disabling of "experimental" modules differ from the same of "normal" modules?

I oppose introduction of "experimental", as they are bound to add extra configuration complexity with little benefits.

[reneme]

Let me try to spell out my intent for this more from a user's perspective:
First and foremost I would like to clearly mark modules (or APIs for that matter) as "under active development" (i.e. may change in minor versions). This clearly separation of "stable" and "experimental" functionality should allow users take an informed decision about which they rely on. "Stable" being guaranteed functionality and APIs, "experimental" allowing to break API contracts or behaviour in short iteration as the library develops.

Now, I agree that the introduction of "experimental" modules increases the configuration complexity of the library. But I would argue that it doesn't change anything for users that don't want to play with cutting-edge developments. By default, experimental modules would be disabled and not even make it into your compiled binary.

For instance, users that wish to try some PQC algorithm that is yet-to-be standardized can do that deliberately: They would have to (a) enable the experimental implementation at built time and (b) live with the fact that the algorithm and/or the library's API might change according to the decisions taken in the standardization process.

Instead of "experimental" modules we could consider an experimental namespace. For instance Kyber would be used like so: Botan::experimental::Kyber_PublicKey. That way, users clearly see (in their code) that they are about to use some functionality that is "still in active development". However, just introducing an experimental namespace would leave such functionality in the "default" binary, which I find unfavorable.

[mouse07410]

Oh no. The more this unfolds - the worse it sounds.

In any case, please absolutely no Experimental namespace.

I still think that the current mechanism where you can include _or exclude_individual modules is sufficient for users that do not want to deal with "unstable" coffee in the master branch.

[randombit]

I still think that the current mechanism where you can include _or exclude_individual modules is sufficient for users that do not want to deal with "unstable" coffee in the master branch.

I don't see this as at all distinct from that mechanism. In fact it will be mediated by that same mechanism in configure.py. We already have a load_on configuration for modules, this would add load_on experimental that acts identically to the existing load_on request with some additions to the documentation so that it is clear that we don't provide full compatability guarantees for modules so marked.

[randombit]

FWIW I'd be somewhat against an experimental namespace, just as it adds a lot of complications when we do stabilize a module, which is likely to happen regularly over the course of 3.x release series. If you enable something, it appears like a normal part of the library, we warn (eg in configure.py output) that you have enabled something experimental, and from there it's up to you.