Eclipse Community Forums: Oomph » MacOS Secure Storage keychain Name change

Help

Home

Home » Eclipse Projects » Oomph » MacOS Secure Storage keychain Name change

Show: Today's Messages :: Show Polls :: Message Navigator

MacOS Secure Storage keychain Name change [message #1857571]

Wed, 15 February 2023 14:47

Mark Lawrence

Messages: 28
Registered: February 2023

Junior Member

Not necessarily an oomph thing, apologies, but I've created a new Oomph Product/Project combo for my team for an Eclipse Instance to live alongside existing Eclipse installations they currently have.

I'm getting an issue on MacOS. The customised Installers I've created have an issue accessing any existing master password in the MacOS keychain, probably because they are unsigned etc. So I am recommending team members delete their existing secure_storage file as well as any equinox.secure.storage entry in keychain. As part of the Eclipse Installer steps, the passwords are entered as variables, and a new master password & secure storage is created.

This works great and their new IDE works perfectly with passwords remembered etc. However, existing IDEs are then broken trying to access the secure storage. They show a 'No password provided' popup, and its impossible to get it to store any passwords without deleting the secure_storage file and letting it recreate, and then the behaviour switches and new IDE shows the 'No password provided' popup.

So I've tried specifying a new new secure_storage file using eclipse.keyring in the eclipse.ini for the new oomph'ed IDE, however the problem still remains, it seems the old IDE lays claim to the equinox.secure.storage entry in the keychain & will change the password on creating the secure_storage file, blocking access for the other IDE.

Is there any way around this? Is it possible to influence the name used in the keychain entry so each installation can have its own master password, rather than they all use 'equinox.secure.storage'?
I've seen I could provide a password file for the secure storage, but I think that might be an insecure way of protecting passwords? Plus I don't really want to ask the team to create this file as part of their installation steps

[Updated on: Wed, 15 February 2023 15:46]

Report message to a moderator

Re: MacOS Secure Storage keychain Name change [message #1857574 is a reply to message #1857571]

Wed, 15 February 2023 16:35

Mark Lawrence

Messages: 28
Registered: February 2023

Junior Member

I almost thought I had a workaround for this, by letting oomph create the keychain master password and secure storage file, with the key being to set up the hint for later use. Then when using the old IDE again and receiving the 'No Password provided' error, to go into the secure storage preferences, then recovering the master password with the hint answers.

This does work briefly, the old IDE accesses the secure storage and can read the passwords and everything works, however, the recovered master password does not appear to be remembered. If I close down the older IDE and re-open, it cannot read the storage again & I would have to re-run the recovery.

So I'm still stuck with this.

[Updated on: Wed, 15 February 2023 16:37]

Report message to a moderator

Re: MacOS Secure Storage keychain Name change [message #1857578 is a reply to message #1857574]

Wed, 15 February 2023 17:45

Ed Merks

Messages: 33145
Registered: July 2009

Senior Member

I don't have a mac, just a really old virtual box that probably doesn't work well anymore. So I'm not sure how I can help. :-(

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: MacOS Secure Storage keychain Name change [message #1857602 is a reply to message #1857578]

Thu, 16 February 2023 15:01

Mark Lawrence

Messages: 28
Registered: February 2023

Junior Member

So I think the issue is Oomph is installing everything inside the Eclipse.app bundle. I'm doing a codesign on it to regenerate the signature before first launch, however I can see the signature is immediately broken on loading the instance due to a large number of files being added in the Eclipse.app/Contents/Eclipse/configuration directory.
App notarization has been hardened in Ventura, so I think something is going on under the hood which causes the keychain & secure storage not to play well with each other as soon as the signature is broken.
Is there a way to get Oomph to use a custom 'configuration' directory outside of the Eclipse.app bundle in-order for the contents of the bundle to not change? I've tried adding -configuration to the Eclipse ini, but that only really starts working after the install.

Report message to a moderator