Skip to content

safeStorage.isEncryptionAvailable() doesn't respect app.name when called before the app is ready on macOS #45328

@erikian

Description

@erikian

Preflight Checklist

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:

Image

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.

Metadata

Metadata

Labels

Type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions