Bugzilla – Full Text Bug Listing
| Summary: | [sec] Add "description" text to password providers | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Oleg Besedin <ob1.eclipse> | ||||
| Component: | Security | Assignee: | Security Inbox <equinox.security-inbox> | ||||
| Status: | RESOLVED DUPLICATE | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | eclipse, Kevin_McGuire, martinae, Mike_Wilson, tjwatson | ||||
| Version: | 3.4 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Oleg Besedin
After discussing with McQ I decided not to push this one as a 3.4 API change exception. Shall we mark it for 3.4.1? Adding API in a point release also requires an API change exception approval, correct? I am for deferring this after 3.4.0 but is it important enough for a point release? (In reply to comment #2) > Adding API in a point release also requires an API change exception approval, > correct? Good point, but would give us longer runway (part of issue against 3.4 is we're in API freeze, but other part is we're trying to lock down). >I am for deferring this after 3.4.0 but is it important enough for a > point release? The sooner the API goes in the greater uptake in developers supplying the information. But other than that no. Don't you want to bundle this API request with bug 230242? Both requests will improve the quality of the UI considerable. My personal opinion is that the current state of the UI justifies the late addition of the API. Without the descriptions I think the UI is more or less useless to have. I don't think it makes sense to wait for 3.4.1, 3.4.1 should also not add any API. And, as Kevin mentioned, waiting for 3.5 has the disadvantage that all clients that contribute now will not provide the extra information what will make them look bad in the UI. This is new API, and the change is a simple addition of optional properties to an extension point. I hope we can do this for 3.4. (In reply to comment #4) > Without the > descriptions I think the UI is more or less useless to have. > Um... no. *With* the UI, those who know what they are doing, can work. Without it, no one can. Clearly, having it is better than not having it, whatever it looks like. Having said that, if there is a consensus that this is seriously impacting the usability of 3.4, then by all means bring the request forward to the PMC. The description field would clearly add usability but I don't feel it to be as much as deal breaker for 3.4 as Martin does. Those who are unsure can check the doc. I'd prefer a UI where that wasn't required but I don't think there's a problem with people misinterpreting what's there, just not understanding it immediately. But Martin since you feel more strongly about it feel free to bring it forth for approval. By contrast, bug #230242 is just downright confusing and its easy to misinterpret the behaviour as a system failure. Assuming we can implement it, how the following description texts looks like? => Windows Integration: The provider uses Windows APIs to encrypt randomly generated 'master' password in a way specific to the login credentials. Users who can log into the Windows account can access contents of the secure storage. => Mac Integration: The provider uses operating system's keyring to store randomly generated user-specific 'master' password. Users who can log into the operating system account can access contents of the secure storage. => UI Prompt: The provider brings up secure storage login dialog for the user to input the 'master' password. (In reply to comment #7) The first two look good. They explain how the information in encrypted (so you how much you can trust it, where the stuff goes) and how you are exposed. Some comments. Minor grammar fixes are marked *: => Windows Integration: - should read "encrypt *a* randomly generate" => Mac Integration: - should read "The provider uses *the* operating system's" - should read "to store *a* randomly generated" => UI Prompt: - should read "brings up *a* secure storage" - the part that's missing for me is understanding where the master password is stored, and how it's stored (can someone read it off somehow? If I delete my workspace is it gone too?) Great, thank you! I must have slept through few English classes :-). Ver.2: Grammar corrected as suggested, sentence added to UI prompt. => Windows Integration: The provider uses Windows APIs to encrypt a randomly generated 'master' password in a way specific to the login credentials. Users who can log into the Windows account can access contents of the secure storage. => Mac Integration: The provider uses the operating system's keyring to store a randomly generated user-specific 'master' password. Users who can log into the operating system account can access contents of the secure storage. => UI Prompt: The provider brings up a secure storage login dialog for the user to input the 'master' password. This provider does not persist 'master' password in any way but relies on the user to input it. These look good, very clear, +1 We should put these strings in today for NLS deadline. If we get approval for the API change then great we reference them, if not then the strings are there already for 3.5. Marking as duplicate as the change was done as a part of the bug 230242. *** This bug has been marked as a duplicate of bug 230242 *** |