On Wed, 2007-08-29 at 17:04 -0400, Havoc Pennington wrote:
Hi,
I wrote down the schemas for the current information stored by
various apps. Here those are, essentially 5 kinds of object:
Firefox/Epiphany/etc. Browser Web Site Login
Domain (exact domain:port we logged in to)
Please use
Havoc Pennington wrote:
Hi,
I guess my simpler API suggestion amounts to the same API currently
used for network password, but with varargs for the properties so it
can be used for any set of lookup properties
So, I could have just said that I guess, sorry for the longer mail.
The
On Tue, 2007-08-28 at 18:23 -0400, Havoc Pennington wrote:
Hi,
Thanks for the bug links, those are helpful.
Here are some questions I have about conventions for storing stuff in
the keyring, which would be relevant to the Gossip bug (and future
similar bug against Pidgin, etc.)
- when
On 8/28/07, David Zeuthen [EMAIL PROTECTED] wrote:
On Tue, 2007-08-28 at 17:33 -0400, Havoc Pennington wrote:
- fix Firefox to use the keyring, or at least let apps query Firefox
password manager storage
- have some mechanism for smart deductions, like I can guess you
have an XMPP
Bryan Clark wrote:
Can an application that stores a secret be able to retrieve that same secret
without unlocking the keyring?
Yes for sure.
I never really understand why NetworkManager, the one who put certain
secrets into my keyring needs to ask my permission to get those secrets
back.
David Zeuthen wrote:
http://people.freedesktop.org/~david/gnome-keyring-allow-deny.png
(actually this instance of the dialog, btw, looks pretty hostile to end
users. Maybe I'm just not using gnome-keyring correctly from
gnome-mount to save the LUKS pass phrase in the keyring. Shrug.)
Hi,
Even though the keyring is locked, it seems like the application that set
the secret should be able to retrieve it. I don't know how you want to make
sure it's the same calling application, there might be some tricks in that.
But this would reduce the number of login / access the keyring
Are you asking for an unencrypted area that only one application has
read access to? If so, you might be able to do something like that
with SELinux (or AppArmor?), but I don't think it would be a very
robust solution.
The Linux kernel key service can do this for session/user/user+session
Hi,
On 8/29/07, Alan Cox [EMAIL PROTECTED] wrote:
Are you asking for an unencrypted area that only one application has
read access to? If so, you might be able to do something like that
with SELinux (or AppArmor?), but I don't think it would be a very
robust solution.
The Linux kernel
On Wed, 29 Aug 2007 16:39:04 -0400
Ray Strode [EMAIL PROTECTED] wrote:
Hi,
On 8/29/07, Alan Cox [EMAIL PROTECTED] wrote:
Are you asking for an unencrypted area that only one application has
read access to? If so, you might be able to do something like that
with SELinux (or
Havoc Pennington wrote:
I wrote down the schemas for the current information stored by
various apps. Here those are, essentially 5 kinds of object:
Firefox/Epiphany/etc. Browser Web Site Login
Domain (exact domain:port we logged in to)
Username
Password
Username Input Field
Hi,
On 8/29/07, Stef Walter [EMAIL PROTECTED] wrote:
Sadly an HTTP login is far more complex than just that. In basic and
digest authentication 'realm' is sent from the server, which is really
what defines which login to use.
Also digest authentication has the concept of a 'domain', which is
Hi,
I guess my simpler API suggestion amounts to the same API currently
used for network password, but with varargs for the properties so it
can be used for any set of lookup properties
So, I could have just said that I guess, sorry for the longer mail.
The varargs are more convenient even for
- have some mechanism for smart deductions, like I can guess you
have an XMPP account that matches your google.com username/password -
maybe this just has to be in the apps, not sure
This needs some care. There are evils that lurk on the web side of this.
One big one is that if a central
On Tue, 2007-08-28 at 17:33 -0400, Havoc Pennington wrote:
snip
Anyway, I'm thinking about how to clean up the password-storage situation.
Here is the current situation:
- Pidgin just sticks passwords in plain text in app-specific XML files
- Gossip does the same thing, plain text in XML
Hi,
Thanks for the bug links, those are helpful.
Here are some questions I have about conventions for storing stuff in
the keyring, which would be relevant to the Gossip bug (and future
similar bug against Pidgin, etc.)
- when do you use default/NULL vs. session keyring? (I think I've
asked
On Tue, 2007-08-28 at 22:56 +0100, Bastien Nocera wrote:
Gossip should really know better though:
http://bugzilla.gnome.org/show_bug.cgi?id=343513
FWIW, Gajim uses the keyring. Which is nice.
___
desktop-devel-list mailing list
Havoc Pennington wrote:
I forgot to mention taking the encrypted keyring blob and sticking it
on a server somewhere, but (I think) that's an independent issue from
getting everything to use the same keyring and same keyring entries.
Well there are obviously security issues to this.
Perhaps
Alan Cox wrote:
I just started thinking about this today, so let me know what's missing.
One of the things you can use the TPM for in a treacherous computing
system is simply as a poor quality smart card. And for that matter
working with a proper smart card is similar. Being able to share my
Havoc Pennington wrote:
Anyway, I'm thinking about how to clean up the password-storage situation.
Here is the current situation:
- Pidgin just sticks passwords in plain text in app-specific XML files
- Gossip does the same thing, plain text in XML files
- Firefox has its whole own
Hi Havoc,
Cleaning up and making more apps use the keyring is definitely a
worthwhile effort in my mind.
On Tue, 2007-08-28 at 17:33 -0400, Havoc Pennington wrote:
- fix Firefox to use the keyring, or at least let apps query Firefox
password manager storage
- have some mechanism for smart
On Tue, 2007-08-28 at 18:23 -0400, Havoc Pennington wrote:
Hi,
Thanks for the bug links, those are helpful.
Here are some questions I have about conventions for storing stuff in
the keyring, which would be relevant to the Gossip bug (and future
similar bug against Pidgin, etc.)
snip
I'm
Havoc Pennington wrote:
- when do you use default/NULL vs. session keyring? (I think I've
asked this before, but I forget)
Use NULL (which automatically maps to the default keyring) when you
don't care what keyring a password is stored in, but you want it stored
for good. In many cases this
Hi,
On 8/28/07, Stef Walter [EMAIL PROTECTED] wrote:
Havoc Pennington wrote:
I forgot to mention taking the encrypted keyring blob and sticking it
on a server somewhere, but (I think) that's an independent issue from
getting everything to use the same keyring and same keyring entries.
Hi,
On 8/28/07, Stef Walter [EMAIL PROTECTED] wrote:
- have some mechanism for smart deductions, like I can guess you
have an XMPP account that matches your google.com username/password -
maybe this just has to be in the apps, not sure
Along with what Alan said, pushing this too far down
Hi,
On 8/28/07, Bastien Nocera [EMAIL PROTECTED] wrote:
I'm not sure anyone's really thought of the conventions behind using
each field for something specific. You'd need to ask Alex, he wrote it
after all :)
I am hoping he'll read the thread ;-)
Ideally I think we'd allow Gossip and
the one thing that drives me nuts about gmail is that it doesn't
default to reply all...
On 8/28/07, Havoc Pennington [EMAIL PROTECTED] wrote:
Hi,
On 8/28/07, Stef Walter [EMAIL PROTECTED] wrote:
So what you're really talking about is storing the concept of an
'account' with all related
On Tue, 2007-08-28 at 18:48 -0400, Havoc Pennington wrote:
The functionality I'm after is the same thing we already have for
online.gnome.org, where if you are logged in to the web site, then the
desktop can use the same cookie to sign on to the XMPP server.
If cookies are all you want, then
Hi,
On 8/28/07, David Zeuthen [EMAIL PROTECTED] wrote:
One important thing about the gnome-keyring prompts is that they display
information the user should be able to trust / understand. Things like
that App X is trying to use the key stored by App Y. [1]
Yeah. I'm not sure these dialogs make
resend to list...
On 8/28/07, Havoc Pennington [EMAIL PROTECTED] wrote:
Hi,
On 8/28/07, David Zeuthen [EMAIL PROTECTED] wrote:
On Tue, 2007-08-28 at 18:48 -0400, Havoc Pennington wrote:
The functionality I'm after is the same thing we already have for
online.gnome.org, where if you
Exactly, yep. I can write some simple spec up, but first I want to
understand all the current thinking (so far it sounds like there's a
pretty blank slate for spec'ing this out)
You might want to have a chat with Dave Howells at Red Hat as well. Dave
did the Linux kernel side key management
On Tue, 2007-08-28 at 19:08 -0400, Havoc Pennington wrote:
A better approach, for example, would be to have selinux or signatures
or something such that apps that come with the OS are automatically
trusted and the dialog or other obscure procedure only arises for
third-party apps. Then people
32 matches
Mail list logo
