feat: add secure-storage / keychain plugin

[FabianLars]

Yet another keychain tauri plugin? 😮‍💨 Yep yep, mainly because it serves as the replacement for stronghold and i thought it may be reasonable to hold our hands over this (more so than the non secure store plugin imo) and the other plugins all seem kindaaa dead (or maybe not since they just as slim as this one)

I probably won't merge this until keyring v4 is released or getting closer to a release at least.

About the implementation there are only 2 things i think are worth to discuss:

1. The plugin name. keychain and keyring or whatever were already taken and i thought that maybe people don't know what that mean so i went with a mix of expo's secureStore and electron's safeStorage but very open for suggestions.
2. api naming: keyring uses secret and password and i used binary and string. i don't like either tbh but i didn't look into all of keyring's backends to see why they chose that naming scheme.
3. linux backend: for this poc i went with keyutils without persistence (== reset on reboot). the last (yanked) keyring v4 rc version used sync-secret-service as the default but i don't like that it links to c libs (dbus). Since this is linux i couldn't be bothered to look into it that much at this point.

Also i think in the future it would be cool to have something built-in that encrypts the secrets before giving them to keyring so that on Windows they aren't stored as plain text for everyone to read. Of course that wouldn't really be secure but better than nothing.

[github-actions]

Package Changes Through 403f54b

There are 12 changes which include deep-link with patch, deep-link-js with patch, stronghold with patch, stronghold-js with patch, fs with patch, fs-js with patch, geolocation with patch, geolocation-js with patch, opener with patch, opener-js with patch, updater with minor, updater-js with minor

Planned Package Versions

The following package releases are the planned based on the context of changes in this pull request.

package	current	next
api-example	2.0.36	2.0.37
api-example-js	2.0.32	2.0.33
deep-link-example-js	2.2.6	2.2.7
deep-link	2.4.3	2.4.4
deep-link-js	2.4.3	2.4.4
fs	2.4.2	2.4.3
fs-js	2.4.2	2.4.3
dialog	2.4.0	2.4.1
dialog-js	2.4.0	2.4.1
geolocation	2.3.0	2.3.1
geolocation-js	2.3.0	2.3.1
opener	2.5.0	2.5.1
opener-js	2.5.0	2.5.1
http	2.5.2	2.5.3
http-js	2.5.2	2.5.3
persisted-scope	2.3.2	2.3.3
single-instance	2.3.4	2.3.5
stronghold	2.3.0	2.3.1
stronghold-js	2.3.0	2.3.1
updater	2.9.0	2.10.0
updater-js	2.9.0	2.10.0

Add another change file through the GitHub UI by following this link.

---

Read about change files or the docs at github.com/jbolda/covector

[FabianLars]

oh man that edition shit is annoying in a workspace for ci

[Ludea]

awesome idea to replace stronghold !

Some answer:
1 - SecureStorage is a good name. Simple and easy to understand what is the purpuoe of the plugin
2 - binary name can be confusing. WDYT aabout string and data ?
3 - if persistence is enable for Macos and Windows, it seems logical to enable it for linux too. If you don't like c api, maybe there is a pure rust lib to do the same thing ?

[xty]

1. The plugin name. keychain and keyring or whatever were already taken and i thought that maybe people don't know what that mean so i went with a mix of expo's secureStore and electron's safeStorage but very open for suggestions.

Calling it Secure Storage is about as good as secureStore, but we can do better – security has many facets (e.g. confidentiality, integrity, availability), so Secure Storage can be interpreted in different ways while this plugin focuses on confidentiality. It doesn't, for example, guard against data corruption. Therefore, I would propose going with Secret Storage or Secret Store instead in order to be more precise.

2. api naming: keyring uses secret and password and i used binary and string. i don't like either tbh but i didn't look into all of keyring's backends to see why they chose that naming scheme.

I know where you're coming from. "bytes" over "binary", perhaps? This should feel straightforward to Rust and JavaScript programmers alike.

3. linux backend: for this poc i went with keyutils without persistence (== reset on reboot). the last (yanked) keyring v4 rc version used sync-secret-service as the default but i don't like that it links to c libs (dbus). Since this is linux i couldn't be bothered to look into it that much at this point.

I agree with the previous commenter in stressing the need for consistency, but as a POC I'll let you get away without persistence. 😉 Despite the many challenges, please don't make GNU/Linux a second-tier platform.

[FabianLars]

Therefore, I would propose going with Secret Storage or Secret Store instead in order to be more precise.

That makes so much sense!! I'll still include the other name(s) as an alias somewhere for SEO reasons though.

I know where you're coming from. "bytes" over "binary", perhaps? This should feel straightforward to Rust and JavaScript programmers alike.

In hindsight so obvious...

3 - if persistence is enable for Macos and Windows, it seems logical to enable it for linux too. If you don't like c api, maybe there is a pure rust lib to do the same thing ?

I agree with the previous commenter in stressing the need for consistency, but as a POC I'll let you get away without persistence. 😉 Despite the many challenges, please don't make GNU/Linux a second-tier platform.

That goes against my nature of a professional Linux hater though :(
Anyway, seems like the keyring crates are now ready-ish so i'll take a proper look at the backends to see which one makes the most sense for us.

---

Thank you both for the valuable feedback!

[FabianLars]

what about just tauri-plugin-secrets ? I can't decide between Store and Storage so i thought maybe neither? 😂
If we indeed end up adding something like electron's safeStorage apis (which are about encrypting/decrypting and not about storing data directly) that may also make more sense.

Why is naming stuff so hard 😮‍💨

[xty]

what about just tauri-plugin-secrets ? I can't decide between Store and Storage so i thought maybe neither? 😂

If you're not entirely happy with either, despite the alliteration, consider a third option: Secret Vault. 😂

1. "secret" goes well with "vault" – I even checked the Oxford Collocations Dictionary.
2. The term "vault" is used by password managers like Bitwarden and 1Password, as well as by HashiCorp. It should definitely evoke the right imagery.

If we indeed end up adding something like electron's safeStorage apis (which are about encrypting/decrypting and not about storing data directly) that may also make more sense.

tauri-plugin-secrets works too, but only if you want de-emphasize the storage aspect. If I'm not mistaken, the user would be mostly interested in storing their sensitive data somewhere – whether that capability is provided by the plugin per se, from their perspective, is only an implementation detail.

[FabianLars]

tauri-plugin-secrets works too, but only if you want de-emphasize the storage aspect.

I kindaaa wanted to do the opposite. secret-store etc to me (as a non native speaker) sounds more like the store itself is secret and not that it's a store for secrets. maybe secrets-store with an extra s improves that better than dropping the second word idk

[xty]

I kindaaa wanted to do the opposite. secret-store etc to me (as a non native speaker) sounds more like the store itself is secret and not that it's a store for secrets. maybe secrets-store with an extra s improves that better than dropping the second word idk

Why not ask a large language model? They may not excel at programming but are best at answering language questions. 😂

Honestly, Secret Vault, Secret Store, Secrets, Secrets Store are all probably fine. If you really can't decide, create a poll in GitHub Discussions.