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, 02:14 AM
Dan McGee
Default signing: move to new signing verification and return scheme

On Mon, Jun 27, 2011 at 7:58 PM, Allan McRae <allan@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@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.


Thread Tools

All times are GMT. The time now is 06:58 AM.

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