[packagekit] GNOME summit and more about GPG keys
madcat at mymadcat.com
Wed Oct 10 01:44:26 PDT 2007
Robin Norwood a écrit :
> 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
> 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
> 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 ;-)
More information about the PackageKit