[packagekit] GPG keys
tla at rasmil.dk
Tue Oct 2 23:58:30 PDT 2007
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
>>> 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.
> Ultimately, the backends will have repo controls, like:
> 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.
> PackageKit mailing list
> PackageKit at lists.freedesktop.org
There is two ways it can can be handled as i see it:
* 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the PackageKit