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