Update Ubuntu support to more current LTS version(s)

[baentsch]

As per discussion open-quantum-safe/boringssl#115 (comment)

• Create CI image(s) with Ubuntu 22 & 24
• Deploy in CI testing

(- [ ] Create reminder automation to keep in sync with updated PLATFORMS.md referencing Ubuntu LTS (instead of outdated 20/Focal). Edit/add: unnecessary as open-quantum-safe/ci-containers#84 introduced the notion of "ubuntu:latest")

[baentsch]

Instead of "reminder automation" suggest to commit to supporting "ubuntu:latest" tag as provided by docker hub (and used as basis for CI container) in PLATFORMS.md. Objections, anyone? This way OQS will automatically "stay fresh" (or the team be reminded of dependent software updates if (the) CI (container build) breaks.

[dstebila]

Does :latest track the actual latest release, or the latest LTS release? I am fine either way, I just note that your initial plan had been track more current LTS versions. I don't follow Ubuntu closely enough to know if it matters whether we track LTS or latest release.

[baentsch]

Does :latest track the actual latest release, or the latest LTS release?

The latter (as arguably makes most sense for end users): https://hub.docker.com/_/ubuntu/

[baentsch]

Deployment in CCI conceptually straightforward, but will not be done by myself as per #1789 (comment)

[planetf1]

From a developer perspective, using :latest is very appealing for the reasons described above. In isolation it's what I'd prefer....!

However in general one of the best practices of establishing a secure software supply chain (including reproducivility) is to use version pinning - including by hash.

The work to maintain these distinct pinned versions (which is notable .. for example there's a risk of actually worsening security if an urgent patch isn't fixed up) is to use automated dependency management tools, such as dependabot.

These tools will then typically create a PR, which can go through an explicit review process before being accepted into the codebase.

To some extent one might argue that use in CI is a little less critical - we're not actually shipping this code. However it is being used to generate our code, so we can see how a malicious actor could inject a threat, or something that avoids testing ....

[baentsch]

one of the best practices of establishing a secure software supply chain

I do not recall OQS ever adopting the desire let alone commitment to be part of such supply chain. It actually still strongly discourages its productive use, i.e., absence from any supply chain, and has not decided to change this nor put any plan in place how to do this.

Don't get me wrong, your points are all sensible -- but probably not the most urgent work to be tackled: First comes the decision to make OQS productive (which would be a prime reason for me to keep contributing), then the decision which parts this applies to, then what this entails for those parts, what guarantees to give on which platforms, which testing (on specific, to-be-decided platforms) this requires -- and then how to pin down testing tool versioning. Please also consider that any pinning limits freedom of action (on those parts of the code that shall remain "purely experimental" -- so that also needs deciding first).

[dstebila]

one of the best practices of establishing a secure software supply chain

I do not recall OQS ever adopting the desire let alone commitment to be part of such supply chain. It actually still strongly discourages its productive use, i.e., absence from any supply chain, and has not decided to change this nor put any plan in place how to do this.

I do not understand why you say that OQS "has decided not to change this" (meaning changing from discouraging production use to supporting production use). On the contrary, a desire to move OQS to being suitable for production use was stated in the OQS visioning exercises last fall, was a main motivation for moving OQS into LF, and has come up many times in discussions at the PQCA as well.

It is true that we have not yet put in place a plan on how to do this. But despite the lack of a cohesive plan, I think over the past few months we have seen activity from contributors trying to move the project in this direction from their understanding of what production-ready would require, including:

• adopting a scorecard of some best practices for open-source project security
• improving software supply chain security from both an [incoming] and outgoing perspective
• adding formally verified cryptographic implementations
• adding stringency around software licensing (DCO, BoringSSL license, CC0 relicensing of libjade upstream)

This certainly not everything that needs to be done. Perhaps you may think some of these are actually a step backwards or sideways at best. But I cite them here to support the claim that there is activity around moving towards the goal of production use.

It is also true that the statement that OQS is not recommended for production use remains in the README. It is possible for us to be working towards our goal without having yet achieved it. I would only want to announce such a switch – and change the README – when we as a group collectively decide we have reached that stage.

I am struggling to find time to push forward many of the planning activities, including the plan for moving OQS towards production-ready.

[baentsch]

I do not understand why you say that OQS "has decided not to change this"

This is not what I said. Please read again: I said OQS "has not decided to change this". That is a difference in my understanding of the language -- but it's your native language and not mine, so I may be wrong, so I guess I have to elaborate:

We have agreed (and I kept pushing for years) to consider catering for productive use -- but no formal decision has been taken to do this - and particularly for which sub projects and which components and what this entails. Very much to the contrary, OQS still discourages productive use and there is an open discussion item on this topic.

You list all activities that have been taken in the past months -- but I beg you to not forget all activities in this direction in the past years (more automation, more testing, more CI, constant following of up- and downstream patch levels of important software like openssl, etc.).

Still, as you state, OQS has not taken the step to stand behind the software as an entity like OpenSSL does. And I fully appreciate you have other things to do -- as you appreciate the same being true for me. Hence let me repeat also in this place another thing we agreed in the visioning exercise to need, namely a product manager bringing things into a sensible sequence: What is needed for enabling productive use, get users and their buy-in, create the missing and prioritize the existing issues, get buy-in by the people doing the actual work, putting in place the "fulfilment processes", seeing things get done -- just naming a few tasks.

Again, please do not take my comment as stating that nothing has been done --as it would de-value the work of many people, including mine-- but that there is no coherent drive, no formal decision and commitment as to what to achieve by when but a hodgepodge of activities (of which supporting Ubuntu 24 is but one).

[baentsch]

However it is being used to generate our code

Could you please elaborate on this @planetf1 ? I'm not sure I understand how a CI image "generates our code".

There is exactly one place where OQS makes generated code available and that is not in this sub project -- and it's actually one of the things that I will revert the moment that OQS makes the decision to "be productive" and leave that to professional packagers downstream such as apt or brew -- unless of course OQS also makes the decision to make available binaries it stands behind... But that would open a whole new can of worms....

[baentsch]

The work to maintain these distinct pinned versions (which is notable .. for example there's a risk of actually worsening security if an urgent patch isn't fixed up) is to use automated dependency management tools, such as dependabot.

That in turn is something I entirely agree with: Using dependabot would be better -- but it would mean work to deploy and maintain, etc. If you're willing to take this on (or know someone who would), please by all means, do -- I just cannot.

[planetf1]

However it is being used to generate our code

Could you please elaborate on this @planetf1 ? I'm not sure I understand how a CI image "generates our code".
....
professional packagers downstream such as apt or brew -- unless of course OQS also makes the decision to make available binaries it stands behind... But that would open a whole new can of worms....
Indeed! It's probably an easier story with the distribution builds (fedora, ubuntu etc) - is that another discussion we should start?
For brew it's a bit different in that the maintainer is a just a regular sw dev from the UK .. I don't think we have anything there yet? If important should track as another issue?

The tools on the CI image form part of the build process by which we create executable code that is then tested. My thought is that a compromise(or bugs) of the tools (by not pinning) could lead to tests passing that shouldn't. Security issues being missed for example.

I understand the concern this may be going further than is appropriate (and there may be a lot of simpler ways such things can happen). I'm going to ask about this scenario in the openssf groups. But it does seem that anything that can compromise the build/test process, even if that isn't shipped, could lead to vulnerabilities.

[baentsch]

there may be a lot of simpler ways such things can happen

120% agree. One such thing is that there are sensible (or even necessary) tests not present to begin with -- and there are quite a few of those....

[SWilson4]

As far as I can tell, our current Jammy and Noble images are only built for x86_64. I'm thinking that we can use our shiny new GitHub Arm runner to build and push images for arm64 in CI---does this sound reasonable to you @baentsch?