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.