On Wed, Jul 23, 2025 at 8:31 PM Michael Stone <mst...@debian.org> 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?
