Andreas Metzler <ametz...@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
signature.asc
Description: PGP signature
