On 22 Mar, 2007, at 09:54, Mimi Yin wrote:
Thx Grant...
Do any non-Windows / non-Apple apps use the OS keychain? As in, is
there a reason we can't use the OS keychain?
Hey, Mimi
Non-Apple apps do use the OS keychain (Colloquy, SSHKeychain are 2 I
use all the time).
Long-term, I'd say that's what we want Chandler to do. I believe the
barrier is engineering time:
- For Linux, I don't think there's a standard service like this, so
we have to roll a complete implementation anyway (i.e. as
Heikki has done).
- For the Mac, the OS keychain APIs aren't available from standard
Python, so there's work involved in making them available. Also, if
you adopt platform-dependent solutions, there's work involved in
making sure the right platforms call the right code.
- I'm not sure what the story is for Windows. I'd be surprised if
there wasn't a standard password encryption service, but I haven't
researched that.
--Grant
On Mar 22, 2007, at 9:41 AM, Grant Baillie wrote:
On 22 Mar, 2007, at 09:34, Mimi Yin wrote:
Hi Heikki,
How does this relate to OS keychains? How do Outlook, Apple Mail
and Thunderbird encrypt your passwords? or do they?
I can answer some of these (dunno about Outlook).
- This is unrelated to OS keychains (i.e. doesn't use them in any
way).
- Apple Mail uses the OS keychain for password encryption. So does
Safari.
- Thunderbird has its own password encryption feature. So does
Firefox. I don't think the two share any data, but I could be wrong.
--Grant
On Feb 20, 2007, at 3:33 PM, Heikki Toivonen wrote:
Chandler has the ability to remember passwords, and many high
profile
programs (e.g. Firefox) that have this ability can encrypt these
passwords.
Doing encryption/decryption like this traditionally requires the
user to
set a master password. The master password is never stored on
disk, it
will be asked from the user on demand, and may be remembered in
memory
until program shutdown or timeout.
I think we need to provide some level of encryption support in
Preview
timeframe. For example, I think our users should be able to
submit their
repositories to us for debugging purposes without us learning their
passwords.
Do we want to default to requiring a master password to encrypt and
decrypt the other passwords?
Or do we start unencrypted, offer a "encrypt" checkbox in the
accounts
dialog, and also when making a repository backup/dump? (I think
I am
slightly in favor of this.)
Do we want to provide encrypting arbitrary items/attributes? (I
wouldn't
worry about this until after Preview.)
Do we want to protect the passwords in memory? I must point out
that
this would be quite a bit of work, and it is not certain we
could even
cover all cases (passing password strings into libraries we may
not have
control over, for example). This would involve things like:
clear out
master password on timeout, never store the other passwords in
clear
text except for the moment when they are needed, zero out the
actual
bits in memory once done, prevent password memory from being
swapped
out, etc. (I wouldn't worry about passwords in memory myself.)
Please note that Chandler already supports encrypting the entire
repository. An alternative on some operating systems is to ask
the OS to
encrypt the disk/directory where the repository is.
Another thing to note is that many OSes provide password safes
of their
own with naturally platform specific APIs. I am not suggesting
we try to
hook up with these in Preview timeframe.
Reply-to set to design.
--
Heikki Toivonen
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
