[packagekit] GPG keys

[Robin Norwood]

Richard Hughes <hughsient at gmail.com> writes:

> 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

Yes, that.

>> 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?

Yeah, that's what I was thinking - all the various information is a bit
much to stuff into an error message.

"SignatureRequired"?
"NeedSignature"?
"PackageSignatureImportRequest"?

>> 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.

I have little knowledge of how other packaging systems handle
signatures, so it's hard for me to know what needs to be abstracted, and
what the full set of data might be available in a
"PackageSignatureImportRequest" for the various backends.  I was just
going to go with what yum provides, and let others add to that.  It
looks like yum deals with the key's url, userid, keyid, and timestamp.

>> 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.

Well, once per repository, but really the most Fedora users ever
encounter is two or maybe three.  (Livna, et al)

>> 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.

-RN

-- 
Robin Norwood
Red Hat, Inc.

"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching