Update OQS Demos Project

[ajbozarth]

OQS Demos as a project has gotten out of date due to lack of contribution. In order to bring the demos project back up to date and reinvigorate it we had a planning meeting on June 27th 2024. The minutes for that meeting will be posted below and a more in depth planning proposal will be shared and discussed here in the coming weeks.

[ajbozarth]

June 27th Meeting Notes

Attendees (based on the meeting transcript and my memory)

• @ajbozarth
• @baentsch
• @dstebila
• @maximilien
• @planetf1
• @Martyrshot
• @ydoroz
• @praveksharma
• @johnma14

History (provided by @baentsch )

• Started out as a collection of READMEs and blog posts provided by various authors
• Demos became stale over time and thus were updated to Dockerfiles, many of the existing demos Dockerfiles were created by @baentsch

Purpose of the demos

1. Teach users how to use OQS
2. Aid the OQS project, such as use in CI
3. Prover users a stable starting point for using OQS

Current State of the project (provided by @baentsch )

• All demos have a Dockerfile except the chromium demo since it's build can take up to 15 hours and would be unusable in CI
• curl and nginx demos are the most important and maintained, and are used by the test server
• httpd is supported because it is simple

Future

• @baentsch : get all the current demos running and up to date for use in CI

• @ajbozarth : can we update the Dockerfiles to leverage a base image with liboqs/provider?

  • @baentsch : We intentionally don't use a base image because most demos use different configurations for liboqs and the provider. To some degree this is "intentionally diverse" for CI

• @ajbozarth : should we keep the current demos in separate directories in one repo format?

  • separate directories allow easy removal of deprecated demos (will remain in git history)
  • separate repos is overkill for most demos, but could be useful if a specific demo becomes "large" enough

• Core purpose: CI and user tutorials

• Project Goal: Move the demo contents to their upstream projects. This would mean meeting with those project teams to coordinate once demos are back up to date

• Long-term Goal (ie 2-5 years): Complete deprecation of the demos repo as all PQ support exists out of the box in the upstream projects

Next Steps

@ajbozarth will draft a proposal based on the above discussion and present it at a future OQS Status meeting in addition to posting it here for discussion. Aiming for July 9th meeting, but may take longer due to holidays.

Once the proposal is generally accepted, @ajbozarth and any other volunteers will start executing on it.

[ajbozarth]

Now that meeting minutes are posted feel free to add any clarifications or corrections.

Also I have no permissions on this repo and can't update the labels or assignee on this issue.

[baentsch]

Now that meeting minutes are posted feel free to add any clarifications or corrections.

Thanks for the summary @ajbozarth !

Just adding/reiterating my proposal from the meeting: Contributions to #182 are the most urgently needed and "lowest hanging fruit". But of course any contributions are welcome.

I will (continue to) intentionally refrain from contributing too much to gauge whether there's true "community interest" in this or whether this sub project should be left to wither away. For the avoidance of doubt, I'd find the latter wrong as it will weaken OQS -- but I simply don't have the power any more to keep maintaining this single-handedly. Also my motivation is not increased witnessing things like the below:

Adding/documenting in writing here your verbal statement from the meeting @ajbozarth that IBM has "many OQS-based demos" in-house that it may consider contributing -- and I have a hunch that other companies have/do the same.

I heard this comment with great sorrow: Isn't FOSS most powerful when people (and companies) work together? The community could grow and learn; OQS in this case could benefit; lots of duplicate effort could be avoided.

This comment goes to all corporate members of PQCA (@dstebila @thb-sb please carry this plea to the TAC and GB): Please seriously consider contributing integrations of an OSS library (OQS) into other OSS libraries to the OSS community earlier than later. Proprietary code integrations may of course stay proprietary to afford "competitive advantage". I'd still personally consider the latter wrong as this wastes resources (many companies paying many people to do the same thing), introduces risks (proprietary integrations not gaining enough scrutiny to assure proper security standing) and doesn't strengthen a commonly used OSS component (OQS in this case not getting feedback from secret integrations). Allow me to tag @bencemali and his team and company as a great (counter)example: They seem to use OQS, contribute their findings and motivate changes to OQS based on their use -- all the while pursuing their own product(s). Big Thanks! This is how I understand FOSS to work for everyone and which motivates me to keep contributing.

Also I have no permissions on this repo and can't update the labels or assignee on this issue.

OQS originally had the common FOSS "meritocracy" principle: People that contribute & maintain got GH management rights. The LF take-over did away with this, though: Even I as "maintainer" (call me MINO :-) can't give you those permissions. Hence tagging @ryjones to give @ajbozarth or anyone else any GH permissions they want on this project: IMO this sub project will never be considered sensitive for productive use so I see no risk in this.