Binary distributions

[planetf1]

Is there a list of binary distributions (particularly aided by the core team, or at least well-supported) of liboqs? Obviously there are more built by individuals for their own needs.

I can build liboqs from source (and have the most flexibility), but when explaining to others how to use liboqs, pointing to a easily accessible built version - such as installed from their standard linux distro, or a common package manager (like homebrew on macos) can make things easier & less error prone

Looking around I found a few references:

• https://packages.fedoraproject.org/pkgs/liboqs/ - looks to be current. I've myself installed liboqs from fedora 39. This is really useful (also builds at https://koji.fedoraproject.org/koji/packageinfo?packageID=37370 ) . I presume this is the current official initiative for fedora?
• https://copr.fedorainfracloud.org/coprs/rrelyea/liboqs/ - I presume this was an early, now defunct initiative. It targets a broader range of distributions than the above
• https://code.launchpad.net/ubuntu/+source/liboqs - an earlier .8.x version for a range of ubuntu versions. Non-official?
• https://repology.org/project/liboqs/information - some additional random hits
• https://formulae.brew.sh/formula/liboqs - homebrew. This looks current, presumably official?
• https://aur.archlinux.org/packages?O=0&SeB=nd&K=liboqs&outdated=&SB=p&SO=d&PP=50&submit=Go - archlinux. unofficial?
• https://www.freshports.org/security/liboqs - FreeBSD (0.8.x)

No doubt there are many more

Is this documented anywhere? Would it be useful to add those with some backing/confidence that are being maintained (happy to volunteer helping out in doc etc, search in more detail & catalog)

Logically the topic could continue with the other subprojects like python binding.

Many thanks!

[beldmit]

I am the maintainer of liboqs and oqs provider in Fedora, I confirm this is the official Fedora initiative. But we intentionally build only NIST-approved algorithms

[baentsch]

Is there a list of binary distributions (particularly aided by the core team, or at least well-supported) of liboqs?

Not really. OQS never really cared about binary distributions for lack of (human and CI) resources (and experiences, say with non-Linux/non-x64 platforms). Even a general platform support strategy is currently only "in the making" (see #1605), so anyone doing distros (cudos to @beldmit ) may face "surprises".

Only oqsprovider does provide binaries as part of its releases as the maintainer of that project considers it a key feature for a "binary loadable module".

happy to volunteer helping out in doc etc, search in more detail & catalog

Please, by all means, go ahead! It would also be nice if you could collect (CI) environments we could rely on if we decide to support specific platforms. It would help M1 as well as not really well-supported arcane IBM platforms (sorry, couldn't resist :).

[planetf1]

thanks.. makes sense to only distribute the NIST candidates in built form for now.
Sorry for the slow reply (many threads) - I'll do some more digging ... and be back here.

[SWilson4]

Does this still reflect current wishes of liboqs upstream, now after the NIST project was finalized? TIA, cu Andreas

At the moment, I would say "yes"—we don't yet have an implementation of the final version of FIPS 204. After that lands, perhaps we can revisit this decision. @open-quantum-safe/tsc Might this be worth discussing in tomorrow's meeting?

[baentsch]

As @SWilson4 pointed out, OQS at this point in time does not include software in line with the final versions of all published NIST standards (see #1894 (comment) for details). There further are several unresolved discussions as to what it takes to transform the software into a state that it can be considered safe for use by "Average Joe", e.g., open-quantum-safe/tsc#1.

The mission of the project currently is unchanged to "provide software for evaluation and prototyping", so I'd second the "Yes" by @SWilson4.

That said, @ametzler , you may want to build your own opinion as to whether it's OK to include OQS in stable releases. I am a more cautious person than the committee majority of corporate America controlling OQS with the position of "just drop usage warnings" and "let the user decide". I am of the opinion that this is security software, warranting additional caution/quality concerns. This opinion also is based on my insight of the state of the software and its origins -- but may be tainted by my position of a maintainer (with a thus perceived responsibility to provide reliable software).

@open-quantum-safe/tsc Might this be worth discussing in tomorrow's meeting?

Yes, a verbal exchange of thoughts between people with time to participate only via meetings and those contributing publicly/via GH surely may be beneficial to understand the mutual concerns and goals.

[dstebila]

@open-quantum-safe/tsc Might this be worth discussing in tomorrow's meeting?

Yes, a verbal exchange of thoughts between people with time to participate only via meetings and those contributing publicly/via GH surely may be beneficial to understand the mutual concerns and goals.

I don't think that's an appropriate response. We have meetings to facilitate these discussions; the TSC will not be the sole location for those discussions, but it can be one venue for them.

[baentsch]

I don't think that's an appropriate response. We have meetings to facilitate these discussions; the TSC will not be the sole location for those discussions, but it can be one venue for them.

I didn't think I "said" anything other than that, sorry if that got across in an unintended way: My goal is to ensure people are not disadvantaged due to their (lack of) mastery of language or (un)availability in specific time zones (or general lack of time) by having different venues for discussion (incl. meetings and GH).

[ametzler]

Thanks for the quick responses, continuing to keep this in Debian/unstable only seems to be the right thing to do.

[adrien-n]

Hi,

(apologies if an earlier version of this message got through your notifications or inbox :) )

I'm looking at updating liboqs and the openssl provider in Ubuntu and Debian. There are at least two aspects: a) update packages, regardless of whether they are shipped in a distribution release, b) offer them to users.

Ubuntu releases an LTS version every 2 years and an interim ones every 6 months. There are planning stages months before each development cycle and feature freezes a couple month before the release. My current plan is to prepare an update of liboqs for 25.04 which is an interim version and hope that you are satisfied with liboqs' status by 26.04 LTS so that users can benefit from it.

I discussed that with other Ubuntu/Canonical developers and we feel like there is no perfect and clear-cut solution. We want to include oqs early enough, but not too early. Except we don't have crystal balls either. The best we can do is prepare everything, do the integration, and either not do the final integration steps for now, or do it but hide it behind a feature flag. One thing we all agreed upon is that only hybrid cryptography makes sense and we'll make sure to make this clear in Ubuntu. Moreover, nobody felt that it is possible to commit to support for post-quantum cryptography software today: our motivation is to help make things move forward.

My rationale for targetting the next interim release (25.04) is how much work will still have to happen afterwards in the distribution, and if we aim for wider availability in 26.04, all of it will have to be done within a year or so. If not 26.04, the following Ubuntu release that will be used as widely will 28.04 and I think everyone will agree it's getting too far in the future (especially since it means real world deployments at least several months later).

There is no intention to actively promote these packages and as I said above, I'd like to offer them in the distribution so that people can start evaluating them and provide feedback. An additional benefit will be the CI that runs on amd64/arm64/armhf/ppc64el/s390x (not riscv sadly due to its slowness).

What do you think about this? Does it seem to sound to begin preparations today but gate everything so that actually enabling requires an active operation from users?

[baentsch]

Thanks for this thorough description of events (at least I wasn't aware of until now), @adrien-n ! Just this statement triggers a question in my mind:

One thing we all agreed upon is that only hybrid cryptography makes sense and we'll make sure to make this clear in Ubuntu

Does this mean you will want to disable "plain PQ" algorithms or keep them but just attached with a documented warning? If the former, do you expect a config option to do this or would you patch the code accordingly? In the prototype-only oqsprovider all of this is configurable (exactly for experimentation as per its stated usage goal) but we didn't consider adding an option to do this (yet) in OpenSSL (which for now is not based on oqs): See openssl/openssl#25848 . Worthwhile opening a separate discussion there?

[adrien-n]

That's a good question. I don't have a full answer at the moment however. Ideally, there wouldn't be any specific configuration or patch: following upstream's choices should always come first. Specific options and patches in distributions should only exist to solve distribution problems IMO.

I think that in practice, the first step will be an updated package and then some integration. It's possible that for Ubuntu it will be limited to a PPA and/or we use warnings (or use runtime configuration to disable everything?). Some of that will depend on openssl and gnutls for instance (if oqs is needed while building gnutls, then a PPA won't be appropriate: an openssl provider is more flexible than gnutls' typical approach AFAIU). Later on we'll probably either expand what's enabled, or restrict it: it's difficult to say for now. :)

I've had bad experiences with the past where different runtimes couldn't communicate together as expected because they were configured slightly differently. I'm a bit scared that each distribution comes up with its own set of algorithms with only partial overlap. We can discuss that further for openssl indeed.

NB: with current openssl and ubuntu policies, Ubuntu will probably have to stick to the next openssl LTS (has to be 3.5 or maybe 3.6) for four years after the LTS release.