FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Pacman Development

 
 
LinkBack Thread Tools
 
Old 06-28-2011, 12:58 AM
Allan McRae
 
Default signing: move to new signing verification and return scheme

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

Thread Tools




All times are GMT. The time now is 07:15 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org