Hi!

One of the main advantages of the SOP CLI is that it is a standardized
interface, which means having to hardcode specific implementations in
code kind of defeats the point of that interface. It would be nice to
be able to by default just use «sop» and use that interface behind
an alternative (in the dpkg alternatives system), then the local admin
can select any of the existing implementations. I'm not sure how you'd
want to decide on the priority of the alternatives though, perhaps at
least by level of compliance (although I don't mind greatly TBH :)?

Thanks,
Guillem

Hi!

I've implemented a proposal for this in the attached patch. It also
adds a «sop» virtual package (or at least pretends to, did not run any
debcargo command) so that other packages can depend on any
implementation of the interface.

I initially included alternatives also for the completion but I don't
think they support the «sop» name anyway (at least the bash and fish
ones), and I don't think they can act in a polymorphic way depending
on the file they have been loaded from either.

The currently proposed patch would not make it possible to easily
denote a default implementation though, so perhaps you'd prefer two
sets of virtual packages, one for the current default, and one for
any implementation. Or another option could be to introduce a real
«sop» package (which then could provide its own command completion
files too :), perhaps the spec, etc, and depend first on the preferred
implementation and the virtual package for any sop implementation such
as «sqop | sop-impl» or whatever. The drawback with the real package
approach is that it requires this artificial metapackage.

I think this would also deserve filing a request for an addition to
the Debian policy virtual-package list for coordination with other
potential SOP implementations, once the layout is settled.

Thanks,
Guillem

On Wed, 8 Dec 2021 Guillem Jover <guillem@debian.org> wrote:> One of the
main advantages of the SOP CLI is that it is a standardized

I was also surprised by the lack of a sop alternative, especially given
that sqopv provides a sopv alternative.

Maybe the idea is to wait for the IETF sop standard to be accepted
before starting to ship sop?

Hi Daniel and other maintainers,

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.

Would reviewing/applying Guillem's patch and uploading rust-sequoia-sop
with the sop alternative be welcome work?

Thanks!

Paride

Hi Paride--

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.

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.

[...]

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