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

Re: Stateless OpenPGP command-line interface for package management


Quoting Guillem Jover (2020-02-06 13:45:46)
> Daniel Kahn Gillmor (CCed) has been working on a proposal for a stateless
> OpenPGP command-line interface (that would ideally eventually be supported by
> all OpenPGP implementations), both RFC draft and reference implementation,
> and we had a chat some time ago on what might be the requirements from a
> package manager PoV, where I mentioned I'd bring it up on the dpkg and apt
> lists.

awesome! Thanks! :)

> I think that what we mostly need is:
>   * verification support for:
>     - multiple keyrings, mentioned explicitly as AFAIR there was talk
>       about dropping this from GnuPG (?) (already supported).
>     - inline signatures for .dsc, .changes, InRelease, etc
>       (planned with something lile detach-inband-signature-and-message?).
>     - unbundling inline signatures from their data, which could make it
>       possible to remove the OpenPGP signature ASCII armored parsing
>       code from dpkg-dev and apt, but this would come at the cost of
>       having to depend on such implementation, which would increase
>       the build-essential set. :/
>     - being able to warn about or reject specific weak constructs,
>       needed by apt, in the future by dpkg (not supported AFAICS).
>   * querying support for:
>     - getting the key ID matching a pattern in a keyring, needed by
>       debsig-verify to match on its policy (not supported AFAICS).
>     - getting the key ID used in a signature, needed by
>       debsig-verify to match on its policy (not supported AFAICS),
>     - getting the signature date (?), used by debsigs
>       (not supported AFAICS, seems just informational use).
>   * conversion support for:
>     - binary to ASCII armored signatures, f.ex. for upstream tarball
>       signatures (already supported).
>   * signing support for:
>     - specifying a key ID (not supported AFAICS?).
> These are off the top of my head, I might be missing more from apt's
> side though. But I think we'd all be very happy if we could stop
> having to parse --with-colons stuff, and having to deal with mixed metadata
> and data streamed out from GnuPG. :)

mmdebstrap is also doing the --with-colons stuff parsing, so I'm very
interested in this and wanted to add my two cents. What mmdebstrap basically
needs is an answer to the question:

   "I have a keyring I know that I want to use (like
   /usr/share/keyrings/ubuntu-archive-keyring.gpg) -- is the key material from
   that keyring fully included in the keys trusted by apt?"

Essentially I want to find out whether mmdebstrap should manually add the
keyring I know is the right one to the ones apt should trust or whether that's
not necessary because apt already trusts it.

So far mmdebstrap is setting up a new gpg --homedir and parses gpg
--with-colons to find out whether the fingerprints contained in the keyring I
want are also found in the keyrings apt trusts.

It would be nice if I would not need to setup a gpg home directory anymore and
not need to parse --with-colons anymore. I assume the functionality I need is
covered by the "querying support" part above?


cheers, josch

Attachment: signature.asc
Description: signature

Reply to: