| Silent failure of HTTPS authentication in Eclipse Installer [message #1842164] |
Thu, 10 June 2021 16:26  |
 Elie Richa
Messages: 72
Registered: February 2016 |
Member |
|
|
Hello folks,
I'm using a product definition setup stored on a server that requires authentication. The same server also provides P2 repositories also with authentication.
The Eclipse Installer correctly prompts the User for credentials, but on Linux, using the option to save the password for future use is creating issues sometimes.
Here's the scenario, with Eclipse Installer version 1.21.0:
1. The installer prompts for my credentials (supposedly to update the product setup)
2. I enter correct credentials and ask to save them in the secure storage
3. The installer prompts for credentials again immediately.
4. I enter them correctly again and ask again to save them in the secure storage.
5. The installer is now happy, but I am not sure it managed to update the setup. It could be using a local cached version.
5. I proceed with the installation.
6. Later during the execution of P2 Director, the installer complains of not being able to access the P2 repository that requires authentication and offers to use an outdated cache.
7. Refusing the cached version stops the installation. The only choice is to accept to continue with an outdated P2 cache + a potentially outdate Oomph setup in the first place.
Looking at the installer log, I find the following exception that goes unnoticed:
!ENTRY org.eclipse.oomph.setup.core 4 0 2021-06-09 09:34:27.886
!MESSAGE Unable to locate secure storage module (org.eclipse.equinox.security.linuxkeystoreintegration).
!STACK 0
org.eclipse.equinox.security.storage.StorageException: Unable to locate secure storage module (org.eclipse.equinox.security.linuxkeystoreintegration).
at org.eclipse.equinox.internal.security.storage.PasswordProviderSelector.findStorageModule(PasswordProviderSelector.java:199)
at org.eclipse.equinox.internal.security.storage.SecurePreferencesRoot.getModulePassword(SecurePreferencesRoot.java:237)
at org.eclipse.equinox.internal.security.storage.SecurePreferencesRoot.getPassword(SecurePreferencesRoot.java:230)
at org.eclipse.equinox.internal.security.storage.SecurePreferences.get(SecurePreferences.java:267)
at org.eclipse.equinox.internal.security.storage.SecurePreferencesWrapper.get(SecurePreferencesWrapper.java:123)
at org.eclipse.oomph.preferences.util.PreferencesUtil$AutoRefreshSecurePreferencesWrapper.get(PreferencesUtil.java:590)
at org.eclipse.oomph.setup.internal.core.util.ECFURIHandlerImpl$AuthorizationHandlerImpl.authorize(ECFURIHandlerImpl.java:737)
at org.eclipse.oomph.setup.internal.core.util.ECFURIHandlerImpl$AuthorizationHandlerImpl.reauthorize(ECFURIHandlerImpl.java:765)
at org.eclipse.oomph.setup.internal.core.util.ECFURIHandlerImpl$ConnectionHandler.process(ECFURIHandlerImpl.java:1763)
at org.eclipse.oomph.setup.internal.core.util.ECFURIHandlerImpl.createInputStream(ECFURIHandlerImpl.java:323)
at org.eclipse.emf.ecore.resource.impl.ExtensibleURIConverterImpl.createInputStream(ExtensibleURIConverterImpl.java:358)
at org.eclipse.oomph.setup.internal.core.util.ECFURIHandlerImpl$ETagMirror$Worker.perform(ECFURIHandlerImpl.java:1361)
at org.eclipse.oomph.util.WorkerPool$Worker.run(WorkerPool.java:434)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
The same scenario occurs sometimes with "Perform Setup Tasks" in Eclipse, but I can't find an exception anywhere.
Deleting ~/.eclipse/org.eclipse.equinox.security/secure_storage seems to solve the issue. But it always comes back a few weeks later and I can't pinpoint why yet.
I found two potentially relevant reports on Bugzilla:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=527772
https://bugs.eclipse.org/bugs/show_bug.cgi?id=537833
One mentions a conflict between 32bit and 64bit Eclipse versions, but that's not the case here. While multiple Eclipse versions exist, they are all 64bit versions.
I suspected it was happening when using different Eclipse versions, but one of the above Bugzillas confirms that the secure_storage format is stable and should happily serve different Eclipse versions.
Any ideas of what I could try out the next time this occurs?
And could the installer and setup executioner be improved to make authentication failures more visible instead of continuing somewhat silently?
Thanks!
Elie Richa, Ph.D
Software Engineer, AdaCore
https://www.adacore.com
|
|
|
| Re: Silent failure of HTTPS authentication in Eclipse Installer [message #1842183 is a reply to message #1842164] |
Fri, 11 June 2021 05:53  |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
It would be good to learn the underlying cause. but I don't work regularly on Linux and have never see this type of problem. Once this problem occurs it would certainly be good to try to debug it at that point like I did with the 32/64 bit stuff. But as you can see, it's hard to get the correct people involved because all this stuff is free and no one feels it's their duty to work on such hard problems for free...
The implementation is intentionally such that a failed authentication will fall back to using a cached version but I suppose that could be changed. A failure to load a setup in the installer would generally end up prompting you for changing your network proxy settings so that would need some more attention. You can see that the loading is done on many threads so collecting the different failures from the different threads would also need attention. It's not entirely trivial...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.02878 seconds
] 
Search
Help
Register
Login
Home
