Re: [E-devel] E SVN: mekius IN trunk/empower: . data po src/bin

[Cedric B. <ced...@fr...>]

Hi,

On Sat, Sep 1, 2012 at 8:51 PM, Gustavo Sverzut Barbieri
<bar...@pr...> wrote:
> On 01/09/2012, at 11:05, Nicholas Hughart <me...@me...> wrote:
>> On 09/01/2012 12:27 PM, Gustavo Sverzut Barbieri wrote:
>>> Nice work, mekius!
>>>
>>> I did not read the code or tried the executable (going to catch a plane
>>> back to brazil) but it looks promising!
>>
>> Lol, don't read the code you'll probably get sick :P
>>
>>>
>>> Taking to gnome guys at Linux Plumbers Conf they said they have the same
>>> agent to talk natively the protocols of the ssh and gpg agents, then they
>>> can show an unified experience for users. What do you think?
>>
>> Yeah, I will eventually put askpass support back in for SSH/sudo. Not
>> sure how gpg works.  Gnome may handle this via their keyring stuff which
>> would also be storing the key.  We could extend empower to be such a
>> keyring type library/application, but maybe wait until we have a number
>> of apps actually using gpg keys?
>
> The key ring also stores passwords such as mail, irc, chat...
>
> We could check their API, maybe it's easy to just implement it with empower and eet and their stuff can use ours. Shouldn't be much more than "I'm this app and need password for account X", then give it back. The first part likely it's even over DBus, the second likely not due Security reasons (maybe a private bus or ssl socket)

I am particularly suspicious about all current keyring implementation.
I don't feel like they are securely saving my password. A first
obvious requirement is to never swap nor save on suspend any password.
My understanding is that we need to be root to request a non swappable
memory. Detecting suspend shouldn't be a problem. The second point is
that when I save my password for mail, irc, web, once unlocked I don't
want it to be accessible from any other application. It is also
problematic if the password transit through the dbus daemon, I hope
they at least use the direct end to end connection for that purpose.

If all my assertion are correct, implementing a keyring should be done
in a root daemon. Application should directly connect to it through a
direct socket and as long as they maintain that socket open the
password they required will be available on request to the application
(In an ideal case, application never store the password for any long
period of time, they just request it, use it, wipe it out, and request
it again later if needed). When a connection is established by an
application, the daemon should talk to the user session somehow and
ask if they allow that particular app to access that password. The
composite manager should be able to make a visual difference on that
particular request.

As far as I see it, it's not an easy task, and I seriously doubt it
has been implemented correctly in any Freedesktop standard (as
always...). But I may be wrong.
-- 
Cedric BAIL