On Mon, Jun 27, 2011 at 7:58 PM, Allan McRae <[email protected]> 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<[email protected]> >> --- >> >> 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. -Dan
