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
On Wed, 2007-08-29 at 13:52 -0400, Behdad Esfahbod wrote:
- Do things more Pythonesque. Looking at Pango bindings, for
example
replace all to_string() methods with __str__. Same for compare(),
equal(), etc. Or should it be in addition?
Other example I once really wanted was generator
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
Behdad Esfahbod wrote:
On Wed, 2007-08-29 at 12:37 -0300, Johan Dahlin wrote:
Greetings
Couple thoughts:
- Do things more Pythonesque. Looking at Pango bindings, for example
replace all to_string() methods with __str__. Same for compare(),
equal(), etc. Or should it be in addition?
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
El mié, 29-08-2007 a las 23:36 +0200, Andi Albrecht escribió:
2007/8/29, Johan Dahlin [EMAIL PROTECTED]:
Hi Johan and all,
in general I think it is a very good idea to port PyGTK to Python 3.x
as soon as possible. The api must not be stable with the fist alpha
release, but it need to be
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
quote who=Johan Dahlin
Python 3.0 is the current development focus of the Python community.
It is different from the old 2.x series in the sense that it will not be
backwards compatible with the old python releases.
All the python bindings needs to be ported over to the new C Python API.
15 matches
Mail list logo