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.

[baentsch]

Thanks for that timeline heads-up @adrien-n. fwiw, my hope is that OpenSSL will have good, OQS-independent PQC implementations available for all NIST-standardized algorithms in such LTS (at least I try to help make that happen, but wouldn't give a guarantee at this time, particularly considering to the many options "around" those algorithms wrt key formats or the various "hybridization options"... Should those still not have "stabilized"/finalized by the time of your LTS, then an availability of oqsprovider in "unstable" may be the best approach to hedge all bets).

Concerning the question above (hybrid only support or all-option support), I'd personally very much prefer the latter: IANA has assigned code points to "pure" ML-KEM, so why not give users the option to use them? The crypto code for that exists anyway -- albeit I agree, it has not stood the test of time...

[dstebila]

@adrien-n Just getting caught up on some older issues. Did you get the information you need to be able to proceed? Or is there more you're looking for from us?

[adrien-n]

@baentsch It's difficult to predict future state and I wouldn't worry that much about it. Releasing a distribution version is taking many many late decisions for plenty of packages and typically it's not possible to take these decisions earlier on. I'd say that's the life of releasing a distribution. ;p

Regarding support for hybrid-only or pure PQC, I think we all want to enable pure but the unknown is exactly when that will happen and whether it's done in several steps (especially wrt shipping vs. enabling by default). We definitely want to start with hybrid so pure will be something in addition to and not instead of. As such, for shipping, it's probably mostly going to be a matter of time and release schedule deadlines. For enabling by default, it's another matter but things have ample time to change by then, and it's not impossible to enable features post-release if needed.

@dstebila I've investigated more one of the first issue for the Debian packaging which is also probably the least interesting: licenses and copyrights. Debian packaging requires that every file has license and copyright data. Unfortunately the data in liboqs' upstreams can be lost during updates because it's tied to file paths rather than stored in the files themselves. This also makes it difficult to automatically created the corresponding database. I went for a restricted set of algorithms and opened the following PRs:

• Add SPDX headers and copyright notices at the beginning of files. pq-crystals/kyber#93
• Add SPDX headers and copyright notices at the beginning of files. pq-crystals/dilithium#99
• Add SPDX headers and copyright notices at the beginning of files. sphincs/sphincsplus#64
• Add SPDX headers and copyright notices at the beginning of files. PQClean/PQClean#579

I decided to work on the file upstreams as I didn't have to track their origins and the bet is that I selected the relevant ones (mostly at least: I know it's definitely not perfect but the work should be transferable). As you can see, I didn't get feedback for these PRs, which is not a surprise because it's definitely non-exciting stuff.
Is there a good way to integrate these changes in liboqs even if these upstreams or upstreams-squared didn't pickt hem up? I didn't yet have time to do it myself and see the result on automation but I shall do that this week.

[dstebila]

@planetf1 In the 2024-12-05 OQS TSC meeting, we discussed this issue. The list of resources you started to collect is great. Would you be willing to turn this into a table, with contact information (Github handles or otherwise) for each distribution? Also there's the question of whether we would want to put this in the Wiki tab of Github or somewhere else.

[planetf1]

sure, we can start to collate, just need to figure out where. I'd presume the obvious place would be somewhere in the https://github.com/open-quantum-safe/www repo so it appears on https://openquantumsafe.org/ . Not sure where it fits the best. Could be under liboqs, but it may be broader in scope (for example oqsprovider ?)

[dstebila]

Okay, how about starting a new page distributions under applications?