[pacman-dev] [PATCH 4/4] signing: move to new signing verification and return scheme
dpmcgee at gmail.com
Mon Jun 27 22:14:07 EDT 2011
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
>> us the flexibility we need to verify everything we need to, as well as
>> 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
>> type be an alpm_list_t instead? Or better yet, an array of enum values
>> 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.
More information about the pacman-dev