[packagekit] GPG keys

[Tim Lauridsen]

Richard Hughes wrote:
> On Tue, 2007-10-02 at 15:44 -0400, Robin Norwood wrote:
>   
>> 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.
>>     
>
> Which probably needs to be renamed to be abstract.... ;-)
>
>   
>>>> 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"?
>>     
>
> Ultimately, the backends will have repo controls, like:
>
> a(s=rid,s=description)=GetRepoList()
> RepoEnable(s=rid,s=value)
> RepoSetData(s=rid,s=data,s=value)
>
> So maybe RepoAuthenticationRequired, RepoAuthRequired or
> RepoValidateRequired would be best.
>
>   
>> 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.
>>     
>
> What does userid and timestamp convey?
>
>   
>>> 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)
>>     
>
> Sure, but updates and fedora should already be added. Livna is the only
> one this should apply to.
>
> Thanks,
>
> Richard.
>
>
> _______________________________________________
> PackageKit mailing list
> PackageKit at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/packagekit
>   
There is two ways it can can be handled as i see it:
1.
* If a key is need then the backend send a signal with info about the 
key and aborts.
* The frontend calls a backend helper with information about repoid & 
keyid to install (if the user answer yes to some kind of dialog)
* the frontend rerun the previous transaction again ( remember the old 
transaction is not an option, when using helpers)

2. Implement  2 way signals, so  the  frontend  can send  signals back 
to  the helper  (write some stuff  to standard in).
* if a key is need then the backend send a signal and wait for a 
confirmation signal (from stdin)
* If the signal is 'CONFIRMATION_YES' then install the key and contiune 
the Transaction, if the signal is 'CONFIRMATION_NO' then abort.

 The 2 way signals, can give some extra options, the user can have the 
possibility to see and confirm the transaction before it is processed
but the 1. is more simple.

Tim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/packagekit/attachments/20071003/37a8c772/attachment-0004.htm>