[packagekit] GPG keys

[Richard Hughes]

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.