Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [dsdp-tm-dev] New Equinox Secure Storage


Since this is totally internal implementation it can wait until
M7 or even slightly later. For now, I was just wondering whether 
we really want this such that I could ask for help on the equinox

I'm not sure whether we'd want to migrate old passwords from the
Keyring. Perhaps it would make sense to do a one-time-import of
The RSE slots into the Secure Storage; once an RSE slot exists
In secure storage, delete the stuff in the keyring and do no more

Since the keyring is usually stored in the Configuration Area,
I don't see a problem with mixing different Eclipse Versions (with
And without secure storage) on a single workspace. Problems could
Only arise if users deliberately share a keyring between Eclipse 3.3
And Eclipse 3.4 installations with the -keyring commandline option.

Also, note that currently RSE 3.0M6 still works on Eclipse 3.3 --
Adopting Secure Storage would put in a hard dependency on 
Eclipse 3.4

Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member

> -----Original Message-----
> From: dsdp-tm-dev-bounces@xxxxxxxxxxx 
> [mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On Behalf Of David Dykstal
> Sent: Mittwoch, 02. April 2008 15:04
> To: Target Management developer discussions
> Subject: Re: [dsdp-tm-dev] New Equinox Secure Storage
> I would love to use this out of the PPM. The current keyring 
> implementation
> is a bit funky. I think this would go a long way toward 
> cleaning up the
> internals. Do you think we need to migrate currently stored passwords?
> Since this is really an internal issue we'll put it on the 
> tentative list
> for M7, but I think bugs have a higher priority.
> I don't mind using provisional API as long as I know it is 
> provisional.
> Also on the horizon, though further out, is JAAS, which could 
> go some way
> to cleaning up credentials providers.
> _______________________
> David Dykstal
> david_dykstal@xxxxxxxxxx
> _______________________________________________
> dsdp-tm-dev mailing list
> dsdp-tm-dev@xxxxxxxxxxx

Back to the top