Community
Participate
Working Groups
I20080502-0100 - observed on 64-bit gtk - open the CVS Repositories view, create a connection to dev.eclipse.org with option "Save password" checked, press Finish - when the Secure Storage Dialog (#1) comes up press Cancel - when the Secure Storage Dialog (#2) comes up press Cancel - re-enter your cvs password and do not check "Save password" this time - in the CVS Repositories view expand the dev.eclipse.org tree and its HEAD item - when the Secure Storage Dialog (#3) comes up press Cancel - when the Secure Storage Dialog (#4) comes up press Cancel - select any project in HEAD, right-click -> Check out - when the Secure Storage Dialog (#5) comes up press Cancel - the project is retrieved It seems like only showing this dialog once when attempting to save the password would make sense. Failing to supply the secure store password five times did not actually stop me from doing anything, it was just disruptive.
Unable to duplicate with I20080510-2000 (admittedly, on Windows with OS integration provider disabled, not on Linux). Could you try again with a recent build?
I still see this with the I20080513-2000 build. Ping me if you want to investigate on our 64-bit machine.
Observing Grant do it, the scenario is: - disable OS integration module if it is present for the OS - create a CVS connection with a valid password, save password - [secure storage password might be setup here] - delete CVS connection - restart - enter again the CVS connection with the correct password, save password - when secure storage login dialog comes up, press cancel - a number of prompts for secure storage password will come up as user tries to expand Head and check out bundles The key to this is that saving of the CVS password in the secure storage gets cancelled from the secure storage login dialog.
Created attachment 101346 [details] Sample patch - just an illustration The sample patch makes CVS aware that caching password can fail. The change in this sample is small and it fixes the scenario described in this bug, but I have a feeling that there are other similar scenarious that might have excessive login prompts.
(In reply to comment #3) > - a number of prompts for secure storage password will come up as user tries to > expand Head and check out bundles If I understood it correctly the dialog asking the user to input the 'master' password shows up every time we try to access Secure Storage (either to read or write password), right? I wasn't able to see them coming up while working with the Repo view itself, however after I clicked Finished and before the page closed I saw the Secure Storage dialog couple of times. This is because we try to validate the connection using cached credentials, which in fact are not there (canceled SS dialog). The funniest thing is that when we finally manage to get through validation and close the "Add CVS Repo" dialog (without using SS), the connection will appear in the Repo view and it will work fine, basing on password provided in the "Add Repo" dialog (just for this session). The other thing I noticed is that SS dialog pops up even though I didn't check "Save pass" option: 1. Create new CVS location with username and password 2. Uncheck "Save password" option 3. Right click on the location in the Repo view => SS dialog comes up Moreover I noticed is that every time the user cancels the SS dialog an error is logged. The code says that the exception should be logged every time an attempt of reading password ends up with "(...) invalid keyring or corrupted data". Does the "invalid keyring" covers also cases when the user canceled the dialog on purpose? I'm not sure if any error should be logged then. And here is another scenario: bug 232982. As Oleg said, this is only the tip of the iceberg. The patch he provided works for this scenario but I would rather keep the dialogs popping up (at this moment, so the user would know that something is wrong) and look for a more complex solution.
(In reply to comment #5) Fixing this doesn't seem to be a good move at this time. I think we should leave it as it is, since the annoying dialog is better than a regression which can be accidentally caused.
I'm moving it to 3.6, however I will spend some time trying to fix it for 3.5.
Grant, recently bug 288587 was fixed in this area. Is the problem you describe still an issue?
I'm not sure, we no longer have the machine that was showing this problem. I've tried the comment 0 steps on an equivalent 64-bit RHEL4 install and I don't see the problem, but I also don't see the problem with 3.6M5, which would not include the fix for bug 288587. So this report can probably be closed.
