Re: GNOME Keyring and Seahorse Goals and Vision

[Stef Walter <stefw gnome org>]

On 2010-10-10 09:16, Adam Schreiber wrote:
> In the 'Icons' section, rather than reuse the seahorse icons, we
> should reach out to the Gnome Art/Graphics team.  There was an IRC
> dust up a while back in which neither I nor the Gnome Art guy involved
> were entirely civil, but the gist was that we were using out-of-date
> modified tango icons inappropriately without attribution.  We should
> probably get that straightened out.

Added. Do you have more specifics?

> Trust Assertions
> 
> Is there a way we could boot-strap trusted GPG keys into vouching for certs?

Perhaps. There was an interesting idea brought up at GUADEC by Tobias
Müller. The suggestion of storing trust assertions as certificates
signed by different keys (for various purposes).

This can be added as an implementation once the actual specifications
and PKCS#11 extensions for trust assertions are agreed on.

> gsecrets should probably follow the conventions of glib-dbus and other
> platform librarys that integrate GObjects and DBus.

Yes good plan. Do you have time to do more research as to what those are
specifically?

> Seamless security:  I think the philosophy of providing security, but
> not the appearance of more security than there actually is should be
> carried forward.  This policy is at odds with user expectations and
> causes such misunderstandings as the "I can see my passwords when the
> key ring's unlocked" problem.  I agree we should try to come up with a
> solution to this problem, but not at the cost of this policy.

Yes that's true. Good point. Added.

> Prevent logging or caching of secrets:  Encrypting the
> passwords/secrets between DBus consumers doesn't even require a MITM
> attack.  It's vulnerable to the same malign requestor attack as usual.
>  This is a continuation of "If your security context is compromised,
> everything is".

Clarified in two places.

> I agree with the Non-Goal 100%.  My philosophy and focus has always
> been on making existing crypto easier to use, not reinventing the
> stuff that's hard to get right.  Crypto UI has it's own pitfalls that
> are hard enough without reinventing the wheel.

Roger. Although obviously, we'll sometimes overlap with stuff that's
already developed in one way or another.

> Kudos for getting that all down in writing Stef.

I hope it's a help both for us, and for new people wanting to get
involved in the project.

Cheers,

Stef