Future of oqs-openssl111

[baentsch]

Functionally, oqs-openssl111 by now is significantly behind the capabilities of oqs-provider (pretty much all open issues in the project are to add features already available in oqs-provider).

It also is based on an old OpenSSL code base that only receives security updates but no other upgrades. All security updates must be manually applied (oqs-provider receives all upstream --incl. security-- updates automatically).

Thus: Maintaining oqs-openssl111 costs effort within this project and across subprojects, incl. downstream consumers/integrations (profiling, curl, etc.).

This issue therefore is to get input/opinions to finally jointly agree how to carry on with this subproject:

• Can we agree on a set of criteria to cease supporting it? Or maybe a timeline for that? Or is there really no way to stop supporting it (the statement by @christianpaquin hinted at that for his company).
• Alternatively, would anyone volunteer to take on the maintenance of oqs-openssl111 (closing the open issues and maintaining all parallel downstream integrations)?

As usual, all input welcome.

[christianpaquin]

I'd suggest keeping support for 1.1.1 as long as OpenSSL does (September 2023, per their webpage). Until then, we don't need to have a feature match with the active provider project, but should aim to provide "best effort" to maintain interop within the feature intersection (perhaps manual testing everytime we release a snapshot is sufficient?). Downstream projects can switch to 3.0.

[baentsch]

Downstream projects can switch to 3.0.

That's something I fully agree with and which I'd personally prioritize over any work on/with oqs-openssl111.

perhaps manual testing everytime we release a snapshot is sufficient?

Not really: We will (already did) notice differences, so testing will be guaranteed to fail if we don't "look after" oqs-openssl111 before such sporadic testing.

The implication if we'd do this is that the release cycle at each snapshot is getting longer as we'll then need to scramble to debug and fix those "guaranteed" failures (already, two IETF PQ-interop hackathons are happening without us having done a single release also due to this "dependency chainlink").

This effort will be made more difficult by failures to remember what all has changed in the maintained code bases (of OpenSSL3 and oqsprovider): That's extremely inefficient and time consuming. I'm personally already "suffering" from this "code-knowledge dementia" right now (but then again, I'm old, so it may be easier for others).

I'd suggest keeping support for 1.1.1 as long as OpenSSL does (September 2023, per their webpage).

Is staying with a software dependency until it reaches the end of its LTS support prudent? Doing that for commercial software sounds like a pretty high risk -- for a "research vehicle" such as oqs-openssl it sounds like wasted effort given the recommended alternative (OpenSSL3+oqs-provider) is there, working and maintained (for much longer).

[baentsch]

Not entirely surprising but informative: https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/