replace oqs-openssl111

[baentsch]

With openssl/openssl#19312 merged, oqs-provider together with OpenSSL3 (master) now deliver the same level of functionality as oqs-openssl111.
This issue is to propose replacing oqs-openssl111 with openssl3+oqs-provider where possible in the demos.

Applicable integrations (tick if done) -- suggested order of importance

• openssl3
• OpenVPN
• curl
• nginx
• httpd
• epiphany
• envoy
• quic
• mosquitto
• ngtcp2
• unbound
  - [ ] haproxy (available upstream)
• liboqs-python

Not applicable: Wireshark, Chromium, openssh, openlitespeed

[baentsch]

haproxy testing (via curl) now fails as haproxy is still using oqs-openssl111 and we severed the "interoperability tie" between oqs-provider (used by curl) and oqs-openssl111 (used by haproxy).

Question thus: Would anyone mind we drop haproxy from the list of supported (and tested) integrations (until someone finds time and interest again to support it -- via new PR)?

[baentsch]

Given today's decision to keep supporting oqs-openssl111 work on this topic is put on the backburner. I personally would very much welcome other's contributions regarding maintenance of oqs-openssl111.

[baentsch]

@dr7ana @igorbarshteyn @Keelan10 @chiachin2686 @ryndia You all kindly contributed oqs-openssl111 integrations to oqs-demos and we'd like to ask whether you'd also be willing to help move these to opensslv3.

Background: With the EOL notice by OpenSSL we're now also bringing support for oqs-openssl111 to an end. Therefore, this issue is to track the migration of all integrations towards openssl v3 and oqs-provider. I basically did this for all checked items (just completed epiphany in #209 -- so it may serve as an example what the update entails) but am unsure I find the time before September (OpenSSL111 EOL) to do it for all integrations, so I'd be grateful if you could consider helping with this.

[dr7ana]

I would love to help! I will also take another look at the image size issue we had discussed previously. I've had a lot on my plate starting a new position (as I'm sure you do as well normally), but I will prioritize this for July without issue, thank you for your patience

[baentsch]

@dr7ana Thank you very much! By all means, prioritize your new job! Your contribution will be very welcome any time!

[baentsch]

OpenSSL111 has gone end of life. The demos not yet moved off OpenSSL111 should be sunset, too. Until someone finds time to do the upgrade of envoy, quic and mosquitto I'd suggest to drop them from the list of supported integrations (and of CI), similar to haproxy that also has nobody interested in supporting it any more.

[dr7ana]

@baentsch I know I'm apologizing for the umpteenth time for not getting this done, but I will do it soon I promise! I will also fix the oversize binary issue

[baentsch]

@baentsch I know I'm apologizing for the umpteenth time for not getting this done, but I will do it soon I promise! I will also fix the oversize binary issue

Absolutely no reason to apologize. We all do this on our spare time and voluntarily -- and at least I am grateful for any contribution, regardless of timing. All I want to achieve with the above is set proper user expectations.

[baentsch]

Tagging @johnma14 fyi

[johnma14]

@baentsch I just got to see this message now. For some reason, I never got any notification. I will work on updating the HAProxy demo.

[baentsch]

@baentsch I just got to see this message now. For some reason, I never got any notification. I will work on updating the HAProxy demo.

@johnma14 in case @ajbozarth didn't notify you as per #273 (comment), consider work on haproxy moot; any and all other contributions along the lines above very welcome!

[gobbledy-gook]

Hey there folks!

I have been working on integrating OPENSSLv3 (in-place of openssl1.1.1) with liboqs-python with the help of oqs-provider. I could build and install the liboqs-python module and it is working fine with the examples/kem.py, example/sig.py and examples/rand.py. However I am not able to get a success at running minitest.py as described here https://github.com/open-quantum-safe/liboqs-python/blob/main/docker/minitest.py

Should I take this to a discussion or this is the right place for this? @baentsch

Thanks!

[baentsch]

This is a good place to have the conversation. What's the exact problem/error message?

[gobbledy-gook]

Folder Structure on my machine (I am trying to set it up on my machine for a specific purpose which is out of scope of this issue is regarded)

/opt
     /liboqs
     /liboqs-python
     /oqssa
     /openssl
     /oqs-provider

As discussed here - open-quantum-safe/oqs-provider#507 (comment) that minitest.py should always give a successful connection for port numbers 6000-6108 but I am getting a successful connection only at port:6000 and port:6054.

There are multiple error factors, it would be great if you could point-out the priority of those error factors which I must re-check in-order to rectify it. Factors I think could cause issues:

• openssl.cnf file wrongly configured (I have added the updates to openssl.cnf file here)
• incomplete connection with the oqs-provider
• maybe owner-permissions for using certificates (not sure if this affects)

[gobbledy-gook]

@baentsch as you know I have been working on integrating openssl3 with liboqs-python and troubling with loads of QnA discussions. Now, I have some progress in that, but I am not yet absolutely sure if it is ready for a merge. So it would be great if I could get some help with some suggestions on that OR should I just open a PR and there it can be discussed for changes?

Following is the screenshot of the output when I minitest.py only for port:6138 which uses sig: dilithium2 and kex: kyber512.

The only way I know to verify if openssl3 is being used for this is to check ssl.OPENSSL_VERSION.

[baentsch]

The screenshot LGTM. Thanks for taking this so far, @gobbledy-gook ! I personally think a ready-made docker image with oqs support in python makes a lot of sense for a user community not normally building stuff from source, so a PR building this reliably would be welcome as far as I'm concerned -- and a good place to discuss "rough edges".

The only question I have is whether it should be in this project or in liboqs-python updating the dockerfile there. Any preference from your side, @vsoftco @ajbozarth ? Please also chime in with a user's perspective @gobbledy-gook where best to put this.

[gobbledy-gook]

Please also chime in with a user's perspective @gobbledy-gook where best to put this.

I believe it should be in liboqs-python. A user should not be hopping from one place to other finding the updates on single thing and ops-demos seems to be a good place for demonstration of usage in applications rather than language wrappers. Here we can attach a link, in case someone lands here first.

Edit: Opened a PR

[ajbozarth]

Any preference from your side

None from me, it seems to make sense in either location, so I'll defer to @gobbledy-gook preference of liboqs-python