Summary: | [4x][br][security] Adopt Equinox Secure Storage for RSE Passwords | ||
---|---|---|---|
Product: | [Tools] Target Management | Reporter: | Martin Oberhuber <mober.at+eclipse> |
Component: | RSE | Assignee: | David Dykstal <ddykstal.eclipse> |
Status: | RESOLVED FIXED | QA Contact: | Martin Oberhuber <mober.at+eclipse> |
Severity: | major | ||
Priority: | P2 | CC: | contact, ddykstal.eclipse, ob1.eclipse |
Version: | 3.0 | Keywords: | helpwanted, investigate |
Target Milestone: | 3.4 M6 | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Bug Depends on: | |||
Bug Blocks: | 370237 |
Description
Martin Oberhuber
2008-04-02 08:40:32 EDT
The similar request for CVS: bug 222124 The similar request for core.net: 214796 Both of those include "draft" patches. I'll try to provide similar "draft" patch for RSE, but it will probably be a few days to couple weeks before I can get to it. Where can I find RSE source code? Thanks Oleg. For RSE, best use the rse-anonymous.psf project set from http://www.eclipse.org/dsdp/tm/development/cvs_setup.php It's unlikely we'll get to this in the 3.0 time frame, but I'm giving it another chance for RC1. Dave do you think this is realistic in 3.0 ? - For CVS it seems to work smoothly now, so the migration should not be overly difficult... Moving enhancements to the 3.1 release. See also bug 244982, and the Documentation: http://help.eclipse.org/ganymede/topic/org.eclipse.platform.doc.user/reference/ref-securestorage-options.htm http://help.eclipse.org/ganymede/topic/org.eclipse.platform.doc.isv/guide/secure_storage_dev.htm Looks like we'll need to do this in 3.4 / Juno since Eclipse 4.x doesn't ship the old 2.x style API's for passwords any more. See also bug 370237 , bug 336129 . (In reply to comment #7) > Looks like we'll need to do this in 3.4 / Juno since Eclipse 4.x doesn't ship > the old 2.x style API's for passwords any more. > > See also bug 370237 , bug 336129 . This should not be too tough. I was initially worried about migrating existing password stores but I think that is not practical and we should start fresh. That sounds great! At any rate, we should make sure to document the change - maybe along with documenting the physical location of the old password store on disk as well as the new one, such that users can delete the old (unsafe) password store. Another option might be keeping the old code for _reading_ the old store around such that users who must migrate some passwords can deploy the *.auth bundle (actually I guess that on top of 3.8 the old code should still work out of the box). So to me it looks like migration should be easy if we want to support it. I'm setting target milestone 3.4M6 then (the next one) since that's typically the feature freeze milestone and we're talking about a significant feature change here. Thanks, Martin I will be integrating this change to the PasswordPersistenceManager for M6. Documentation and migration will still need to be tested but the function for saving passwords will be there and will function identically to previous releases. There is no API change in PasswordPersistenceManager, but there is a dependency added to org.eclipse.rse.core for the new secure storage API. The plugin versions will be updated as a result. Adding JUnits for PasswordTestSuite to our build suite as well. Migration testing complete. New JUnit testcases added. Resolving as fixed. |