-
Notifications
You must be signed in to change notification settings - Fork 16.4k
Description
Preflight Checklist
- I have read the Contributing Guidelines for this project.
- I agree to follow the Code of Conduct that this project adheres to.
- I have searched the issue tracker for a bug report that matches the one I want to file, without success.
Electron Version
34.0.1
What operating system(s) are you using?
macOS
Operating System Version
Sequoia 15.2
What arch are you using?
arm64 (including Apple Silicon)
Last Known Working Electron version
No response
Expected Behavior
safeStorage.isEncryptionAvailable()
should create a Keychain Access entry named {app.name} Safe Storage
.
Actual Behavior
A Keychain Access entry named Chromium Safe Storage
is created instead.
Testcase Gist URL
https://gist.github.com/erikian/a8a354ee5cfa6e090653a2bbbfb2adb9
Additional Information
The main side-effect is a password prompt suggesting that the app is trying to access data from Chromium:
I did some testing and the prompt doesn't seem to be shown for code-signed apps (at least on TestFlight), but the production app still uses Chromium Safe Storage
and it doesn't sound like a good idea to allow our app's encrypted data to be saved under another app's name (especially Chromium).
A bunch of Electron apps like Figma and VS Code have a properly named entry in Keychain Access, so I'd expect to see one with my app's name (or at least Electron
) when debugging safeStorage
issues; it should not be possible to have different names depending on what point of the app's lifecycle the entry is created (if I move the safeStorage.isEncryptionAvailable()
call from the top-level to the app.whenReady
callback in my demo, the correct name is used).
The existing documentation doesn't list any caveats for calling safeStorage.isEncryptionAvailable()
before the app is ready on macOS, so the docs needs to be updated if the naming issue is not something that can be fixed.