On 2025-03-04 02.16, Daniel Kahn Gillmor wrote: > 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. [...]
Thanks for the insightful reply and for the link to the upstream bug: this is the kind of information I was looking for, and aligns well with what I was expecting. Cheers, Paride
