[packagekit] GPG keys

[Richard Hughes]

On Tue, 2007-10-02 at 14:23 -0400, Robin Norwood wrote:
> *** Add a way to import GPG keys ***
> In fedora, if you add a signed repo you have to agree to the GPG key.
> Anyone have an opinion as to how this should be implemented?

Me ;-)

> My first guess is:
> o Something requests that a packaged be installed.
> o Backend detects that the package is signed with a GPG key that is not
>   installed on the system.
> o Backend returns an error for the package install 'missing GPG key
>   "foo"'

Or rather: PK_ERROR_ENUM_GPG_FAILURE

> o Backend generates a signal containing all the relevant GPG key info.

Can't we just use the error text? If we do use a signal we can also
present other information about the key (id, website url, that sort of
thing) so actually a signal might be most sane. Any ideas on a name?

> o User is presented with UI explaining the situation.
> o Assuming the user agrees to install the GPG key, an 'install GPG key'
>   action is generated, followed by a re-running of the original
>   transaction.

Very sane.

> The error code for the failed package install transaction could probably
> include all of the requisite information for requesting the GPG
> installation, but it seems more correct to me to have that passed via a
> signal.

Any ideas? We also need to keep this abstract - i.e. not mention GPG at
all and make it some other random word. This means we can use PGP (or
rhn or whatever) in the other backends.

> Also, the clients will have to remember the original transaction to
> re-run it.

Sure, we can't just do this in pk-client as we need user interaction. I
don't think this is a big problem.

> Also also, if more than one GPG key is required for a given transaction,
> that means a lot of round trips, attempting the transaction and failing
> each time.  Maybe the backend can detect this and just generate multiple
> 'GPG signature required' signals.

Hmm. I'm not so worried about round trips actually, the interaction with
the user is going to be the slowest part by miles, and you'll want to be
able to approve/deny each one. Plus you only have to do this once, ever.

> Thoughts?  I haven't looked at the code to implement this yet, so the
> above could be a pipe dream.

No, it's actually pretty easy. All the code is in place for the extra
methods - the only tricky bit will be making this abstract.

Richard.