[pacman-dev] SigLevel options redux

[Kerrick Staley]

Sounds good; thank you very much for working on this.

-Kerrick Staley
On Jul 28, 2011 4:53 PM, "Dan McGee" <dpmcgee at gmail.com> wrote:
> So this is a bit messy. My last patch gets us close to what we need,
> but turns out, I didn't fully understand what the ramifications of my
> options were in the last patch here:
> http://mailman.archlinux.org/pipermail/pacman-dev/2011-July/013856.html
>
> * The Package/Database/(implicit all) stuff is fine.
> * The optional/required stuff is fine (for the most part).
> * Not so great is the marginal and unknown OK stuff.
>
> Basically, there are three facets to every signature that we can examine.
>
> * Validity: Is this signature signing the data it says it is? This is
> basically three-valued- good, bad, or unknown. In GPGME, the unknown
> case comes up if we don't have a copy of the public key in our
> keyring, for instance.
> * Trust: Do we trust this key? Note that this is very different than
> the above "is this signature valid" question. This brings in the whole
> web of trust business, the blackhole discussions regarding CACert,
> signing each other's keys, etc.
> * "Timeliness" (not sure what to call it): aka is this signature
> expired, key expired, or key revoked.
>
> So the important fact that my prior implementation did not handle
> above was the missing public key. I'm thinking we should not allow for
> this case, and attempt to tell the user to import the key (or prompt
> them to do so, or something). Regarding "Optional" signature level, if
> we find a sig, we should not proceed if we cannot verify.
>
> As far as options go, here is what is likely worth providing:
> * Validity- nothing. The signature has to be good if it exists,
> nothing else is valid.
> * Trust- nix what we had before. I think just one coarse-grained
> option would be good here, and that is 'AlwaysTrustworthy' (naming
> suggestions welcome if that isn't clear, came from gpgv man page).
> This would replace the AllowMarginal/AllowUnknown options and
> basically cover the bases of both. With this option, we will trust
> every key *except* those marked "never trust"; without it the web of
> trust will kick in and the key will need to have a certain level of
> trust that way. This basically replicates what the stripped-down gpgv
> does.
> * Timeliness- I'm not totally sure what to do here. Maybe we shouldn't
> even worry about this yet, and go with reasonably sane defaults:
> - expired signature: don't allow. Since sigs have infinite lifetime
> by default, there is probably a good reason to not allow one that has
> gone sour.
> - expired key: allow it (as long as the above expired sig case
> doesn't apply too). Many keys are created with expiration dates, but
> this doesn't make valid signatures created with them immediately
> invalid.
> - revoked key: obviously don't allow it.
>
> Thoughts? I'm just going to go ahead with this scheme unless I hear
> vastly different ideas on this.
>
> -Dan
>