Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms
Andreas Metzler writes: > On 2025-07-25 Simon Josefsson wrote: >> Andreas Metzler writes: > [...] > >> > * 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. > >> 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. > > Hello, > > If there is a stable release of liboqs this indeed makes sense. 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 signature.asc Description: PGP signature
Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms
On 2025-07-25 Simon Josefsson wrote: > Andreas Metzler writes: [...] > > * 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. > 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. Hello, If there is a stable release of liboqs this indeed makes sense. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms
Andreas Metzler writes:
>> Is it forbidden for packages to exist in unstable and/or experimental
>> only in Debian?
>
> 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.")
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.
>> 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.
> [...]
> Two things:
> * Afaiui upstream would prefer we did not do that.
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.
> * 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.
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
signature.asc
Description: PGP signature
Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms
On 2025-07-23 Simon Josefsson wrote:
> Andreas Metzler writes:
>>> The documented reason for removal from unstable was a FTBFS
>>> https://bugs.debian.org/1100144
>> [...]
>> 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.
> Is it forbidden for packages to exist in unstable and/or experimental
> only in Debian?
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.")
> 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.
[...]
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
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms
On Wed, Jul 23, 2025 at 8:31 PM Michael Stone wrote: > > On Wed, Jul 23, 2025 at 08:05:48PM -0500, Aaron Rainbolt wrote: > >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 benchmarking application that doesn't exist and which happens to only > use the version in debian stable? That seems pretty unlikely, no? > > >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. > > 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? > > >> 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. > > > >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. > > So let's worry about it when it becomes a problem. We do have > backports... > > >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. > > 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?
Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms
On Wed, Jul 23, 2025 at 08:05:48PM -0500, Aaron Rainbolt wrote: 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 benchmarking application that doesn't exist and which happens to only use the version in debian stable? That seems pretty unlikely, no? 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. 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? 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. 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. So let's worry about it when it becomes a problem. We do have backports... 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. 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.
Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms
On Wed, Jul 23, 2025 at 7:42 PM Michael Stone wrote: > > On Wed, Jul 23, 2025 at 06:40:39PM -0500, Aaron Rainbolt wrote: > >Who says we can't build anything against it though? > > Anyone using common sense, IMO. That isn't an argument. > >Big, security-sensitive packages can't use it, but other programs might > >end up needing it in the future for non-security-sensitive things. > > 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. 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. > >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`. > > 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. 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.
Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms
On Wed, Jul 23, 2025 at 06:40:39PM -0500, Aaron Rainbolt wrote: Who says we can't build anything against it though? Anyone using common sense, IMO. Big, security-sensitive packages can't use it, but other programs might end up needing it in the future for non-security-sensitive things. 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. 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`. 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.
Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms
On Wed, Jul 23, 2025 at 6:15 PM Michael Stone wrote: > > On Wed, Jul 23, 2025 at 05:57:11PM -0500, Aaron Rainbolt wrote: > >To me it sounds like perhaps it should be listed as explicitly > >unsupported from a security perspective? > > 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`.
Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms
On Wed, Jul 23, 2025 at 05:57:11PM -0500, Aaron Rainbolt wrote: To me it sounds like perhaps it should be listed as explicitly unsupported from a security perspective? 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.
Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms
On Wed, Jul 23, 2025 at 5:20 PM Simon Josefsson wrote: > > Andreas Metzler writes: > > >> The documented reason for removal from unstable was a FTBFS > >> https://bugs.debian.org/1100144 > > [...] > > > > 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. > > 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. 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.) > It seems good that GnuTLS stopped using liboqs though, because GnuTLS > _is_ intended for secure online usage whereas liboqs is not. > > /Simon
Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms
Andreas Metzler writes: >> The documented reason for removal from unstable was a FTBFS >> https://bugs.debian.org/1100144 > [...] > > 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. 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 signature.asc Description: PGP signature
Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms
On 2025-07-23 Hector Oron wrote: > El mié, 23 jul 2025 a las 6:40, Andreas Metzler () escribió: >> On 2025-07-22 Hector Oron Martinez wrote: >>> I would like to provide Quantum Safe algorithms for Debian usage and >>> form a team of people that works enabling this in the project. >> 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 ) > The documented reason for removal from unstable was a FTBFS > https://bugs.debian.org/1100144 [...] 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 -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms
Hector Oron writes: > Hello, > > El mié, 23 jul 2025 a las 12:56, Simon Josefsson > () escribió: > >> How about updating that to the latest release, and make (say) the >> 'Debian Security Tools' the maintainer, with interested people as >> Uploaders? > > 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. > >> 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. > > 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. 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 signature.asc Description: PGP signature
Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms
Hello, El mié, 23 jul 2025 a las 12:56, Simon Josefsson () escribió: > How about updating that to the latest release, and make (say) the > 'Debian Security Tools' the maintainer, with interested people as > Uploaders? 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. > 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. 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, -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms
Hello Andreas, El mié, 23 jul 2025 a las 6:40, Andreas Metzler () escribió: > On 2025-07-22 Hector Oron Martinez wrote: > > I would like to provide Quantum Safe algorithms for Debian usage and > > form a team of people that works enabling this in the project. > 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 ) The documented reason for removal from unstable was a FTBFS 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. > GnuTLS has (temporarily, until nettle has PQ in a released version) > switched to leancrypto from liboqs, have you looked at that? 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 -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms
Hector Oron writes: >> 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 > > Yes, that is great. I suggest we create a team and work on enabling > this feature in the distribution for the forky release. 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 signature.asc Description: PGP signature
Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms
On 2025-07-22 Hector Oron Martinez wrote: > Package: wnpp > Severity: wishlist > Owner: Hector Oron Martinez > X-Debbugs-Cc: [email protected], [email protected], > [email protected], [email protected], [email protected] > * Package name: liboqs > Version : 0.14.0 [...] > 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. 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
Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms
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 > 22 juli 2025 kl. 09:42 skrev Hector Oron Martinez : > Package: wnpp > Severity: wishlist > Owner: Hector Oron Martinez > X-Debbugs-Cc: [email protected], [email protected], > [email protected], [email protected], [email protected] > > * 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!
Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms
Hello, El mar, 22 jul 2025 a las 11:00, Simon Josefsson () escribió: > It is already in Debian: > https://tracker.debian.org/pkg/liboqs This was removed from unstable, see https://bugs.debian.org/1100144 > 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 Yes, that is great. I suggest we create a team and work on enabling this feature in the distribution for the forky release. Regards
Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms
Hi Hector, On Tue, 22 Jul 2025, 10:43 Hector Oron Martinez, wrote: > 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! > FYI, liboqs is already packaged for Debian. You are welcome to join its maintenance effort! Best, Andrius >
Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms
Package: wnpp Severity: wishlist Owner: Hector Oron Martinez X-Debbugs-Cc: [email protected], [email protected], [email protected], [email protected], [email protected] * 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!
