[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Regarding ideas to replace gpgv with sqv

Hi everyone,

On Thu, 28 Jan 2021 11:15:18 +0100,
Julian Andres Klode wrote:
> Today I received a private email suggesting some people want to replace
> the use of gpgv in apt with sqv.
> In the spirit of social contract's "We will not hide problems", I hereby
> disclose my response to that idea and the issues with it:

It wasn't my intent to exclude anyone.  My hope was to first
informally chat about this with a core dev to see if there is even any
interest in the idea, and to get some suggestions on how to start the
discussion with the broader community thereby improving the
signal-to-noise ratio on any public forums.  Normally, I'd try to do
that at someplace like FOSDEM.  But, that's obviously not possible
right now.

> I do not want to replace gpgv with sqv, but rather directly link to
> sequioa from the C++ code.

The idea for sqv originated from dkg in this bug report:


As I understand it, dkg approached the gpg developers about various
improvements to gpgv's interface, which he thought would be useful to
Debian, but the gpg developers responded that gpgv's API is frozen.
Hence his request to the hopenpgp developers to create a better tool.

Using Sequoia directly from C++ should not be a problem.  We have a C
FFI, which is reasonably complete, and we'll be happy to add any
missing bindings, which you need.


In practice, we've found that it is easier and compacter to develop a
shim that implements the required high-level functionality in Rust,
and then use that from the application.  Here's a nice example:


> Because the whole external parsing business
> is meh, and I also want to have further insight into which keys are in
> which files to be able to display nice information about repositories
> and which key files sign them and to be able to notify you if the
> repository is signed by a different key file suddenly.


> However, there are two issues at hand:
> 1) Rust is not widely available, it's only around half of the
>    architectures apt needs to work on.
>    It's missing support for alpha, hppa, hurd-i386, ia64, kfreebsd-i386,
>    kfreebsd-amd64, m68k, ppc64, sh4, and x32.

As a former DD working on Hurd, I sympathize.  (For the record, I
think Debian actually supports rust on ppc64.  At least rustc appears
to be available on ppc64.  Of course, your point stands.)

> 2) I'm not convinced I'll be able to get it into Ubuntu, as I'm not sure
>    the security team there would be interested in security supporting it.
>    Currently, we only have Rust in Ubuntu to the extend needed to build
>    Firefox.
> Analysis:
> 1) means that the gpgv code will need to stay around and these ports
>    will use completely different verification code paths. I'm not sure I
>    want to maintain 2 code paths.
> 2) is the major blocker. We will not have two separate code paths for
>    stable Ubuntu and Debian releases.

There is possibly another way forward: use SOP.  SOP stands for
"Stateless OpenPGP."  dkg designed it to be a general-purpose,
OpenPGP-implementation agnostic API.  Thus, if a program targets SOP,
each user can choose their preferred OpenPGP implementation.  You can
read about it here:


The current I-D describes a command-line interface.  However, dkg and
justus (cc'd) have started working on a C API.  Some of the discussion
on that work is documented here:


If apt were to use SOP, you'd only have to maintain a single code
path, but different distributions and different architectures could
still use their preferred OpenPGP backend.

FWIW, the OpenPGP interoperability test suite, which tests 7 different
OpenPGP implementations, tests the implmentations via a SOP frontend:


If there were a C API, we'd probably switch to it, so any SOP
implementation automatically has a large test suite.

:) Neal

Reply to: