Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #118053 > unrolled thread

Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms

Back to article view | Back to linux.debian.devel

Contents

  Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms Hector Oron Martinez <zumbi@debian.org> - 2025-07-22 09:50 +0200
    Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms Andreas Metzler <ametzler@bebt.de> - 2025-07-23 06:50 +0200
      Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms Hector Oron <zumbi@debian.org> - 2025-07-23 13:10 +0200
        Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms Andreas Metzler <ametzler@bebt.de> - 2025-07-23 18:40 +0200
    Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms Simon Josefsson <simon@josefsson.org> - 2025-07-24 00:00 +0200
      Re: Bug#1109697: ITP: liboqs -- library for quantum-safe  cryptographic algorithms Simon McVittie <smcv@debian.org> - 2025-07-24 10:40 +0200
        Re: Bug#1109697: ITP: liboqs -- library for quantum-safe  cryptographic algorithms Chris Hofstaedtler <zeha@debian.org> - 2025-07-24 11:20 +0200
        Re: Bug#1109697: ITP: liboqs -- library for quantum-safe  cryptographic algorithms Simon Josefsson <simon@josefsson.org> - 2025-07-24 11:40 +0200
      Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms Andreas Metzler <ametzler@bebt.de> - 2025-07-24 19:20 +0200
        Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms Simon Josefsson <simon@josefsson.org> - 2025-07-25 10:20 +0200
          Re: Bug#1109697: ITP: liboqs -- library for quantum-safe  cryptographic algorithms Andreas Metzler <ametzler@bebt.de> - 2025-07-25 19:20 +0200
            Re: Bug#1109697: ITP: liboqs -- library for quantum-safe  cryptographic algorithms Simon Josefsson <simon@josefsson.org> - 2025-07-26 10:00 +0200
    Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms Michael Stone <mstone@debian.org> - 2025-07-24 01:20 +0200
    Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms Michael Stone <mstone@debian.org> - 2025-07-24 02:50 +0200
    Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms Michael Stone <mstone@debian.org> - 2025-07-24 03:40 +0200

#118053 — Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms

Package: wnpp
Severity: wishlist
Owner: Hector Oron Martinez <zumbi@debian.org>
X-Debbugs-Cc: debian-devel@lists.debian.org, jas@debian.org, merkys@debian.org, zumbi@debian.org, woohee9527@gmail.com

* 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!

[toc] | [next] | [standalone]

#118055

On 2025-07-22 Hector Oron Martinez <zumbi@debian.org> wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Hector Oron Martinez <zumbi@debian.org>
> X-Debbugs-Cc: debian-devel@lists.debian.org, jas@debian.org, merkys@debian.org, zumbi@debian.org, woohee9527@gmail.com

> * 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

[toc] | [prev] | [next] | [standalone]

#118065

Hello Andreas,

El mié, 23 jul 2025 a las 6:40, Andreas Metzler (<ametzler@bebt.de>) escribió:

> On 2025-07-22 Hector Oron Martinez <zumbi@debian.org> 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  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

[toc] | [prev] | [next] | [standalone]

#118071

On 2025-07-23 Hector Oron <zumbi@debian.org> wrote:
> El mié, 23 jul 2025 a las 6:40, Andreas Metzler (<ametzler@bebt.de>) escribió:

>> On 2025-07-22 Hector Oron Martinez <zumbi@debian.org> 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'

[toc] | [prev] | [next] | [standalone]

#118074

[Multipart message — attachments visible in raw view] — view raw

Andreas Metzler <ametzler@bebt.de> 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

[toc] | [prev] | [next] | [standalone]

#118092 — Re: Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms

On Wed, 23 Jul 2025 at 23:53:58 +0200, Simon Josefsson wrote:
>Is it forbidden for packages to exist in unstable and/or experimental
>only in Debian?

It is allowed. firefox (the non -esr version) and wine-development are 
examples of packages that exist only in unstable (with a RC bug to stop 
them from migrating to testing), while libsdl3-mixer and openjk are 
examples of packages that exist only in experimental.

Packages that exist in unstable will frequently be picked up by other 
distributions and included in their ostensibly stable releases, often 
automatically and often ignoring RC bugs (the most obvious example is 
Ubuntu universe, which automatically includes every package from Debian 
unstable at the time of Ubuntu's freeze unless specifically configured 
not to), so I would recommend experimental for this purpose.

