Bug 183068 - Extend Keyring to allow keep passwords without persistence
Extend Keyring to allow keep passwords without persistence
Status: RESOLVED INVALID
Product: platform
Classification: Unclassified
Component: Options&Settings
6.x
All All
: P2 (vote)
: TBD
Assigned To: Jesse Glick
issues@platform
:
Depends on:
Blocks: 173413
  Show dependency treegraph
 
Reported: 2010-03-29 12:24 UTC by Vladimir Voskresensky
Modified: 2010-03-30 23:09 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vladimir Voskresensky 2010-03-29 12:24:33 UTC
To prevent keeping passwords in memory on CND side we need an API from Keyring like:
Keyring.keep(String key, char[] pwd)
such ability should not ask for masterpassword

Keyring.get(String key)
must return keeped password.
"keeped" password must not be persistent
Comment 1 Jiri Rechtacek 2010-03-29 12:34:48 UTC
Jesse, could you evaluate this? Thanks
Comment 2 Jesse Glick 2010-03-30 21:41:09 UTC
I need some use case. If you just want to not store passwords, you can register a KeyringProvider which keeps them in memory only, or which simply discards them. Description is unclear since "prevent keeping passwords in memory" and "password must not be persistent" seem to contradict one another.
Comment 3 Vladimir Voskresensky 2010-03-30 22:08:48 UTC
(In reply to comment #2)
> I need some use case. 
1)
- our infrastructure asks user about password and user keep "Save Password" unchecked 
=> user must not be disturbed by "master password" dialog while password should be kept somehow in memory for the use
2)
- CLI based API clients don't want any persistent on disk, but needs storage for passwords for the current session
3)
- sudo like clients: once entered password is kept in memory during one session and all child processes has needed priviledges. 

>If you just want to not store passwords, you can register 
> a KeyringProvider which keeps them in memory only, or which simply discards
> them. 
We don't want to deal with own cryptography impl. We want to use what is provided by Platform in this area, but without "master password" dialog.

>Description is unclear since "prevent keeping passwords in memory" and
> "password must not be persistent" seem to contradict one another.
Persistent means "store" on disk. If user keep unchecked "Remember Password" => he don't want to "persist", but (like once entered password for sudo) next operations would not ask him password again in this IDE session.
Comment 4 Jesse Glick 2010-03-30 23:09:47 UTC
> - our infrastructure asks user about password and user keep "Save Password" unchecked 
> => user must not be disturbed by "master password" dialog

So don't call Keyring.read to begin with. (Or use an operating system with a native keyring - once again, Solaris 10 is tracked separately and that covers practically every system in use today.)

> - CLI based API clients don't want any persistent on disk, but needs storage for passwords for the current session

Then you can trivially create and register your own KeyringProvider which just retains a Map<String,char[]> of passwords. The standard IDE distribution should of course not contain such a provider, but if you make a CLI app you can add whatever service you like.

> We don't want to deal with own cryptography impl.

If you do not store to disk, then no cryptography is needed.

> We want to use what is provided by Platform in this area, but without "master password" dialog.

This makes no sense - to store to disk securely without platform support you need a master password.

> If user keep unchecked "Remember Password"

There is no such label in the keyring module; perhaps you are talking about one of your own modules.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo