Bugzilla – Full Text Bug Listing
| Summary: | Unable to locate secure storage module error in newly installed Oxygen | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Hernan Gonzalez <hjg.com.ar> |
| Component: | Security | Assignee: | Security Inbox <equinox.security-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | akurtakov, andy_2639, Ed.Merks, hjg.com.ar, tjwatson |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | stalebug | ||
|
Description
Hernan Gonzalez
Problem also present with latest Oxygen 3a (4.7.3a) Also: I use Eclipse for RCP coding, and the error also appears when I "launch Eclipse application" from my *.product view. I've checked that the relevant org.eclipse.equinox.security.* ( org.eclipse.equinox.security.win32.x86_64 ) is included in the dependencies. Does the file <home>/.eclipse/org.eclipse.equinox.security/secure_storage exist in the file system? If it does exist, perhaps it's corrupt in some way and you could rename/remove it so that a new version is created. Thanks for the answer. Yes, after removing the secure_storage file the error was gone. Actually, the file was not regenerated (I wonder which action could I do to trigger its creation?) Could it be that a secure_storage generated by some Eclipse installation is incompatible with another Eclipse in the same machine-user? I was practically unaware of the existence <home>/.eclipse/ directory and now I'm worried: does this mechanism works well if I'm running several different Eclipse instances (32 and 64 bits) in the same machine? Shouldn't we rather have something like <home>/.eclipse/<eclipse instance id>/ ? And how does this works with a RCP product? I could post my secure_storage file if this helps. (In reply to Hernan Gonzalez from comment #3) > Thanks for the answer. > Yes, after removing the secure_storage file the error was gone. > That was my suspicion, i.e., that it can't read the file but doesn't explicitly log that as the failure. > Actually, the file was not regenerated (I wonder which action could I do to > trigger its creation?) > It will only be generated if you're actually prompted for a password and you provide one and you choose to save it in secure storage. Note there is a preference Under General -> Security -> Secure Storage. > Could it be that a secure_storage generated by some Eclipse installation is > incompatible with another Eclipse in the same machine-user? > No that's not likely. This representation is highly stable and has been around for a very long time. > I was practically unaware of the existence <home>/.eclipse/ directory and > now I'm worried: does this mechanism works well if I'm running several > different Eclipse instances (32 and 64 bits) in the same machine? It's a good question about 32/64 bit. I can't really answer that. Someone with deeper technical knowledge would need to answer that. The only problem with several Eclipse instances at the same time is that one might overwrite the passwords already stored by another application. There's generally a popup dialog when that would happen. It's kind of annoying. > Shouldn't we rather have something like <home>/.eclipse/<eclipse instance > id>/ ? > No, because then you'd need to provide the password again for every installation you ever create. If you only have one or two, that wouldn't be a big deal, but I'm working on Oomph and I have literally hundreds... > And how does this works with a RCP product? > The same way. > I could post my secure_storage file if this helps. No, sharing files containing passwords is not a good idea. Yes, I could trigger the creation of a secure_storage file from a Eclipse 4.5.2 (32 bits) instance (recipe: go to Windows->Preferences->Network connections and set Active Provider Manual and create some HTTP proxy entry with password) I closed that Eclipse and open my new Eclipse (4.7.3a, 64 bits) and the "org.eclipse.equinox.security.storage.StorageException: Unable to locate secure storage module" is thrown. So, it seems that the <home>/.eclipse/ mechanism is not robust in regard to several Eclipse instances running in the same machine/user (at least for this secure_storage file). (In reply to Hernan Gonzalez from comment #5) > Yes, I could trigger the creation of a secure_storage file from a Eclipse > 4.5.2 (32 bits) instance (recipe: go to Windows->Preferences->Network > connections and set Active Provider Manual and create some HTTP proxy entry > with password) > > I closed that Eclipse and open my new Eclipse (4.7.3a, 64 bits) and the > "org.eclipse.equinox.security.storage.StorageException: Unable to locate > secure storage module" is thrown. > > So, it seems that the <home>/.eclipse/ mechanism is not robust in regard to > several Eclipse instances running in the same machine/user (at least for > this secure_storage file). I think this conclusion is too general. I.e., I do this (run multiple Eclipse instances) all the time without a problem (other than overwriting of the secure storage), but I don't run both 32 bit applications and 64 bit applications. If you do things in the reverse order, i.e., run the 64 bit application first, saving a password, does the 32 bit application then manifest the problem with not being able to use the secure storage. Certainly if the format of the file is affected by the bitness of the application, there should be one file per bitness...
Here the secure_storage files generated with Eclipse 32/64 bits, with sensitive information masked with ***
32 bits:
org.eclipse.equinox.security.preferences.version=1
org.eclipse.equinox.security.preferences.cipher=PBEWithMD5AndDES
org.eclipse.equinox.security.preferences.keyFactory=PBEWithMD5AndDES
/org.eclipse.equinox.secure.storage/windows/encryptedPassword=\t,***
/org.eclipse.equinox.secure.storage/verification/org.eclipse.equinox.security.windowspasswordprovider=org.eclipse.equinox.security.windowspasswordprovider\t***
/org.eclipse.core.net.proxy.auth/HTTP/user=org.eclipse.equinox.security.windowspasswordprovider\t***
/org.eclipse.core.net.proxy.auth/HTTP/pass=org.eclipse.equinox.security.windowspasswordprovider\t***
64 bits:
org.eclipse.equinox.security.preferences.version=1
org.eclipse.equinox.security.preferences.cipher=PBEWithMD5AndDES
org.eclipse.equinox.security.preferences.keyFactory=PBEWithMD5AndDES
/org.eclipse.equinox.secure.storage/windows64/encryptedPassword=\t***
/org.eclipse.equinox.secure.storage/verification/org.eclipse.equinox.security.windowspasswordprovider64bit=org.eclipse.equinox.security.windowspasswordprovider64bit\t***
/org.eclipse.core.net.proxy.auth/HTTP/user=org.eclipse.equinox.security.windowspasswordprovider64bit\t***
/org.eclipse.core.net.proxy.auth/HTTP/pass=org.eclipse.equinox.security.windowspasswordprovider64bit\t***
It seems quite clear that they are incompatible, each one specifies a concrete (32/64 bits) provider, and when it's not found an exception is thrown.
> I think this conclusion is too general.
Yes, I agree with that.
I'll try to move this to Equinox. As far as being a properties file, it should be possible for both bitness versions to coexist in that file. If you manually copied the two lines (hard to see with the wrapping): /org.eclipse.equinox.secure.storage/verification/org.eclipse.equinox.security.windowspasswordprovider64bit=... /org.eclipse.equinox.secure.storage/windows64/encryptedPassword=... from the 64 bit file to the 32 bit file (or vice versa) the two lines from the 32 bit to the 64 bit: /org.eclipse.equinox.secure.storage/verification/org.eclipse.equinox.security.windowspasswordprovider=... /org.eclipse.equinox.secure.storage/windows/encryptedPassword=... Does that fix the problem in both bitness applications? I.e., if Equinox's security framework properly created the provider would that actually fix the problem. The Equinox team will need to comment on this problem because they are the experts... > As far as being a properties file, it should be possible for both bitness versions to coexist in that file.
I guess so. But I also guess that, once your (say) Eclipse 64b has written the property
/org.eclipse.core.net.proxy.auth/HTTP/user=org.eclipse.equinox.security.windowspasswordprovider64bit\t***
... then, even if you have both (32/64) entries defined
/org.eclipse.equinox.secure.storage/verification/org.eclipse.equinox.security.windowspasswordprovider64bit=...
/org.eclipse.equinox.secure.storage/windows64/encryptedPassword=...
/org.eclipse.equinox.secure.storage/verification/org.eclipse.equinox.security.windowspasswordprovider=...
... still you'll have the problem when you open with Eclipse 32b, because it will try to locate the org.eclipse.equinox.security.windowspasswordprovider64bit and that plugin will not exist.
At most, a warning should be emitted, I think, but not an exception (several, actually).
It would be great if you could try it, then we would not need to guess or speculate about what would and wouldn't work and about what problems it might introduce. The implementation might be such that the fragment looks for its own properties, not that all properties are considered up front, so this might be a suitable workaround for the time being... Hopefully someone from the Equinox team will add some insight. Yes, the results are these: My secure_storage (*** is a mask, OEE = org.eclipse.equinox , line numbers prepended ) 1 OEE.security.preferences.version=1 2 OEE.security.preferences.cipher=PBEWithMD5AndDES 3 OEE.security.preferences.keyFactory=PBEWithMD5AndDES 4 /OEE.secure.storage/windows/encryptedPassword=\t*** 5 /OEE.secure.storage/windows64/encryptedPassword=\t*** 6 /OEE.secure.storage/verification/OEE.security.windowspasswordprovider=OEE.security.windowspasswordprovider\t*** 7 /OEE.secure.storage/verification/OEE.security.windowspasswordprovider64bit=OEE.security.windowspasswordprovider64bit\t*** 8 #/org.eclipse.core.net.proxy.auth/HTTP/user=OEE.security.windowspasswordprovider\t*** 9 #/org.eclipse.core.net.proxy.auth/HTTP/pass=OEE.security.windowspasswordprovider\t*** 10 /org.eclipse.core.net.proxy.auth/HTTP/user=OEE.security.windowspasswordprovider64bit\t*** 11 /org.eclipse.core.net.proxy.auth/HTTP/pass=OEE.security.windowspasswordprovider64bit\t*** In this configuration it opens ok in Eclipse 64b, it throws Exception in Eclipse 32b. Viceversa if I comment 10,11 and uncomment 8,9. No errors if I comment 8,9,10,11. Thanks for the detailed analysis. I think it's fair to conclude from this that a single password file for 64 bit and 32 bit applications just don't work, at least not currently. Either the framework should use two bitness-specific files, or it should tolerate the union of the two sets of properties... I'm starting to wonder if anyone monitors this inbox. Some sign of life would be awfully nice. (In reply to Ed Merks from comment #14) > I'm starting to wonder if anyone monitors this inbox. Some sign of life > would be awfully nice. Hmmm, I see this message now, but didn't see all the past ones. Sorry. I am not an expert in this code so cannot immediately comment on why it is behaving this way. Seems like someone should have a closer look and fix this ... contributions welcome. I guess there are not experts left, right? Maybe I'll have some time to look at this after Photon is out the door, but it's not a big problem for me personally of course (and p2 has many more problems that could use attention and would have bigger impact for more users). Is anyone looking into this or target should be removed? I haven't the time and likely won't for quite a while. Removed target platform as per previous comment. https://bugs.eclipse.org/bugs/show_bug.cgi?id=355086 also has the problem of incompatible password providers for 32/64 bit Windows. In https://bugs.eclipse.org/bugs/show_bug.cgi?id=355086#c6 I describe that this seems to be a bit artificial because actually the stored data is compatible but just the different naming of the password providers causes the problem. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |