Fix integrations to specific commits?

[baentsch]

For some integrations (epiphany/glib-networking, nghttp2, mosquitto, ngtcp2, openlitespeed, openssl, openvpn, quic, unbound) we are tracking "main"/"master" branch of the respective project(s): This leads to breakages outside our immediate control as and when significant upstream changes occur affecting the integration, see e.g. this build breakage.

This issue therefore is to propose "pinning" all integrations to specific upstream releases or commits to reduce our work effort (not following any more all upstream build/API changes to maintain a "green" CI state).

The price paid for this reduction in work on our side would be possible "slow and silent degradation" of "OQS-readiness" of the pinned integrations (as already may be a problem for already pinned integrations, e.g., curl, httpd etc.). This might be mitigated by regularly "revising up" the pinned integrations.

Anyone reading this please speak up if this were a problem for them -- or have alternative proposals.

[baentsch]

@ajbozarth as you're picking a demo for your personal learning exercise, you may want to keep this issue in the back of your mind.

[planetf1]

I agree with this proposal (and can help)- we should have a 'process' around those updates, rather than just following main/master.

We can probably find a tool to help automate this -- dependabot is great, though it's scope may not extend just to repo code (it works great with java/npm/python packages & github actions)

[baentsch]

and can help

That would be great! In an ideal world, it'd be great to have both: Reliable docker images based on known-good upstream versions (for PQ users of the integration to always have sth working) as well as regular (e.g., weekly?) tests against main/master of the upstreams ("canary" for OQS dev team) such as to get timely notifications when/if sth breaks/may need attention by the OQS dev team. Would the be possible to be automated via dependabot @planetf1 ? If not, I'd personally currently give preference to reliability for users, i.e., "fixed" upstream versions.

[planetf1]

I can take a look at the possibilities
@ajbozarth probably makes sense to look at this as you tackle a particular demo, since you may do some refactoring & updating in any case. Which do you plan on tackling first? Is it already in a decent state?

As a first step I'd like to check the dependabot settings under Settings->Code security and analysis . I don't have access currently (probably would need admin access). I think this will allow a subset of notifications to be added into the security tab (no PRs)

Previously I've configured dependabot via the dependabot.yml (before it was integrated into the github ui)

However this approach will definately raise PRs on any dependencies that aren't up to date, and letting this loose on all our demos in one go is probably not useful.

Once we've identified a demo to test I can create a config, but restrict it to the path of the demo we're trying out, so we can incrementally enable it on each

[baentsch]

Is it already in a decent state?

Please note that any of the demos listed under the "supported" column is by definition in a "decent state". If problems are found, I'd expect issues to be raised so the specific people that agreed to maintain a demo can take a look/correct things.

Generally, I'd also suggest creating agreement on the definition of "decent state" so everyone can work towards the same goal. You may also want to note open-quantum-safe/www#215 where I made suggestions to downgrade my original definition of "decent state" (fully CI-tested, automatically generated, documented and operational dockerimage at docker hub) in line with contribution level such as to set proper expectations with users.