[pacman-dev] Package checking options (was: Changed all references to signature verification level in libalpm symbols to 'verifysig'.)

Rémy Oudompheng remyoudompheng at gmail.com
Tue Jun 14 02:26:27 EDT 2011


On Tue 14 June 2011 at 00:47 -0500, Kerrick Staley wrote:
> On Wed, Jun 1, 2011 at 3:46 PM, Dan McGee <dpmcgee at gmail.com> wrote:
> > I also think
> > we may need to be a bit more granular than our current
> > Always/Optional/Never trifecta. We have a multitude of possibilities
> > when checking a signature:
> >
> > * Valid signature, fully trusted (or ultimate,
> > (GPGME_VALIDITY_{ULTIMATE, FULL}).
> >
> > * Valid signature, unknown trust/unknown key (GPGME_VALIDITY_UNKNOWN,
> > GPGME_SIGSUM_KEY_MISSING).
> > * Valid signature, trust somewhere in between (marginal,
> > GPGME_VALIDITY_MARGINAL).
> >
> > * Valid signature, user is never valid (GPGME_VALIDITY_NEVER)
> > * Valid signature, signature is however expired (GPGME_SIGSUM_SIG_EXPIRED)
> > * Valid signature, key is however expired (GPGME_SIGSUM_KEY_EXPIRED)
> > * Bad signature, trust level is irrelevant (GPGME_VALIDITY_RED)
> 
> It seems that the first 3 in the last group are corner cases (I could
> not, for the life of me, find a real example of when
> GPGME_VALIDITY_NEVER would come up). For the middle two, having a
> signature with an unknown or nonexistent key doesn't really say
> anything about the validity of the package, so I think that outcome
> should just lumped in among the last 4. So, then, this boils down to
> "the signature is good", "the signature is bad", or "the signature is
> marginally trusted", but I think there are other cases (hashed,
> database unsigned) that should be considered.

I'm not sure about what you are saying: we have multiple axes:
- the signature is valid/invalid/expired/there is none
- the key is expired/has trust level X (where X can be any value,
  including "I absolutely hate that guy and swear I won't ever install
  any package signed by him")

So of course, formally we want to reduce this to a mere boolean value,
but people may want to configure how that happens.

Rémy.


More information about the pacman-dev mailing list