[pacman-dev] [PATCH 4/4] signing: move to new signing verification and return scheme
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.
More information about the pacman-dev