Bug#1001330: sqop: Provide a sop alternative for sqop

[Guillem Jover]

Package: sqop
Version: 0.22.2-2
Severity: wishlist

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

[Guillem Jover]

Control: tag -1 patch

Hi!

Post by Guillem Jover
Package: sqop
Version: 0.22.2-2
Severity: wishlist
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 :)?

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

[Paride Legovini]

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

Post by Guillem Jover
interface, which means having to hardcode specific implementations in
code kind of defeats the point of that interface.

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?

--
Paride

[Paride Legovini]

Post by Paride Legovini

Post by Guillem Jover
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.

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

[Daniel Kahn Gillmor]

Control: forwarded 1001330 https://gitlab.com/dkg/openpgp-stateless-cli/-/issues/42

Hi Paride--

Post by Paride Legovini
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.

Post by Paride Legovini
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!

[Paride Legovini]

Post by Daniel Kahn Gillmor
Control: forwarded 1001330 https://gitlab.com/dkg/openpgp-stateless-cli/-/issues/42
Hi Paride--

Post by Paride Legovini
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.

Post by Paride Legovini
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