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
> works *grin*. If enough valid sigs are detected, we're good. If
> not, fail.
Do you mean that for each signature in the selected keyring (based on
the vendor, not the fingerprint), we'd export each one individually and
then verify the .deb against that? I mean if we want to support a
minimum-signatures then I guess that's what we'd need to do because
gpgv does not seem to support that. sq for example does with its
--signatures option, but SOP does not either.
I'm also pondering now whether instead of a keyring it might be easier
to manage and to implement to use a directory to hold all the
signatures, say:
<policy-dir>/keyrings/<vendor>/origin/fingerprint-a.pgp
<policy-dir>/keyrings/<vendor>/origin/fingerprint-b.pgp
<policy-dir>/keyrings/<vendor>/role-builder/fingerprint-c.pgp
<policy-dir>/keyrings/<vendor>/role-builder/fingerprint-d.pgp
Or perhaps better just by some name to avoid potential reliance on
fingerprint formats that might change with OpenPGP spec revisions,
say:
<policy-dir>/keyrings/<vendor>/origin/archive-auto.pgp
<policy-dir>/keyrings/<vendor>/origin/archive-2022.pgp
<policy-dir>/keyrings/<vendor>/role-builder/builder-a.pgp
<policy-dir>/keyrings/<vendor>/role-builder/builder-b.pgp
Or perhaps the min-signatures could then become min number of
verifications from these named keyrings.
> Does that sound reasonable? What am I missing?
Overall it does, but as mentioned before, it's hard for me to tell
what's missing from the silent users. :)
I guess I'll collect my thoughts, and your input and will try to draft
something and ask for wider input from the list.
Thanks,
Guillem
