Hi, from my user/dogfooder perspective and experience with Chandler, I agree that preview users would be more apt to provide whole repositories in bug reports if they knew their passwords were somehow protected. I hadn't appreciated previously the interesting complexities of protecting passwords and I am unable to address all points made. However, towards the goal of getting feedback, it seems to me that if the work is well understood and QA can get what they need for testing, basic shielding of passwords in submitted repositories is desirable for preview, even if categorized as feature creep. I guess in my opinion not all scope creep is entirely undesirable, depending on the cost.
Thanks, Andre On Fri, 23 Mar 2007 10:48:10 -0700, "Aparna Kadakia" <[EMAIL PROTECTED]> said: > Even though I agree that this is a desirable feature for Preview, it > would have been nice to see it on the PReview plan so we could have > scheduled time for it. > > On Mar 22, 2007, at 7:37 PM, Katie Capps Parlante wrote: > > > Hi Heikki, > > > > I agree that a password encryption feature is something that we're > > going to want, and given that you have it working on your branch it > > makes sense to incorporate it. Apologies for not speaking up earlier. > > > > I will acknowledge (for PPD, QA teams) that this could be > > considered minor feature creep, adding QA load, etc. We need to > > make sure we have a spec, in particular for testing. Can you help > > with that? > > > > You ok with this Sheila and Aparna? > > We do need a spec to test this out. So, yes as long as we get one we > should be fine. > > > > > More comments in line... > > > > 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. > > > > You make a good point here. Mimi pointed out offline that we still > > might be stuck if a user only decides they want to send us their > > repository after they're in a situation where Chandler has wedged > > -- at this point it would be too late to set up the master > > password. Nonetheless, it will prove useful in some situations. > > > >> Do we want to default to requiring a master password to encrypt and > >> decrypt the other passwords? > > > > I think you have it right in your implementation: by default, no, > > not required. > > +1 > > > > >> 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.) > > > > Yup, perhaps we could hear from Mimi the best place for this. > > > >> Do we want to provide encrypting arbitrary items/attributes? (I > >> wouldn't > >> worry about this until after Preview.) > > > > Yup, sounds like feature creep right now. Perhaps best to wait > > until we hear some user asking for the feature. :) Any thoughts Mimi? > > > >> 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.) > > > > Agree with your assessment. > > > >> 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. > > > > Yes, perhaps encrypted filesystems are the long term solution for > > people who really care about this. > > > >> 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. > > > > Yup, I agree with other conversations in the thread that this is > > the direction we want to go in, and too expensive for Preview. > > Perhaps this would be a good "helpus" project? > > > > Cheers, > > Katie > > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > > > > 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
