This should be relatively easy if anyone wants to help contribute. It does look like we need an API method added after all. Not sure what data we should expose by it? It would make sense to return the already decoded data, but I'm not sure.

Finally, just add something in src/pacman/package.c that shows yes/no/true/false (whatever convention is) and have it show up only for sync packages, and only if the pgpsig field mentioned is not NULL.

Hmm you got me into cloning pacman and i am currently lookingat dump_pkg_full , where there is a mention of "Signatures :" . I'll investigate some more.

Update: pacman -Qip works and shows signature info, i will see if i can make a patch for -Si http://dpaste.org/WRvT/
Hmmm since pacman -Si calls dump_pkg_full, with FROM_SYNCDB , and currently dump_pkg_full only shows Signatures with PKG_FROM_FILE, so thats why -Si doenst show it.

Would it make sense to break out the base64'd decoding/verification from _alpm_gpgme_checksig and use this to verify pkg->base64_sig for output on -Si?

Also, it would appear that we don't write the %PGPSIG% field to the local DB, so unless we fix that, we can't see this info on -Qi.

We can not really verify anything for -Si as the package could well be not downloaded. The only thing we can display is the list of signatures and who signed it.

And signatures information make no sense for -Qi at all.


So -Qip shows something like:
Signatures : Valid, fully trusted from "Allan McRae <me@allanmcrae.com>"

We could have -Si show
Signatures : None
or
Signatures : From "Allan McRae <me@allanmcrae.com>"
From "Someone Else <foo@example.com>"

I like the output allan gives:
Signatures : None
else
Signatures : From "Allan McRae <me@allanmcrae.com>"
From "Someone Else <foo@example.com>"

I'm not sure it's possible to show anything more than a 'yes' or 'no'. Looking at how we currently verify signatures and trying not to glaze over while looking through the gpgme header, it wouldn't appear that there's a way to do anything with the signature data in the absence of the file it's tied to. Dan, feel free to correct me if I'm wrong on this -- I'm happy to implement this.

At least initially I planned on doing a yes or no only, as I know we can do that.

A thought would be "validating" the signatures against /dev/null just to get the key information, but gpg/gpgme currently has a stupid bug where it stops listing signatures after the first one if validation fails.

That's lovely...

Something as simple as the below would be enough to get a "Signed" field showing on -Si output.

https://github.com/falconindy/pacman/commit/dcb35fdb212c3de958b4daf300353bfb3758e7ea

This looks good for a first iteration. I do think it would make more sense to decode and hand to the frontend so they don't also have to include base64 routines, but not sure what to do then about memory allocation and responsibility, so that will take a bit more thought. I think it would be a bit excessive to decode every signature on DB load time, as once DBs start to have signatures for every package it might cut into load time a decent amount.