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

Re: Stateless OpenPGP command-line interface for package management

On Thu, Feb 06, 2020 at 01:45:46PM +0100, Guillem Jover wrote:
> 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

(a bit early for my long awaited birthday present, but I am not
complaining – means I at least can stop thinking about going full NIH
and further generalize apt wrapper(s) around gpg(v) and becoming (more)
insane in the process…)

> I think that what we mostly need is:
>     - inline signatures for .dsc, .changes, InRelease, etc
>       (planned with something lile detach-inband-signature-and-message?).

and of course detached (Release + Release.gpg) – apt internally splits
InRelease into a Release and Release.gpg pair and hands this off to gpgv
to have one less codepath.

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

As apt would need that at runtime it is also a promotion to installed by
default on every Debian system (with the assumption that apt is on every
Debian system).

We would probably need a non-python implementation for that.

>     - being able to warn about or reject specific weak constructs,
>       needed by apt, in the future by dpkg (not supported AFAICS).

apt e.g. started to decline SHA1 well before upstream did. Every
rejection should ideally have a --its-okay flag though as it is a bit
sad that with every improvement we loose access to historic data.

At the moment it is just too hard, but ideally I would like apt to have
the option to say "I know its SHA1 and the key is expired, but download
the data anyhow" without giving in and just disabling every check.

>   * 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),

apt would like to know the same for the whole Signed-By and related
things (which does both by keyring file and by key fringerprint).
apt would "just" need fingerprint instead of "key ID" here though.

Sort of the reverse would be interesting to be able to drop apt-key
for the more niece usecases of "which keys are included in keyring(s)"
and "which keyring includes key with ID". As these queries tend to be
done by users allowing more than just fingerprint would be good but
hardly mission critical.

>   * signing support for:
>     - specifying a key ID (not supported AFAICS?).

while apt itself doesn't use it, our tests do lots of signing. So
signing with expired keys, weak hashes and stuff should ideally not be
too hard. Convincing gnupg to do it is… fun.

Proper support for clearsigning with multiple keys [0] might be helpful
for ftpmasters/dak as that used to be one problem in providing InRelease
for stable releases.

[0] https://lists.gnupg.org/pipermail/gnupg-users/2013-July/047118.html

Apart from ftpmasters/dak, I guess (c)debootstrap maintainers might be
interested as well (as they sort-of reimplement apt they have the
same big problem of "verifying Release" and with same (or worse)
requirement of the least external dependencies possible).

I fear though that we will find at least one user for every feature
gnupg currently has, but wrapped in an interface which doesn't lend
itself very well to automation and/or additional wrapping.
So this could end up being a colossal undertaking…

Best regards

David Kalnischkies

Attachment: signature.asc
Description: PGP signature

Reply to: