[packagekit] GNOME summit and more about GPG keys

Adrien BUSTANY madcat at mymadcat.com
Wed Oct 10 08:09:42 PDT 2007


Robin Norwood a écrit :
> Adrien BUSTANY <madcat at mymadcat.com> writes:
>
>   
>> Robin Norwood a écrit :
>> Just about the confirmation window I was talking about in the precedent
>> mail, to accept or not gpg keys, I did a simple mockup :
>> http://maison.mymadcat.com/~madcat/ecran.jpg . That way we don't need to
>> show the user a scarrying gpg key, but he can see it if he wants to.
>>     
>
> Yeah, this option was brought up in the RH discussion - rolling up the
> GPG fingerprint might be the way....
>
> My only concern with that is that it might fool the user into thinking
> all the security is already taken care of.
Well, we can make the message more explicit, more frightening :-p
>   I was also thinking - if the
> key is already in /etc somewhere, then the user has already trusted
> something (like the repo's RPM)...so maybe we could have different
> messaging if the key already exists in /etc versus the case where they
> key needs to be downloaded from an external URL.
>   
Hmm I never had to to download a gpg key from the internet... If we take
livna, freshrpms, or other main repos, they all ship an rpm file, so the
key is installed in /etc. Here again, that's only for fedora/rh. But as
you say, the formulation should't be the same.
> In the /etc case, if an attacker has managed to write to /etc, the user
> has already lost...we can just say 'Trust this new repository?'.  If the
> key needs to be downloaded on the system, we could hint that the user
> should *really* check to make sure they trust that URL.
>   
Maybe that's out of the subject, but is this that easy to write into
people's /etc ? I was just thinking of vista's interface, with all those
nagging screen blockers asking you if you're really sure you want to
click on the mouse. Of course we aren't there yet, and security is an
important concern, but the point is not to harass the user either.
> -RN
>
>   

Adrien



More information about the PackageKit mailing list