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

Allan McRae allan at archlinux.org
Mon Jun 27 20:58:37 EDT 2011


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.

> 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.

Allan


More information about the pacman-dev mailing list