XPost: linux.debian.bugs.dist
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.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)