RE: Seahorse re: 2.4 Proposed Modules

[Andrew Sobala <aes gnome org>]

Hi Jacob,

I've just downloaded seahorse to try it out.

On Mon, 2003-05-05 at 08:10, Jacob Perkins wrote:
> URL: http://seahorse.sourceforge.net
> 
> Description: Seahorse is a frontend for gnupg. The goal is to try to
> integrate seahorse/gpg into gnome in order to make key management and
> crypto easier.
> Key management is basically as complete as can be right now, except for
> key server support.

wrt. the "seahorse" binary, I think it's very confusing if you don't
know how gpg works. Let me give a non-gpg user's reaction to using it.

I start it up and I see a list of people. I click on one of them to look
at their key and choose properties. Now we're in jargon rich territory.
I see tabs for "Primary key", "User ID", "Subkey 1"... a lot of widgets
are insensitive, presumably because of limitations in the protocol, but
I don't know why. It appears I can add signatures to keys, although it's
insensitive, and I don't know what they are.

I can sign keys apparently - the program gives me a warning asking if
I'm sure I want to, but no indication of why I might not.

> Gnome integration is being worked on. Right now this includes a context
> menu for nautilus and a control center capplet for configuring pgp/gpg.

The context menu is nice, although I think "decrypt" should always
attempt to validate signatures and give a report on them instead of
having a separate "decrypt and sign" option.

The capplet is a waste of space. It essentially lets me set a "Default
Key", and enable/disable 3 options named "Ascii armor", "Text mode" and
"Encrypt to self." I don't actually know what these are, but it sounds
like a case for sensible defaults.

> Future plans include a gedit plugin, an out-of-process context to
> synchronize the key-ring, nautilus property pages, and a gnome-vfs view
> of the keys.

Yeah.

Like Havoc, I think that the UI needs to be aimed at "someone who wants
to encrypt files and send them to someone else" instead of "someone who
wants to have a graphical front-end to gpg."

Additionally, maybe approaching this from a "people" point of view
instead of a "key" point of view would be good? Perhaps integrating with
the evo address book with "People you can encrypt to?" I know that this
is a merge of 2 data sources, since the gpg database is the standard
place for keys to be stored under linux (and they should never be stored
separately in the evo address book), but it might be worth thinking
about.

-- 
Andrew Sobala <aes gnome org>

"A freudian slip is when you say one thing but you mean your mother." -- unknown