On Mon 2025-06-02 19:15:01 +0100, Simon McVittie wrote: > Sure, but unfortunately we don't live in an ideal world, and we're > unlikely to arrive in one before the trixie release!
agreed, hence the patch ;) I'd love to hear suggestions for what next steps you think we need to get closer to the ideal world post release! >>In the long run, it would be nice to not hard-code this specific >>preference list, and just let the system default OpenPGP verifier work >>as planned. > > What is "the system default OpenPGP verifier"? Is that a > yet-to-be-designed mechanism, or some sort of default-sopv virtual > package or metapackage, or what? i'd expect the system default OpenPGP verifier to be whatever package Provides: sopv, and is pointed to by sopv in the default $PATH. At the moment, that's an update-alternatives question. Guillem and I have had a lengthy conversation [0] about possible other ways of doing it, which haven't really resolved into anything beyond what's in place today. [0] https://gitlab.com/dkg/openpgp-stateless-cli/-/issues/42 I'd love to get more feedback on what you (and others) think a stable and simple way to have that be a stock choice for debian. >>For OpenPGP signature verification, prefer specific implementations of >>the Stateless OpenPGP Verification subset rather than just the generic >>"sopv" variant. > ... >>+ sqopv | rsopv | gosop | sopv | gpgv, > > Thanks, this answers the question I wanted to ask on behalf of my Debian > derivative: "which sopv implementation should we prefer to work around > this?" -> sqopv. i don't personally have a strong preference among the three listed implementations. I've tested them all personally and i found them reasonable both in terms of performance and robustness; and they all perform well on the OpenPGP Interoperability Test Suite [0]. I chose the order here following Holger's listing, really. [0] https://tests.sequoia-pgp.org/ > But, is there a reason why the less-preferred (non-sqopv) > implementations need to be listed explicitly? If they can be dropped > from the or-group, then that would mitigate your maintenance concerns. I agree we could remove them, probably without any functional difference. Similarly, we could choose either of the other two as that primary placement and it would also be fine on all release architectures. > sqopv seems to exist on all release architectures, and on all -ports > architectures that have a working rustc/cargo. Even if we're assuming > that non-Rust -ports architectures are important, the the minimum to get > a predictable installation would be to list some real package that > exists on those architectures as higher-preference than (i.e. before) > the sopv virtual package, like maybe: > > sqopv # real package, but not on all architectures > | gpgv # real package, portable fallback > | sopv # virtual package I think this order would be a mistake. We should prefer sopv over gpgv, because the sopv semantics and interface are deliberately minimalist, stable, and well-understood. gpgv has corner cases that make it challenging to use in situations where OpenPGP might evolve (e.g., it fails when it sees a signature that it doesn't understand, even if that signature is coupled with a signature it *does* understand; and, its ability to select which OpenPGP certificate to trust can't cope with armored certificates; and, the way that you identify certificates has idiosyncratic rules that don't follow standard unix conventions; and, it deliberately doesn't implement the latest version of OpenPGP). Please list gpgv *after* sopv. I say this as one of the co-maintainers of the GnuPG suite in debian. If anything, i would recommend dropping support for gpgv from devscripts. It will still be usable in normalized form with sopv-gpgv for those people who really want that to be their system OpenPGP verifier. And there will be less code to maintain in devscripts. > (Or, perhaps more realistically, if we get a default-sopv metapackage or > virtual package in forky, then that would replace sqopv.) That's an interesting proposal, and i'd be happy to work through the details there and make it happen after the trixie release. --dkg
signature.asc
Description: PGP signature
