On Sunday, September 2, 2012, Cedric BAIL wrote: > Hi, > > On Sat, Sep 1, 2012 at 8:51 PM, Gustavo Sverzut Barbieri > <barbi...@profusion.mobi <javascript:;>> wrote: > > On 01/09/2012, at 11:05, Nicholas Hughart <mek...@mekius.net<javascript:;>> > 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.
Paranoids just don't use it. Plain simple, it's optional. ;) > > 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. You're going crazy. There are other levels of security that should handle that. Like encrypted swap. The Machine access security should be considered as well See chromium. They explicitly declined saving encrypted passwords reasoning that if you care about it (iow: you'd set a main password) you'd be using encrypted /home and would never allow someone to access your account without supervision. Which is clearly okay. > > 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. There is no standard. Kde and Gnome do their own stuff. > -- > Cedric BAIL > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net <javascript:;> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
