[packagekit] GNOME summit and more about GPG keys

[Adrien BUSTANY]

Robin Norwood a écrit :
> Hi,
>
> So, I gave a little demo of PackageKit at the GNOME summit on Monday.
> It went well.  Nothing crashed.  :-)  There were some good questions and
> comments afterwards.  The response seemed positive to me.  There was a
> bit of a discussion about "How applications can install plugins with
> PackageKit".  For instance, gimp plugins and gstreamer codecs.  To be
> able to do this, we should probably have simple python and C bindings to
> install things with a semantic of "give me a package which provides
> 'x'".  The bindings we have now are pretty close, and maybe just example
> code needs to be easily available.
>
> However, one problem is that there isn't a consistant cross-distro way
> that I know of to name these sorts of deps...so either distros will need
> to become consistant or the deps need to be generated and maintained
> somewhere.
> Thoughts on this?
>   
Can't you do a search like "what package does provides the file
/usr/gimp/plugins/xxx" with yum ? If not, it would be handy since rpm
does it with -qf...
>
> Second, GPG signing - had a few discussions with RHers at the office
> today about GPG signing...everyone pretty much agrees that the current
> way to do it sucks.  Some ideas to fix it:
>
> o Accepting a GPG signature should happen when you add a repository, not
> when you try to install a package.  yum repo config (not sure about
> other backends) can include a URL to the GPG key...so, a yum plugin
> could be created to check to see:
>
>   - foreach repo:
>     - Is GPG checking enabled?
>     - Is the GPG key installed?
>     - If not, then do the prompt user thing (the repo_signature_required
>     signal)
>
>   And if an unexpected GPG key occurs at some other time, probably just
>   error out...this way, the gpg check occurs early in the transaction,
>   instead of after PK goes away to think for awhile.
>   
Maybe there should be a frontend to manage yum repos (like unbuntu
does). Of course, repo files are standard rpms, but that would be useful
(maybe we could add a different extension to repos rpms ?). That way,
when the user adds a repo, that frontend would fire up and ask him if he
trusts the repo (with an option to see the key, and maybe check it
against a keyserver).
> o Keyserver(s): We (well, individual distros, or some central group)
> could set up a public keyserver.  This way, when the user is presented
> with a key, an additional check could be run to see if they key matches
> one in the keyserver.  The user then has an added layer of trust, rather
> than verifying the fingerprint against a URL that could have been
> forged.  This does put a burden on whoever runs the keyserver, because
> then *they* have to go and verify that a person or org before a new key
> is uploaded.
>
> o Many, many people ranted about how bad it is to show the user a hex
> string.  Having a keyserver might mitigate that, but...
>
> o Fedora should include it's keys at install time, instead of the first
> time yum is run (maybe this is already fixed, but it's silly).
>
> That's it - sorry for the fairly disorganized braindump.
>   
Don't know if piping it through sort would have been better ;-)
> -RN
>
>   
Adrien BUSTANY