[pacman-dev] [PATCH 4/4] signing: move to new signing verification and return scheme

[Dan McGee]

On Mon, Jun 27, 2011 at 7:58 PM, Allan McRae <allan at archlinux.org> wrote:
> On 28/06/11 07:39, Dan McGee wrote:
>>
>> This gives us more granularity than the former Never/Optional/Always
>> trifecta. The frontend still uses these values temporarily but that will
>> be changed in a future patch.
>>
>> * Use 'siglevel' consistenly in method names, 'level' as variable name
>> * The level becomes an enum bitmask value for flexibility
>> * Signature check methods now return a status code rather than a simple
>>   integer success/failure value. This allows callers to determine
>>   whether things such as an unknown signature are valid.
>> * Specific signature error codes mostly disappear in favor of the above
>>   returned status code; pm_errno is now set only to PKG_INVALID_SIG or
>>   DB_INVALID_SIG as appropriate.
>>
>> Signed-off-by: Dan McGee<dan at archlinux.org>
>> ---
>>
>> This is still a slight WIP, but mostly finished. Thoughts? I think this
>> gives
>> us the flexibility we need to verify everything we need to, as well as
>> allow
>> frontend validation and useful display of what we found via -Qip with the
>> return code business.
>
> Looks good to me.  The patch was far less scary to review that I thought it
> was going to be given the size!  This definitely looks like it has all the
> flexibility we need now.

That is good to hear- both the non-scary and the agreement on
flexibility. It means we're getting really close. A lot of the
diffstat here was just replacing enum constants as necessary and the
variable/function renames, so some diffstat churn is to be expected.
Nothing terribly complicated or brand new though.

>> Outstanding issues:
>> * Need to correctly handle the UNKNOWN_OK and MARGINAL_OK flags.
>> * Need to handle multiple sigs. Right now the last one wins; should the
>> return
>>   type be an alpm_list_t instead? Or better yet, an array of enum values
>> with
>>   the size returned in a passed parameter, which would be much more light
>>   weight than the whole linked list.
>
> I was thinking that multiple sigs should be a case of return the worst case
> scenario.  i.e. if two pass and one fail, then it is a fail.  But I suppose
> we would want access to the information of which sigs passed/failed etc for
> frontends to access and display.  The array of enums sounds fine.

I was leaning toward this too, but thinking that we shouldn't limit
the frontends to only what we plan on doing. With that said, the
frontend is going to get a signature status but no real identifier to
what key it was signed with in this current scheme...I'll take a look
at how easy that is to accomplish.

On a side note, if you want to test something signed with two keys, go and
1) grab a package and a sig file off a mirror
2) move the sig file somewhere else temporarily so it doesn't get overwritten
3) sign the package with your key
4) cat /tmp/fromthemirror.sig >> foobar-1.0-1-pkg.tar.xz.sig

And like magic, you have two sigs. gpg --verify will show you both,
and gpgme will perform the same process.

-Dan