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

Re: Regarding ideas to replace gpgv with sqv

On Thu, Jan 28, 2021 at 11:15:18AM +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:
> I do not want to replace gpgv with sqv, but rather directly link to
> sequioa from the C++ code. 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.

Features why I want a library:

- I want to notify users when the keyring that signs a repo changed

- I want to block repositories from switching the keyring they sign
  with (they need to sign with both old and new keys for transitional
  periods). This ties repos to keyring files while avoding the need for
  any signed-by

- I want to provide a command to list the keys in the keyring and which
  repo is signed by which, including a machine-readable output format

> 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.
> 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.

This would add about 140 packages to Ubuntu main, which seems excessive,
and probably is not going to fly - it's a 2% increase in packages to
provide security support for.

I think overall, atm the problems outweight the benefits. If Rust were more
portable or we drop most of the ports, and we could lose like let's say
a 120 dependencies from the library, that would make things a lot easier,
but I'm not holding my breath.

debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en

Reply to: