XPost: linux.debian.bugs.dist
From:
[email protected]
Hi!
On Wed, 2024-03-20 at 19:05:59 +0000, Steve McIntyre wrote:
On Wed, Dec 20, 2023 at 11:59:31PM +0100, Guillem Jover wrote:
On Wed, 2023-12-20 at 15:30:24 +0000, Steve McIntyre wrote:
Package: debsig-verify
Version: 0.23+b2
Severity: important
Tags: patch
Ouch, I've been increasingly unhappy with the whole policy thing,
because it was not functioning as documented, fixing it to do so has
broken multiple use cases, it seems like unnecessary complexity and in
a way trying to reimplement some of the checks that should be done by
the OpenPGP implementation, and it is getting in the way of adding
other OpenPGP backends due to the insistence of tying the signature
issuer fingerprint with the policy to apply, which means the primary >certificate fingerprint cannot be used as would perhaps be usually >expected.
Nod. To make everything work reliably here for all cases, we're now
making 4 copies of the policy directory for every key we might use,
using both the long keyid and the full fingerprint for each of the
master key and the signing subkey. Then we're including a keyring with
all of the keys in each of those policy directories. It's not
wonderful... :-/
Ugh. :/ I'd expect that if the keys are new-ish (and they have a
fingerprint packet), and the package providing the policy does not
need to cater to old debsig-verify packages then just using the
fingerprint path would be enough though? In any case yeah, this is
all very nasty.
I recorded part of this in the TODO, and I had in mind asking you
about how you use this as part of the redesign work, but I'll leave
that for a later point. :)
ACK. :-)
So, I'm curious...
Debsig-verify does seem to be really quite over-complicated, at least
for our use case. Wouldn't it be much simpler to just have a keyring
per origin, and then (maybe) a system config file to state which
origin(s) are needed. The policy definition files don't seem to add
any value here. IMHO.
I don't know what was the thinking in the original design and
implementation choices TBH, the only thing I can go by is the
specification and design documents from that time. AFAIR this was
designed before (or at a similar time) as the repo signing, so there
was probably not much experience in this area. And perhaps also to
be flexible for unexpected ways people could end up using this.
Also when pondering about how to redesign and simply this, my other
fear is that I've had zero visibility over how people are using this
(if at all) except four your invaluable input!
Currently my thinking is that multiple origins and the role-based
signing ideas are not bad, and that some kind of stacking would be
interesting to support, as you might want to sign .debs taken from
somewhere else, or to record the provenance steps where the packages
have gone through (but perhaps no one is using that for example, or
would ever do, dunno :).
As part of this redesign my main motivation would be to be able to
integrate this directly into dpkg-deb (so no new external libraries,
where in the past I even played with switching from XML to JSON, but
that's still unnecessary complexity and dependencies), and being able
to use SOP as the primary OpenPGP interface (probably also gpgv in
addition).
So from the TODO (slightly edited now):
* Redesign policies:
- Do not require XML.
- Do not require fetching the fingerprint for signatures and keys.
- Use the origin name as entry point, and role names to refer to keyrings.
- Use filesystem as policy declaration? For example:
<policy-dir>/keyrings/<vendor>/origin.pgp
<policy-dir>/keyrings/<vendor>/role-maint.pgp
<policy-dir>/keyrings/<vendor>/role-uploader.pgp
<policy-dir>/keyrings/<vendor>/role-builder.pgp
- Use a deb822 file for a policy file to denote optional/required/reject?
I'm not even sure we might need a deb822 file, perhaps if that part is needed/wanted at all it could even be a few text files with just one
line each containing a fingerprint. Say:
<policy-dir>/keyrings/<vendor>/policy/optional
<policy-dir>/keyrings/<vendor>/policy/reject
<policy-dir>/keyrings/<vendor>/policy/required
or similar. And then the match would be based on the vendor, not the fingerprint, which then should make key rotation, and the OpenPGP
verification (even using SOP) easier to implement, to deploy and to
reason about, I think.
It would also be lovely if the design was less restricted by
GnuPG. (Yes, I know!) A real problem for me is that debsig-verify
wants to see *every* signature accounted for when verifying a
package. This is opposite to the behaviour of gpgv, which is more like
what we were inititally expecting / hoping for. We're signing packages
with a rolling range of N keys for our releases, similar to Debian's Release.gpg setup, and now we have to include 4*N policy directories
for debsig-verify, and our keyring files all have to include *all* the
keys.
Yes, the current policy seems all backwards to me too.
So, I'd be tempted by something easier to follow:
* config to say which keyring(s) to use, and (maybe) some config to
say "need minimum N valid sigs"
I think the above would cover part of this. I guess for the minimum
valid sigs we could add a new file (or config option if going for a
simple config file, or a deb822 policy file or similar). Say:
<policy-dir>/keyrings/<vendor>/policy/min-signatures
containing say "3", or whatever.
* keyring(s) including key(s)
* when validating signatures, verify each of them individually rather
than expecting GnuPG to DTRT. I think we both know how well that
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)