[packagekit] GPG keys
Robin Norwood
rnorwood at redhat.com
Thu Oct 4 12:10:44 PDT 2007
Ok,
Just checked in a first try at the RepoSignatureRequired signal. Only
supported in the dummy backend until I figure out how to do it for the
yum one.
Also, comments + flames appreciated.
-RN
Richard Hughes <hughsient at gmail.com> writes:
> On Wed, 2007-10-03 at 09:58 -0400, Robin Norwood wrote:
>> Richard Hughes <hughsient at gmail.com> writes:
>>
>> >> > Or rather: PK_ERROR_ENUM_GPG_FAILURE
>> >>
>> >> Yes, that.
>> >
>> > Which probably needs to be renamed to be abstract.... ;-)
>>
>> Yup. 'signature' is probably the right generic term.
>
> Yes, that's much better.
>
>> >> "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.
>>
>> RepoSignatureRequired, or RepoSigRequired maybe...
>
> RepoSignatureRequired is good for me.
>
>> 'signature' is the best generic term, I think.
>>
>> >> 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?
>>
>> It's the userid "Robin Norwood (Red Hat, Inc.) <rnorwood at redhat.com>"
>> and time stamp (creation date, IIRC) of the gpg key used to sign the
>> package. You'll want to show all four bits of info to the user when
>> asking her to import the key.
>
> Sure, we can add all of those to the callback. I don't see a harm in
> including all the fields, we can make it more abstract if and when
> another backend needs to do something slightly different.
>
>> >> > 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.
>>
>> Maybe. IIRC, Fedora still doesn't import the GPG key until the first
>> time you run yum (or pirut, or PackageKit). Regardless, there shouldn't
>> ever be more than a couple.
>
> Cool. Hack away :-)
>
> Richard.
>
>
> _______________________________________________
> PackageKit mailing list
> PackageKit at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/packagekit
>
--
Robin Norwood
Red Hat, Inc.
"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching
More information about the PackageKit
mailing list