[packagekit] GNOME summit and more about GPG keys

[Robin Norwood]

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?


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.

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.

-RN

-- 
Robin Norwood
Red Hat, Inc.

"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching