Re: Regarding ideas to replace gpgv with sqv
On Sun, Jan 31, 2021 at 02:01:02PM +0100, Neal H. Walfield wrote:
> On Thu, 28 Jan 2021 11:15:18 +0100,
> Julian Andres Klode wrote:
> > 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:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872271
>
> 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.
I generally don't consider calling an external program from a library to
be the correct way around :)
>
>
> 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.
>
> https://docs.sequoia-pgp.org/sequoia_ffi/index.html
Yeah, I know.
>
> 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:
>
> https://gitlab.com/wiktor-k/rust-php-bindings-example
Possibly.
>
> > 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.)
Yes, to some extend, but sequioa is not built yet.
https://buildd.debian.org/status/package.php?p=rust-sequoia-openpgp
because librust-backtrace FTBFS.
I don't care about these ports as we don't need to provide security support
for them, so well, so keeping frozen gpgv code paths around would work
(heck, they'll still get updated anyway, but no need to rush out updates
for stable releases in like 8 years or so when the existing stable
releases have all EOLed).
>
> > 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:
>
> https://datatracker.ietf.org/doc/html/draft-dkg-openpgp-stateless-cli-02
>
> 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:
>
> https://gitlab.com/dkg/openpgp-stateless-cli/-/issues/32
>
> 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.
Different backends have different bugs, so we do want to use the same
backends across major distros to ensure that we all see the same bugs.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Reply to: