Mention keyring package in Wrapping APIs vignette?

[maelle]

More precisely, should this workflow be added to that vignette: In an API package doc, recommend the user store their API key with keyring and retrieve it with Sys.getenv(API_KEY=keyring::key_get("API-NAME")?

[hadley]

What’s the advantage of doing that that you’re thinking of?

[maelle]

Storing the secrets in the OS' credentials store is supposed to be safer than storing them in .Renviron.

[asadow]

I too noticed keyring is not in the httr2 docs, whereas httr has this vignette: Managing secrets.

Interested in this discussion as e.g. qualtRics wraps an API and depends on the user having secrets stored in .Renviron.

[hadley]

Hmmm, I guess since I wrote that httr vignette I'm no longer sure that the keyring is that much more secure. I think it's theoretically more secure, but in practice it's unlikely to make much difference because for an attacker to have access to your .Renviron then that implies they have access to your computer, and are thus can already access your OS keychain.

OTOH maybe people are using project specific .Renviron files which are much more dangerous because they're more likely to end up accidentally committed into git?

[maelle]

Right, maybe it just feels more secure but your point about git seems important.

More niche and less important:

• I like that the OS keychain really feels more different from writing a secret in a script (compared to .Renviron vs secret in script, in both cases you write things in clear in a file which seems to be a bad habit like having a docx with all your passwords).
• I know screen-sharing Renviron by mistake is not a big risk but I also like that this couldn't happen with the OS keychain.

[hadley]

Hmmmm, this all feels like it should maybe be a separate vignette that's env vars vs keychain, but then httr2 doesn't feel like quite the right place for it. Maybe it would be better as a keyring vignette?

[maelle]

but how would httr2 users even think of reading keyring docs, could there be a pointer, even small? :slightly_smiling_face:

[hadley]

Right, we'd point to it everywhere we mention env vars.

[hadley]

I updated the keyring readme: https://keyring.r-lib.org/dev/. Do you think that's sufficient for selling it as an alternative to env vars or do I need to write more?

[maelle]

Nice, thank you! I added comments in https://github.com/r-lib/keyring/pull/139 :smile_cat:

[hadley]

I think this requires more than just a change to the docs: for it to be a useful (and meaningfully more secure workflow), secret_encrypt() and friends need to know to look in the keychain. I think that's probably still worth doing, but I won't get to it in this release.

[hadley]

See notes in related PR; need more work in keyring until we can enable this automatically.

[arnaudgallou]

Just to add to the previous points that have been made. Using a keyring is more secure when backing up data on an external hard drive because credentials should still be password protected as opposed to a file like .Renviron that will be accessible by anyone who has the hard drive (unless you explicitly protect the hard drive or .Renviron with a password).

[hadley]

@arnaudgallou I'm not sure that's a compelling argument — if you're worried about the physical security of the hard drive, you should be encrypting the whole thing.

[arnaudgallou]

I agree that's what you should do in practice but for an average user like me who only has a couple of API keys to secure and regularly back up my computer, the simplicity and convenience of keyring is appealing. I wouldn't use keyring for that purpose only but it's a little plus to me.