Control: forwarded 1001330 https://gitlab.com/dkg/openpgp-stateless-cli/-/issues/42
Hi Paride-- On Mon 2025-02-17 22:35:38 +0100, Paride Legovini wrote: > Any news on this? I'd like to port a tool to the stateless interface, > but not having sop available under its standard name is discouraging. Thanks for the interest! I agree that not having a standard /usr/bin/sop is a bit disappointing for a dependent set of tools, but there are other options available. For example, you could build your package against some specific "sop" (e.g. "sqop" or "pgpainless-cli" or "rsop" or "gosop", all of which are available in debian already), and let your user decide via a configuration choice if they want to use another implementation. Furthermore, when a /usr/bin/sop alias *does* become available, it should be fairly easy to replace the single spot in your code where your default choice of "sop" is set by default. > Would reviewing/applying Guillem's patch and uploading rust-sequoia-sop > with the sop alternative be welcome work? The reasons that i haven't adopted these patches yet are documented in the upstream bug report at https://gitlab.com/dkg/openpgp-stateless-cli/-/issues/42 -- i'm concerned because there isn't yet a clear way to ensure that the various subcommands are all implemented, and that any updated changes in new versions of the sop specification have been taken into account by any given implementation. The `sopv` verification-only subset is much narrower, and has a proper versioning scheme that makes it capable to do this kind of thing, and for the moment, we're advancing that via the "alternatives" system in debian to see whether we can make it work cleanly. So, an application like smartmontools, which currently has a dependency on gpg but only for verifying OpenPGP signatures in /usr/sbin/update-smart-drivedb should be relatively easy to switch to the generic sopv. But a more sophisticated tool (for example, a MUA or other encrypted messenger) should probably not depend directly on /usr/bin/sop in debian at the moment. --dkg PS let me take an additional plug here for reporting issues with the sop specification itself, if you are a *consumer* of the sop interface. Most of the issues reported on the sop issue tracker (https://gitlab.com/dkg/openpgp-stateless-cli/-/issues) come from sop implementers or other standardizers, and are focused on things like the OpenPGP interoperability test suite (https://tests.sequoia-pgp.org/). Guillem and a few other potential application developers who need an OpenPGP interface have offered feedback about what works for them, and what else they feel like is missing; i would welcome more engagement from developer who want to consume the sop interface, even if they can't consume it as /usr/bin/sop at the moment!
signature.asc
Description: PGP signature
