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

[Kerrick Staley]

On Mon, Jun 13, 2011 at 6:13 PM, Dan McGee <dpmcgee at gmail.com> wrote:
> I have objections on your way of going about business here. I present
> what i thought was a reasonable approach, got some feedback by Allan,
> and then you attempt to throw something completely different at us
> without really responding to what is wrong with my proposal.
>
> I'm trying my hardest to not get seen as a stick in the mud and
> impediment to progress here, but it is damn hard to keep my cool when
> my years of experience with this codebase gets shoved aside without so
> much as a "I don't think you considered this" bit of feedback. My
> ideas tend to be backed by those years of experience, and adding
> config options is not something we like to do willy-nilly, nor do we
> want a complicated config file.

Sorry. I often prefer to write in a very direct way (e.g. less
instances of "I think...", "I feel...", etc.), even when I really mean
to make a suggestion, because it is terser. I thought it was
appropriate in this situation because it's a feature I really want to
see implemented, and while "We should..." tends to generate a response
along the lines of either "yes" or "no, do this", "Should we..." tends
to generate a 20+ message thread. While this isn't a bad thing, I
thought it'd be better to just propose a fully-thought-out, workable
scheme from the start, so that it could be built off of. I spent
several hours devising this scheme and ensuring that it covers all
functionality that I thought would be useful, without requiring too
much configuration.

Anyway, I think my writing style is somewhat in poor taste; I'll try
to tone it down.

I feel like the config file syntax is mostly a trivial issue anyway;
it should fall into place once we have decided (a) which situations we
should handle specially, and (b) which actions can be taken in those
situations. I feel that having separate directives for each case would
be cleaner, but the "CheckLevel" syntax works as well, and since it's
a question of conventions, it's squarely your call (as is, ultimately,
everything else I suggest).

> > No marginal signatures should come up, because I don't think we should
> > use such signatures during the interim when not all developers have
> > fully validated keys; a developer's key can just be excluded from
> > pacman-keyring until it is fully validated.
> That is a pretty bold assumption. You do realize there are more repos
> out there that are not provided by a distro that people might want to
> use and have signatures involved, right?

OK, you're right.

> SigPreviouslySigned- an interesting thought, but definitely not
> something we need on first pass- there are also a multitude of issues
> here considering everyone starts from a different point.

Yeah, I wasn't even planning on implementing it at first; I just
thought it'd be something we wanted in the long term, so I put it in
among the rest.

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.

-Kerrick Staley