Adds docker build to generate test server package

[bhess]

Adds docker-based build for test server package, using ubuntu docker base.

Difference to previous test server config: only (pq-)signatures and kems with matching security levels are configured (exception are the baseline rsa/ecdsa signatures).

Note: The PR currently includes a common.py, which can be automatically loaded once open-quantum-safe/oqs-provider#173 is merged.

[baentsch]

See separate comment

[baentsch]

Thanks for de-jinja-ing this. Not sure I am enthused about seeing scala appear instead :-} But then again, this code

• does not seem to be the same running at test.openquantumsafe.org -- at least this PR contains lots of references to Chromium and the test server only contains one line (intentional, btw?),
• is not used for CI,
• is not pushed to docker hub,

so I don't really mind.
This begs the question, though: Is there any automation using this code or is it purely for demo purposes and your internal use?

[bhess]

Deployment isn't fully automated as the tar archive generated by the docker build still needs to be copied to the server. The docker build is however the same running at test.openquantumsafe.org - Chromium-related pages are generated but not referenced (keeping them around just in case there is Chromium support again in the future).

[baentsch]

Chromium-related pages are generated but not referenced

Hmm:

[bhess]

With Chromium-related page, I meant the dedicated page on test.openquantumsafe.org that lists all supported ports.

Hmm:

I left this in intentionally, for awareness of the Chromium limitations, without advertising specific ports. So would you remove this as well?

[baentsch]

for awareness of the Chromium limitations, without advertising specific ports. So would you remove this as well?

I personally would: We really don't support Chromium --or boringssl-- any more, right? Besides, the support always was very limited (only a few algorithm combinations -- hence the text you left in). Therefore, I would go even further and would remove as part of this PR Chromium from the list of supported demos -- I did the same with haproxy as there was no feedback to the opposite (no-one speaking up voicing interest to use it). Code remained, but no CI any more. That way, it can be resuscitated if someone would pledge the time to maintain it.

@dstebila @christianpaquin What's your take? We could then even close #189 as there was no activity on this from our side (@Raytonne, please speak up if you see a need for this).

[dstebila]

for awareness of the Chromium limitations, without advertising specific ports. So would you remove this as well?

I personally would: We really don't support Chromium --or boringssl-- any more, right? Besides, the support always was very limited (only a few algorithm combinations -- hence the text you left in). Therefore, I would go even further and would remove as part of this PR Chromium from the list of supported demos -- I did the same with haproxy as there was no feedback to the opposite (no-one speaking up voicing interest to use it). Code remained, but no CI any more. That way, it can be resuscitated if someone would pledge the time to maintain it.

@dstebila @christianpaquin What's your take? We could then even close #189 as there was no activity on this from our side (@Raytonne, please speak up if you see a need for this).

Agreed, unless we get someone speaking up and contributing to maintaining our boringssl and Chromium work.

[Raytonne]

Agreed, unless we get someone speaking up and contributing to maintaining our boringssl and Chromium work.

Hi - I can help to maintain the boringssl & chromium fork

[baentsch]

Hi - I can help to maintain the boringssl & chromium fork

Great to hear that. Thanks @Raytonne ! I'd then be fine merging this PR as-is.