* Package name : liboqs Version : 0.14.0 Upstream Contact: https://github.com/open-quantum-safe/liboqs/issues * URL : https://openquantumsafe.org/ * License : Apache-2.0, BSD-3-Clause, CC0, Expat, GPL-3, public-domain Programming Lang: C, Assembler Description : library for quantum-safe cryptographic algorithms liboqs is an open source C library for quantum-safe cryptographic algorithms. It provides a collection of open source implementations of quantum-safe key encapsulation mechanism (KEM) and digital signature algorithms; a common API for these algorithms; a test harness and benchmarking routines. . liboqs is part of the Open Quantum Safe (OQS) project, which aims to develop and integrate into applications quantum-safe cryptography to facilitate deployment and testing in real world contexts. In particular, OQS provides prototype integrations of liboqs into TLS and SSH, through OpenSSL and OpenSSH. I would like to provide Quantum Safe algorithms for Debian usage and form a team of people that works enabling this in the project. This package is the first step, from my point of view, to get this enabled in the distribution. Thanks for watching!
Hi Hector, FYI, liboqs is already packaged for Debian. You are welcome to join its maintenance effort! Best, Andrius
Hello, El mar, 22 jul 2025 a las 11:00, Simon Josefsson (<simon@josefsson.org>) escribió: This was removed from unstable, see https://bugs.debian.org/1100144 Yes, that is great. I suggest we create a team and work on enabling this feature in the distribution for the forky release. Regards
Hi It is already in Debian: https://tracker.debian.org/pkg/liboqs I have an update here that could be reviewed and uploaded, I have talked to Adrian and Andrius about this - maybe with all of us helping we can finish it? https://salsa.debian.org/debian/liboqs /Simon
[...] liboqs already once was part of Debian/sid and was removed later. One of the major reasons was that upstream did not want to see liboqs shipped in a stable release (See https://github.com/orgs/open-quantum-safe/discussions/1625 ) GnuTLS has (temporarily, until nettle has PQ in a released version) switched to leancrypto from liboqs, have you looked at that? cu Andreas
Hector Oron <zumbi@debian.org> writes: How about updating that to the latest release, and make (say) the 'Debian Security Tools' the maintainer, with interested people as Uploaders? Hector, did you package 0.14.0 or did you just plan to do so? If you packaged 0.14.0 I could merge it into my git repo above, or something. /Simon
Hello Andreas, El mié, 23 jul 2025 a las 6:40, Andreas Metzler (<ametzler@bebt.de>) escribió: https://bugs.debian.org/1100144 I do still think we need to provide this package to start enabling PQC in the distribution, then consider if we want this in stable release or not. Many other distributions have this package available: https://repology.org/project/liboqs/versions In anycase, thanks for the discussion hyperlink, that is very interesting. Maybe leancrypto is a better way forward for enabling PQ, someone should look into this, it looks interesting. For reference, https://repology.org/project/leancrypto/versions Thanks for the information, very useful. One question, is there a clear way forward to enable PQ and keep compatible with others? Does it make sense to package everything until the path forward is more clear? Regards
Hello, El mié, 23 jul 2025 a las 12:56, Simon Josefsson (<simon@josefsson.org>) escribió: That's exactly what I wanted to do, I am not part of 'Debian Security Tools', and I am not sure if they want to take on the PQ burden, probably we should discuss with them if they want to take it, I won't have objections to that. Alternatively, we could create a 'Debian PQ task force' team to figure out how are we going to integrate this in the distribution. I have not yet worked on updating the package to 0.14.0, I was planning to do that, but then I thought it might be best to discuss how we move forward with this. Regards,
Hector Oron <zumbi@debian.org> writes: Sounds good! Please join the security group, it is simple I think. Proliferation of Debian maintainer groups seems like a hassle to me, and we are short number of interested people anyway.. /Simon
[...] Hello, Yes. liboqs ended up being unmaintained, lagging multiple upstream versions behind. I pondered adopting/rescueing it but refrained from doing so when I got the impression this might probably never be a candidate for Debian stable, i.e. it should always have lived in experimental instead of sid. cu Andreas
Andreas Metzler <ametzler@bebt.de> writes: Is it forbidden for packages to exist in unstable and/or experimental only in Debian? While liboqs is not intended for normal production use because of certain properties, it is useful for its designated purposes of experiments and testing. I think we somehow conflate these two, thinking that everything in a Debian stable release MUST be intended for secure production use. I think it is fine to ship things with known serious issues for certain use-cases, but perfectly good properties for other use-cases, as long as the limitations and use-cases are clearly documented. So to me having liboqs in a Debian stable release seems acceptable. It seems good that GnuTLS stopped using liboqs though, because GnuTLS _is_ intended for secure online usage whereas liboqs is not. /Simon
To me it sounds like perhaps it should be listed as explicitly unsupported from a security perspective? (How that works, I haven't looked into yet, but I know check-support-status from debian-security-support can find info about what is and isn't supported somehow, so I'm sure it can be done.)
To me it sounds like it shouldn't be in debian. We can't really build anything against it, so it's basically a curiosity/learning tool...and for that purpose the source is more useful and easily obtained elsewhere.
Who says we can't build anything against it though? Big, security-sensitive packages can't use it, but other programs might end up needing it in the future for non-security-sensitive things. Plus, "the source is more useful and easily obtained elsewhere" doesn't work when dependencies in a stable release of Debian may not be new enough to build the latest version of things. `sudo apt install liboqs-dev` is orders of magnitude easier than `git clone ...; # figure out the right version to check out, possibly by trial and error; # figure out the actually needed build dependencies, may need trial and error here too; configure; make`.
Anyone using common sense, IMO. A non-security-sensitive application that needs PQC vs existing widely available encryption algorithms? Do you have any plausible example of this? "Might maybe needs this someday" isn't very compelling. Do you have actual examples of applications which need to use an obsolete version of this (let's be honest, security sensitive) library which is declared to be unstable? And the concern is that the library will evolve to not build on stable debian, but the application will not? This smells a lot more like rationalizing than addressing practical concerns.
That isn't an argument. One easy plausible example would be a benchmarking application that tested quantum-resistant algorithms as part of the tests it ran (say Phoronix Test Suite, not that it does that now but it could some day). A communication application with experimental PQC support would be another example, and indeed if liboqs is intended to ever mature to something usable in a security-sensitive use case, it would make sense for people wanting to add PQC support to use liboqs now and then upgrade their PQC support to "not experimental" once the library was declared ready for security-sensitive use. This library in particular? No, but I've run into this situation with other software in the past, even in distros less stable than Debian. I don't really see how the concerns you're expressing are practical, they seem to be "I don't understand why anyone would use this". The only practical concerns I can see are archive size (haven't heard any concerns that the archive is getting to big so far) or maintainership burden (there's someone interested in maintaining it for now and the project doesn't look massive), and both of those concerns apply to every package in the archive. There are people actively interested in both packaging and using liboqs in this thread, if I'm understanding correctly, so "why would anyone use this" doesn't make sense as an argument to me.
A benchmarking application that doesn't exist and which happens to only use the version in debian stable? That seems pretty unlikely, no? Or use a different library, right? That's a lot of "maybe in the futures" which assume that this library will someday become essential. If the support is experimental and it's a *communication application*, we're not likely to ship in enabled in stable, right? So let's worry about it when it becomes a problem. We do have backports... No, the concerns are about shipping a *security sensitive library* in stable (so it needs to last for *years*) when the upstream specifically says not to do that. So far I haven't seen *any* strong reason to make that (IMO) really bad decision which would be biting us in 2030 or later.
The library is, by upstream's declaration, not security-sensitive, because it can't be used for security-sensitive purposes (yet). Yet it exists, and people want to use it. The only way this could come back to bite us is if developers foolishly make applications that are advertised as "post-quantum *secure*" but use liboqs for that security, despite upstream's warnings. If there's a demand for it now, I think the people interested in packaging and using it should be the arbiters of if it belongs or not. (It's not like I have any say here, I literally only said anything in this thread to bring up debian-security-support, and it turned into an argument.) If we're going to refuse to ship things that will break badly in a security-sensitive situation, why do we ship anything that's marked as not security supported in debian-security-support?
Hello Simon,
*I* think having packages only available in experimental is perfectly
fine. unstable is ditchy because iirc it has happened that our stopgap
measure to prevent testing migration (rc-bug) failed to work. Imho that
might work for leaf-packagages but not for libraries because it adds
another possibility for making errors. ("Gosh I did not realize my
package did not migrate to testing anymore because it picked up a dep on
a non-migratable package.")
[...]
Two things:
* Afaiui upstream would prefer we did not do that.
* I doubt that a multi-year old version of liboqs (which is what you'd
have in stable in a not too distant future) would be useful for
experiments and testing. liboqs is pretty fast moving. You would want
bleeding edge for experimenting.
cu Andreas
Andreas Metzler <ametzler@bebt.de> writes: Okay. Is the experimental buildd setup the same as for unstable? I recall that uploading to experimental built things differently that caused it to not be similar to uploading to unstable, triggering weird build errors. But maybe the buildd setup has evolved since then. That is a good reason to keep it out of stable, although we should qualify if they understood what they were asking for. Having it in stable to support experiment and testing seems to be in line with their stated goals. It seems more that they don't want it to be used for protecting sensitive data, which is a different request. My primary use-case for liboqs in stable is to setup interop testing between different PQ libraries and help development of PQ libraries. Having some OLD and stable release of liboqs widely available is what I would prefer. I want to test that some other PQ crypto libraries are able to interop with some old known-to-produce-correct-results liboqs. So there is no need for this liboqs to be able to protect sensitive data. It just have to produce something. Which seems to match what the liboqs maintainers says it is good for. /Simon
[...] Hello, If there is a stable release of liboqs this indeed makes sense. cu Andreas
Andreas Metzler <ametzler@bebt.de> writes:
In what way are the liboqs releases less stable than many other things
we accept into stable? The limitation seems to be:
WE DO NOT CURRENTLY RECOMMEND RELYING ON THIS LIBRARY IN A
PRODUCTION ENVIRONMENT OR TO PROTECT ANY SENSITIVE DATA. This
library is meant to help with research and prototyping. While we
make a best-effort approach to avoid security bugs, this library has
not received the level of auditing and analysis that would be
necessary to rely on it for high security use.
There are other things in stable with similar properties, which many
find useful because their field of interest is research and prototyping.
/Simon