[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [dsdp-tm-dev] New Equinox Secure Storage
|
Sure,
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
List.
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
Updates.
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
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
> -----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
> https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
>
