<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Richard Hughes wrote: <blockquote cite="mid:1191359385.2882.49.camel@hughsie-laptop" type="cite"> <pre wrap="">On Tue, 2007-10-02 at 15:44 -0400, Robin Norwood wrote: </pre> <blockquote type="cite"> <pre wrap="">Richard Hughes <a class="moz-txt-link-rfc2396E" href="mailto:hughsient@gmail.com"><hughsient@gmail.com></a> writes: </pre> <blockquote type="cite"> <pre wrap="">On Tue, 2007-10-02 at 14:23 -0400, Robin Norwood wrote: </pre> <blockquote type="cite"> <pre wrap="">*** 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? </pre> </blockquote> <pre wrap="">Me ;-) </pre> <blockquote type="cite"> <pre wrap="">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"' </pre> </blockquote> <pre wrap="">Or rather: PK_ERROR_ENUM_GPG_FAILURE </pre> </blockquote> <pre wrap="">Yes, that. </pre> </blockquote> <pre wrap=""> Which probably needs to be renamed to be abstract.... ;-) </pre> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">o Backend generates a signal containing all the relevant GPG key info. </pre> </blockquote> <pre wrap="">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? </pre> </blockquote> <pre wrap="">Yeah, that's what I was thinking - all the various information is a bit much to stuff into an error message. "SignatureRequired"? "NeedSignature"? "PackageSignatureImportRequest"? </pre> </blockquote> <pre wrap=""> 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. </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> What does userid and timestamp convey? </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap="">Well, once per repository, but really the most Fedora users ever encounter is two or maybe three. (Livna, et al) </pre> </blockquote> <pre wrap=""> Sure, but updates and fedora should already be added. Livna is the only one this should apply to. Thanks, Richard. _______________________________________________ PackageKit mailing list <a class="moz-txt-link-abbreviated" href="mailto:PackageKit@lists.freedesktop.org">PackageKit@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/packagekit">http://lists.freedesktop.org/mailman/listinfo/packagekit</a> </pre> </blockquote> 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 </body> </html>