>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.

Debian stable is exactly for production use, and software that is only 
suitable for experiments and testing seems out-of-scope for stable, at 
least to me. I think we could benefit from having a better place for 
software (especially leaf packages) that is compatible with stable, and 
intended to be used alongside stable, but is not, itself, stable; or 
perhaps that's already fasttrack.debian.net.

If a liboqs maintainer wants to make a trixie-compatible version of 
liboqs available, experimental + trixie-fasttrack would be one possible 
setup. That's what I'm intending to do for openjk, a game engine that 
has never had an upstream release and quite possibly never will.

     smcv

[toc] | [prev] | [next] | [standalone]

#118093 — Re: Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms

* Simon McVittie <smcv@debian.org> [250724 10:38]:
>On Wed, 23 Jul 2025 at 23:53:58 +0200, Simon Josefsson wrote:
>>Is it forbidden for packages to exist in unstable and/or experimental
>>only in Debian?
>
>It is allowed. firefox (the non -esr version) and wine-development are 
>examples of packages that exist only in unstable (with a RC bug to 
>stop them from migrating to testing), while libsdl3-mixer and openjk 
>are examples of packages that exist only in experimental.
>
>Packages that exist in unstable will frequently be picked up by other 
>distributions and included in their ostensibly stable releases, often 
>automatically and often ignoring RC bugs (the most obvious example is 
>Ubuntu universe, which automatically includes every package from 
>Debian unstable at the time of Ubuntu's freeze unless specifically 
>configured not to), so I would recommend experimental for this 
>purpose.

Also for Debian itself it is beneficial if such packages don't land 
in unstable. For one, it avoids other packages using them to build 
(when they then cannot migrate). And it keeps the QA list down.

Thanks,
Chris

[toc] | [prev] | [next] | [standalone]

#118094 — Re: Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms

[Multipart message — attachments visible in raw view] — view raw

Simon McVittie <smcv@debian.org> writes:

> On Wed, 23 Jul 2025 at 23:53:58 +0200, Simon Josefsson wrote:
>>Is it forbidden for packages to exist in unstable and/or experimental
>>only in Debian?
>
> It is allowed. firefox (the non -esr version) and wine-development are
> examples of packages that exist only in unstable (with a RC bug to
> stop them from migrating to testing), while libsdl3-mixer and openjk
> are examples of packages that exist only in experimental.

Thanks for confirming!  This aspect wasn't terribly clear to me. Is it
discussed in any policy document?

>>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.
>
> Debian stable is exactly for production use

There are plenty of things in debian stable clearly marked as unsuitable
for critical use - most of the Go and Rust ecosystems, but many other
packages too.  Or am I missing something?

Maybe it is the definition of "production use" that is what is at heart
here.  Production use of software X for user A may be completely frown
upon for user B because they have different use-cases in mind that it
doesn't meet desirable properties.  I don't think unsuitability for one
use-case is motivation enough to ban a package from stable and/or
unstable.

/Simon

[toc] | [prev] | [next] | [standalone]

#118098

On 2025-07-23 Simon Josefsson <simon@josefsson.org> wrote:
> Andreas Metzler <ametzler@bebt.de> 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'

[toc] | [prev] | [next] | [standalone]

#118101

[Multipart message — attachments visible in raw view] — view raw

Andreas Metzler <ametzler@bebt.de> 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

[toc] | [prev] | [next] | [standalone]

#118106 — Re: Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms

On 2025-07-25 Simon Josefsson <simon@josefsson.org> wrote:
> Andreas Metzler <ametzler@bebt.de> 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'

[toc] | [prev] | [next] | [standalone]

#118113 — Re: Bug#1109697: ITP: liboqs -- library for quantum-safe cryptographic algorithms

[Multipart message — attachments visible in raw view] — view raw

Andreas Metzler <ametzler@bebt.de> writes:

> On 2025-07-25 Simon Josefsson <simon@josefsson.org> wrote:
>> Andreas Metzler <ametzler@bebt.de> 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

[toc] | [prev] | [next] | [standalone]

#118076

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.

[toc] | [prev] | [next] | [standalone]

#118079

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.

[toc] | [prev] | [next] | [standalone]

#118081

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.devel

csiph-web