Community
Participate
Working Groups
With Eclipse 3.4M6 comes the new Equinox Secure Storage component: http://download.eclipse.org/eclipse/downloads/drops/S-3.4M6-200803301350/eclipse-news-M6.html#equinox.security.storage We should adopt this for RSE Password Persistence, instead of the current Eclipse Keyring. The fix should be relatively simple since only org.eclipse.rse.core / PasswordPersistenceManager class should need to get modified.
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.
